נכתב ע"י רוברט נחום
מייסד ומנכ"ל בטופנדה. מומחה שיווק וקידום אפליקציות, יועץ לחברות בתחומי השיווק הדיגיטלי, המובייל ו-התוכן.
איך מקדמים ומשווקים אפליקציה באמת: המדריך המלא מ-ASO ועד משתמשים משלמים
תוכן עניינים
אפשר לבנות אפליקציה מצוינת, להשקיע במוצר, ללטש את ה-Onboarding ולחבר מערכת תשלומים. כל זה עדיין לא מבטיח שמישהו ימצא אותה, יתקין אותה או יהפוך ללקוח.
שיווק אפליקציות בנוי משני מנגנונים שעובדים יחד. הראשון הוא ASO, קיצור של App Store Optimization. מטרתו לשפר את הנראות של האפליקציה בחנויות ואת היכולת של עמוד האפליקציה לגרום לחשיפה להפוך להתקנה. המנגנון השני הוא User Acquisition, או UA, שבו משתמשים בקמפיינים ממומנים כדי להביא משתמשים חדשים ולכוון את מערכות הפרסום לאנשים בעלי ערך עסקי.
החיבור בין שני המנגנונים חשוב. קמפיין יכול להביא הרבה תנועה לעמוד חלש ולהפסיד כסף. עמוד חנות מצוין יכול להמיר היטב, אבל בלי מספיק חשיפה יישאר די שקט. גם מדידה טובה לא תציל מוצר שמבצע אופטימיזציה לאירוע הלא נכון.
לכן צריך להסתכל על שיווק אפליקציות כמערכת אחת: נראות, עמוד מוצר, התקנה, שימוש, תשלום ומדידה. נתחיל במקום שבו משתמשים רבים פוגשים את האפליקציה בפעם הראשונה, בחנות האפליקציות.
קראו את מקרי הבוחן שלנו וגלו למה הלקוחות שלנו ממליצים עלינו
ASO: איך מגדילים נראות והתקנות בחנויות
המטרה של ASO היא לשפר את ה-discoverability של האפליקציה, כלומר את הסיכוי שמשתמשים יגלו אותה בתוך App Store או Google Play.
חיפוש הוא חלק מרכזי מהתהליך, אך הוא רק חלק ממנו. משתמשים מגלים אפליקציות גם דרך קטגוריות, המלצות, אזורי Similar Apps, רשימות עריכה , אזורים בחנות שמציגים למשתמשים את אפליקציות ה-featured ועוד. לאחר החשיפה מגיע מבחן נוסף: האם המשתמש שנכנס לעמוד האפליקציה מבין במהירות מה היא עושה ולמה כדאי לו להתקין אותה?
מכאן אפשר לחלק את עבודת ה-ASO לשתי משימות:
- להביא יותר משתמשים רלוונטיים לעמוד האפליקציה.
- להגדיל את שיעור המשתמשים שמתקינים לאחר שהגיעו אליו.
Apple בוחנת בחיפוש את ההתאמה בין השאילתה לבין שם האפליקציה, מילות המפתח והקטגוריה הראשית. לצד אלה היא משתמשת גם באותות התנהגותיים כמו הורדות, מחיקות, מספר דירוגים ואיכות הדירוגים והביקורות.
Google נעזרת במידע שבעמוד החנות כדי להבין את האפליקציה ולהציג אותה בחיפוש, בהמלצות ובאזורי הגילוי השונים. מיקום האפליקציה משתנה בהתאם לסוג המכשיר, אזור התצוגה והמשתמש, כאשר התאמת האפליקציה לחיפוש המשתמש היא השיקול המרכזי.
במילים פשוטות, עמוד האפליקציה צריך לדבר בשתי שפות בו-זמנית. שפה אחת עוזרת לחנות להבין מה האפליקציה עושה. השפה השנייה עוזרת לבני אדם להבין למה להתקין אותה.
השדות הטקסטואליים ב-App Store וב-Google Play
האופטימיזציה הטקסטואלית משתנה בין שתי החנויות.
ב-App Store השדות המרכזיים הם:
- App Name או Title, עד 30 תווים
- Subtitle, עד 30 תווים
- שדה Keywords ייעודי, עד 100 תווים
- Description
- Promotional Text, עד 170 תווים
- קטגוריה ראשית ומשנית
ה-Description וה-Promotional Text מסייעים בעיקר בהסבר ובהמרה. ה-Promotional Text ניתן לעדכון ללא הגשת גרסה חדשה, אך אינו משפיע על דירוג החיפוש. לעומתם, שם האפליקציה, ה-Subtitle ושדה ה-Keywords הם חלק מרכזי מעבודת מילות המפתח.
ב-Google Play השדות הטקסטואליים העיקריים הם:
- App Name או Title, עד 30 תווים
- Short Description, עד 80 תווים
- Full Description, עד 4,000 תווים
Google Play אינה מספקת שדה Keywords נפרד. מילות המפתח צריכות להשתלב בשם ובתיאורים באופן טבעי, מדויק וקריא. דחיסה מלאכותית של ביטויים יכולה להפוך עמוד מוצר לטקסט שאף אדם סביר לא ירצה לקרוא, וגם Google דורשת שהמידע יהיה רלוונטי, תיאורי ולא מטעה.
מחקר מילות מפתח לאפליקציות מול מחקר SEO
מחקר מילות מפתח לאפליקציות צריך להתבסס על התנהגות חיפוש בתוך חנויות אפליקציות. משתמש שמחפש בגוגל עשוי לרצות מאמר, מדריך, אתר, מוצר או תשובה לשאלה. משתמש שמחפש ב-App Store או ב-Google Play מחפש אפליקציה שאפשר להתקין.
הכוונה שונה, התוצאות שונות וגם שפת החיפוש עשויה להיות שונה.
לכן נפח חיפוש מכלי SEO רגיל אינו תחליף לנתוני חיפוש מהחנויות. ביטוי יכול לקבל הרבה חיפושים בגוגל וכמעט לא להופיע בחיפושים בתוך App Store. מי שבונה את אסטרטגיית ה-ASO שלו על הנתון הלא נכון עלול להשקיע תווים, תוכן וזמן בביטויים שלא יביאו תנועה רלוונטית.
מחקר טוב מתחיל במיפוי של כמה דברים:
- הצעת הערך של האפליקציה
- הבעיה שהיא פותרת
- הקטגוריה שאליה היא שייכת
- הפיצ'רים המרכזיים
- השפה שבה המשתמשים מתארים את הצורך
- מתחרים ישירים
- אפליקציות דומות
- הביטויים שבהם משתמשות אפליקציות מצליחות בתחום
Apple Ads מספקת מדד בשם Search Popularity. זהו מדד יחסי לפופולריות של ביטוי בחיפושי App Store, ולא מספר מוחלט של חיפושים. הוא עדיין שימושי מאוד כדי להבין אילו ביטויים נהנים מביקוש יחסי בתוך החנות.
כלי Keyword Research של Topanda משלב נתוני Apple Search Ads Popularity עם מחקר של אפליקציית היעד, מתחרים, אפליקציות דומות ומילות מפתח קיימות. לאחר בניית מפת המילים אפשר להשתמש בכלי Metadata Optimization כדי לסדר את הביטויים בתוך ה-Title, ה-Subtitle ושדה ה-Keywords, לבדוק מגבלות תווים, לזהות כפילויות ולראות אילו ביטויים עדיין אינם מכוסים. יש גם מדריך ASO של Topanda שמציג את התהליך שלב אחר שלב.
Play Console שימושית למדידת ביצועים לאחר שהעמוד כבר קיבל תנועה. היא יכולה להראות ביקורים, קליקים להתקנה, פתיחות ויחסי המרה. הנתונים האלה עוזרים לבדוק אם שינוי בעמוד שיפר את הביצועים בפועל. הם אינם כלי למחקר מקדים של נפחי חיפוש, ובאפליקציה חדשה ממילא אין עדיין מספיק תנועה היסטורית שעליה אפשר לבסס החלטה.
בחירת מילות מפתח: רלוונטיות, ביקוש ותחרות
בחירת מילות מפתח נשענת על שלושה צירים:
- רלוונטיות: הביטוי מתאר צורך, שימוש, פיצ'ר או תועלת שהאפליקציה באמת מספקת.
- ביקוש: משתמשים מחפשים את הביטוי בתוך החנות.
- יכולת תחרותית: לאפליקציה יש סיכוי סביר להתברג מול האפליקציות שכבר מדורגות עבורו.
ביטוי פופולרי מאוד יכול להביא הרבה תנועה, אבל בדרך כלל מושך גם תחרות חזקה. ביטוי קטן וממוקד יותר עשוי להביא פחות חשיפות, אך להעניק לאפליקציה סיכוי טוב יותר להגיע למיקום גבוה ולהמיר משתמשים רלוונטיים.
ב-App Store כדאי לנצל היטב את החלוקה בין Title, Subtitle ו-Keywords. חזרה על אותה מילה בכמה שדות מבזבזת מקום, משום שהחנות יכולה להרכיב ביטויים ממילים שמופיעות במטא-דאטה.
המטרה היא לבנות תיק של ביטויים. חלקם רחבים ותחרותיים, חלקם ממוקדים יותר, וכולם קשורים למוצר באופן אמיתי.
נכסי עמוד המוצר: מה גורם למשתמש להתקין
אחרי שהמטא-דאטה הביא משתמש לעמוד, מתחיל החלק שבו העמוד צריך לשכנע אותו להוריד את האפליקציה.
האייקון הוא אחד הנכסים הראשונים שהמשתמש רואה בחיפוש, בהמלצות, ברשימות ובמודעות. הוא צריך להיות מזוהה, ברור ומובחן גם כשהוא מוצג בגודל קטן. אייקון עשיר בפרטים יכול להיראות נהדר על מסך עיצוב ולהפוך לכתם צבע כשהוא מופיע בין עשרים אפליקציות אחרות.
צילומי המסך הם בדרך כלל נכס ההמרה החשוב ביותר. הם צריכים להציג במהירות את התועלות, הפיצ'רים והחוויה. ב-App Store אפשר להעלות עד עשרה צילומי מסך, וכאשר אין App Preview, אחד עד שלושה מהצילומים הראשונים עשויים להופיע כבר בתוצאות החיפוש.
לכן הצילומים הראשונים צריכים לבצע שתי עבודות. למשוך תשומת לב עוד לפני הכניסה לעמוד, ואז להסביר את הערך לאחר הכניסה.
כדאי לבנות אותם כרצף הגיוני. הצילום הראשון מציג את ההבטחה המרכזית, הבאים אחריו מראים כיצד היא מתממשת במוצר. משתמשים רבים לא יגיעו לצילום השמיני כדי לגלות את הפיצ'ר החשוב ביותר. החיים קצרים וגם הסבלנות בחנויות אפליקציות.
Apple מאפשרת להוסיף עד שלושה App Preview Videos. סרטון מתאים במיוחד למשחקים, כלי עריכה, אפליקציות כושר ומוצרים שבהם תנועה, אינטראקציה או מעבר בין שלבים הם חלק מהערך. הסרטון עשוי להתנגן אוטומטית ללא קול, ולכן המסר צריך להיות מובן גם בלי קריינות.
ב-Google Play קיימים Feature Graphic, Screenshots ו-Promo Video. ה-Feature Graphic מקבל חשיבות מיוחדת כאשר משתמשים גם בסרטון קידומי, ויכול להופיע במשטחי תצוגה רלוונטיים.
Apple מציעה גם In-App Events לקידום אירועים מוגבלים בזמן, כגון תחרות, עונה חדשה, תוכן חי או עדכון משמעותי. האירועים יכולים להופיע בעמוד המוצר, בחיפוש ובמשטחי גילוי. Product Page Header מאפשר להציג בחלק העליון של העמוד תמונה או וידאו שמדגישים מותג, תוכן עונתי או פיצ'ר מרכזי.
מתי Video תורם להמרה בחנויות
סרטון בעמוד אפליקציה הוא כלי הדגמה. כאשר הפונקציונליות מובנת טוב יותר בתנועה, הוא יכול לקצר את ההסבר ולעזור למשתמש לקבל החלטה.
בקטגוריה שבה המשתמשים אינם רגילים לצפות בווידאו, או במוצר שהערך שלו עובר טוב יותר בשלושה צילומי מסך, הסרטון עלול לתפוס מקום בלי לתרום. סרטון איטי, עמוס או לא ברור יכול גם לפגוע בהמרה.
הדרך לקבל החלטה היא להשוות ביצועים. גרסה עם וידאו מול גרסה בלעדיו, סרטון אחד מול סרטון אחר, או רצף צילומי מסך שונה.
בדיקות A/B הופכות דעה לנתון
ב-App Store כלי הבדיקות נקרא Product Page Optimization. אפשר ליצור עד שלוש וריאציות מול עמוד המוצר המקורי ולבדוק App Icon, Screenshots, App Preview Videos, Description ונכסים נוספים. App Store Connect מציגה נתונים סטטיסטיים, רמת ביטחון והערכה לגבי הווריאציה המובילה.
ב-Google Play הכלי נקרא Store Listing Experiments. אפשר לבצע ניסויים גרפיים על האייקון, ה-Feature Graphic וצילומי המסך, וגם ניסויים מקומיים שבהם בודקים טקסטים ותיאורים לפי שפה או שוק.
הגמישות של Google רחבה יותר בכל הקשור לבדיקת טקסטים ולוקליזציות. בשתי הפלטפורמות העיקרון זהה: משנים רכיב מוגדר, מודדים את השפעתו על ההתקנות ומקבלים החלטה לפי התוצאה.
דירוגים וביקורות כחלק מהמוצר
הדירוג שמופיע ליד האייקון משפיע על האמון, על יחס ההמרה ועל הנראות בחנות. מבחינת המשתמש, הוא מספק תשובה מהירה לשאלה אם אנשים אחרים מרוצים מהאפליקציה.
לכן איסוף Ratings ו-Reviews צריך להיות חלק מתוכנן ממסע המשתמש. הרגע המתאים לבקש דירוג הוא לאחר שהמשתמש קיבל ערך: השלים משימה, סיים פעולה, הגיע להישג או השתמש בהצלחה בפיצ'ר מרכזי.
ב-iOS הבקשה מתבצעת באמצעות `SKStoreReviewController`. Apple מאפשרת להציג בקשה עד שלוש פעמים בתקופה של 365 ימים לאותו משתמש. ב-Google Play משתמשים ב-In-App Review API. Google מנהלת מכסה דינמית, ולכן קריאה ל-API אינה מבטיחה שהחלון יוצג בכל פעם.
מעבר לאיסוף הדירוגים, צריך לנהל את הביקורות עצמן. Play Console מאפשרת לנתח אותן לפי מדינה, שפה, גרסת אפליקציה, גרסת Android, מכשיר ומפעיל סלולר. הפילוחים האלה יכולים לחשוף בעיה נקודתית. למשל, גרסה מסוימת שקורסת במכשיר מסוים ומייצרת פתאום גל של דירוגי כוכב אחד.
תגובה לביקורת חשובה גם היא. היא מראה למשתמשים שהמפתח מקשיב, ולעיתים גורמת למשתמש לעדכן את הציון לאחר שהבעיה נפתרה.
משבר דירוג נראה אחרת בכל חנות
מנגנון חישוב הדירוג שונה בין App Store לבין Google Play, ולהבדל הזה יש משמעות מעשית בזמן תקלה.
ב-App Store הדירוג המסכם מוצג בנפרד לכל טריטוריה, וההיסטוריה שנצברה ממשיכה להשפיע עליו. אפליקציה ותיקה עם הרבה דירוגים נהנית מסוג של שכבת הגנה: גל קטן של ציונים שליליים לא בהכרח יפיל את הממוצע מיד.
Apple מאפשרת לאפס את הדירוג המסכם בעת שחרור גרסה חדשה. האיפוס משפיע על הציון המוצג, אך הביקורות הכתובות הישנות נשארות בעמוד.
ב-Google Play הדירוג הגלוי נותן משקל גבוה יותר לדירוגים עדכניים. Play Console מציגה בנפרד גם Lifetime Average Rating, שהוא הממוצע ההיסטורי של כל הדירוגים מאז ההשקה.
המשמעות פשוטה. גרסה בעייתית יכולה לפגוע בדירוג הגלוי ב-Google Play במהירות. לאחר תיקון הבעיה, גל חדש של דירוגים חיוביים יכול גם לשקם אותו מהר יותר, משום שהמשוב העדכני מקבל משקל משמעותי.
כלי App Rating Simulator של Topanda מאפשר לבדוק תרחישים כאלה. אפשר לחשב כמה דירוגים נדרשים כדי להגיע לציון יעד, לבחון השפעה של משבר עתידי ולבדוק מה יקרה לאחר שיפור במוצר או בתהליך בקשת הדירוג. עבור Google Play הכלי משתמש במודל סימולציה עם מחצית חיים של 60 יום כדי לייצג ירידה במשקלם של דירוגים ישנים.
כדאי להתייחס לדירוג כאל מדד מוצר. ירידה חדה היא לעיתים סימפטום לתקלה, לביצועים טכניים חלשים או לשינוי שהמשתמשים לא הבינו. צוות שיווק יכול למדוד את הנזק. צוות המוצר צריך לטפל בסיבה.
חשיפה אורגנית מעבר לתוצאות החיפוש
אפליקציה יכולה לקבל תנועה גם כשהמשתמש לא חיפש את שמה או מילת מפתח שעליה היא מדורגת.
ב-App Store מופיע אזור המלצות בשם You Might Also Like. ב-Google Play קיימים משטחי המלצה וגילוי משלה. הופעה ליד אפליקציה גדולה ורלוונטית יכולה להעביר לעמוד תנועה אורגנית משמעותית.
המנגנונים של Apple ושל Google שונים, והם מתבססים על אותות כמו רלוונטיות, קטגוריה, איכות, דירוגים, ביקורות, שפה, מיקום, סוג המכשיר והעדפות המשתמש. ב-Google Play גם איכות טכנית וחוויית המשתמש משפיעות על הסיכוי לקבל נראות בולטת.
כלי App Visibility Viewer של Topanda מאפשר לבדוק באילו משטחי גילוי והמלצה מופיעה אפליקציה, ולבחון לצד אילו אפליקציות היא מוצגת. הוא שימושי גם למחקר מתחרים. אם מתחרה מקבל חשיפה שוב ושוב ליד האפליקציות הגדולות בקטגוריה, כדאי לפחות לדעת שזה קורה.
ערוץ נוסף הוא ה-Featured. אפל יכולה להציג אפליקציות ברשימות, אוספים, סיפורים, App of the Day, Editors’ Choice ואזורים נוספים. אפשר להגיש Featuring Nomination דרך App Store Connect עבור השקה, עדכון משמעותי, תוכן חדש או אירוע בתוך האפליקציה.
בחירת האפליקציות מתחשבת בין היתר בחוויית המשתמש, איכות הממשק, ייחודיות, חדשנות, נגישות, לוקליזציה, נכסי עמוד המוצר ודירוגים חיוביים. Featuring יכול לייצר הרבה מאוד תנועה, אך הוא מתחיל במוצר ובעמוד שראויים לחשיפה הזאת.
לוקליזציה: אפליקציה גלובלית צריכה יותר מעמוד מתורגם
החנויות פועלות באמצעות Storefronts מקומיים. למדינות ולשווקים שונים יש שפות, ביטויי חיפוש, הקשרים תרבותיים, ציפיות ממוצר והרגלי רכישה שונים.
לוקליזציה איכותית כוללת התאמה של:
- Title, Subtitle ו-Keywords
- Description ו-Promotional Text
- Screenshots ו-App Preview Videos
- דוגמאות שימוש
- הצעת הערך והמסרים
- מחירים, מטבעות והצעות מסחריות
תרגום מילולי יכול להיות תקין מבחינה לשונית ועדיין לפספס את הדרך שבה אנשים מחפשים ומדברים בשוק המקומי. לכן כדאי לבצע מחקר מילות מפתח נפרד לכל שפה ושוק, ולא לתרגם את רשימת הביטויים האנגלית ולהכריז על סיום העבודה.
Apple מאפשרת ליצור עד 70 Custom Product Pages. כל עמוד יכול לכלול נכסים, Promotional Text, מילות מפתח ו-Deep Link ייחודיים. Google מאפשרת Local Store Listings ו-Custom Store Listings לפי שפה, מדינה, קמפיין או קהל.
היכולות האלה הופכות את עמוד החנות לנכס שאפשר להתאים גם למקור התנועה. משתמש שהגיע מקמפיין על פיצ'ר מסוים יכול לראות עמוד שממשיך בדיוק את אותו מסר.
קראו את מקרי הבוחן שלנו וגלו למה הלקוחות שלנו ממליצים עלינו
רכישת משתמשים בתשלום לקידום אפליקציות
לאחר שבנינו עמוד חנות שמסוגל לקבל תנועה ולהמיר אותה, אפשר להגדיל את החשיפה באמצעות User Acquisition.
יש שתי דרכים מרכזיות לבנות את המסע.
ב-App-to-App המשתמש רואה מודעה במכשיר הנייד ולוחץ ישירות לעמוד האפליקציה ב-App Store או ב-Google Play. המסלול קצר: מודעה, חנות, התקנה.
היתרון הוא מעט חיכוך. החיסרון הוא שהשליטה במסר מסתיימת כמעט ברגע הלחיצה. עמוד החנות צריך להמשיך את ההבטחה של המודעה ולסגור את ההמרה.
ב-Web-to-App המשתמש עובר קודם לאתר או ל-Landing Page, ורק לאחר מכן לחנות או לאפליקציה. המסלול ארוך יותר, אך הוא מעניק שליטה רחבה יותר בתוכן, בהצעה, במדידה ובקריאה לפעולה.
Landing Page יכול להתאים את עצמו למילת החיפוש, לקהל, לפיצ'ר, למחיר או לבעיה הספציפית שהמשתמש רוצה לפתור. אפשר למדוד בו צפייה בתוכן, לחיצה על CTA, השארת פרטים, התחלת תשלום ורכישה.
Deep Links משלימים את המנגנון עבור משתמשים שכבר התקינו את האפליקציה. App Links באנדרואיד ו-Universal Links ב-iOS מאפשרים לשלוח אותם למסך הרלוונטי בתוך האפליקציה במקום לעמוד הבית או לחנות.
ב-Google Search עמוד הנחיתה מחבר את כל המסע
Web-to-App מתאים במיוחד לקמפיינים ב-Google Search.
בקמפיין Search אפשר להפנות את כותרת המודעה ל-Landing Page ייעודי, ולהוסיף App Asset שמוביל ישירות לחנות. כאשר מוגדרים App Assets לשתי הפלטפורמות, Google יכולה להציג למשתמש את החנות המתאימה למכשיר שלו.
עמוד הנחיתה מאפשר ליצור רצף ברור:
- המשתמש מחפש ביטוי מסוים.
- המודעה עונה על החיפוש.
- עמוד הנחיתה מרחיב בדיוק את אותו המסר.
- הקריאה לפעולה מתאימה לשלב שבו המשתמש נמצא.
- המשתמש נשלח לחנות המתאימה למערכת ההפעלה.
- לאחר ההתקנה הוא מגיע לתוכן הרלוונטי באמצעות Deep Link, כאשר התשתית תומכת בכך.
הרצף הזה חשוב כי Search מבוסס על כוונה. משתמש שמחפש פיצ'ר מסוים מצפה לקבל תשובה ממוקדת. עמוד חנות כללי מתקשה לפעמים לענות על כמה כוונות שונות בו-זמנית. Landing Pages ועמודי חנות מותאמים מאפשרים לפצל את המסרים ולשמור על התאמה לאורך המסע.
רכישה ב-Web משנה את הכלכלה וגם את האחריות
Web-to-App מאפשר במקרים מסוימים להשלים את הרכישה באתר לפני ההתקנה או מחוץ למערכת התשלום של החנות.
הגישה הזאת נותנת למפתח שליטה רחבה בעמוד המכירה, במחיר, בקופונים, ב-Upsell, ב-Cross-sell, בתנאי הניסיון ובאיסוף פרטי הלקוח. במקרים מסוימים היא גם משנה את מבנה העלויות, משום שעמלות על עסקאות דיגיטליות בחנויות עשויות להגיע עד 30% במסלולים מסוימים. שיעור העמלה בפועל תלוי בפלטפורמה, במדינה, בסוג העסקה, בהכנסות ובתוכנית המפתח. Google ו-Apple מציעות שתיהן מסלולי עמלה מופחתת (15% במקום 30%) למפתחים קטנים, כך שהעמלה המדויקת תלויה בגודל העסק ובמודל ההכנסות שלו.
החיסכון בעמלה מגיע עם אחריות תפעולית. כאשר התשלום מתבצע מחוץ לחנות, המפתח נדרש לנהל סליקה, אבטחת תשלום, תאימות PCI-DSS כאשר מטפלים בפרטי כרטיס, חיובים חוזרים, ביטולים, Refunds, מחלוקות, מיסוי, חשבוניות, המרות מטבע ותמיכת לקוחות.
הבחירה היא החלטה עסקית. חברה עם תשתית Billing ותפעול מתאימה יכולה להרוויח מהשליטה ומהחיסכון. מצד שני, צוות קטן עלול לגלות שהוא חסך עמלה וקיבל בתמורה מחלקת כספים, תמיכה וניהול סיכונים שלא תכנן להקים בכלל.
Apple Ads מקלה על המדידה ב-iOS
Apple Ads היא ערוץ חשוב לרכישת משתמשי iOS, בעיקר משום שהיא פועלת בתוך סביבת App Store ומספקת מסלול אטריביושן ייעודי לקמפיינים שלה.
Apple Ads Attribution API משלב את AdServices עם API שרתי ומחזיר נתוני שיוך לפי מבנה הקמפיינים. לצורך אטריביושן בסיסי של התקנות לקמפיין, Apple Ads אינה נשענת על זיהוי משתמש בין אפליקציות של חברות שונות.
בפלטפורמות כמו Google ו-Meta התמונה מורכבת יותר בגלל ATT, קיצור של App Tracking Transparency. המנגנון מחייב אפליקציות לבקש אישור לפני Tracking בין אפליקציות, אתרים ונכסים של חברות שונות לצורכי פרסום ומדידה.
כאשר המשתמש אינו מאשר Tracking, אין גישה ל-IDFA והיכולת למדוד אותו ברמת המשתמש מוגבלת. המדידה נשענת אז על שילוב של נתונים ממשתמשים שהסכימו, אירועים בתוך האפליקציה, מדידה מצרפית, מודלים סטטיסטיים ומסגרות הפרטיות של Apple.
MMP ו-SKAN מחברים בין האירועים לקמפיינים
MMP, או Mobile Measurement Partner, הוא גורם מדידה שמרכז אירועים מהאפליקציה ומחבר בין מקורות פרסום שונים.
הוא מסייע בכמה משימות:
- אטריביושן של התקנות והמרות
- דדופליקציה בין מקורות פרסום
- ריכוז אירועים מהאפליקציה
- העברת אירועים לרשתות הפרסום
- תמיכה באופטימיזציה של הקמפיינים
ב-iOS, מדידה מודרנית משלבת גם את SKAdNetwork ואת מסגרות AdAttributionKit של Apple. המערכות מאפשרות למדוד התקנות ואירועים לאחר התקנה באופן מצרפי ושומר פרטיות.
באטריביושן מבוסס קליק, התקנה יכולה להיות מיוחסת כאשר המשתמש מתקין עד 30 יום לאחר הלחיצה. באטריביושן מבוסס צפייה, החלון יכול להגיע עד 24 שעות לאחר הצפייה. ה-Postback מתקבל בדרך כלל בתוך 24 עד 48 שעות מהפעלת האפליקציה.
Conversion Values משמשים כדי לתרגם את ההתנהגות של המשתמש לאות מדידה. אפשר, למשל, לייצג באמצעותם:
- השלמת Onboarding
- התחלת Free Trial
- הוספת אמצעי תשלום
- רכישה
- התחלת מנוי
- רמת הכנסה
- חיזוי של ערך עתידי
המבנה שמגדיר אילו פעולות מקבלות איזה ערך נקרא Conversion Value Schema. הוא צריך לשקף את האירועים שבאמת חשובים לעסק ולספק מספיק נפח כדי שמערכות הפרסום יוכלו ללמוד.
מערכת הפרסום לומדת את מה שביקשתם ממנה
בחירת אירוע ה-Optimization היא אחת ההחלטות החשובות בקמפיין להורדת אפליקציה.
מערכת הפרסום מחפשת משתמשים שצפויים לבצע את האירוע שהוגדר לה. אם בחרנו Install, היא תחפש אנשים שנוטים להתקין. אם בחרנו Purchase, היא תחפש אנשים שדומים יותר לרוכשים. הבעיה היא שלרכישות יש לעיתים מעט מדי נפח, בעוד התקנות מספקות הרבה מידע אך מעט מאוד אינדיקציה לערך עסקי.
אירוע אופטימיזציה טוב צריך לעמוד בשני תנאים:
- להיות קרוב ככל האפשר לתוצאה העסקית החשובה.
- להתרחש בתדירות שמספיקה למערכת לצורך למידה.
Start Trial יכול להיות נקודת פתיחה סבירה. הוא מעיד שהמשתמש התקדם מעבר להתקנה והביע עניין ממשי במוצר. האיכות שלו תלויה בקשר בין התחלת הניסיון לבין רכישה עתידית.
אם פחות מ-30% מהמשתמשים שמתחילים Trial הופכים לרוכשים, ייתכן שהאירוע מוקדם מדי. האלגוריתם יקבל הרבה דוגמאות של מתחילי ניסיון, אך חלק גדול מהן לא ייצג את סוג המשתמש שבאמת מייצר הכנסה.
אפשר לבחור אירוע איכותי יותר, כגון:
- Trial Qualified
- השלמת Onboarding בעומק מסוים
- שימוש חוזר בפיצ'ר מרכזי
- חיבור אמצעי תשלום
- הגעה לרמת שימוש מוגדרת
- פעולה מוקדמת שמנבאת רכישה
המטרה היא למצוא נקודה באמצע המשפך. מוקדמת מספיק כדי לייצר נפח, וקרובה מספיק להכנסה כדי להיות שימושית.
Signal Engineering: תחזית ערך במקום המתנה לרכישה
Signal Engineering הוא השלב המתקדם של אותה חשיבה. במקום לבחור אירוע קיים, בונים Signal חדש שמייצג הסתברות לערך עתידי.
התהליך מתחיל בהגדרת התוצאה העסקית שרוצים לחזות. זו יכולה להיות רכישה, מנוי משלם, חידוש מנוי, הכנסה ביום 30 או LTV.
לאחר מכן מנתחים נתונים היסטוריים ומחפשים התנהגויות מוקדמות שמבדילות בין משתמשים בעלי ערך גבוה לבין יתר המשתמשים. לדוגמה, ייתכן שמשתמשים שמשלימים שלושה שלבים ב-Onboarding, חוזרים לאפליקציה ביום השני ומשתמשים פעמיים בפיצ'ר מרכזי הופכים למנויים בשיעור גבוה במיוחד.
על בסיס ההתנהגויות האלה בונים מודל חיזוי או כלל זכאות. כאשר משתמש חדש מגיע לסף שהוגדר, נוצרת עבורו פעולה חדשה, למשל:
- `PredictedSubscriber`
- `PredictedPayer`
- `PredictedLTV`
- `HighIntentTrialUser`
- `QualifiedOnboardingComplete`
את האירוע שולחים ל-MMP, למערכות הפרסום ובמידת הצורך גם ל-Conversion Value Schema. מכאן האלגוריתם יכול לבצע אופטימיזציה לפי משתמשים בעלי הסתברות גבוהה להפוך ללקוחות, עוד לפני שהרכישה עצמה התרחשה.
זה פותר פער מוכר. Purchase הוא Signal איכותי אך מאוחר ונדיר. Install הוא Signal מהיר ונפוץ אך חלש. אירוע חיזוי מנסה לשלב בין המהירות של אירוע מוקדם לבין האיכות של תוצאה עסקית מאוחרת.
בסוף צריך לחבר את כל השרשרת
קידום אפליקציה מתחיל בעמוד חנות שאפשר למצוא ושמסוגל להמיר. הוא ממשיך בניהול קמפיינים ממומנים והאופטימיזציה שלהם שמביאים את המשתמשים הנכונים, בתשתית שמודדת את המסע ובאירוע אופטימיזציה שמייצג ערך עסקי אמיתי.
סדר העבודה המעשי נראה כך:
- בונים מחקר מילות מפתח ייעודי לכל חנות ושוק.
- מסדרים את המטא-דאטה לפי רלוונטיות, ביקוש ותחרות.
- משפרים את האייקון, צילומי המסך ושאר נכסי העמוד.
- מריצים A/B Tests במקום להסתמך על תחושות.
- מטמיעים תהליך מסודר לאיסוף ולניהול דירוגים.
- עוקבים אחר Similar Apps, המלצות ו-Featuring.
- מתאימים את העמוד לכל שפה, מדינה ומקור תנועה.
- בוחרים בין App-to-App ל-Web-to-App לפי מסע המשתמש והמודל העסקי.
- מחברים MMP, אירועי אפליקציה ומדידת iOS.
- מכוונים את הקמפיינים לאירוע שמנבא לקוחות, הכנסה ו-LTV.
המדד החשוב אינו מספר ההתקנות בפני עצמו. אפליקציה יכולה לקנות המון התקנות זולות ולהישאר עם מעט מאוד לקוחות. המערכת כולה צריכה להביא משתמשים רלוונטיים, לשכנע אותם להתקין, להוביל אותם לערך במוצר ולזהות מוקדם מי מהם צפוי להפוך ללקוח משלם. שם מתחיל שיווק אפליקציות שעובד באמת.
קידום אפליקציות הוא שילוב של ASO לשיפור הנראות וההמרה בחנויות, רכישת משתמשים בתשלום ומדידה שמכוונת את הקמפיינים למשתמשים בעלי ערך עסקי.
מחקר מילות מפתח לאפליקציה צריך להתבסס על חיפושים בתוך App Store ו-Google Play, משום שכוונת המשתמש שם היא למצוא אפליקציה להתקנה.
כדי לקדם אפליקציה באופן עקבי, יש לחבר בין עמוד חנות שממיר, מקורות תנועה, מדידה ואירוע אופטימיזציה שמנבא הכנסה.
בחירת מודל ההכנסות אינה פרט טכני, והיא משפיעה ישירות על הכלכלה ועל האחריות של מכירה מחוץ לחנות; להרחבה ראו מודלים עסקיים ומוניטיזציה לסטארטאפים.
מקורות וכלים להמשך
כדי לבדוק באילו איזורי גילוי והמלצה האפליקציה מופיעה, אפשר להיעזר ב-כלי לבדיקת נראות אפליקציות.
לריכוז הכלים שהוזכרו כאן ולכלים נוספים לקידום ומחקר, ראו כלי השיווק והמחקר של Topanda.
למחקר הביטויים, שיפור המטא-דאטה ובחינת השפעת הדירוגים, ראו כלי מחקר מילות מפתח, אופטימיזציית מטא-דאטה וסימולציית דירוגים.
לפני שבוחרים ביטויים, כדאי למפות את המתחרים ואת האפליקציות הדומות באמצעות כלי לניתוח נישה ומתחרים.
להעמקה במנגנוני החשיפה האורגנית ובתפקיד של Apple Ads, ראו מדריך לנראות אפליקציות ומדריך Apple Ads.
בחירת אירוע האופטימיזציה צריכה להתחבר למטרה העסקית של הקמפיין, בדיוק כפי שמוסבר ב-עקרונות לאופטימיזציית PPC.
לנושאים משלימים של ASO, בדיקות בחנות, עמלות ומדידת אפליקציות, ראו משאבים על ASO, בדיקות בחנות, עמלות ומדידת אפליקציות.
Apple מפרטת את איזורי הגילוי והעקרונות הרלוונטיים ב-הנחיות Apple לגילוי אפליקציות ב-App Store.
כדי להבין כיצד Google Play משתמשת במידע שבעמוד החנות לצורכי גילוי, רלוונטיות ודירוג, ראו הנחיות Google Play לגילוי ולדירוג אפליקציות.
ב-App Store אפשר לבחון וריאציות של עמוד המוצר דרך תיעוד Product Page Optimization של Apple.
ב-Google Play הניסויים בעמוד החנות מתועדים ב-תיעוד Store Listing Experiments של Google Play.
לפרטים על מדידת התקנות ואטריביושן בפרסום ב-iOS, ראו תיעוד Apple למדידת אטריביושן לפרסום.
קידום ושיווק אפליקציות שאלות ותשובות:
איך הכי נכון לקדם אפליקציה חדשה?
בדרך כלל כדאי לשלב בין ASO לבין User Acquisition. ה-ASO עוזר לאפליקציה להופיע בחיפושים ובאזורים נוספים בחנויות ולשפר את יחס ההמרה בעמוד. קמפיינים ממומנים מאפשרים להביא משתמשים חדשים באופן יזום וללמוד אילו קהלים ומקורות מייצרים משתמשים בעלי ערך.
מה עדיף לקידום אפליקציה: ASO או פרסום ממומן?
אין צורך לבחור רק באחד מהם. ASO ופרסום ממומן ממלאים תפקידים שונים ומשלימים זה את זה. ASO משפר את הנראות ואת הביצועים של עמוד האפליקציה, בעוד פרסום ממומן מאפשר להביא משתמשים חדשים בקנה מידה גדול יותר ולשלוט בצורה טובה יותר בקצב רכישת המשתמשים.
איך מביאים לאפליקציה משתמשים משלמים ולא רק התקנות?
צריך למדוד פעולות שמתרחשות לאחר ההתקנה ולתת למערכות הפרסום Signal שמייצג ערך עסקי. במקום להתמקד רק ב-Install, אפשר לבצע אופטימיזציה לאירועים כמו התחלת Trial, רכישה או פעולה אחרת שנמצאה קשורה לסיכוי גבוה יותר של המשתמש להפוך ללקוח משלם.
איך בוחרים מילות מפתח לקידום אפליקציה ב-App Store וב-Google Play?
מילות מפתח צריכות לשלב בין רלוונטיות לאפליקציה, ביקוש בחנות ורמת התחרות. חשוב להשתמש בנתוני חיפוש שמגיעים מעולם האפליקציות ולא להסתמך רק על כלי SEO רגילים, מכיוון שהתנהגות החיפוש ב-App Store וב-Google Play שונה מחיפוש רגיל בגוגל.
איך יודעים אם שיווק האפליקציה באמת עובד?
לא מסתכלים רק על מספר ההתקנות. צריך לחבר בין מקור המשתמש לבין מה שהוא עושה לאחר ההתקנה ולבחון מדדים כמו Conversion Rate, Trial, רכישות, מנויים, CPA, ROAS ו-LTV. המטרה היא להבין אילו ערוצים וקמפיינים מביאים משתמשים שמייצרים ערך אמיתי.
קראו את מקרי הבוחן שלנו וגלו למה הלקוחות שלנו ממליצים עלינו
השאירו פרטים לקבלת ייעוץ טלפוני והצעת מחיר
טלפונים:
054-7505353 (רוברט)
054-5284807 (יורי)
אימייל:
info@topanda.co