רוב הצוותים משיקים פיצ'ר, עוקבים אחר ה-KPI שהגדירו עבורו, ומכריזים על הצלחה כשהמספר זז. האינסטינקט הזה הגיוני, אבל הוא משאיר פער. KPI מראה אם המספר היחיד שבחרתם זז. אנליטיקת מוצר (Product Analytics) בוחנת איך משתמשים מתנהגים לאורך כל התהליך, ולכן היא יכולה להראות גם מה קרה סביב המספר הזה, כולל דברים שאף אחד לא חשב לשאול עליהם. ראינו את זה אצל אחד הלקוחות שלנו, חברת B2B המציעה שירותים מקוונים לאתרי קמעונאות.
השינוי
הצוות עיצב מחדש חלק מתהליך הרישום (Onboarding): הוא פישט את השלב הראשון והעביר כמה שדות חובה לשלב הבא, מתוך הנחה ששלב קל יותר יפחית את אחוזי הנטישה ויביא יותר משתמשים לנקודת התשלום.
ה-KPI היה ברור: לשפר את השלמת השלב הספציפי הזה, ולשפר את היחס הכללי של לידים שהסתיימו ברכישה שהושלמה. בעבודה איתנו, הצוות הטמיע מדידה כראוי ב-Amplitude: כל שלב ב-Onboarding נמדד כאירוע (event), מהמגע הראשון ועד להשלמת הרכישה, לצד מעקב מלא אחר הפעילות באתר.
ה-KPI הראה שזה עבד, אבל משהו לא התחבר
לאחר ההשקה, השלמת שלב היעד עלתה מ-74% ל-92%. לפי המטריקה שהצוות הגדיר, הפיצ'ר היה הצלחה מובהקת. אבל שיעור ההמרה הכללי מליד לרכישה כמעט ולא זז: מ-24.4% ל-24.1%. אם השלב שתוכנן מחדש העביר משתמשים רבים יותר לשלב הבא, השיפור הזה היה אמור להתבטא גם בכמות הרכישות. זה לא קרה. ניתוח צר יותר, שבוחן רק את KPI היעד, היה מפספס את הפער הזה או מסביר אותו בצורה מוטעית. התרשים מראה לאן זה נעלם: המשתמשים הנוספים שעברו את השלב הראשון נשרו כבר בשלב הבא.
חופרים מעבר ל-KPI
מכיוון שהמדידה כיסתה את כל פעילות המשתמש, ולא רק את שלב המשפך המדובר, יכולנו לבדוק עמוק יותר מהמספרים הכלליים. במקום שמישהו יעבור ידנית על הקלטות אחת אחת, סוכן ה-AI של Amplitude סקר את ההקלטות של משתמשים שנטשו לאחר השלב שתוכנן מחדש וזיהה דפוס: קבוצת משתמשים שנתקלה באותה תקלה. זה הוביל אותנו ישר לסיבה: לאחד השדות שהועברו לשלב המאוחר יותר הייתה שגיאת אימות שהופעלה רק במכשירים מסוימים. היא חסמה את המשתמשים הללו מלעבור את השלב, וכך גם מלהגיע לרכישה, ללא סימן ברור מה השתבש.
למה זה היה חשוב יותר מהפיצ'ר עצמו
לתיקון הבאג הייתה השפעה גדולה יותר על ההכנסות מאשר לעיצוב מחדש של ה-Onboarding. אילו ההשקה נבחנה רק מול השלב שהיא באה לשפר, היא הייתה נרשמת כהצלחה בזמן שהבאג ממשיך לגרום לאובדן רכישות במכשירים המושפעים, מבלי להתגלות.
מה כדאי למדוד כדי לתפוס מקרה כזה
זה לא דורש הקמה מיוחדת, רק כמה הרגלים שקל לדלג עליהם:
- כל שלב כאירוע. לא רק השלב שמשנים. שמות אירועים עקביים מאפשרים להשוות בין לפני לאחרי.
- גם את סוף המשפך, לא רק את שלב היעד. לצד ה-KPI של השלב, כדאי לעקוב אחר מדד בקרה (guardrail) כמו שיעור ההמרה מליד לרכישה. אם השלב משתפר ומדד הבקרה לא זז, הפער הזה הוא הסימן.
- מכשיר, דפדפן ומערכת הפעלה בכל אירוע. כך אפשר לפלח נטישה ולראות אם היא מתרכזת בקבוצה מסוימת.
- שגיאות כאירועים. שגיאות אימות ושליחות טופס שנכשלו הן נתוני מוצר, לא רק שורות בלוג.
- הקלטות בתהליכים קריטיים. כדאי לתת ל-AI לעבור עליהן, כדי שאנומליות יצופו בלי שמישהו יצטרך לחפש אותן.
איפה Amplitude עוזרת
שני דברים אפשרו לגלות את זה ב-Amplitude. המדידה כיסתה כל שלב ואת כל פעילות המשתמש, ולא רק את שלב היעד. סוכן ה-AI שלה סקר את ההקלטות, כך שאף אחד לא היה צריך לעבור עליהן אחת אחת.
לא בטוחים מה הנתונים של המוצר שלכם מסתירים? ראו איך אנחנו מקימים אנליטיקת מוצר.