מה עושים אחרי דחייה בגוגל פליי: פתרון מעשי למפתחים

איך לאבחן את סיבת הדחייה ב-Google Play Console

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

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

פתרון בעיות מעורבות בבדיקה סגורה ובודקים לא פעילים

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

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

תיקון הפרות מדיניות והרשאות רגישות באפליקציה

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

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

ניהול נכון של ערעורים והגשה חוזרת ללא סיכון החשבון

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

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

צ׳קליסט לפני שממשיכים

• לקרוא בעיון את פירוט השגיאה המלא בלשונית סטטוס המדיניות ב-Google Play Console
• לוודא ש-12 הבודקים האמיתיים שלכם השלימו 14 ימים רצופים של פעילות באפליקציה
• להפיץ עדכון גרסה אחד לפחות בזמן תקופת הבדיקה הסגורה כדי להוכיח פעילות
• לתקן הרשאות רגישות בקוד או להוסיף הצהרות נדרשות בטופס הפרטיות
• להגדיר מספר גרסה חדש ולייצא קובץ AAB מעודכן לפני ההגשה מחדש
• להגיש את האפליקציה לבדיקה חוזרת בצורה מסודרת דרך לוח הבקרה

שאלות נפוצות