פיתוח האפליקציה הסתיים? כך הופכים את האפליקציה לנכס עסקי צומח

ASO הוא מנגנון צמיחה מתמשך לאפליקציה

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

יש ל-ASO ארבע השפעות מרכזיות.

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

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

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

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

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

גם כלי הניסוי שונים. Apple מאפשרת לבצע Product Page Optimization ולבדוק וריאציות של אייקון, screenshots ו-app previews. Google Play מאפשרת לבצע Store Listing Experiments על טקסטים וגרפיקה, כולל ניסויים לפי שפה.

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

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

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

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

ב-Google Play אפשר לבדוק וריאציות של עמוד החנות באמצעות ניסויי A/B בעמוד האפליקציה ב-Google Play.

ב-App Store אפשר לבחון וריאציות של אייקון, צילומי מסך וסרטוני תצוגה מקדימה דרך ניסויי Product Page Optimization ב-App Store.

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

הקשר בין ASO לבין performance marketing הוא כספי וישיר. המדיה מביאה משתמשים אל עמוד האפליקציה. ביצועי העמוד קובעים כמה מאותם משתמשים יתקינו אותה.

החישוב הבסיסי הוא:

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

החברה מקבלת 20,000 התקנות.

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

אותו מספר מבקרים מייצר כעת 30,000 התקנות. מדובר בתוספת של 10,000 התקנות ובגידול של 50% בתוצאה, בלי להגדיל את הטראפיק.

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

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

ההתאמה צריכה לעבוד לאורך כל המסלול:

קהל הקמפיין ← המסר במודעה ← עמוד החנות ← הפיצ'ר או הערך שהמשתמש ציפה למצוא.

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

ב-App Store אפשר להשתמש ב-Custom Product Pages כדי לבנות עמודים מותאמים לקהלים, לפיצ'רים ולקמפיינים. ב-Google Play אפשר להשתמש ב-Custom Store Listings ולפלח ביצועים לפי עמוד, מקור וקמפיין.

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

כשקמפיין פונה לקהל או למסרים שונים, אפשר להתאים את דף החנות באמצעות Custom Product Pages ב-App Store.

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

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

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

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

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

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

כך מחלקים אחריות ועובדים נכון עם ספק הפיתוח

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

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

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

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

מכאן אפשר לבנות תהליך עבודה קבוע:

• דשבורד שבועי

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

• סקירת ביצועים לפי פלחים

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

• רשימת היפותזות מסודרת

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

• ניסוי מבוקר

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

• הטמעת התוצאה

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

• לולאת משוב למוצר ולפיתוח

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

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

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

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

קידום אפליקציה לאחר פיתוח – שאלות ותשובות: