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