אירוע הוא החלטה שקיבלתם, לא דבר שקרה
כל מוצר פולט מספר בלתי מוגבל של דברים שקורים: קליקים, גלילות, מעברי עכבר, שינויי נתיב. אירוע הוא תת-הקבוצה הקטנה שהחלטתם שראויה לשם, משום שהיא אומרת לכם משהו שתפעלו לפיו. ההחלטה הזו, ולא המימוש הטכני, היא כל העבודה.
המסקנה המעשית היא שתוכנית מדידה היא מסמך מוצר לפני שהיא מסמך הנדסה. אם אינכם יכולים לומר מה הייתם עושים אחרת בהתאם לכך שאירוע נורה או לא, הוא עדיין לא צריך להתקיים.
תנו לאירועים שם לפי תוצאות, לא לפי הממשק
clicked_blue_button מפסיק להיות נכון ברגע שהעיצוב משיק גרסה מחודשת. report_exported שורד אותה, כי הוא מתאר מה המשתמש השיג ולא במה נגע.
בחרו מוסכמה אחת והחזיקו בה: אובייקט תחילה, פעולה בזמן עבר, אותיות קטנות עם קווים תחתונים — invite_sent, project_created, payment_failed. העקביות חשובה יותר מהמוסכמה שבחרתם, כי שמות לא עקביים הם מה שהופך קטלוג אירועים לבלתי ניתן לחיפוש כעבור שני רבעונים.
מוסכמת שמות שאפשר להעתיק
רוב הצוותים לא צריכים להמציא מוסכמה, רק לכתוב אחת. זו קצרה מספיק כדי לזכור אותה ומחמירה מספיק כדי לשמור על קטלוג שאפשר לחפש בו:
| כלל | כן | לא |
|---|---|---|
| קודם האובייקט, אחר כך הפעולה | invite_sent | sent_invite |
| בזמן עבר, כי זה כבר קרה | project_created | create_project |
| אותיות קטנות עם קווים תחתונים | plan_upgraded | PlanUpgraded, plan-upgraded |
| לתת שם לתוצאה, לא לפקד | report_exported | export_button_clicked |
| וריאציות נכנסות למאפיינים | report_exported עם format: csv | report_exported_csv |
| בלי מידע אישי בשמות או בערכים | plan: team | email: 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" סופר הרשמות שהושלמו בלי שום אירוע.

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