אירוע הוא החלטה שקיבלתם, לא דבר שקרה

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

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

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

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

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

מוסכמת שמות שאפשר להעתיק

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

כללכןלא
קודם האובייקט, אחר כך הפעולהinvite_sentsent_invite
בזמן עבר, כי זה כבר קרהproject_createdcreate_project
אותיות קטנות עם קווים תחתוניםplan_upgradedPlanUpgraded, plan-upgraded
לתת שם לתוצאה, לא לפקדreport_exportedexport_button_clicked
וריאציות נכנסות למאפייניםreport_exported עם format: csvreport_exported_csv
בלי מידע אישי בשמות או בערכיםplan: teamemail: ana@acme.com

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

עשרה עד עשרים אירועים, לא מאתיים

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

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

דוגמה מעשית: תוכנית מעקב לאפליקציית SaaS לעסקים

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

אירועמופעל כאשרמאפיינים עיקרייםהשאלה שהוא עונה עליה
signup_completedהחשבון קיים, לא כשהטופס נשלחsourceאילו ערוצים מביאים אנשים שבאמת מסיימים?
workspace_createdסביבת העבודה הראשונה נשמרתteam_sizeכמה מהנרשמים מגיעים לשלב ההגדרה?
teammate_invitedנשלחת הזמנהroleהאם החשבון מתפשט מעבר לאדם אחד?
invite_acceptedהמוזמן מצטרףroleהאם הזמנות הופכות לחברי צוות?
integration_connectedחיבור מצליחintegrationבאילו אינטגרציות משתמשים הצוותים שנשארים?
project_createdפרויקט נשמרtemplateהאם האובייקט המרכזי נוצר בכלל?
report_viewedדוח מסיים להיטעןreport_typeלאן אנשים חוזרים להסתכל?
report_exportedהקובץ נוצרformatהאם התוצר יוצא מהמוצר?
plan_upgradedמערכת החיוב מאשרת את השינויfrom_plan, to_planמה קורה רגע לפני שאנשים משלמים יותר?
payment_failedספק החיוב מדווח על כישלוןreasonכמה מהנטישה היא לא רצונית?
subscription_cancelledהביטול נכנס לתוקףreasonלמה צוותים עוזבים?
feedback_submittedטופס המשוב נשלחcategoryמה המשתמשים מבקשים, במילים שלהם?

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

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

המאפיינים נושאים את הפרטים; האירוע נושא את הפועל

התנגדו לאירוע נפרד לכל וריאנט. report_exported_csv, report_exported_pdf ו-report_exported_xlsx צריכים להיות אירוע אחד, report_exported, עם מאפיין format. כלל האצבע: אם אי פעם תרצו לראות את המספרים מחוברים יחד, מדובר באירוע אחד עם מאפיין.

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

טעויות במעקב אחר אירועים ששוברות דוחות בשקט

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

לכידה אוטומטית ואירועים מפורשים עונים על שאלות שונות

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

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

הגדרת אירועים בדיעבד

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

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

<button id="export-report">Export</button>
<button id="invite-teammate">Invite</button>
<a id="upgrade-plan" href="/he/billing">Upgrade</a>

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

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

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

איך לבדוק אירוע לפני שסומכים עליו

  1. הפעילו אותו בעצמכם ומצאו את ההפעלה שלכם. האירוע צריך להופיע פעם אחת, עם כל המאפיינים מלאים.
  2. השוו את הספירה למקור אמת. אם מסד הנתונים אומר ש-140 פרויקטים נוצרו בשבוע שעבר והאנליטיקה אומרת 95, מצאו את הפער לפני שמישהו בונה עליו גרף. חוסמי פרסומות, הסכמה ובקשות שנכשלו גורמים כולם לספירות בדפדפן להיות נמוכות מהספירות בשרת. הפער צריך להיות יציב, לא הפתעה.
  3. צפו בריפליי הפעלה שבו הוא הופעל. מספר אומר לכם שזה קרה; הקלטה אומרת לכם שזה קרה מתי שאתם חושבים שקרה.
  4. הכניסו אותו למשפך. אירוע שמופיע בלי השלב שחייב לבוא לפניו מופעל מהמקום הלא נכון.

מהיכן להתחיל השבוע

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

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