למשווקים סלולריים, ניווט במודלי תמחור מורכבים של פלטפורמות מעורבות לקוחות יכול להיות אתגר. האם ברצונכם לקבוע את מודל התמחור המושלם עבור האפליקציה שלכם, תוך הימנעות מתשלום יתר? במאמר זה נדריך אתכם בין היתרונות והחסרונות של הגישות הקיימות.
פלטפורמות מעורבות לקוחות בונות את רמות התמחור שלהן על בסיס התרחישים הנדרשים, תוך התחשבות בבשלות האפליקציות והמשימות שהן שואפות לטפל בהן. אחד הקריטריונים המרכזיים מבוסס על שלב הצמיחה של האפליקציה, שניתן למדוד לפי ספירת המשתמשים או המכשירים. בואו נצלול לפרטים.
מודלי תמחור המבוססים על MAU
פלטפורמות מעורבות לקוחות רבות משתמשות בספירת MAU (Monthly Active Users — משתמשים פעילים חודשיים) כשיטת חיוב.
בשוק הסלולרי, MAU מייצג את מספר המשתמשים הייחודיים המתקשרים עם אפליקציה במשך חודש. ההגדרה של מה שנחשב למעורבות עשויה להשתנות, אך היא בדרך כלל מתמקדת בפעולות משתמש משמעותיות כגון פתיחת האפליקציה, כניסה למערכת, ביצוע רכישה, ביצוע סשן, או צפייה בדף.
עם זאת, כאשר מדובר בפלטפורמות מעורבות לקוחות, הן לעיתים קרובות מיישמות פרשנויות משלהן ל-MAU, שעלולות להיות שונות מהגדרת השוק הסטנדרטית או לכלול פרמטרים נוספים. הדבר מוביל לגורמים נסתרים ומורכבויות שעסקים צריכים להיות מודעים אליהן. בואו נבחן פרשנויות אלה כדי להבין טוב יותר את השלכותיהן על התמחור.
1. מודל תמחור מבוסס MAU ונקודות נתונים (למעשה, על נקודות נתונים)
בשימוש של: Braze, CleverTap.
בגישה זו, רמות התמחור מבוססות על ספירת ה-MAU וכוללות מגבלה מוגדרת מראש של “נקודות נתונים” עבור כל MAU.
נקודות נתונים קשורות למידע המתועד בפרופילי משתמשים וכוללות פעולות משתמש שונות באפליקציה: צפיות בדף, לחיצות על קישור ורכישות — כמו גם שינויים בפרופילי משתמשים או מעברים לסגמנט אחר.
העובדה שקיימת מגבלה על מספר נקודות הנתונים עבור כל MAU לעיתים קרובות אינה מצוינת במפורש, לכן תמיד כדאי לעיין בתיעוד הספק ולדרוש שקיפות בחיוב.
משתלם עבור: אפליקציות שמשתמשות בפלטפורמות מעורבות לקוחות בעיקר למטרות אנליטיקה ולא לקמפיינים של מעורבות.
לעומת זאת, אפליקציות עם מעורבות משתמשים גבוהה וניסויי שיווק תכופים (בדיקות A/B/n, ניסויים עם תגים/סגמנטים) עלולות להתקשות להעריך במדויק את השימוש בנקודות נתונים.
דוגמה: נניח שבתוכנית שבחרתם, יש לכם 700 נקודות נתונים המוקצות עבור MAU אחד. נקודות הנתונים הללו עשויות להתחלק כך:
- 100 מאפייני משתמש שמשתנים בכל חודש;
- 50 אירועים, עם 10 מאפיינים לכל אירוע, בסך הכל 500 נקודות נתונים.
כעת, הקצאה זו עשויה להספיק לצרכים שלכם. אך מה יקרה אם אחרי חודש תחליטו להתחיל לאסוף אירועים חדשים ולא תתאימו יותר למגבלות? בסופו של דבר, עם גישה זו אתם מוגבלים מבחינת כמות הנתונים שתוכלו להכניס לפעולה.
| 🤔 מגבלות מודל התמחור המבוסס על MAU ונקודות נתונים | ||
|---|---|---|
| חיזוי נמוך לשימוש בנקודות נתונים ולעלות הסופית: חיזוי מתי מגבלת נקודות הנתונים לא תספיק יותר לצרכים שלכם הוא מאתגר — זה יכול לקרות בצורה בלתי צפויה ופתאומית. כדי להתמודד עם אתגר זה, עליכם לחזות את כל השינויים באירועים מותאמים אישית ובמאפייני משתמשים לטווח הארוך. |
2. מודל תמחור מבוסס MTU (Monthly Tracked Users — משתמשים עוקבים חודשיים)
בשימוש של: MoEngage, Mixpanel, Amplitude, mParticle.
מודל התמחור המבוסס על MTU הוא דרך לחשב חיוב על בסיס מספר המשתמשים שמבצעים אירוע מזכה אחד או יותר בתוך חודש קלנדרי.
כל פלטפורמה מגדירה אירוע מזכה לפי הקריטריונים שלה. יש לציין שהגדרה זו עשויה לכלול אירועים שאינם נוצרים על ידי המשתמשים עצמם, ולכן הם אינם משקפים את הספירה בפועל של המשתמשים המעורבים.
משתלם: כאשר הגדרת ה-MTU של הפלטפורמה תואמת את הבנת השוק של MAU. במקרים כאלה, המודל מציע יכולת חיזוי טובה.
| 🤔 מגבלות מודל התמחור המבוסס על MTU | ||
|---|---|---|
| ROI נמוך יותר: מכיוון שספירת ה-MTU עשויה שלא להיות שווה למספר המשתמשים המעורבים, ה-ROI של קמפיינים שיווקיים עלול להיות נמוך יותר. |
כדי להתגבר על כל אי-הוודאויות סביב מודלי תמחור המבוססים על פרשנות ספירת MAU, עולה אפשרות חלופית: מודל תמחור מבוסס על ספירת מכשירים.
מודל תמחור מבוסס על מנויי פוש
בשימוש של: Pushwoosh, OneSignal.
מודל תמחור זה מחשב את עלות פלטפורמת מעורבות הלקוחות על בסיס המספר הכולל של מנויי פוש (מכשירים עם טוקני פוש תקינים). תוכניות תמחור המבוססות על ספירת מכשירים בדרך כלל מגיעות עם נקודות נתונים ללא הגבלה.
משתלם עבור:
- אפליקציות שמבצעות ניסויי שיווק רבים (הרצת בדיקות A/B/n, יצירת תגים וסגמנטים מרובים) ורוצות להימנע מתשלום יתר עבור נקודות נתונים מיותרות הנובעות מפעילויות אלה.
- אפליקציות שערוץ המעורבות העיקרי שלהן הוא הודעות פוש ורוצות להבטיח שהן משלמות רק עבור משתמשים הניתנים להגעה.
דוגמה: תוכנית Base של Pushwoosh כוללת הקצאה של 1,000 מנויי פוש בחינם, כאשר כל 1,000 מנויים נוספים בעלות של $3 לחודש. מודל התמחור המבוסס על מנויי פוש מבטיח שקיפות ומאפשר לעסקים לקבל החלטות מושכלות.
| ✅ יתרונות | 🤔 מגבלות |
|---|---|
| _ חיוב צפוי: אפליקציות אינן צריכות לחזות את השימוש בנקודות הנתונים שלהן; _ ROI גבוה יותר לקמפיינים של הודעות פוש: אפליקציות מחויבות אך ורק עבור מספר המשתמשים שניתן להגיע אליהם דרך הודעות פוש. * גישה לקהל השלם: עבור המחיר שאתם משלמים, אתם מקבלים גישה לקהל השלם ויכולים מאוחר יותר לערב מחדש משתמשים שלא אינטראקציה עם האפליקציה, כל זאת ללא הוצאות נוספות. | * קשיי ניווט: מכיוון שמשווקים סלולריים רגילים לתכנן את אסטרטגיות המעורבות שלהם על בסיס MAU, ייתכן שיהיה להם מאתגר לנווט ברמות תמחור המבוססות על מדד שונה, כגון מספר מנויי הפוש. |
💡 בעוד OneSignal ו-Pushwoosh חולקים גישה מבוססת מנויים, הבדל מרכזי עולה באסטרטגיית תמחור המסרים בתוך האפליקציה. בניגוד לתמחור הקבוע של Pushwoosh, OneSignal גובה תשלום עבור חשיפות בתוך האפליקציה, מה שעלול לגרום לעלויות משתנות. הבדל זה מדגיש את החשיבות של יכולת חיזוי תקציבי ומעורבות ללא הגבלות.
בחירת מודל התמחור המושלם עבור האפליקציה שלכם
אם כך, האם מודל תמחור מסוים מתאים לאפליקציה ספציפית תלוי בטקטיקות המעורבות של האפליקציה, כמו גם בפרטים של אסטרטגיית השיווק והתכנון הפיננסי שלה.
אפליקציות שמשתמשות בפלטפורמות מעורבות לקוחות יותר לצורכי אנליטיקה מאשר לקמפיינים של מעורבות יכולות להסתגל למודל המבוסס על נקודות נתונים.
מודל התמחור המבוסס על MTU יכול להציע חיוב צפוי במקרה שהגדרת MTU כוללת אך ורק אירועים שהופעלו על ידי משתמשים.
לבסוף, עבור אפליקציות המחפשות יעילות עלות תוך ניסוי בטקטיקות שיווק וטירגוט משתמשים דרך הודעות פוש, מודל התמחור המבוסס על מנויי פוש מוכיח את עצמו כבחירה אופטימלית.
מוכנים לדון בתמחור שלכם בפרטים? צרו קשר עם צוות Pushwoosh:
השוו את תוכניות Pushwoosh ובחרו את המתאימה לכם:
