כיצד מיושמת Retentioneering באפליקציה באוויר

שמירה על משתמש באפליקציה לנייד היא מדע שלם. מחבר הקורס תיאר את היסודות שלו במאמר שלנו על VC.ru פריצת צמיחה: ניתוח אפליקציות לנייד מקסים גודז'י, ראש תחום למידת מכונה ב-App in the Air. מקסים מספר על הכלים שפותחו בחברה תוך שימוש בדוגמה של עבודה על ניתוח ואופטימיזציה של אפליקציה למובייל. גישה שיטתית זו לשיפור המוצר, שפותחה ב-App in the Air, נקראת Retentioneering. אתה יכול להשתמש בכלים האלה במוצר שלך: חלק מהם נמצאים בפנים גישה חופשית ב-GitHub.

App in the Air היא אפליקציה עם יותר מ-3 מיליון משתמשים פעילים ברחבי העולם, בעזרתה ניתן לעקוב אחר טיסות, לקבל מידע על שינויים בזמני יציאה/נחיתה, צ'ק אין ומאפייני נמל תעופה.

ממשפך למסלול

כל צוותי הפיתוח בונים משפך הפעלה (תהליך שמטרתו קבלת המשתמש של המוצר). זהו השלב הראשון שעוזר לכם להסתכל על כל המערכת מלמעלה ולמצוא בעיות באפליקציה. אבל ככל שהמוצר יתפתח, תרגישו את המגבלות של גישה זו. באמצעות משפך פשוט, אינך יכול לראות נקודות צמיחה לא ברורות למוצר. מטרת המשפך היא לתת מבט כללי על שלבי המשתמשים באפליקציה, כדי להראות לכם את מדדי הנורמה. אבל המשפך יסתיר בתבונה חריגות מהנורמה כלפי בעיות ברורות או להיפך, פעילות משתמשים מיוחדת.

ב-App in the Air בנינו משפך משלנו, אבל בגלל הספציפיות של המוצר, בסופו של דבר קיבלנו שעון חול. לאחר מכן החלטנו להרחיב את הגישה ולהשתמש במידע העשיר שהאפליקציה עצמה נותנת לנו.

כשאתה בונה משפך, אתה מאבד את מסלולי הכניסה של המשתמש. מסלולים מורכבים מרצף של פעולות של המשתמש ושל האפליקציה עצמה (לדוגמה, שליחת הודעת דחיפה).

באמצעות חותמות זמן, ניתן בקלות רבה לשחזר את מסלול המשתמש וליצור ממנו גרף עבור כל אחד מהם. כמובן, יש הרבה גרפים. לכן, עליך לקבץ משתמשים דומים. לדוגמה, אתה יכול לסדר את כל המשתמשים לפי שורות טבלה ולפרט באיזו תדירות הם משתמשים בפונקציה מסוימת.

על סמך טבלה כזו, עשינו מטריצה ​​וקיבוץ משתמשים לפי תדירות השימוש בפונקציות, כלומר לפי צמתים בגרף. זה בדרך כלל הצעד הראשון לקראת תובנות: למשל, כבר בשלב זה תראו שחלק מהמשתמשים כלל לא משתמשים בחלק מהפונקציות. כאשר עשינו את ניתוח התדרים, התחלנו ללמוד אילו צמתים בגרף הם "הגדולים ביותר", כלומר באילו עמודים משתמשים מבקרים בתדירות הגבוהה ביותר. מיד מודגשות קטגוריות שונות מהותית לפי קריטריון כלשהו שחשוב לך. הנה, למשל, שני אשכולות של משתמשים שחילקנו לפי החלטת המנוי (היו 16 אשכולות בסך הכל).

איך להשתמש בזה

על ידי הסתכלות על המשתמשים שלך כך, תוכל לראות באילו תכונות אתה משתמש כדי לשמור אותם או, למשל, לגרום להם להירשם. באופן טבעי, המטריצה ​​תציג גם דברים ברורים. למשל שמי שרכש מנוי ביקר במסך המנוי. אבל חוץ מזה, אתה יכול גם למצוא דפוסים שלעולם לא היית יודע עליהם אחרת.

אז לגמרי בטעות מצאנו קבוצה של משתמשים שמוסיפים טיסה, עוקבים אחריה באופן פעיל לאורך כל היום ואז נעלמים לזמן רב עד שהם שוב טסים לאנשהו. אם ננתח את ההתנהגות שלהם באמצעות כלים קונבנציונליים, היינו חושבים שהם פשוט לא מרוצים מהפונקציונליות של האפליקציה: איך עוד אפשר להסביר שהם השתמשו בה ליום אחד ולא חזרו. אבל בעזרת גרפים ראינו שהם מאוד פעילים, פשוט כל הפעילות שלהם מתאימה ליום אחד.

כעת המשימה העיקרית שלנו היא לעודד משתמש כזה להתחבר לתוכנית הנאמנות של חברת התעופה שלו בזמן שהוא משתמש בסטטיסטיקה שלנו. במקרה כזה, נייבא את כל הטיסות שהוא קונה וננסה לדחוף אותו להירשם ברגע שירכוש כרטיס חדש. כדי לפתור בעיה זו, התחלנו גם לשתף פעולה עם Aviasales, Svyaznoy.Travel ויישומים אחרים. כאשר המשתמש שלו רוכש כרטיס, האפליקציה מבקשת ממנו להוסיף את הטיסה ל-App in the Air, ואנחנו רואים את זה מיד.

בזכות הגרף ראינו ש-5% מהאנשים שנכנסים למסך המנוי מבטלים אותו. התחלנו לנתח מקרים כאלה, וראינו שיש משתמש שעובר לעמוד הראשון, יוזם את החיבור של חשבון הגוגל שלו ומיד מבטל אותו, מגיע שוב לעמוד הראשון וכך הלאה ארבע פעמים. בהתחלה חשבנו, "משהו בבירור לא בסדר עם המשתמש הזה." ואז הבנו שסביר להניח שיש באג באפליקציה. במשפך זה יתפרש כך: המשתמש לא אהב את מערך ההרשאות שהאפליקציה מבקשת, והוא עזב.

בקבוצה אחרת היו 5% מהמשתמשים הולכים לאיבוד על המסך שבו האפליקציה מבקשת מהם לבחור אחת מכל אפליקציות היומן בסמארטפון שלהם. משתמשים היו בוחרים יומנים שונים שוב ושוב ואז פשוט יוצאים מהאפליקציה. מסתבר שהייתה בעיית UX: לאחר שאדם בחר לוח שנה, הוא היה צריך ללחוץ על סיום בפינה השמאלית העליונה. רק שלא כל המשתמשים ראו את זה.

מסך ראשון של אפליקציה באוויר

בגרף שלנו ראינו שכ-30% מהמשתמשים לא עוברים את המסך הראשון: זה נובע מהעובדה שאנחנו די אגרסיביים בדחיפה של המשתמש להירשם. במסך הראשון, האפליקציה מבקשת להירשם באמצעות Google או Triplt, ואין מידע על דילוג על רישום. מבין אלה שיוצאים מהמסך הראשון, 16% מהמשתמשים לוחצים על "עוד" וחוזרים שוב. גילינו שהם מחפשים דרך להירשם פנימית באפליקציה ואנו נשחרר אותה בעדכון הבא. בנוסף, 2/3 מהיוצאים מיד לא לוחצים על כלום. כדי לגלות מה קורה להם, בנינו מפת חום. מסתבר שלקוחות לוחצים על רשימה של תכונות אפליקציה שאינן קישורים ניתנים ללחיצה.

ללכוד רגע מיקרו

לעתים קרובות ניתן לראות אנשים רומסים שבילים לצד כביש האספלט. שימור הוא ניסיון למצוא את השבילים הללו ובמידת האפשר לשנות את הדרכים.

כמובן, זה רע שאנחנו לומדים ממשתמשים אמיתיים, אבל לפחות התחלנו לעקוב אוטומטית אחר דפוסים שמצביעים על בעיית משתמש באפליקציה. כעת מנהל המוצר מקבל התראות באימייל אם מתרחשות מספר רב של "לולאות" - כאשר המשתמש חוזר לאותו מסך שוב ושוב.

הבה נבחן אילו דפוסים במסלולי משתמשים מעניינים בדרך כלל לחפש כדי לנתח בעיות ואזורי צמיחה של יישום:

• לולאות ומחזוריות. הלולאות שהוזכרו לעיל הן כאשר אירוע אחד חוזר על עצמו במסלול של המשתמש, למשל, לוח שנה-לוח שנה-לוח שנה. לולאה עם הרבה חזרות היא אינדיקציה ברורה לבעיית ממשק או סימון לא מספיק של אירועים. מחזור הוא גם מסלול סגור, אך בניגוד ללולאה הוא כולל יותר מאירוע אחד, למשל: צפייה בהיסטוריית טיסות - הוספת טיסה - צפייה בהיסטוריית טיסות.
• Flowstoppers – כאשר המשתמש, עקב מכשול כלשהו, ​​אינו יכול להמשיך בתנועה הרצויה שלו דרך האפליקציה, למשל מסך עם ממשק שאינו ברור ללקוח. אירועים כאלה מאטים ומשנים את מסלול המשתמשים.
• נקודות התפצלות הן אירועים משמעותיים שלאחריהם מופרדים המסלולים של לקוחות מסוגים שונים. בפרט, מדובר במסכים שאינם מכילים מעבר ישיר או קריאה לפעולה לפעולת היעד, ולמעשה דוחפים חלק מהמשתמשים אליה. לדוגמה, מסך כלשהו שאינו קשור ישירות לרכישת תוכן באפליקציה, אך בו לקוחות נוטים לקנות או לא לקנות תוכן, יתנהג אחרת. נקודות התפצלות יכולות להיות נקודות השפעה על פעולות המשתמשים שלכם עם סימן פלוס – הן יכולות להשפיע על ההחלטה לבצע רכישה או קליק, או סימן מינוס – הן יכולות לקבוע שלאחר מספר שלבים המשתמש יעזוב את האפליקציה.
• נקודות המרה שהופסקו הן נקודות התפצלות פוטנציאליות. אתה יכול לחשוב עליהם כעל מסכים שיכולים לעורר פעולת מטרה, אבל לא. זו יכולה להיות גם נקודת זמן שבה למשתמש יש צורך, אבל אנחנו לא מספקים אותו כי אנחנו פשוט לא יודעים על זה. ניתוח מסלול צריך לאפשר לזהות צורך זה.
• נקודת הסחת דעת - מסכים/חלונות קופצים שאינם מספקים ערך למשתמש, אינם משפיעים על המרה ויכולים "לטשטש" מסלולים, להסיח את דעתו של המשתמש מפעולות היעד.
• נקודות עיוורות הן נקודות נסתרות של האפליקציה, מסכים ותכונות שקשה מאוד להגיע למשתמש.
• ניקוזים - נקודות בהן נזילת תנועה

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

זה מזכיר לי בדיחה נהדרת. בודק נכנס לבר ומזמין: כוס בירה, 2 כוסות בירה, 0 כוסות בירה, 999999999 כוסות בירה, לטאה בכוס, -1 כוס בירה, כוסות qwertyuip בירה. הלקוח האמיתי הראשון נכנס לבר ושואל איפה השירותים. הבר בוער בלהבות וכולם מתים.

מנתחי מוצר, שקועים עמוק בבעיה זו, החלו להציג את המושג מיקרו-מומנט. המשתמש המודרני זקוק לפתרון מיידי לבעיה שלו. גוגל התחילה לדבר על זה לפני כמה שנים: החברה קראה לפעולות משתמש כאלה מיקרו-רגעים. דעתו של המשתמש מוסחת, בטעות סוגר את האפליקציה, לא מבין מה נדרש ממנו, מתחבר שוב כעבור יום, שוב שוכח ואז עוקב אחר הקישור שחבר שלח לו במסנג'ר. וכל המפגשים האלה יכולים להימשך לא יותר מ-20 שניות.

אז התחלנו לנסות להגדיר את העבודה של שירות התמיכה כך שהעובדים יוכלו להבין מה הבעיה כמעט בזמן אמת. עד שאדם מגיע לדף התמיכה ומתחיל לכתוב את השאלה שלו, נוכל לקבוע את מהות הבעיה, לדעת את המסלול שלו - 100 האירועים האחרונים. בעבר, ביצענו את ההפצה האוטומטית של כל בקשות התמיכה לקטגוריות באמצעות ניתוח ML של הטקסטים של בקשות התמיכה. למרות הצלחת הסיווג, כאשר 87% מכל הבקשות מחולקות נכון לאחת מ-13 הקטגוריות, זוהי עבודה עם מסלולים שיכולים למצוא באופן אוטומטי את הפתרון המתאים ביותר למצב המשתמש.

אנחנו לא יכולים לשחרר עדכונים במהירות, אבל אנחנו יכולים להבחין בבעיה, ואם המשתמש עוקב אחר התרחיש שכבר ראינו, שלח לו הודעת דחיפה.

אנו רואים שהמשימה של ייעול אפליקציה דורשת כלים עשירים ללימוד מסלולי משתמש. יתרה מכך, בהכרת כל הנתיבים בהם עוברים המשתמשים, ניתן לסלול את הנתיבים הדרושים, ובעזרת תוכן מותאם, הודעות דחיפה ואלמנטים של ממשק משתמש אדפטיביים "ביד" מובילים את המשתמש לפעולות ממוקדות המתאימות ביותר לצרכיו ומביאות כסף , נתונים וערך אחר עבור העסק שלך.

מה לשים לב

• לימוד המרת משתמש רק באמצעות משפכים כדוגמה פירושו לאבד את המידע העשיר שהאפליקציה עצמה נותנת לנו.

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

• הם עוזרים למצוא דפוסים לא ברורים של התנהגות משתמשים.

• כלי Retentioneering מאפשרים לבנות כלי ML אוטומטיים לחיזוי אירועים ומדדי מפתח של משתמש: אובדן משתמש, LTV ומדדים רבים אחרים הנקבעים בקלות על הגרף.

אנחנו בונים קהילה סביב Retentioneering להחלפה חופשית של רעיונות. אתה יכול לחשוב על הכלים שאנו מפתחים כשפה שבה אנליסטים ומוצרים מיישומי מובייל ואינטרנט שונים יכולים להחליף תובנות, טכניקות ושיטות מיטביות. ניתן ללמוד כיצד להשתמש בכלים אלו בקורס פריצת צמיחה: ניתוח אפליקציות לנייד מחוז בינארי.

מקור: www.habr.com