כולנו עושים שימוש בכלי אנליטיקס (Analytics) דוגמת גוגל אנליטיקס ו-Mixpanel על מנת לקבל נתונים על התנהגות המשתמשים שלנו.
בשימוש כזה, חשוב להבין כי כל כלי אנליטיקס מוכוון למענה על צורך מסוים – ושם הוא מצטיין.
כך, רוב כלי האנליטיקס נותנים מענה הולם בעיקר לבעיות שיווק ומכירות (User-Acquisition), כלומר – משפך ההמרה.
כל עוד אנו מבינים זאת ובאמת מחפשים מענה לצורך הזה – הכל נהדר.
אך בשלב כלשהו בחיי החברה, עולים צרכים נוספים – שמתחילים לאתגר מאוד את יכולות כלי האנליטיקס הקיים לתת להם מענה.
טיפול בתחום ה-Retention הוא אחד השלבים הראשונים בהם כלי האנליטיקס מתחיל לגלות 'סימני מצוקה'.
במאמר נציג 7 היבטים בהם כלי האנליטיקס מתקשה לתת לנו מענה בעולם ה-Retention, כולל הכוונה לפתרונות אפשריים.
המאמר יחולק ל-2:
- חלק א' – תפיסת כלי האנליטיקס הקיימים בשוק וסוגיות נתונים.
- חלק ב' – מתודולוגיית מדידה וניתוח נתוני נטישות.
חלק א' – תפיסת כלי האנליטיקס הקיימים בשוק וסוגיות נתונים הגורמים לבעיות Retention
רוב כלי האנליטיקס מיועדים בעיקר למדידת תהליך ההמרה ופחות לבעיות Retention
כמעט כל כלי האנליטיקס כיום מנסים להציע חבילה יחסית כוללת למדידת ביצועי אתרים / אפליקציות. חבילה כזו כוללת בין השאר:
- ניתוח משפך המכירה
- זיהוי מקורות תנועה לאתר/מוצר (לעיתים גם מודלי Attribution).
- מדדי זמנים ותדירות
- טיפול ב-Retention באמצעות ניתוחי Cohort.
חבילה כזו אמנם נותנת מענה יחסית סביר לפעילות החברה. ויחד עם זאת, המיקוד המשמעותי של רוב כלי האנליטיקס הוא במשפכי המכירות וזיהוי מקורות התנועה.
כמעט בכל אתר / מוצר קיים תהליך שבו מבקר משתכנע לקנות הצעת ערך (גם אם היא בחינם) ולהשתמש בה.
משפך המרה (Conversion Funnel) הוא השיטה הנפוצה והטריוויאלית ביותר לצורך מדידה של התהליך הזה.
לאחר הפיכת המבקרים למשתמשים מדדי השימוש במוצר הופכים ייחודיים עבור כל חברה.
כלי האנליטיקס הקיימים מנסים לתת לשלב זה פתרון דרך בשני אופנים:
- הגדרת אירועים ספציפיים (Event Tracking).
- שמירת משתנים מותאמים (Custom Variables) בכל אירוע.
הבעיה היא, שלאור הייחודיות של כל אתר / מוצר, לא תמיד אפשר לחשב מדדים כמותיים מדויקים עבור שלב השימוש במוצר (Engagement).
בחלק מהכלים (דוגמת Google Analytics, Mixpanel), קיימת אפשרות להגדיר מטריקות מעט מורכבות יותר.
יחד עם זאת, ברוב המקרים המטריקות הייחודיות גם מורכבות לאפיון, וגם קשות למימוש טכני (קידוד בשפה שלא תמיד מוכרת למפתחים).
תחום ה-Retention סובל מכך באופן מיוחד, מאחר והסיבות לנטישה יכולות לנבוע מבעיות גם טרם ההמרה וגם בשימוש השוטף.
לדוגמה: מכירה ללקוחות לא מתאימים היא בעיה טרם ההמרה, לעומת נטישה לאור בעיית ביצועים בעת השימוש.
כנובע מהסיבות הללו – פתרון בעיות Retention דורש שימוש גם בנתונים הנשמרים טרם ההמרה וגם בנתוני השימוש השוטפים. שימוש כזה הוא מורכב ומחייב הטמעה בקוד.
לפיכך, קיימת רמת מורכבות גבוהה לזיהוי הגורמים לבעיות Retention. מרבית כלי האנליטיקס לא מתמקדים בכך – אלא מסתפקים בפתרון יחסית בסיסי בדמות ניתוחי Cohort.
לא כל נתוני הפעילות של המשתמשים נשמרים בכלי האנליטיקס
במרבית כלי האנליטיקס קיימת אפשרות להטמיע מעקב אחר אירועים (event) ספציפיים של המשתמש (לחיצה על כפתור, Login, גלילה מטה/מעלה וכיו"ב).
לפני שהמשתמש נרשם ומתחיל להשתמש במוצר, אין לנו עדיין זיהוי ייחודי שלו. לכן, הנתונים הנוגעים למשתמשים מגיעים מעצם השימוש בדפדפן / מכשיר ספציפי של כל משתמש (Client).
לאחר הרשמה או תחילת שימוש באפליקציה מתרחשים מאחורי הקלעים אירועים אחרים – דוגמת אישור הרשמה, תשלום וכיו"ב. אירועים אלה אינם מתרחשים בצד המשתמש (Client), אלא בצד השרת (Server), ולכן הטמעה טיפוסית של כלי אנליטיקס לא תכלול אותם.
נתונים אלה יישמרו לרוב בבסיס נתונים ייעודי של האפליקציה, במקרים רבים בצורה גולמית של Log'ים.
כך, נוצר מצב שבו יש לנו 2 מקורות נתונים – נתונים מהמכשיר של המשתמש (נשמרים בכלי האנליטיקס), ונתונים מהשרת (נשמרים ב-DB).
פתרון בעיות שונות בחיי הלקוח דורש שימוש בנתונים ממקורות שונים.
כך, לדוגמה, בעיות המרה (שיווק, מכירות) או בעיות UX/UI עושות שימוש בנתוני האנליטיקס – בצד ה-Client.
לעומתן, בעיות שימוש במוצר (Engagement) עושות שימוש בנתונים הפנימיים (מה-DB).
בעיות Retention דורשות לרוב שילוב של שני מקורות הנתונים, ולכן כלי האנליטיקס לבדו אינו מספיק.
בעת הטמעת כלי האנליטיקס עדיין לא יודעים להגדיר במדויק מהי נטישה או מה הגורמים לה
בסעיף הקודם צוין כי לא כל הנתונים הרלוונטיים לנטישה נשמרים בכלי האנליטיקס. אך בנוסף למגבלות נתונים הנובעות מארכיטקטורה של המוצר, קיימות בעיות הנוגעות לאפיון שלו – בדגש על חוסר ידע.
בתחילת הפעילות על מוצר / אתר אנחנו עדיין יחסית באפילה. בשלב זה אנחנו לרוב עדיין לא מודעים לקיום של בעיית נטישה במוצר – כי אין עדיין פעילות בו…
בשלב הזה אנו ממוקדים בפיתוח המוצר, ולא בשיקולי נתונים שצריך לשמור, וגם ההטמעה הראשונית של כלי האנליטיקס מתבצעת בהתאם. לכן, הסבירות שנשמור מבעוד מועד בדיוק את הפרמטרים שעשויים להימצא כמסבירים נטישה בכלי האנליטיקס היא אפסית.
יתרה מכך – בתחילת הפעילות איננו יודעים כלל להגדיר במדויק מהי נטישה במוצר שלנו. לדוגמה: האם נטישה היא הסרת המוצר, או חוסר שימוש בו? ובמקרה של חוסר שימוש – כמה זמן של חוסר שימוש מהווה נטישה? כנובע מכך, כנראה שקשה מאוד לשמור מבעוד מועד את המידע הדרוש לצורך טיפול בבעיות Retention.
התוצאה היא חוסר בנתונים שיאפשרו לנו לפלח כיאות את האוכלוסייה ולזהות אוכלוסיות בסיכון גבוה לנטישה ולטפל בהן.
כנובע מחוסר המודעות לכך, יזמים רבים נוטים לסמוך על ניתוח ה-Retention בכלי האנליטיקס באופן גורף, ולא להבין שקיימת אצלם בעיה חריפה של נטישות. במילים אחרות – להשאיר את המצב האמיתי של נטישת המשתמשים 'מתחת לרדאר'.
עד כאן חלקו הראשון של המאמר.
בחלקו השני יוצגו 4 סיבות נוספות לבעיות Retention הנובעות ממגבלות של כלי האנליטיקס המוטמע במוצר או באתר שלך, והפעם בדגש על בעיות מתודולוגיות בניתוח הגורמים לנטישה.