רוב המשפכים מודדים את המוצר, לא את המשתמש
פתחו כלי ניתוח טיפוסי והמשפכים בנויים מכל אירוע שצוות ההנדסה במקרה מכשר: route_loaded, account_created_v2, modal_opened. הן מדויקות מבחינה טכנית וכמעט חסרות תועלת להחלטות מוצר, מפני שהן מתארות את מה ש תוכנה עשה, לא מה ש משתמש ניסה לעשות. משפך שמודד את בסיס הקוד שלכם אומר לכם מתי רכיב התרנדר; משפך שמודד כוונה אומר לכם היכן מישהו ויתר.
הפתרון הוא לבנות משפכים לאחור מתוך התנהגות שנצפתה — ולאמת כל שלב מול הקלטות אמיתיות לפני שאתם סומך על ולו מספר אחד. הנה זרימת העבודה.
תן שם לשלבים לפי כוונת המשתמש
המשפכים הטובים ביותר נקראים כמו סיפור משתמש: מגיע לתמחור ← מתחיל הרשמה ← יוצר מרחב עבודה ← מתקין את קטע הקוד ← רואה את ההקלטה הראשונה. כל שלב מתאר התקדמות מנקודת המבט של המשתמש. תוויות פנימיות כמו account-created-v2 או dashboard-route-loaded שימושיים עבור קוד, אך הם מסתירים את הכוונה מסקירת המוצר.
כשמשפך נקרא בשפת המשתמש, כולם מזהים את הפער מהר יותר. אם משתמשים רבים יוצרים מרחב עבודה אך אינם מתקינים את קטע הקוד, השאלה הבאה ברורה — ואינך צריך אנליסט שיתרגם. מבחן פשוט: אם עובד חדש לא יכול לקרוא בקול את שלבי המשפך שלכם ולהבין את מטרת המשתמש, השלבים נקראים עבור מהנדסים, לא עבור החלטות.
אמתו כל שלב עם הקלטות
לפני שאתם מתייחסים למשפך כאמת, צפו בהפעלות סביב כל מעבר. באגי המשפך הנפוצים ביותר אינם בתרשים — הם בהגדרות האירועים שמזינות אותו:
- מופעל מוקדם מדי: האירוע נפעל כשרכיב מתרנדר או נתיב נטען, לא כשהמשתמש באמת משלים את הפעולה — מנפח את אותו שלב ומסתיר את הדליפה שמתחתיו.
- מופעל לעיתים קרובות מדי: ניסיון חוזר, רינדור מחדש או שליחה כפולה סופרים את אותו משתמש פעמיים, כך שההמרה נראית טובה ממה שהיא.
- מופעל מהסיבה הלא נכונה: האירוע לוכד תופעת לוואי במקום את מצב ההצלחה המיועד.
הקלטות הפעלה הם הדרך המהירה ביותר לתפוס הגדרות אירועים שנראות נכונות בלוח מחוונים אך נכשלות בהקשר. צפו בשלוש הפעלות לכל מעבר; אם האירוע תואם למה שהמשתמש בבירור התכוון, סמוך על השלב. אם לא, תקן את ההגדרה לפני שתפעל על סמך הנתונים.
קראו את הנשירה, ואז לכם לצפות בה
תפקידו של משפך אינו להציג מספר — אלא להפנות אתכם להקלטות שמסבירות את המספר. כששלב מדמם, אל תעצב מחדש מתוך תחושת בטן. סננו למשתמשים שהגיעו לאותו שלב ונטשו, צפו בחמישה מהסשנים שלהם, ובדרך כלל תמצאו אחת מתוך קבוצה קטנה של סיבות:
- שגיאת ולידציה או כפתור מושבת ללא הסבר.
- שדה חובה או הרשאה שלמשתמש לא היו וגם לא יכול היה לפתור.
- רגע של בלבול — הפעולה הבאה לא הייתה במקום שאליו הביטו.
- שום דבר לא בסדר בכלל: הם קיבלו את מה שהיו צריכים ועזבו מרוצים (“דליפה” שאינה כזו).
המקרה האחרון הזה הוא הסיבה שמשפכים לבדם מטעים. המספר אומר “נשירה”; ההקלטה אומרת “הצלחה”. רק הצמד יחד אומר את האמת.
שמרו על משפך הפעלה אחד כמקודש
צוותים קטנים צריכים לתחזק משפך הפעלה מרכזי אחד ולסקור אותו שבועית. התנגד לפיתוי ליצור תריסר משפכים חופפים — הם מפצלים את הקשב ומאפשרים לכל אחד לבחור את התרשים שמחמיא לפרויקט שלו. משפך ממוקד יוצר קצב תפעולי משותף: מה השתנה השבוע, לאן ההמרה זזה, ואילו הפעלות מסבירות את התנועה?
סביב אותו משפך מקודש יחיד תוכלו ליצור משפכים קצרי מועד וחד-פעמיים לחקירות ספציפיות, ואז לארכב אותם. המשמעת היא להחזיק במספר יחיד שכל הצוות סומך עליו וחוזר אליו, ולא למקסם את מספר לוחות המחוונים.
שאלות נפוצות
האם שלבי המשפך צריכים להיות צפיות בדף או אירועים?
אירועים, כמעט תמיד. צפיות בדף מתארות ניווט, לא הישג — משתמש יכול לטעון את דף ה“הצלחה” מבלי להצליח, או להצליח בתוך אפליקציית עמוד יחיד ללא ניווט. הגדירו את השלבים כאירועים שמייצגים את כוונת המשתמש האמיתית.
כמה שלבים צריך שיהיו במשפך?
רק כמה שמספרים את הסיפור — בדרך כלל ארבעה עד שישה. כל שלב צריך להיות נקודת החלטה משמעותית. אם שני שלבים סמוכים תמיד ממירים יחד, אחד אותם; הפער ביניהם לא מלמד אתכם דבר.
למה ההמרה במשפך שלי נראית גרועה מהמציאות?
בדרך כלל שלב נפעל מוקדם מדי או סופר את אותו משתמש יותר מפעם אחת, או שאינך מבצע הסרת כפילויות לפי משתמש. אמתו כל אירוע מול הקלטות, וודא שאתם מודדים משתמשים ייחודיים, לא אירועים גולמיים.
האם אני צריך ריפליי הפעלות כדי להשתמש היטב במשפכים?
אתם יכולים להריץ משפכים בלי זה, אבל תנחש את הסיבות. הצמדת כל נשירה להקלטות שמאחוריה היא מה שהופך משפך מדוח סטטוס למקור של תיקונים. ראו ריפליי הפעלות ללא הרעש.