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

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

בהתחלה הייתה מילה, והמילה הייתה "ננסה?"

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

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

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

תוצאות ראשונות או מאיפה לקבל רעיונות

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

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

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

• במקום CJM גדול, המכסה תריסר ישויות, נעשה שימוש פעיל רק בשניים. יש צורך בנוסף להפנות משתמשים למקומות שאנו צריכים באמצעות פתרונות UX.
• חלק מהדפים, שעוצבו על ידי מעצבי UX כדי להיות מקצה לקצה, בסופו של דבר אנשים מבזבזים עליהם כמות בלתי סבירה של זמן. אתה צריך להבין מה הם רכיבי העצירה בעמוד מסוים ולהתאים אותם.
• לאחר 10 מעברים, 20% מהאנשים החלו להתעייף ועזבו את הפגישה באפליקציה. וזה לוקח בחשבון את העובדה שהיו לנו עד 5 דפי כניסה באפליקציה! עליך לזהות דפים שבהם משתמשים נוטשים באופן קבוע את הפעלות ולקצר את הדרך אליהם. אפילו טוב יותר: זהה כל מסלול קבוע ואפשר מעבר מהיר מדף המקור לדף היעד. משהו במשותף עם ניתוח ABC וניתוח עגלות נטושות, אתה לא חושב?

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

על אכזבות והשראות

אכזבה מס' 1

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

גרף מעבר שנבנה על ידי ספריית Retentioneering

השראה מס' 1

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

אכזבה מס' 2

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

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

/host/item/24/ip(modal:modal/host/item/ip/create)

פירושו שבדף "כתובות IP" המשתמש הוסיף כתובת IP. והנה שתי בעיות נראות בבת אחת:

• כתובת האתר מכילה סוג של פרמטר נתיב - המזהה של המחשב הוירטואלי. צריך לשלול את זה.
• כתובת האתר מכילה את מזהה החלון המודאלי. אתה צריך איכשהו "לפרוק" כתובות URL כאלה.
  בעיה נוספת הייתה שבעצם האירועים שסימנו היו פרמטרים. לדוגמה, היו חמש דרכים שונות להגיע לדף עם מידע על מכונה וירטואלית מהרשימה. בהתאם, נשלח אירוע אחד, אך עם פרמטר שציין באיזו שיטה המשתמש ביצע את המעבר. היו הרבה אירועים כאלה, וכל הפרמטרים היו שונים. ויש לנו את כל ההיגיון של אחזור הנתונים בניב SQL עבור Clickhouse. שאילתות של 150-200 שורות החלו להיראות שגרתיות במקצת. בעיות הקיפו אותנו.

השראה מס' 2

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

1. פריקת אירועים מאחסון הנתונים הגולמיים והכנתם לעיבוד.
2. הבהרה היא "פירוק" של אותם מזהים ממש של חלונות מודאליים, פרמטרים של אירועים ופרטים אחרים שמבהירים את האירוע.
3. העשרה (מהמילה "להיות עשיר") היא הוספת אירועים עם נתונים ממקורות צד שלישי. באותו זמן, זה כלל רק את מערכת החיוב שלנו BILLmanager.
4. סינון הוא תהליך של סינון אירועים המעוותים את תוצאות הניתוח (אירועים מיציעים פנימיים, חריגים וכו').
5. העלאת אירועים שהתקבלו לאחסון, שקראנו להם נתונים נקיים.
   כעת ניתן היה לשמור על רלוונטיות על ידי הוספת כללים לעיבוד אירוע או אפילו קבוצות של אירועים דומים. לדוגמה, מאז מעולם לא עדכנו את פריקת ה-URL. אמנם, במהלך תקופה זו נוספו מספר וריאציות חדשות של כתובת אתר. הם עומדים בכללים שכבר נקבעו בשירות ומעובדים בצורה נכונה.

אכזבה מס' 3

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

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

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

השראה מס' 3

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

אוטומציה של אנליטיקס

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

ואז חשבתי: למה לא, Retentioneering מאחסן את כל הנתונים במבנה pandas.DataFrame. וזה, בגדול, שולחן. כך הופיע שירות נוסף: Data Provider. הוא לא רק הכין טבלה מהגרף, אלא גם חישב עד כמה העמוד והפונקציונליות הקשורה אליו פופולריים, כיצד הוא משפיע על שימור המשתמש, כמה זמן משתמשים בו נשארים בו ואילו דפים עוזבים משתמשים לרוב. והשימוש בהדמיה ב-Tableau הפחית את עלות לימוד הגרף עד כדי כך שזמן האיטרציה לניתוח התנהגות במוצר הצטמצם כמעט בחצי.

דניל ידבר על אופן השימוש בהדמיה זו ואיזה מסקנות היא מאפשרת להסיק.

עוד שולחנות לאלוהי השולחן!

בצורה פשוטה, המשימה נוסחה כך: הצגת גרף המעבר ב-Tableau, מתן יכולת סינון והפיכתו ברור ונוח ככל האפשר.

לא באמת רציתי לצייר גרף מכוון בטבלה. וגם אם הצליח, הרווח, בהשוואה לגפי, לא נראה מובן מאליו. היינו צריכים משהו הרבה יותר פשוט ונגיש. שולחן! אחרי הכל, הגרף יכול להיות מיוצג בקלות בצורה של שורות טבלה, כאשר כל שורה היא קצה מסוג "יעד מקור". יתר על כן, כבר הכנו בקפידה טבלה כזו באמצעות כלי Retentioneering ו-Data Provider. כל מה שנותר לעשות הוא להציג את הטבלה בטבלה ולחטט בדוח.

אם כבר מדברים על איך כולם אוהבים שולחנות.

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

ל-Tableau מבחר עשיר של מחברים. מצאנו אחד שפתר את הבעיה שלנו

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

טופס חיבור ל-WDC שלנו. דניס עשה את החזית שלו ודאג לבטיחות

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

כך נראה מערך נתונים גולמיים בממשק Tableau

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

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

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

• מהם המעברים השכיחים ביותר?
• לאן הם מגיעים מדפים ספציפיים?
• כמה זמן אתה מבלה בממוצע בדף הזה לפני היציאה?
• באיזו תדירות אתה מבצע את המעבר מ-A ל-B?
• באילו דפים הסשן מסתיים?

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

מה קיבלנו?

היכן אנשים חורגים לרוב מלוח המחוונים?

קטע מהדוח שלנו. לאחר לוח המחוונים, כולם עברו לרשימת ה-VMs או לרשימת הצמתים

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

מאיפה הם מגיעים לרשימת האשכולות?

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

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

בוא נשאל משהו יותר קשה.

היכן משתמשים לרוב נוטשים את ההפעלה שלהם?

משתמשי VMmanager עובדים לרוב בכרטיסיות נפרדות

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

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

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

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

הטבלה התבררה כנפחית למדי, אך אנו מקווים שהיא לא חדלה להיות קריאה

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

הכנו את המדריך פשוט כמצגת ב-Google Docs. כלי טבלה מאפשרים לך להציג דפי אינטרנט ישירות בתוך חוברת עבודה של דוח.

במקום אפילוג

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

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

מקור: www.habr.com