מפצחים את המדיניות של Play – מפגש שאלות ותשובות

טוב.

תודה לכולם שהצטרפתם אלינו לפאנל הזה בנושא פענוח המדיניות של Google Play.

אני יאן קליינרט, מהנדס קשרי מפתחים בצוות Android לרכבים.

אני אהיה המנחה של הפאנל היום.

אני מעביר את רשות הדיבור לחברי הפאנל שלנו, בוגדן ופול, כדי שיציגו את עצמם.

ובוהדן, נתחיל איתך.

שלום לכולם,

אני בוגדן, ואני עובד בצוות המהימנות והבטיחות של Google Play.

אני עובדת כאן כבר יותר מ-4 שנים, ובתחום האמינות והבטיחות בטכנולוגיה כבר יותר מעשור.

אני אוהב לראות איך הטכנולוגיה, התעשייה והתרבות משתלבות, ואיך אירועים מעודדים פיתוח של אפליקציות חדשות. אני אוהב אירועים כאלה שבהם אנחנו יכולים לעשות כמיטב יכולתנו כדי לעזור למפתחים כמוכם להצליח.

שלום לכולם,

קוראים לי פול.

אני עובד באותו צוות כמו בוגדן, ואני עוסק בתחום המהימנות והבטיחות בערך באותו פרק זמן כמו בוגדן, כבר עשור, ורוב הזמן הזה בצוות המהימנות והבטיחות של Google Play.

אז אני מאוד שמח להיות כאן על הבמה היום, ובואו נתחיל.

בסדר, תודה.

אז כדי להכין את הקרקע לפני שנתחיל את הפאנל, אני אחזיר את רשות הדיבור לפול.

הוא יתחיל בסקירה קצרה של מקורות המידע בנושא מדיניות, מידע על שיטות מומלצות ודברים כאלה, כדי לעזור לכם להכין את האפליקציה לבדיקת עמידה במדיניות חלקה ויעילה יותר.

כן.‏

אז מה זה בעצם אומר, מדיניות Play?

אלה הכללים הבסיסיים שמפתחים חייבים לפעול לפיהם כשהם מפרסמים ומתחזקים אפליקציות לנייד בחנות Google Play.

הוספנו כמה קישורים קצרים על המסך למשאבים של מדיניות Play.

הקישור הראשון מוביל למרכז המדיניות למפתחים.

אם תלחצו על "עדכונים אחרונים" בחלק העליון של הדף, תוכלו לקרוא פרטים על כללי מדיניות חדשים, וגם עדכונים או הבהרות לגבי כללי מדיניות קיימים.

אם אתם מעדיפים ללמוד באמצעות סרטונים או אודיו, הקישור הקצר השני יוביל אתכם לפלייליסט של סרטוני Policy Bytes.

אלה סרטונים שבהם אנחנו מסבירים על עדכוני המדיניות.

ולבסוף, הקישור השלישי יוביל אתכם לדף שבו תוכלו לקבל מידע נוסף על התובנות לגבי המדיניות של Play ב-Android Studio, תכונה שנועדה לספק הנחיות מועילות לפני הבדיקה, שמועברות כבדיקות Lint ב-Android Studio.

טוב.

יש גם מיומנות Android שעוזרת לבדוק אפליקציות ל-Android בהתאם למדיניות של Google Play, כדי לוודא שהן עומדות בדרישות בנושא הרשאות, מחיקת חשבונות ואבטחת נתונים.

אתם יכולים להתקין את הסקיל הזה באמצעות ה-Android CLI, בדיוק כמו כל סקיל אחר.

android skills list
android skills add play-policy-insights

ולסיום, לפני שנתחיל עם כמה מהשאלות של יאן, רצינו לשתף כמה שיטות מומלצות לעבודה עם המדיניות של Play ובדיקות האפליקציות.

הראשונה היא לספק לבודקים פרטי כניסה.

זה נשמע פשוט, אבל סיבה נפוצה מאוד לעיכובים או לדחיות היא תוכן לא נגיש.

אם האפליקציה דורשת התחברות, או אם יש בה תוכן שמוגן בחומת תשלום, קרדיטים או מינויים, צריך לספק פרטי כניסה לבדיקה.

באפליקציות מסוימות, זה אומר לספק פרטי כניסה רק בהתחלה, ובאפליקציות אחרות, יכול להיות שיהיו חלקים שונים, כמו התוכן בתשלום שהזכרתי.

אפשר לעשות את זה ב-Play Console, ואז לספק את פרטי הכניסה האלה לבודקים שלנו.

בעבר קראו לזה "גישה לאפליקציה", אבל עכשיו קוראים לזה "פרטי כניסה", וזה נמצא בקטע "תוכן האפליקציה".

ואז צריך לוודא שפרטי הכניסה עוקפים כל סוג של אימות דו-שלבי, CAPTCHA, חומות תשלום וכו'.

כן, צריך להשבית את קודי הגרסאות הישנים.

לכן, מפתחים חווים לעיתים קרובות את מה שאנחנו מכנים, באופן לא רשמי, לולאות דחייה, כי הם מעלים גרסת build נקייה ותואמת לסביבת הייצור, אבל הם שוכחים לעיתים קרובות שגרסה ישנה יותר, שלא תואמת, עדיין פעילה ב-Play Console במסלול אחר, בין אם מדובר בבדיקה פתוחה לציבור, בדיקה בקבוצה מוגדרת וכו'. לכן, גם אם חבילת האפליקציה נמצאת במסלול בדיקה ישן, היא כפופה לבדיקת עמידה במדיניות של Play, למדיניות של Play.

לכן, אם האפליקציה מבקשת הרשאות מוגבלות או משתמשת בערכות SDK מיושנות ופגיעות, היא עדיין תהיה כפופה לבדיקה.

לכן, לפני שלוחצים על כפתור השליחה, חשוב לוודא שכל קודי הגרסאות המיושנים הוחלפו או הושבתו בכל המסלולים.

שלישית, כדאי להקדיש מספיק זמן לבדיקות ולהשתמש בפרסום מנוהל.

לכן, תהליך הבדיקה והפרסום של אפליקציות יכול להימשך שבעה ימים, ולפעמים יותר, במיוחד אם מדובר באפליקציה חדשה או באפליקציה שמבקשת הרשאת גישה למידע רגיש.

לכן, כדאי לתת מספיק זמן אספקה.

אם אתם מתכננים השקה גדולה, הקפידו לשלוח את האפליקציה החדשה לפחות שבועיים לפני תאריך ההשקה בפועל.

ואז אפשר לקשר את זה לפרסום מנוהל.

פרסום מנוהל הוא תכונה שמאפשרת להשהות עדכונים שאושרו עד שאתם מוכנים לפרסם אותם. כך אפשר למנוע עיכובים בלתי צפויים במהלך קמפיינים שיווקיים או השקות רגישות אחרות.

בנוסף, חשוב להימנע משליחה חוזרת של האפליקציה אחרי שהיא כבר נשלחה לבדיקה.

כי אם תעשו את זה, הספירה לאחור תתחיל מחדש.

אני חושב שלפעמים מפתחים שוכחים את זה, והם מפתחים אפליקציה עד שלב מסוים, ואז שוכחים, "אה, אני צריך לעשות את השינוי הקטן הזה".

הם שולחים אותו מחדש, ואז הוא חוזר לתחילת תהליך הבדיקה.

נכון, צריך לבדוק את ההצהרות.

לכן, הצהרות התוכן של האפליקציה, כמו סעיף אבטחת הנתונים, מדיניות הפרטיות או הרשאות לתמונות או לסרטונים, חייבות להתאים לקובץ מניפסט של אפליקציה של קודי הגרסאות או החבילות הפעילות בכל המסלולים.

לדוגמה, אם בקובץ המניפסט של האפליקציה יש בקשה לגישה למיקום מדויק, אבל בטופס הצהרת ההרשאות לא מצוינת המטרה של הגישה הזו, האפליקציה עלולה להיות כפופה לאכיפה, וסביר מאוד שזה יקרה.

לכן, חשוב לוודא שערכות SDK של צד שלישי לא שולפות נתונים שלא הצהרתם עליהם.

גם אם האפליקציה שלכם לא משתמשת בנתון מסוים, אם תבחרו לשלב SDK שכן משתמש בו, זה עלול להוביל לאכיפה.

לכן, כדאי לעיין ב-Google Play SDK Index כדי לראות תובנות לגבי יותר מ-100 מערכות ה-SDK המסחריות הנפוצות ביותר.

לפני שנמשיך, יש לי שאלה קצרה.

אז כשאתה אומר "אכיפה", למה אתה מתכוון בדיוק?

מה המשמעות של המונח הזה?

פעולות אכיפה יכולות להיות כל פעולה שלילית, החל מאזהרות ודחיות ועד לפעולות אכיפה חמורות יותר כמו הסרות, השעיות או אפילו חסימות של חשבונות.

אז כשאני אומרת "אכיפה", אני מתכוונת לפעולות האלה.

מגניב.

תודה.

כן.‏

ולבסוף, להגיש ערעור.

אל תשלחו שוב את אותה גרסה אחרי שהיא נדחתה.

בנוסף, דחיות חוזרות ונשנות בגלל אותה בעיה בפרק זמן קצר עלולות להפעיל סימון אלגוריתמי שמוביל לאכיפה חמורה יותר, כמו הסרות או השעיות.

לכן, אם האפליקציה נדחתה, אל תשלחו אותה שוב מיד בלי לבצע שינויים, לנחש או להתייחס למשוב.

נשלח לכם הודעות גם לתיבת הדואר הנכנס ב-Play Console וגם לכתובות האימייל שסיפקתם, עם פרטים על ההפרה הספציפית והנחיות לפתרון הבעיה.

ואם אתם לא מסכימים, או אולי לא מבינים, אבל נניח שאתם לא מסכימים עם דחייה, אתם יכולים לערער, נכון?

אם לדעתכם מדובר בזיהוי שגוי, אתם יכולים להשתמש בקישור שמופיע בהודעה כדי לערער.

וזה צעד ראשון טוב יותר מאשר פשוט למהר לשלוח מחדש בלי לבצע שינויים.

אותו דבר לגבי התשובה שקיבלתם. אם היא לא ברורה לכם, אולי היא ארוכה מדי, אולי יש בה יותר מדי פסקאות, לא משנה מה הסיבה, זה בסדר גמור לחזור לצוות הערעורים.

כשתעשו את זה, תתכתבו באימייל עם אדם אמיתי.

יכול להיות שיש מגבלות על מה שהם יכולים לומר, אבל בדרך כלל אפשר לקבל פרטים נוספים על הסיבה לדחייה.

במקרים אחרים, צוות הערעורים מבין שהתקשורת יכולה להיות ארוכה למדי.

לכן, הם יכולים להדגיש או להבליט את החלקים שרלוונטיים ספציפית לכם ולאפליקציה שלכם.

אז כן.

עכשיו אני מעביר את רשות הדיבור בחזרה ליאן.

טוב.

תודה.

לכן אספנו שאלות ממפתחים במגוון ערוצים ומקורות שונים.

אז השאלות שמופיעות כאן היום מייצגות חלק מהבעיות שאנחנו שומעים עליהן לעיתים קרובות ממפתחים בכל מה שקשור למדיניות.

אז נתחיל עם זה.

מהן כמה מהסיבות הנפוצות לדחיית אפליקציה שקשורות להרשאות?

ואיך המפתחים יכולים להימנע מדחיות שקשורות להפרות של מדיניות ההרשאות?

טוב.

הרשאות, אני אטפל בזה.

אז כן, ההרשאות, ובמיוחד הרשאות הגישה למידע רגיש, חייבות להיות חיוניות למטרה העיקרית של האפליקציה, כפי שהיא מפורסמת.

לכן, אם יש לכם תכונה משנית או תכונה שלא קיימת באפליקציה או שלא מפורסמת, סביר מאוד שהאפליקציה תידחה.

לכן, חשוב לוודא שההצהרה תואמת לתרחיש לדוגמה של האפליקציה.

בנוסף, במקרים רבים אפליקציה נדחית כי הקישורים לסרטונים שסיפקתם בהצהרות פשוט לא נגישים.

צוות הבדיקה שלנו צריך שתהיה לו גישה לאפליקציה, לקישורים לסרטונים שאתם מספקים, לכל מה שנמצא באפליקציה, כדי לבדוק אותה באופן מלא.

לכן, חשוב לוודא שהכול נגיש באפליקציה, במניפסט ובהצהרה.

לכן, חשוב לוודא ששלושת הפריטים האלה הושלמו, וסביר מאוד להניח, טוב, אני לא רוצה להגיד סביר מאוד להניח, אבל התהליך יהיה חלק יותר.

מגניב.

טוב.

אז יותר מפתחי אפליקציות מתחילים להשתמש בפלטפורמות של צד שלישי עבור תוכן שנוצר על ידי AI באפליקציות שלהם, נכון?

אם הפלטפורמות האלה יוצרות תוכן לא הולם, לא מדויק מבחינה עובדתית או משהו כזה, האם זה יכול להוביל לדחייה של האפליקציה של המפתח, ומי באמת אחראי במקרים כאלה?

כן.‏

כן, זה יכול לגרום לדחייה.

מאז שהשקנו את חנות Play, העמדה שלנו תמיד הייתה שהמפתח אחראי לכל מה שיש באפליקציה שלו, או לכל מה שהמשתמש יכול לגשת אליו באפליקציה.

למרות ש-AI גנרטיבי הוא תחום חדש, זה נכון גם לגביו.

אני חושב שההקבלה הטובה ביותר ל-AI גנרטיבי היא תוכן שנוצר על ידי משתמשים, כי בשתי כללי המדיניות האלה צריך שיהיו הרבה מאותם סוגים של, אתם יודעים, צריך שיהיה סימון, אתם יודעים, אם מופיע משהו שהוא לא ממש מתאים.

חייב להיות מנגנון סינון.

אני חושב שיש, כלומר, יש כמובן כללי מדיניות אחרים שחלים, אבל הדרך שבה אני אוהב להסתכל על זה היא שאם יש לך תוכן של GenAI, יש לך את Google שבודקת את האפליקציה, יש לך משתמשים שלוחצים על דגל אם הם רואים משהו לא הולם, ואז יש לך את מנגנוני הסינון שלך.

אז בעצם Google, המפתחים, אתם והמשתמשים פועלים יחד כדי לשמור על האפליקציה בטוחה ככל האפשר לכולם.

אוקיי.

מצוין.

אבל באופן כללי, האם אנחנו ממליצים, בנוסף למנגנונים שמאפשרים למשתמשים לדווח על תוכן, שמפתחים ישימו איזשהו, לזה אתה מתכוון במנגנון הסינון?

כדי למנוע הצגה של סוגי תוכן מסוימים למשתמשים מלכתחילה?

נכון.

כן.‏

אז כמו בתהליך הבדיקה, הצוותים שלנו לא ינסו לחפור בקוד שלכם או לבצע הנדסה הפוכה כדי להבין מהו בדיוק מנגנון הסינון שלכם.

הם רק יבדקו אם אפשר לגשת לתוכן בלתי הולם.

ואם הם יכולים, אז נשלח כמה הודעות בחזרה, ואז הצוות שלך יצטרך להבין איך הם יכולים להפוך את מנגנון הסינון הזה ליותר חזק.

בסדר גמור.

מגניב, תודה.

אז יש מדיניות שנקראת מדיניות התחזות או מדיניות העתקה, נכון?

אז אם אפליקציה נדחתה במסגרת המדיניות בנושא התחזות, אבל המפתח חושב שזו טעות, מכל סיבה שהיא, מה הוא צריך לעשות?

ואיך אפשר להימנע מראש מדחייה מהסוג הזה?

ערעור.

כן, זו הייתה אחת מהשיטות המומלצות, החמישית לדעתי, שמופיעות על הלוח. אם הבקשה שלכם נדחתה, כדאי לכם לערער.

מה צריך לעשות? התרחישים הנפוצים ביותר הם שהמותג שמתחזים אליו הוא המותג שלכם, נכון?

או שאתם מפתחים אפליקציה בשביל מישהו אחר, וזה כנראה המקרה הכי נפוץ, שבו יש מפתחים שיוצרים אפליקציות למתקני הכושר שלהם, SaaS, אתם יודעים, סוג של פתרון SaaS.

אבל קל יותר לפרסם אותן בחשבון הפיתוח שלך, נכון?

אתם יכולים להגיש ערעור, והצוות שלנו יחפש את מה שנקרא "הוכחת הרשאה".

נניח שיש לכם לקוח בשם "העוף של יוסי", ויש לו את העוף הכי טוב, אתם יודעים, ממערב למיסיסיפי.

הם יתנו לכם מכתב הוכחת הרשאה, על נייר מכתבים רשמי של החברה עם הלוגו שלה, שבו כתוב: "אנחנו, חברת 'העוף של יוסי', נותנים הרשאה למפתח ABC להשתמש בתמונות ובדמות שלנו באפליקציה שלו". מומלץ שהם יציינו את שם האפליקציה ואת שם חבילת ה-APK של האפליקציה.

למשל, com.joeschicken.app או משהו כזה, ואז אפשר להגיב למפתח ולתת לו את התיעוד הזה.

אוקיי.

ואז, אני חושב שהחלק השני היה--

האם יש משהו שהם יכולים לעשות באופן יזום כדי להימנע מכך?

למשל, האם אפשר להעלות את, שכחתי איך קוראים לזה, הוכחה למשהו, אתם יודעים, בזמן ששולחים את הבקשה הראשונה?

כן.

בסדר.

ב-Play Console יש טופס שנקרא "הודעה מראש". אפשר לשלוח אותו ולהעלות את המסמכים שמשייכים את החשבון שלך לישות האחרת.

כך תוכלו להגן מראש על האפליקציה שאתם שולחים מפני פעולות אכיפה כאלה.

בהחלט.

מגניב.

טוב.

הזכרת קודם בקצרה את השימוש בערכות SDK של צד שלישי בקטע של השיטות המומלצות, אבל הייתי רוצה להתעמק בזה קצת יותר.

אז כשאפליקציות משתמשות בערכות SDK של צד שלישי, נראה שמפתחי האפליקציות אחראים לאופן שבו ערכות ה-SDK האלה משתמשות בנתונים כמו נתוני משתמשים.

אז איך המפתחים יכולים לדעת שערכות ה-SDK עומדות בדרישות של המדיניות בנושא אבטחת נתונים ומדיניות בנושא נתוני משתמשים?

איך הם יכולים להתמצא בסביבה הזו?

כן, זו שאלה מצוינת.

בשנתיים הראשונות שלי ב-Google עבדתי הרבה עם ערכות SDK, וזה קצת קשור לשאלה הקודמת, שבה דיברנו על AI גנרטיבי ועל תוכן שנוצר על ידי משתמשים, רק במובן שכל מה שיש באפליקציה, בסופו של דבר, הוא באחריות המפתח.

אני חושב שפול הזכיר בקצרה בהקדמה שיש לנו משהו שנקרא Google Play SDK Index, ואפשר פשוט לחפש את זה ב-Google.

התוצאה הראשונה או השנייה צריכה להיות Google Play SDK Index, ומה שתקבלו זה דף אינטרנט שיש בו יותר ממאה, אולי כמה מאות ערכות SDK שמחולקות לפי קטגוריות: האם זו ערכת SDK למונטיזציה, או למודעות, או לבריאות, או למשהו אחר?

הדף הזה פשוט שולף נתונים שזמינים באופן ציבורי.

זה משהו ש-Google מארגנת.

אבל מה שתשימו לב אליו הוא שכאשר אתם עוברים על ערכות ה-SDK האלה, בצד של חלק מהן יהיה תג שאומר משהו כמו "רשום ב-SDK Console".

כמו שלכם כמפתחים יש את Play Console לאפליקציות שלכם, למפתחי SDK יש אפשרות לקבל גישה ל-SDK Console.

הם צריכים לעבור תהליך בדיקה דומה.

הם שולחים לנו את ה-SDK שלהם.

‫Google מבצעת כמה בדיקות שונות, ואם העסק עומד בדרישות, הוא מקבל את התג.

מה זה אומר מבחינתכם כמפתחים? אתם יכולים להיכנס לאינדקס הזה ולראות אילו ערכות SDK עברו את התהליך הזה.

זה לא מבטיח שהאפליקציה תאושר או שערכת ה-SDK תמיד תעמוד בדרישות, אבל זה נותן שני יתרונות.

הסיבה הראשונה היא שיש סיכוי הרבה יותר גבוה שהאפליקציה לא תידחה אם משתמשים ב-SDK הזה.

רק הסתברות.

הדבר השני, וזה משהו שאני ממש אוהב בכל התהליך הזה, הוא שאם אנחנו מגלים שבערכת ה-SDK יש משהו שלא תואם, אנחנו נוקטים גישה דו-שלבית.

החלק הראשון הוא שנפנה למפתח ה-SDK ונגיד לו: "היי, שמנו לב שערכת ה-SDK שלך שולחת נתוני משתמשים באופן שלא תואם למדיניות".

ואז הם יפעלו כדי שהאפליקציה או ה-SDK שלהם יעמדו בדרישות.

במקביל, או קצת אחרי, הצוותים שלנו שולחים התראות או אזהרות למפתחים.

בהתראה יהיה כתוב משהו כמו: "היי, שמנו לב שהאפליקציה שלך שולחת את הנתונים האלה באופן שלא תואם למדיניות, וזה קורה ב-ABC SDK".

לכן, הפעולות שאתם יכולים לבצע כמפתחים הן פשוט לעדכן את ה-SDK לגרסה התואמת שהם סיפקו.

אם אתם רוצים לנקוט בצעד קיצוני יותר, אתם יכולים להסיר את ה-SDK או להחליף אותו, אבל אני יודע שזה דורש הרבה מאמץ ועבודה.

אבל זה מה שאני אוהב ב-Google Play SDK Index.

כן.‏

באינדקס לא מצוין בדיוק באילו כללי מדיניות הוא עומד או לא עומד, אבל מקבלים את התג הזה, וזה סוג של מה שהייתי מכנה "הבעת אמון".

אוקיי.

כן.‏

אוקיי, נשמע טוב.

ואם הבנתי נכון את מה שאמרת, אם אנחנו שולחים הודעות למפתחים ואומרים להם, "אתם משתמשים ב-SDK הזה ויש בו בעיה".

האם אנחנו אומרים להם, למשל, אם הם הולכים לעדכן, האם אנחנו אומרים להם איזו גרסה? אם המפתח מתקן את זה, האם אנחנו אומרים להם, למשל, "היי, גרסה טובה יותר היא כזו וכזו"?

או שהם פשוט צריכים לעשות קצת מחקר בעצמם?

לדעתי קוד הגרסה מופיע שם.

כן, אל תתפוס אותי במילה, אבל אני חושב שקוד הגרסה מופיע שם, והם יכולים לעדכן אליה.

כן, ולמען השקיפות, אני לא מפתח בעצמי, אני לא מהנדס, אבל משיחות עם מפתחים, מה שאני מבין זה שלפעמים זה פשוט כמו ללחוץ על כפתור או על כמה כפתורים, ואז מתחילים את תהליך העדכון של ה-SDK בתוך האפליקציה.

מגניב.

מגניב.

תודה.

טוב.

דיברת קצת על פרטי כניסה, וזה נושא שאני מכיר לפחות קצת, ועל כמה שחשוב שהמידע הזה יהיה שם.

אז הזכרת דברים כמו עקיפת אימות דו-שלבי והבטחת דרך לעקוף חומות תשלום או גישה לתוכן שמבוסס על מינוי.

אבל מהם המצבים הנפוצים האחרים שמפתחים צריכים להביא בחשבון?

לדוגמה, נתקלתי במקרים שבהם באפליקציות מסוימות יש תוכן שאפשר לגשת אליו רק במדינות מסוימות או במיקומים גיאוגרפיים מסוימים, או למשל באפליקציית הודעות שבעצם דורשת שתי התחברויות כדי לבדוק אותה.

האם יש מצבים אחרים שבהם המפתחים צריכים לעשות קצת יותר מאשר רק לספק פרטי התחברות?

כן.‏

אני חושב שתמיד כדאי להתחיל ולסיים עם פרטי הכניסה שאתם מספקים לצוות הבדיקה, ולוודא שהם נותנים להם גישה לכל התכונות באפליקציה.

הקטע הזה ב-Play Developer Console נקרא בעבר "גישה לאפליקציה", ולפני כחודש בערך הוא שונה ל"פרטי כניסה".

אז כן, יש מקום שבו אפשר להזין את שם המשתמש, הסיסמה, ואני חושב שמתחת לזה יש שדה טקסט חופשי.

לכן, אתם יכולים לתת הוראות כמו מהם השלבים להתחברות אם הם לא פשוטים.

אם רוצים, אפשר גם לספק למשתמשים פרטי התחברות נוספים.

כדי לתת לך קצת תובנות, כשהצוותים שלנו בודקים את האפליקציות, זה לא שמישהו יושב בחדר, מחטט קצת ואז פשוט לוחץ על אישור או דחייה.

יש הרבה צוותים שבוחנים את כללי המדיניות ותהליכי העבודה השונים, ולכן סביר מאוד להניח שיותר מאדם אחד יתחבר לאפליקציה שלכם בכמה מכשירים, לפעמים באזורים שונים.

ואני מבין את הקושי כי הרבה מנגנוני בטיחות אומרים, "אם אנחנו רואים הרבה התחברויות", אז, למען בטיחות המשתמש, זה מפסיק ומחזיר את זה.

אבל לא משנה מה תבחרו לעשות, רק שתדעו שאנחנו בודקים את האפליקציה בהרבה תהליכי עבודה שונים, אז יכול להיות שתראו את זה.

לכן, כדאי לספק את פרטי ההתחברות האלה.

כן.‏

מגניב.

כן, חשוב מאוד להשתמש בטקסט החופשי בהצהרה.

אז אם חשבון ההדגמה שלכם הוא לא רק שם משתמש וסיסמה, ויש עוד שלבים שצריך לבצע, אתם צריכים לוודא שצוות הבדיקה שלנו מבין איך להיכנס לאפליקציה.

אולי תוכלו, אתם יודעים, לספק סרטון שמראה איך לעשות את זה, רק כדי לוודא שהצוות שלנו מבין איך לעשות את זה אם זה יותר מורכב, אתם יודעים, משם משתמש וסיסמה.

כן.‏

לפעמים אנחנו בודקים אפליקציות בעצמנו, ויש כמה התחברויות די מפוארות.

למשל, ראיתי סרטונים שבהם, ואני לא ממציא את זה, אומרים ללחוץ על הכפתור הזה 17 פעמים, ואז לצייר X על המסך, ואז מצב המפתח מופיע, ואז יש עוד 11 שלבים שצריך לבצע. אז בבקשה אל תעשו את זה.

כי זה קצת מקשה על העניינים.

תרחיש אחד ששמעתי עליו הוא, אתם יודעים, אפליקציות מסוימות יאפשרו לכם רק מספר מסוים של התחברויות רצופות, או התחברויות בו-זמנית לאפליקציה, לפני שהיא תגיד, "אה, אתם צריכים להסיר אחת".

אז אם האפליקציה שלך תומכת בזה, כדאי לכלול גם מידע על איך למצוא את הדף שבו אפשר להסיר את הגישה להתחברויות קודמות.

כן.‏

מגניב.

לכן, כשאנחנו מעדכנים את כללי המדיניות או מפרסמים כללי מדיניות חדשים, לפעמים המפתחים צריכים לבצע שינויים באפליקציה שלהם. בהתאם לשינויים הנדרשים, יכול להיות שייקח קצת זמן להטמיע אותם.

אז לפעמים יש להם מועד אחרון, נכון?

למשל, עד לתאריך הזה, צריך לעשות XYZ כדי לעמוד בדרישות של מדיניות חדשה.

אם המועד האחרון מתקרב, אבל המפתח יודע שהוא יצטרך עוד זמן כדי לעמוד בדרישות, מה האפשרויות שלו?

כן, זה נשמע כמו אזהרה.

כן, זה נשמע כמו אזהרה.

כן.‏

כן, אז לגבי אזהרות, כלומר, הדבר הפשוט הוא, כמו, זה – פשוט לבקש עוד זמן, נכון?

התהליך עובד בדרך כלל כך: אנחנו מפרסמים כללי מדיניות חדשים, עדכונים של כללי מדיניות קיימים או אפילו רק הבהרות.

ואני חושב ש-Google בדרך כלל נותנת מספיק זמן מראש.

יכול להיות שנודיע על המדיניות הזו באופן פומבי 6 חודשים לפני שנתחיל לפעול.

ואז, כן, אז האזהרות יישלחו ואנחנו נגיד, "היי, האפליקציה שלך מפרה את המדיניות הזו שהוכרזה", אתם יודעים, "לפני 6 או 12 חודשים", או מה שזה לא יהיה.

אבל דבר אחד, ופול ואני קצת מתנגדים לזה לפעמים, אבל הם עשויים לומר שיש לך 7 ימים לבצע את השינוי הזה.

והפיתוח לוקח הרבה זמן.

אנחנו מבינים את זה.

אז מה שהייתי עושה זה פשוט להגיב.

אפשר לעשות את זה באמצעות ערעור, ולכתוב משהו כמו, "היי, אנחנו מבינים את המדיניות ואת הסיבה לכך שהאפליקציה שלנו לא עומדת בדרישות.

אנחנו כבר עובדים על זה, או שאלה השלבים שאנחנו מתכוונים לבצע כדי לפתור את הבעיה שקשורה למדיניות, אבל אנחנו צריכים עוד זמן".

לכן, בדרך כלל הם יתנו לכם קצת יותר זמן.

אם עברו עוד 7 ימים, ואתם מתקרבים לסוף התקופה הזו, אתם יכולים לבקש שוב.

הוא לא אינסופי, כמובן.

אבל כמו שאמרתי, פול ואני מתנגדים, אבל זה ברמה האישית, וגם ברמה גבוהה יותר.

למשל, כשאנחנו יודעים שמדיניות חדשה עומדת להיכנס לתוקף, ואנחנו יודעים מי עובד עליה, אנחנו אומרים, "תראו, אפשר לתת אזהרה של 28 ימים במקום 7 ימים, או לפחות 14 ימים?"

כן.‏

בסדר.

אם אתם מראים שאתם פועלים בתום לב, כלומר שאתם מבצעים שינויים כדי לעמוד בדרישות, Google Play תעבוד איתכם כדי לקבוע מועד אחרון חדש.

ציר זמן משופר.

אוקיי.

אז נשמע שהערעורים הם כמו כלי רב-תכליתי שעוזר בהרבה מצבים כאלה, כל עוד משתמשים בהם כמו שצריך.

למשל, אם אתם חושבים שיש סיבה מוצדקת להגיש ערעור, כדאי להגיש אותו ולפרט כמה שיותר למה אתם עושים את זה. זה יכול לעזור לכם לקבל את ההתחשבות והעזרה שאתם צריכים.

טוב.

אז אם למפתח יש כמה אפליקציות בחשבון פיתוח אחד, ואני יודע שזה קורה כל הזמן.

ואפליקציה אחת מושעית בגלל הפרת מדיניות כלשהי, מה זה אומר לגבי כל חשבון הפיתוח?

האם זה מסכן את החשבון או אפליקציות אחרות שעומדות בדרישות?

איך זה עובד?

יכול להיות.

זה כמו מפתחים של מותג פרטי.

דיברתי קודם על "העוף של יוסי", נכון?

ואולי יש לכם לקוחות שכולם פועלים בתחום הזה.

אני חושב על זה כמו משחק בייסבול, שבו יש פסילות, נכון?

לצערנו, יש גורמים זדוניים שמנסים להיכנס לחנות Play, וזו אחת מהסיבות לכך שיש לנו סוגים שונים של אכיפה – החל מאכיפה קלה ועד לאכיפה חמורה יותר, כמו הסרות, השעיות ואפילו חסימות של חשבונות.

אז אם יש לכם הרבה אפליקציות דומות בחנות Play, ואחת מהן מושעית, נניח ש…

כן.

אתה גורם זדוני, נכון?

אז אתם מתקנים את זה, ואחרי חודש מנסים להכניס את זה שוב.

ואז הצוותים שלנו מגלים את זה ומשעים את החשבון שוב, נכון?

ואז אתם מסירים את זה מהאפליקציה, ואז אתם מחזירים את זה אחרי חודש, ואז, אוקיי, עכשיו יש לנו דפוס התנהגות שחוזר על עצמו, ואתם, אתם, אתם בתורכם, קיבלתם שלוש פסילות, ועכשיו אתם בחוץ, נכון?

אבל נניח שאתם מפתחים אפליקציה למסעדת עוף, שזה לא תוכן זדוני או משהו כזה, אתם רק מנסים להביא אוכל טעים לאנשים.

אז נניח שאתם שולחים את כל האפליקציות האלה בו-זמנית, למשל באמצעות צינור עיבוד נתונים של CI/CD או משהו כזה, ו-10 אפליקציות מקבלות את הדחייה או ההשעיה הזו בו-זמנית, אנחנו נתייחס לזה כפסילה אחת כי אנחנו מבינים שאתם מפתחים הרבה מאוד אפליקציות בו-זמנית.

כן.

מעניין.

אז אני חושב שזו התשובה לשאלה.

כן, מקסים.

תודה.

ויש לי עוד דוגמה אחת.

והשאלה הזו אולי… הרבה מהשאלות האלה היו יותר למפתחים מבוססים, אבל השאלה הזו היא יותר על ההתחלה, כשמגדירים את Play Console.

אז נניח שפרופיל התשלומים שלכם ב-Google Play אומת, זהות... וואו, זה ארוך.

השגיאות באימות הזהות נעלמו, ורק אימות מספר הטלפון נשאר.

למשל, מה מפתח צריך לעשות במקרה הספציפי הזה כדי לוודא שחשבון הפיתוח שלו מוכן לפרסום אפליקציות?

לפעמים נראה שאתה אוסף חלקים בודדים של הפאזל, או אם הם לא יודעים איך לסיים את התהליך במקרה כזה, מה הם יכולים לעשות?

כן, שאלו אותי שאלה דומה לא מזמן באירוע אחר, אבל אני חושב שזה נכון כמובן למפתחים חדשים, אבל אני חושב שהרבה מהמפתחים הקיימים היו צריכים לבצע את האימות הזה שוב.

זה היה לפני שנה בערך, נכון?

אני לא ממש זוכר.

הרבה מהם אומתו באופן אוטומטי, אבל חלק מהם לא אומתו והיו צריכים לעשות את זה.

אוקיי.

או אולי אם הכתובת שלהם והפרופיל שלהם ב-Dun & Bradstreet לא תואמים, כמו…

בסדר.

בסדר.

הפרופיל ב-Google.

אוקיי.

כן, אז נניח שזה מספר הטלפון.

אענה על השאלה הזו בשתי דרכים.

אוקיי.

אחד מהם הוא, אוקיי, אז הרבה פעמים כשעוברים את השלבים האלה, מופיעות התראות ב-Play Console.

אז פשוט תופיע התראה שאומרת, "היי, הגיע הזמן לרשום את מספר הטלפון שלך".

וזה די פשוט.

אתם מזינים אותו בפורמט של מספר טלפון בינלאומי, פלוס 1 408, לא משנה מה המספר.

תצטרכו לבצע אימות באמצעות SMS או שיחת טלפון ולפעול לפי השלבים שמופיעים שם.

אבל לפעמים אתם מנסים לעשות את זה ומקבלים הודעת שגיאה או משהו כזה, כי היו לנו מפתחים שזה קרה להם, או שהם לא קיבלו את קוד ה-SMS.

אני אראה לך את השלבים כדי להגיע לצוות הערעורים.

זה צוות אחד, אבל למעשה יש עוד חצי תריסר או שני תריסר צוותים אחרים ש…

Will.

אפשר לענות על שאלות ב-Play Console דרך תפריט העזרה, אם יש לך גישה אליו.

עכשיו, ממשק המשתמש השתנה קצת.

הוא היה בתפריט בצד ימין של מסך הבית.

בתחתית המסך היה כפתור עזרה.

הוא נעלם, אבל עכשיו אם פשוט גוללים לתחתית של כל דף, כפתור העזרה מופיע בכותרת התחתונה.

כשלוחצים עליו, מופיע כפתור קטן בצורת גלולה כחולה עם הכיתוב "יצירת כרטיס תמיכה".

אני חושב שזה מה שכתוב שם.

כן.

כן.

ואז מופיעים תפריטים נפתחים שבהם אפשר לשאול שאלות.

יש סדרה של תפריטים נפתחים שיובילו אתכם ישירות למספר הטלפון. אני חושב שאני זוכר את זה כמעט בעל פה, אבל זה משהו כמו "אימות חשבון הפיתוח", התפריט הנפתח השני די דומה, ואז תראו כמה כפתורי בחירה.

אחד מהם מיועד ספציפית לאימות מספר הטלפון.

ואז אולי אתם מקבלים קוד אימות ב-SMS, או שמופיע באג במסך כשאתם מנסים לעבור את התהליך הזה.

אפשר להשתמש בו כדי לאמת את מספר הטלפון, אבל גם כדי לקבל תשובות להרבה שאלות אחרות שקשורות לחשבון הפיתוח ב-Play.

ברוב המקרים, ב-Play Console מוצגים בבירור השלבים הבאים לאימות, אז פשוט צריך לפעול לפי השלבים וזהו.

נהדר.

מגניב.

טוב, הזמן שלנו כמעט נגמר, אז תודה רבה לכולכם שהצטרפתם אלינו לפאנל הזה.