הגדרת ניתוח קבוצות (Cohort Analysis) לאפליקציית מובייל

לעתים קרובות אנו רואים צוותים שמתמקדים ב-DAU בזמן שהם מפספסים את העובדה שהשימור (retention) יורד. הניסיון שלנו מראה: שימור יום 1 של 40% ושימור יום 7 של 20% מצביעים על בעיות שונות. ניתוח קבוצות (Cohort Analysis) הוא הדרך היחידה לראות התנהגות משתמשים אמיתית. הוא מראה כיצד משתמשים מאותה שבוע התקנה מתנהגים 7, 14, 30 ימים לאחר ההשקה הראשונה. DAU מצטבר מסתיר ירידה: אם משתמשים חדשים מגיעים מהר יותר מאשר ישנים עוזבים, DAU גדל—אבל השימור יורד. קבוצות חושפות זאת. המושג של ניתוח קבוצות נמצא בשימוש נרחב באנליטיקה למובייל. עם זאת, בפועל, עולות שגיאות אופייניות: מזהה משתמש לא יציב, בחירה שגויה של הפעולה הראשונה בעלת הערך, חוסר פילוח לפי גרסה. בעיות אלה מעוותות את הנתונים ומטעות את הצוות. צרו קשר כדי להגדיר ניתוח קבוצות בצורה נכונה.

מה דרוש לניתוח קבוצות

שני תנאים חובה: user_id יציב ואירוע הפעלה (activation event). בלעדיהם, לא ניתן לבנות קבוצות בצורה נכונה. חיסכון בתקציב הפרסום לאחר הגדרה מדויקת יכול להגיע ל-20%.

מזהה משתמש (User ID) חייב להישאר זהה לאחר התקנה מחדש של האפליקציה. אם אתה יוצר מזהה חדש בכל פעם, המשתמש תמיד יהיה בקבוצה חדשה. פתרונות:

• iOS: Keychain לאחסון UUID שנוצר (שורד מחיקת אפליקציה)
• Android: AccountManager או מזהה בצד השרת לאחר רישום
• לאחר אימות: Analytics.setUserId(serverUserId) — המשתמש נקשר לחשבון

אירוע הפעלה—הפעולה הראשונה שמראה את הערך של המוצר. לאפליקציות שונות יש אירועים שונים:

בחירת אירוע ההפעלה משפיעה על מה שהקבוצה מראה. app_open רחב מדי—כולל משתמשים מזדמנים. premium_purchase צר מדי לניתוח שימור של כל הקהל.

למה user_id יציב חשוב

ללא מזהה יציב, אי אפשר להבחין בין משתמש חדש למשתמש חוזר לאחר התקנה מחדש. זה מנפח את מספר המשתמשים החדשים ומנמיך את השימור. אנו מבטיחים הגדרה נכונה של Keychain ו-AccountManager בהתאם לפלטפורמה שלך. לפי הנתונים שלנו, 90% מהלקוחות היו עם user_id לא יציב לפני ההגדרה, מה שעיוות את הקבוצות ב-50% או יותר. פנו אלינו לביקורת על האנליטיקה הנוכחית שלכם—נעריך את יציבות ה-user_id ואת תקינות האירועים.

איך לבחור את אירוע ההפעלה?

אירוע ההפעלה צריך לשקף את הרגע הראשון שבו המשתמש מקבל ערך. לאפליקציית כושר, זה workout_completed, לא app_open. אחד הלקוחות שלנו (אפליקציית כושר) לאחר הגדרת קבוצות לפי workout_completed גילה שהשימור בקרב אלה שסיימו את האימון הראשון בתוך היומיים הראשונים היה גבוה ב-30%. שינינו את תהליך הקליטה כדי לדחוף לאימון הראשון, והשימור גדל ב-15% תוך חודש. צרו קשר לייעוץ לבחירת אירוע ההפעלה עבור האפליקציה שלכם.

יישום ניתוח קבוצות

Firebase / BigQuery—הגדרת ניתוח קבוצות

Firebase בונה תרשים שימור (Retention Chart) בקטע Analytics באופן טבעי, אך עם גמישות מוגבלת. לניתוח מעמיק, אנו מייצאים נתונים גולמיים ל-BigQuery דרך Firebase → Integrations → BigQuery. לאחר מכן SQL:

-- Когорта по неделям установки, retention на 7-й день
WITH cohorts AS (
    SELECT
        user_pseudo_id,
        DATE_TRUNC(MIN(PARSE_DATE('%Y%m%d', event_date)), WEEK) AS cohort_week,
        MIN(event_timestamp) AS first_open_ts
    FROM `project.analytics_*.events_*`
    WHERE event_name = 'first_open'
    GROUP BY user_pseudo_id
),
activity AS (
    SELECT DISTINCT
        user_pseudo_id,
        DATE_TRUNC(PARSE_DATE('%Y%m%d', event_date), WEEK) AS activity_week
    FROM `project.analytics_*.events_*`
    WHERE event_name = 'session_start'
)
SELECT
    c.cohort_week,
    DATE_DIFF(a.activity_week, c.cohort_week, WEEK) AS week_number,
    COUNT(DISTINCT c.user_pseudo_id) AS cohort_size,
    COUNT(DISTINCT a.user_pseudo_id) AS retained_users,
    ROUND(COUNT(DISTINCT a.user_pseudo_id) / COUNT(DISTINCT c.user_pseudo_id) * 100, 1) AS retention_pct
FROM cohorts c
LEFT JOIN activity a ON c.user_pseudo_id = a.user_pseudo_id
GROUP BY 1, 2
ORDER BY 1, 2

שאילתה זו מייצרת טבלת שימור שבועית.

Amplitude

ב-Amplitude, ניתוח קבוצות הוא כלי טבעי בקטע Retention Analysis. אנו מגדירים:

1. אירוע התחלה—first_open או אירוע הפעלה
2. אירוע חזרה—session_start או app_open
3. קיבוץ לפי ימים/שבועות
4. פילוח לפי: מקור התקנה, פלטפורמה, גרסת אפליקציה

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

Mixpanel

ב-Mixpanel, קטע ה-Retention בונה מטריצת שימור קלאסית. בנוסף, Lifecycle מראה איזה אחוז מהמשתמשים חוזרים לאחר היעדרות ארוכה. למשחקים מזדמנים, זה מדד חשוב.

השוואת כלים לניתוח קבוצות

קבוצות התנהגותיות

מלבד קבוצות מבוססות זמן (לפי תאריך התקנה), קבוצות התנהגותיות שימושיות—קבוצות של משתמשים שביצעו פעולה ספציפית. לדוגמה, ב-Amplitude Behavioral Cohorts ניתן לפלח משתמשים לפי פעולות: "הוסיף לעגלה", "שיתף תוכן".

# Пример логики в BigQuery:
# Когорта: пользователи, завершившие онбординг
# Вопрос: каков их retention vs пользователи, которые пропустили онбординг?

אם השימור בקרב אלה שסיימו את תהליך הקליטה גבוה פי 2—זו הוכחה שתהליך הקליטה צריך שיפור, לא קיצור.

בעיות אופייניות בהגדרת ניתוח קבוצות

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

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

מה כלול בעבודה

• ביקורת על יציבות ה-user_id ביישום הנוכחי
• הגדרת אירועי הפעלה יחד עם מנהל המוצר
• הגדרת ניתוח קבוצות ב-Firebase + BigQuery / Amplitude / Mixpanel
• שאילתות SQL לדוחות קבוצות מותאמים אישית
• הגדרת קבוצות התנהגותיות להיפותזות מפתח
• תיעוד והעברה לצוות

לוחות זמנים

הגדרת ניתוח קבוצות בכלי מוכן (Amplitude/Mixpanel): 1–2 ימים. BigQuery + שאילתות SQL מותאמות אישית: 2–4 ימים. העלות מחושבת באופן אישי.

פנו אלינו לביקורת על האנליטיקה הנוכחית שלכם—נעריך את יציבות ה-user_id ואת תקינות האירועים.