למה לא מתחילים מרשימת האירועים של GA4?
לפי התיעוד של Google, אירועים ב-GA4 מתחלקים לארבעה סוגים: אירועים שנאספים אוטומטית, אירועי Enhanced Measurement, אירועים מומלצים שמיישמים לפי שמות ופרמטרים מוגדרים מראש ואירועים מותאמים שמגדירים לבד. האירועים המומלצים מחולקים לקטגוריות: לכל סוג עסק, למכירות אונליין, לייצור לידים ולמשחקים. הרשימה טובה ושימושית. הבעיה היא השימוש בה כנקודת פתיחה.
כשפותחים את הרשימה ושואלים "מה מתוך זה רלוונטי לנו", התשובה היא כמעט תמיד "הכול". מסמנים sign_up, login, search, share, file_download, generate_lead, מוסיפים כמה קליקים על כפתורים ושולחים למפתח. אחרי חודש יש 40 אירועים בדוח Events, 25 מתוכם עם ספירה אפסית או חסרת משמעות. השאלה הפשוטה של ההנהלה, "כמה לידים מתאימים הביא האתר החודש ומאיזה ערוץ", עדיין לא נענית, כי generate_lead נורה גם על שגיאות טופס, כי אין קישור בין הליד לסטטוס שלו ב-CRM וכי אף אחד לא הגדיר מה זה "מתאים".
הכיוון ההפוך פותר את זה. כשמתחילים מהיעד, כל אירוע בתוכנית קיים כי הוא נדרש לחישוב של KPI מסוים. אירוע שלא משרת שום KPI לא נכנס. יש לזה גם סיבה טכנית: Google מגבילה נכס GA4 רגיל ל-30 אירועי מפתח (Key Events) ונכס Analytics 360 ל-50. התקציב הזה קטן ממה שנדמה. ממילא אירוע מפתח שאף אחד לא מסתכל עליו רק מרעיש בדוחות.
איך נראית השרשרת מיעד עסקי לאירוע?
אנחנו עובדים עם עץ של שלוש רמות, שבתחום הניתוח העסקי נקרא driver tree. ברמה העליונה נמצא יעד עסקי אחד, מנוסח במספרים שההנהלה מכירה: הכנסות, עסקאות, עלות רכישת לקוח. ברמה האמצעית נמצאים שלושה עד חמישה KPI שמסבירים את היעד. אם ה-KPI עולה, היעד מתקדם. ברמה התחתונה נמצאים האירועים והפרמטרים ב-GA4 שמהם מחשבים כל KPI. הדיאגרמה מראה את העץ לאתר לידים B2B, בנתוני דמו:
עץ מניעים
מיעד עסקי אחד לארבעה KPI ולאירועים ב-GA4
qualify_lead מה-CRM, עם client_idcurrency, value, lead_sourceמקור אמת: סטטוס ב-CRM
generate_lead + sessionsמהאתר, אחרי תגובת הצלחהform_id, lead_source, valueמקור אמת: מערכת הטפסים
qualify_lead + עלות מדיהקישור Google Ads, ייבוא עלויותsource / medium / campaignמקור אמת: חשבוניות מדיה
close_convert_lead מה-CRM, עם client_idcurrency, valueמקור אמת: עסקאות שנסגרו
שימו לב למה אין בעץ. אין page_view כאירוע מפתח, אין קליקים על תפריט, אין scroll. כל אלה קיימים ב-GA4 בזכות האיסוף האוטומטי ואפשר להסתכל עליהם כשצריך, אבל הם לא חלק מתוכנית המדידה כי שום KPI בעץ לא מחושב מהם. העץ גם חושף תלות שחשוב לראות מוקדם: שלושה מארבעת ה-KPI תלויים בנתון שמגיע מה-CRM, לא מהאתר. בלי חיבור בין הליד באתר לסטטוס שלו ב-CRM, התוכנית לא ניתנת ליישום. עדיף לגלות את זה בפגישת התכנון ולא אחרי שלושה חודשי איסוף.
איך נראית תבנית תוכנית המדידה?
התבנית שלנו היא טבלה אחת עם שבע עמודות קבועות. כל שורה היא KPI אחד. העמודה הראשונה היא היעד העסקי שה-KPI משרת. השנייה היא השאלה שההנהלה שואלת, במילים שלה, לא במילים של אנליסט. השלישית היא שם ה-KPI. הרביעית היא ההגדרה המדויקת: מה נספר, מה לא נספר, מה המכנה ומה חלון הזמן. העמודה הזו היא הלב של התוכנית ובדרך כלל גם המקום שבו מתגלים חוסרי הסכמה בין שיווק למכירות. החמישית היא התרגום הטכני: אירוע ופרמטרים ב-GA4. השישית היא מקור האמת החיצוני שמולו מאמתים את המספר. השביעית היא הבעלים, אדם אחד שאחראי שהמספר נכון ושמישהו מסתכל עליו.
כך נראית הטבלה המלאה לאתר לידים B2B. כל הערכים הם נתוני דמו. שמות האירועים לקוחים מקטגוריית ייצור הלידים ברשימת האירועים המומלצים של Google:
| יעד עסקי | שאלה שההנהלה שואלת | KPI | הגדרה מדויקת | אירוע ופרמטרים ב-GA4 | מקור אמת לאימות | בעלים |
|---|---|---|---|---|---|---|
| 20% יותר עסקאות חדשות מהאתר בשנה (דמו) | כמה לידים מתאימים האתר מייצר בחודש ומאיזה ערוץ הם מגיעים? | לידים מתאימים (SQL) בחודש, לפי ערוץ | ליד שנוצר בטופס באתר וסומן במכירות כ"מתאים" בתוך 14 יום. ליד כפול (אותו אימייל בתוך 30 יום) נספר פעם אחת. פנייה דרך ספק חיצוני לא נספרת. הערוץ נקבע לפי session source / medium של השליחה. | generate_lead מהאתר, אחרי תגובת הצלחה מהשרת, עם lead_source, form_id, currency, value.qualify_lead מה-CRM דרך Measurement Protocol או ייבוא אירועים אופליין, עם ה-client_id שנשמר בליד, currency, value. שני האירועים מסומנים כאירועי מפתח. |
CRM: רשומות עם סטטוס "מתאים" ותאריך יצירה בחודש הנמדד | מנהל מכירות (הגדרה), אנליסט (חישוב) |
| אותו יעד | איזה חלק מהמבקרים הרלוונטיים משאיר פרטים? האתר עובד או רק המדיה? | שיעור המרה מסשן לליד | סשנים שבהם נורה generate_lead חלקי כל הסשנים, בלי טראפיק פנימי ובלי בוטים ידועים. סשן עם שני טפסים נספר פעם אחת במונה. נמדד לפי landing page ולפי ערוץ. | generate_lead (כנ"ל) מול מדד Sessions. במונה משתמשים במדד Session key event rate של GA4 ולא בספירת אירועים. |
מערכת הטפסים: מספר שליחות מוצלחות בחודש | מנהל דיגיטל |
| הורדת עלות רכישת לקוח ב-15% (דמו) | כמה עולה לנו ליד מתאים בכל ערוץ ממומן? | עלות לליד מתאים | הוצאת מדיה בחודש בערוץ חלקי qualify_lead בחודש שמקורם באותו ערוץ. לידים אורגניים לא במכנה. ההוצאה כוללת מע"מ לפי החשבונית, לא לפי ממשק הפלטפורמה. | qualify_lead לפי source / medium / campaign. עלות: קישור Google Ads ל-GA4 וייבוא עלויות (Data Import) לערוצים האחרים. |
חשבוניות מדיה חודשיות + CRM | מנהל שיווק |
| אותו יעד | אילו לידים נסגרים לעסקה ומה הם ראו באתר לפני שפנו? | שיעור סגירה מליד מתאים ללקוח | close_convert_lead חלקי qualify_lead מאותו חודש יצירה (קוהורטה), עם חלון של 90 יום. עסקה שנסגרה בלי ליד מהאתר לא נספרת. | close_convert_lead מה-CRM עם client_id, currency, value. לניתוח התוכן: page_location של עמודי מחירון ומקרי לקוח באותו client_id. |
CRM: עסקאות שנסגרו עם מזהה ליד מקור | סמנכ"ל מכירות |
שלוש הערות על הטבלה. ראשית, בעמודת ההגדרה המדויקת מופיעים כללים כמו "ליד כפול נספר פעם אחת" ו"פנייה דרך ספק חיצוני לא נספרת". הכללים האלה לא נולדים באנליטיקס, הם נולדים בשיחה עם מנהל המכירות. התוכנית מתעדת אותם כדי שכולם יספרו אותו דבר. שנית, בעמודת GA4 כתוב מתי האירוע נורה, לא רק מה שמו. "אחרי תגובת הצלחה מהשרת" הוא ההבדל בין ליד לשגיאה. שלישית, הפרמטרים currency ו-value מופיעים בכל שורה כי לפי התיעוד של Google, value חייב להיות מספר ומלווה ב-currency בפורמט ISO 4217. אם הפרמטר חסר או לא תקין, האירוע נספר ב-GA4 אבל לא נשלח ל-Google Ads. בתוכנית לידים B2B זה אומר שהבידינג של Google Ads לא מקבל את הערך.
איפה האירועים המומלצים כן נכנסים לתמונה?
אחרי שה-KPI מוגדרים, הרשימה של Google הופכת לכלי מצוין. אנחנו עוברים על כל שורה בטבלה ושואלים: האם יש אירוע מומלץ שמתאר בדיוק את מה שצריך למדוד? אם כן, משתמשים בו בשם ובפרמטרים המוגדרים. התיעוד של Google מסביר שאירועים מומלצים שנשלחים עם הפרמטרים שלהם ממלאים מימדים ומדדים מוגדרים מראש, מזינים דוחות כמו Lead acquisition ומאפשרים קהלים מוצעים ואינטגרציות עתידיות. רק כשאין אירוע מומלץ מתאים יוצרים אירוע מותאם. במילים של Google: יוצרים אירועים מותאמים רק כשאף אירוע אחר לא מתאים לשימוש. קטגוריית ייצור הלידים כוללת שישה אירועים שמכסים את כל המשפך: generate_lead לטופס שנשלח, qualify_lead ו-disqualify_lead לסינון, working_lead למגע של נציג, close_convert_lead ו-close_unconvert_lead לתוצאה. בדוגמה שלנו השתמשנו בשלושה מהם, כי רק שלושה נדרשו לחישוב ה-KPI.
איך מסמנים את האירועים כאירועי מפתח ב-GA4?
אירוע מפתח (Key Event) הוא, לפי ההגדרה של Google, אירוע שמודד פעולה חשובה במיוחד להצלחת העסק. כל אירוע שנאסף יכול להפוך לאירוע מפתח. ההחלטה מי מהם מקבל את הסימון היא בדיוק החלטה של תוכנית המדידה. שני פרטים מהתיעוד משפיעים על התכנון. ראשית, הסימון לא רטרואקטיבי: הוא משפיע על הדוחות מרגע הסימון ולא משנה נתונים היסטוריים. בדוחות הסטנדרטיים הוא מופיע בתוך עד 24 שעות. לכן מסמנים כבר ביום ההעלאה, לא כשמישהו שואל. שנית, לכל אירוע מפתח יש שיטת ספירה: Once per event, שהיא ברירת המחדל וההמלצה של Google, סופרת כל הפעלה, או Once per session, שמסומנת כ-Legacy וסופרת פעם אחת בסשן. גם שינוי שיטת הספירה חל על אירועים עתידיים בלבד.
בתוכנית לידים אנחנו משאירים Once per event ומטפלים בכפילויות בקוד ובהגדרת ה-KPI, לא בהגדרת GA4. הסיבה: שינוי שיטת הספירה משפיע על כל הדוחות של אותו אירוע, בעוד שהכלל "ליד כפול נספר פעם אחת" נוגע ל-KPI אחד. את ההפרדה בין אירוע מפתח להמרה כדאי להסביר למי שרואה את המספרים: לפי Google, הזרימה היא אירוע, אחר כך אירוע מפתח ואחר כך המרה שנוצרת ב-Google Ads מאירוע המפתח ומשותפת בין הפלטפורמות. המרות ב-Google Ads משתמשות בחלון ייחוס, בייחוס ובשיטת ספירה משלהן. לכן המספר בהן שונה מספירת אירוע המפתח ב-GA4. זה לא באג וזה גם לא נושא לתוכנית המדידה, אלא לדוח השוואה נפרד.
איך בודקים שהתוכנית מיושמת נכון? בדיקות קבלה
תוכנית מדידה בלי בדיקות קבלה היא מסמך כוונות. בדיקת קבלה מגדירה מראש מה נחשב "עובד" לכל שורה בטבלה, כך שהמפתח, האנליסט ומנהל המכירות מסכימים על זה לפני שמתחילים לאסוף נתונים. לאתר לידים יש שתי בדיקות שאסור לדלג עליהן ועוד ארבע שסוגרות את התמונה.
- ליד נספר פעם אחת. פותחים Preview ב-Google Tag Manager, שולחים טופס תקין ובודקים ב-Tag Assistant וב-DebugView של GA4 שהאירוע generate_lead מופיע בדיוק פעם אחת. חוזרים על השליחה בלחיצה כפולה מהירה על הכפתור: עדיין אירוע אחד. מרעננים את עמוד התודה: לא נורה אירוע נוסף. חוזרים לעמוד התודה דרך כפתור "אחורה" בדפדפן: לא נורה אירוע נוסף.
- שגיאה אינה ליד. שולחים טופס עם שדה חובה ריק: לא נורה generate_lead. שולחים אימייל בפורמט לא תקין: לא נורה. מנתקים את החיבור לשרת או מדמים תגובת שגיאה: לא נורה. אם האירוע נורה באחד מהמקרים האלה, ה-push יושב על לחיצת הכפתור ולא על תגובת ההצלחה. המפתח צריך להעביר אותו.
- הפרמטרים מגיעים נכון. ב-DebugView לוחצים על האירוע ובודקים ש-lead_source ו-form_id מגיעים כמחרוזות, ש-value מגיע כמספר ולא כמחרוזת ושcurrency הוא ILS. פרמטר שחסר כאן ייעלם מהדוחות ומ-Google Ads בשקט.
- הסימון והספירה מוגדרים. ב-Admin, תחת Data display, בלשונית Key events, מוודאים ש-generate_lead ו-qualify_lead מסומנים, ששיטת הספירה היא Once per event ושיש ערך ברירת מחדל רק אם התוכנית דורשת אותו.
- החיבור ל-CRM סגור. שולחים ליד ניסוי, מאתרים אותו ב-CRM ומוודאים שה-client_id נשמר ברשומה. משנים את הסטטוס ל"מתאים" ובודקים שאירוע qualify_lead מגיע ל-GA4 עם אותו client_id. בלי השלב הזה, KPI 1, 3 ו-4 בעץ לא ניתנים לחישוב.
- התאמה למקור אמת לאורך שבוע. אחרי שבוע של איסוף משווים את מספר האירועים generate_lead ב-GA4 למספר השליחות המוצלחות במערכת הטפסים ולמספר הלידים החדשים ב-CRM, לפי יום. פער קבוע וקטן, שנובע מהסכמה לקוקיז ומחוסמי פרסומות, הוא תקין ומתעדים אותו בתוכנית כסף מקובל. פער משתנה או גדול מצביע על בעיה בהטמעה ולא על בעיה עסקית.
שתי הערות לבדיקה. ראשית, לפי התיעוד של Google, אירועים לא מופיעים ב-DebugView כשמופעל Consent Mode והמשתמש לא נתן הסכמה, לכן מאשרים את באנר ההסכמה לפני הבדיקה. שנית, בבדיקת ההתאמה למקור אמת זוכרים שנתוני אירוע מפתח מופיעים בדוחות הסטנדרטיים בתוך עד 24 שעות, אז לא משווים את היום הנוכחי.
מהן הטעויות הנפוצות בבניית תוכנית מדידה?
הטעות הראשונה היא להתחיל מהרשימה. כבר דיברנו עליה, אבל יש לה גרסה מתוחכמת יותר: להתחיל מרשימת האירועים שהייתה בנכס Universal Analytics הישן או בקונטיינר GTM הקיים. גם זו רשימה, לא תוכנית. אירועים ישנים נכנסים לתוכנית רק אם KPI בעץ צריך אותם.
הטעות השנייה היא KPI בלי הגדרה מדויקת. "לידים" הוא לא KPI. "שליחות טופס מוצלחות של טופס צור קשר, בלי כפילויות באותו אימייל בתוך 30 יום, בלי טראפיק פנימי" הוא KPI. ההבדל מתגלה בפעם הראשונה שהשיווק מציג 120 לידים והמכירות אומרות שקיבלו 70.
הטעות השלישית היא מקור אמת שהוא GA4 עצמו. GA4 הוא כלי מדידה, לא מערכת רשומות. מקור האמת לליד הוא ה-CRM, לעסקה הוא מערכת החיוב, לעלות מדיה הוא החשבונית. כשאין מקור אמת חיצוני אי אפשר לדעת אם המספר ב-GA4 נכון. אז הדיון עם ההנהלה הופך לדיון על אמינות הכלי במקום על הביצועים.
הטעות הרביעית היא KPI בלי בעלים. מספר שאף אחד לא אחראי עליו מתקלקל בשקט: מישהו משנה את הטופס, האירוע מפסיק לירות ושלושה חודשים אחר כך מגלים גרף שנפל לאפס. הבעלים לא חייב להיות טכני. הוא צריך לדעת מה המספר אמור להיות בערך ולשאול כשהוא לא.
הטעות החמישית היא לדלג על בדיקת "שגיאה אינה ליד". זו הבדיקה שהכי קל להשמיט כי הטופס התקין עובד. ובכל זאת, ברוב הפערים שאנחנו רואים בין GA4 ל-CRM, האירוע נורה על לחיצה ולא על הצלחה. הטעות השישית היא לא לסמן את אירועי המפתח ביום ההעלאה. הסימון לא רטרואקטיבי. שבועיים של נתונים שלא סומנו לא יחזרו.
איך ממשיכים מכאן?
תוכנית מדידה טובה היא מסמך של עמוד או שניים שכולם בארגון מסכימים עליו, לא מפרט של 40 אירועים. אם ה-KPI שההנהלה מבקשת לא מחושבים היום מ-GA4, או שהמספרים בדשבורד לא מתיישבים עם ה-CRM, אנחנו בונים את העץ ואת הטבלה יחד איתכם, כותבים את מסמך ההטמעה למפתחים ומבצעים את בדיקות הקבלה. פרטים בעמוד מדידה מתקדמת ובעמוד ליווי אנליטי. את ה-KPI מהטבלה אנחנו בדרך כלל מעבירים ישירות לדשבורד ניהולי. אפשר לפנות אלינו דרך טופס הקשר.
מדריכים קשורים
מקורות
Analytics Help - Recommended events, Analytics Help - About events, Analytics Help - Mark events as key events, Analytics Help - Change the counting method of key events, Analytics Help - Conversions vs. key events in Google Analytics
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי