איך להשיק אפליקציה למובייל: צ׳קליסט למפתחים עצמאיים

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

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

לפני שבונים: לתקף את הרעיון ולפתוח רשימת המתנה

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

לבדוק ביקוש בתוך כמה ימים

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

לבנות דף נחיתה פשוט עם רשימת המתנה

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

גם החנויות יכולות לאסוף התעניינות: ה-App Store תומך בהזמנה מראש (pre-order) ו-Google Play תומך בהרשמה מראש (pre-registration), כך שאנשים מקבלים התראה כשהאפליקציה זמינה. בדקו את תנאי הזכאות העדכניים בכל אחת מהן.

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

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

בדיקות בטא: TestFlight ומסלולי הבדיקה של Google Play

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

TestFlight ב-iOS

TestFlight של Apple מפיץ גרסאות בטא דרך App Store Connect.

• בודקים פנימיים הם חברים בצוות שלכם ב-App Store Connect ויכולים להתקין גרסאות בלי בדיקת בטא.
• בודקים חיצוניים יכולים להיות כל מי שתזמינו במייל או בקישור ציבורי. הגרסה הראשונה לבודקים חיצוניים עוברת Beta App Review.
• תוקפן של גרסאות בטא פג אחרי תקופה קבועה, אז המשיכו להעלות גרסאות חדשות במהלך בטא ארוכה.

מסלולי הבדיקה של Google Play

• בדיקה פנימית (Internal testing) מעבירה גרסאות לקבוצה קטנה ומהימנה במהירות.
• בדיקה סגורה (Closed testing) מיועדת לבודקים שאתם מזמינים דרך רשימת מיילים או קבוצה, והיא הבחירה המקובלת לבטא אמיתית.
• בדיקה פתוחה (Open testing) מאפשרת לכל מי שמוצא את דף האפליקציה להצטרף לבטא ציבורית.

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

להריץ את הבטא עם מטרה

1. תנו לבודקים שתיים או שלוש משימות ספציפיות, כמו להירשם וליצור רשומה ראשונה.
2. הוסיפו דיווח קריסות ואנליטיקס בסיסי לפני שהבטא מתחילה.
3. אחרי כמה ימים, שאלו שאלה פתוחה אחת: מה היה מבלבל או מעצבן?
4. תקנו קודם קריסות, ואחר כך את נקודות הבלבול הגדולות ביותר באונבורדינג.
5. שחררו גרסאות בטא חדשות באופן קבוע, כדי שהבודקים יראו שהפידבק שלהם משנה.

הבדיקה ב-App Store וב-Google Play: למה לצפות

שתי החנויות בודקות אפליקציות לפני שהן עולות לאוויר, ומפרסמות את הכללים שלהן. קראו פעם אחת לפני ההגשה את הנחיות בדיקת האפליקציות של Apple ואת מדיניות תוכנית המפתחים (Developer Program Policies) של Google Play. זה מונע את רוב הדחיות.

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

סיבות נפוצות לדחייה ב-App Store

• קריסות ובאגים. מי שבודק את האפליקציה נתקל בקריסה או בתהליך שבור.
• מידע חסר. האפליקציה דורשת התחברות, אבל לא סופק חשבון דמו.
• תוכן זמני. Lorem ipsum, נתוני בדיקה, קישורים שבורים או מסכים ריקים.
• מטא-דאטה לא מדויק. צילומי מסך או תיאורים שלא תואמים את מה שהאפליקציה עושה.
• בעיות פרטיות. מדיניות פרטיות חסרה, פרטי פרטיות שלא תואמים את איסוף הנתונים של האפליקציה, או בקשות הרשאה שלא מסבירות למה נדרשת הגישה.
• מחיקת חשבון. אם משתמשים יכולים ליצור חשבון באפליקציה, הם חייבים להיות מסוגלים להתחיל את מחיקתו מתוך האפליקציה.
• תשלומים. תוכן דיגיטלי שנפתח בתוך האפליקציה צריך בדרך כלל לעבור דרך רכישה מתוך האפליקציה (in-app purchase), עם כמה חריגים והבדלים בין אזורים.
• פונקציונליות מינימלית. אפליקציה שהיא בעיקר אתר עטוף, או שמציעה מעט מדי כדי להיות שימושית, עלולה להידחות.

בעיות נפוצות ב-Google Play

• טופס Data safety. הוא חייב לתאר במדויק אילו נתונים האפליקציה וה-SDK-ים שלה אוספים ומשתפים.
• הרשאות רגישות. גישה לדברים כמו מיקום ברקע, SMS או יומן שיחות דורשת שימוש מוצהר ומוצדק.
• רמת API יעד. אפליקציות חדשות ועדכונים חייבים לכוון לרמת API עדכנית של Android.
• מדיניות דף החנות. אייקונים מטעים, דחיסת מילות מפתח או טענות שאי אפשר לגבות.
• מחיקת חשבון ותשלומים. אפליקציות עם חשבונות צריכות דרך לבקש מחיקה, ומוצרים דיגיטליים שנמכרים באפליקציה כפופים לכללי החיוב של Google Play.

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

טיפים ל-App Store Optimization בהשקה קטנה

App Store Optimization, או ASO, פירושו לגרום לדף האפליקציה שלכם להיות קל למציאה בחיפוש בחנות, ומשכנע ברגע שמישהו מגיע אליו.

כותרת, וכותרת משנה או תיאור קצר

שם האפליקציה הוא אחד מאותות החיפוש החזקים ביותר שנמצאים בשליטתכם. שלבו שם מותג עם ביטוי קצר שאומר מה האפליקציה עושה, כמו "מעקב הרגלים" או "מתכנן תקציב". כותרת המשנה (subtitle) ב-App Store והתיאור הקצר (short description) ב-Google Play נותנים לכם עוד שורה קצרה אחת. מגבלות התווים צפופות, אז כל מילה צריכה להיות מונח חיפוש סביר או יתרון אמיתי.

מילות מפתח

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

צילומי מסך וסרטון תצוגה מקדימה

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

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

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

אייקון, דירוגים וביקורות

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

תוכנית לשבוע ההשקה

השקה היא מאמץ קצר ומתוכנן, לא פוסט בודד:

1. שבועיים לפני. הגישו את הגרסה הסופית ובחרו בשחרור ידני (manual release) ב-App Store או בפרסום מנוהל (managed publishing) ב-Google Play, כך שהאפליקציה מאושרת אבל עוד לא באוויר. הכינו צילומי מסך, קליפ דמו קצר, עמוד ערכת עיתונות (press kit) וטיוטות של כל פוסטי ההשקה.
2. כמה ימים לפני. שלחו מייל לרשימת ההמתנה עם התאריך. בקשו מכמה בודקי בטא לנסות את האפליקציה ביום הראשון ולשלוח תגובות כנות.
3. יום ההשקה. שחררו את האפליקציה, בדקו שהיא מותקנת במדינות שחשובות לכם, ושלחו לרשימת ההמתנה מייל עם קישורים ישירים לחנויות. פרסמו את ההודעות שלכם וענו על כל תגובה.
4. הימים השני עד הרביעי. שתפו בשאר הקהילות שברשימה שלכם, אחת או שתיים ביום, בהתאמה לכל קהל. תקנו מהר באגים של ההשקה.
5. סוף השבוע. שחררו עדכון קטן עם תיקונים מהפידבק הראשון, והודו לאנשים שעזרו.

בעדכונים הבאים, השחרור המדורג (phased release) של Apple וההפצה ההדרגתית (staged rollout) של Google Play מאפשרים לעצור אם צצות בעיות.

איפה להכריז על השקת האפליקציה

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

• רשימת ההמתנה ובודקי הבטא שלכם. הקהל הכי חם שלכם. בקשו מהם לדרג את האפליקציה אם היא מוצאת חן בעיניהם.
• קהילות נישה. סאברדיטים, פורומים, וקבוצות Discord ו-Slack סביב הבעיה שהאפליקציה שלכם פותרת. קראו קודם את הכללים, ושתפו למה בניתם אותה במקום להשאיר קישור חשוף.
• קהילות של יוצרים. Product Hunt, Indie Hackers ופוסט Show HN ב-Hacker News מתאימים לאפליקציות עם סיפור של היוצרים או עם זווית טכנית.
• ניוזלטרים ויוצרי תוכן בנישה שלכם. פנייה אישית קצרה עם קישור לדמו עדיפה על הודעה לעיתונות.
• אינדקסים של פרויקטים. הם נותנים לאפליקציה שלכם מקום קבוע שאנשים יכולים למצוא הרבה אחרי שבוע ההשקה. One Dollar Planet היא אפשרות אחת: אפשר להוסיף את האפליקציה שלכם לכוכב הלכת כנקודה ב-$1 שנשארת לתמיד, או עם לוגו ועמוד משלה ב-$10, ומבקרים יכולים לתת לה כוכבים ברשימת הדירוג. כל הפרטים בעמוד איך זה עובד.

מדידת שימור אחרי ההשקה

הורדות מראות שההשקה הגיעה לאנשים. שימור (retention) מראה שהאפליקציה שווה את המקום שלה בטלפון.

• הגדירו אקטיבציה. בחרו את הפעולה שמראה שמשתמש קיבל ערך, כמו יצירת רשומה ראשונה, ועקבו כמה משתמשים חדשים מגיעים אליה.
• עקבו אחרי שימור לפי קוהורטות. בדקו איזה חלק מהמשתמשים החדשים של כל שבוע חוזר ביום 1, ביום 7 וביום 30. עקומה שמתיישרת אומרת שקבוצת ליבה ממשיכה לחזור.
• עקבו אחרי ההמרה בחנות. App Store Connect ו-Google Play Console מציגים חשיפות, צפיות בעמוד והתקנות, כך שאפשר להבין אם צוואר הבקבוק הוא דף האפליקציה או האפליקציה עצמה.
• נטרו יציבות. שיעורי הקריסות והמקרים שבהם האפליקציה לא מגיבה משפיעים על הדירוגים, וב-Google Play איכות טכנית ירודה עלולה להפחית את החשיפה.

אספו רק את הנתונים שאתם צריכים, ושמרו על פרטי הפרטיות ב-App Store ועל טופס ה-Data safety ב-Google Play מעודכנים בהתאם לכל SDK שאתם מוסיפים.

איטרציות אחרי ההשקה

בשבועות שאחרי ההשקה המוצר האמיתי מתחיל לקבל צורה.

1. תקנו קודם קריסות וחסמים. שום דבר אחר לא משנה אם האפליקציה לא עובדת.
2. שפרו את האונבורדינג. הרבה מהמשתמשים שעוזבים עושים את זה כבר בסשן הראשון, אז קצרו את הדרך לאקטיבציה.
3. דברו עם משתמשים פעילים. שאלו מה גרם להם להישאר ומה כמעט גרם להם לעזוב.
4. שחררו עדכונים קטנים וקבועים עם הערות שחרור ברורות.
5. חזרו לדף האפליקציה ונסחו אותו במילים של המשתמשים שלכם, ובדקו גרסאות שונות בעזרת product page optimization של Apple או store listing experiments של Google Play.
6. החליטו מה הלאה. אם השימור בריא, השקיעו בצמיחה. אם הוא חלש, שנו את המוצר לפני שאתם מקדמים אותו חזק יותר.

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

עיקרי הדברים

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

שאלות נפוצות

כמה עולה להשיק אפליקציה למובייל?

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

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

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

כדאי להשיק ב-iOS וב-Android באותו זמן?

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

מה זה App Store Optimization והאם זה עובד לאפליקציות חדשות?

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

איך לקדם אפליקציה למובייל בלי תקציב שיווק?

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