למה משפך ב-GA4 לבדו לא מספיק לאבחון?
משפך ב-GA4 הוא דוח כמותי. הוא נבנה מאירועים, סופר משתמשים שעברו משלב לשלב ומציג את שיעור הנטישה בין כל שני שלבים. זה מצוין לזיהוי המקום שבו הכסף הולך לאיבוד. התשובה שהוא נותן היא "40% מהמשתמשים שהתחילו תשלום לא רכשו". זו תשובה חשובה, אבל היא לא מספרת מה קרה בדקה שבין begin_checkout לבין היציאה מהאתר.
בצד השני, Clarity מראה את אותה דקה. בהקלטה רואים את האצבע מנסה ללחוץ, את הודעת השגיאה שקופצת, את הגלילה המהירה למטה ולמעלה. במפת החום רואים לאן רוב המשתמשים הגיעו ועל מה לחצו. אבל הקלטה היא סיפור של משתמש אחד. מפת חום היא ממוצע של כל המשתמשים בעמוד, גם אלה שלא היו בכלל במשפך. בלי המספרים של GA4 אין דרך לדעת אם מה שראינו בעשר הקלטות מייצג 2% מהנשירה או 60% ממנה.
בפרויקטים שלנו הכלל פשוט: GA4 אומר איפה וכמה. Clarity אומר מה ואיך. רק שילוב של השניים באותו פילוח אומר למה. בלי הפילוח המשותף מקבלים שתי תמונות שלא מתיישבות אחת עם השנייה. בדיוק את המקרה הזה נדגים בהמשך.
מה כל מקור מידע יודע להגיד ומה הוא לא יודע?
הטבלה הבאה מסכמת את חלוקת העבודה בין המקורות. היא לא מדרגת אותם לפי חשיבות. כל אחד מהם עונה על שאלה אחרת. אבחון טוב עובר ביניהם בסדר קבוע.
| סוג נתון | מה הוא יודע להגיד | מה הוא לא יודע | מתי משתמשים |
|---|---|---|---|
| משפך GA4 (Funnel exploration) | כמה משתמשים עברו כל שלב, שיעור הנטישה בין שלבים, זמן ממוצע בין שלבים, הפעולה הבאה הנפוצה אחרי כל שלב, פילוח לפי מכשיר, מקור או כל מימד אחר | מה המשתמש ראה על המסך, איפה לחץ, האם קיבל שגיאה, האם הכפתור היה בכלל גלוי | שלב ראשון תמיד. לאיתור השלב הבעייתי, להשוואה בין תקופות ולהוכחה שתיקון עבד |
| הקלטות Clarity (Recordings) | רצף הפעולות המדויק של סשן בודד: גלילה, לחיצות, הקלדה בטופס, שגיאות JavaScript, רגעי תסכול | כמה סשנים התנהגו כך. הקלטה היא דוגמה, לא מדגם מייצג, אלא אם מסננים ומונים | אחרי שהשלב הבעייתי ידוע. לגיבוש השערות על הסיבה, בסינון לפי עמוד, מכשיר וסוג בעיה |
| מפות חום Clarity (Heatmaps) | איפה מתרכזות הלחיצות על אלמנטים, עד איפה המשתמשים גוללים (Scroll map), איפה הקו הממוצע שמעליו רואים בלי לגלול (Average fold), כמה זמן נשארים בכל חלק של העמוד | סדר הפעולות, מה קרה אחרי הלחיצה, האם המשתמש הגיע מהמשפך או נחת בעמוד ישירות | לבדיקת פריסה: האם הפעולה המרכזית נראית, האם לוחצים על דברים שאינם לחיצים, האם מחפשים משהו שלא קיים |
| Rage clicks ו-Dead clicks | Rage click: לחיצות מרובות באזור מרוכז בזמן קצר. Dead click: לחיצה על אלמנט שלא נותנת שום משוב ולא מובילה לניווט. שניהם זמינים כסינון להקלטות וכשכבה במפת החום | האם המשתמש בסוף נטש. תסכול לא שווה נשירה. חובה להצליב עם המשפך | כקיצור דרך להקלטות הרלוונטיות ביותר. מסננים לפי Rage clicks או Dead clicks בעמוד שבו המשפך נשבר |
איך בונים את המשפך ב-GA4 לפני שפותחים את Clarity?
הטעות הראשונה היא לפתוח את Clarity לפני שיש שאלה מדויקת. השאלה מגיעה מהמשפך. לכן בונים אותו קודם. ב-GA4 נכנסים ל-Explore ובוחרים בתבנית Funnel exploration. התיעוד של Google מאפשר עד 10 שלבים במשפך, אבל לאבחון רכישה ארבעה שלבים מספיקים.
- מגדירים ארבעה שלבים לפי אירועי המסחר הסטנדרטיים: view_item, add_to_cart, begin_checkout, purchase. כל שלב הוא תנאי על שם האירוע, לא על מטריקה.
- בוחרים משפך סגור (Closed funnel). במשפך סגור המשתמש חייב להיכנס בשלב הראשון. לכן שיעורי הנטישה משקפים מסע רצוף ולא כניסות באמצע.
- מוסיפים Breakdown לפי Device category. זה הפילוח שיכריע בהמשך בין ההסברים. לכן הוא חלק מהמשפך מהרגע הראשון.
- מפעילים Show elapsed time כדי לראות את הזמן הממוצע בין השלבים. בוחרים מימד ל-Next action כדי לראות מה המשתמשים עשו אחרי שלב התשלום במקום לרכוש.
- שומרים את המשפך ומצלמים את המספרים לפני כל שינוי באתר. בלי קו בסיס אי אפשר להוכיח שתיקון עבד.
שתי הערות על קריאת המספרים. GA4 מדווח במשפך על משתמשים ולא על סשנים. משתמש שעבר את המסלול פעמיים בטווח התאריכים נספר פעם אחת לפי המסלול הראשון. ב-Breakdown כל משתמש משויך לערך הראשון שחל עליו. לכן משתמש שהתחיל במובייל וסיים בדסקטופ יופיע בשורה אחת בלבד. Clarity מצד שני סופר סשנים. האחוזים לא יהיו זהים בשני הכלים. זה בסדר. מה שצריך להתיישב הוא הכיוון וסדר הגודל.
מה Clarity מוסיף שאין ב-GA4?
הקלטות סשן
ההקלטה משחזרת את הסשן על גבי ה-DOM: גלילה, לחיצות, מעבר בין שדות ושגיאות שנזרקו בדפדפן. היתרון הגדול הוא הסינון. במקום לצפות באקראי, מסננים לפי עמוד התשלום, לפי מכשיר ולפי סוג בעיה. Clarity מסמן אוטומטית כמה דפוסים: Rage clicks, Dead clicks, Excessive scrolling (גלילה אנכית גבוהה בהרבה מהממוצע), Quick backs (יציאה לאתר אחר וחזרה מהירה), שגיאות JavaScript. בנוסף יש Error clicks, שגיאות JavaScript שקורות מיד אחרי לחיצה. הסינון האחרון הוא הכי שימושי לטפסים, כי הוא תופס בדיוק את הרגע שבו המשתמש לחץ על "לתשלום" והטופס נכשל.
מפות חום
Clarity מציע כמה סוגים של מפות. מפת לחיצות (Click map) בנויה על אלמנטים ולא על מיקום עכבר מוחלט. לכן היא עמידה לשינויי רזולוציה. אפשר להציג בה שכבות של Dead clicks, Rage clicks ו-Error clicks בלבד. מפת גלילה (Scroll map) מראה איזה אחוז מהמשתמשים הגיע לכל נקודה בעמוד. היא מסמנת גם את ה-Average fold, הקו הממוצע שמעליו המשתמשים רואים את העמוד לפני שהם גוללים. מפת אזור (Area map) סוכמת לחיצות בתוך מסגרת שמסמנים ידנית. מפת תשומת לב (Attention map) מראה כמה זמן שהו בכל חלק. לאבחון משפך שתי המפות החשובות הן מפת הגלילה ושכבת ה-Dead clicks.
משפכים ב-Clarity
גם ל-Clarity יש משפכים, שנבנים מביקורי עמוד ומאירועים חכמים (Smart events). לכל שלב מוצגים אחוז ומספר הסשנים שהתקדמו ושלא התקדמו. מכל שלב אפשר לקפוץ ישירות להקלטות או למפות החום המסוננות. זה חוסך את הסינון הידני, אבל זה משפך של סשנים ולא של משתמשים. הוא לא מחליף את המשפך ב-GA4 שמחובר לשאר הדיווח העסקי.
איך מחברים את Clarity ל-GA4 ומה החיבור באמת עושה?
האינטגרציה מושכת נתונים מ-GA4 אל Clarity, לא בכיוון ההפוך. אחרי החיבור מופיע ב-Clarity לוח Google Analytics עם סשנים ומשך סשן, ערוצי רכישה ומקור/מדיום, עמודים פופולריים, סשנים לפי מדינה ולפי מכשיר. מכל כרטיס אפשר לעבור להקלטות או למפות חום באותו טווח תאריכים. בנוסף, סגמנטים שהוגדרו ב-Google Analytics מופיעים בלשונית Recordings בלבד, לא בלוח ולא במפות החום. חשוב לדעת שלפי התיעוד של Microsoft, Clarity אינו שולח ל-GA4 את כתובת ההקלטה (Playback URL) כמימד מותאם בגלל קרדינליות גבוהה. לוח ה-GA בתוך Clarity לא תומך בפילטרים או בסגמנטים מלבד טווח תאריכים.
- ב-Clarity נכנסים לפרויקט, לוחצים Settings ואז Setup. תחת Google Analytics integration לוחצים Get Started.
- מתחברים עם חשבון Google שיש לו הרשאה ל-property, בוחרים את ה-property הרצוי ושומרים. לכל פרויקט Clarity אפשר לחבר property אחד בלבד.
- אם החיבור האוטומטי נכשל, מזינים ידנית Account ID, Measurement ID (מתחיל ב-G) ו-Property ID מתוך Admin ב-GA4.
- משלימים את החיבור בצד שלנו: דרך Google Tag Manager שולחים ל-Clarity תגיות מותאמות (Custom tags) בפקודה clarity("set", "key", "value") עם שם שלב המשפך, סוג המשתמש או מזהה הקמפיין. התגיות הופכות לפילטרים בהקלטות, במפות החום ובלוח הבקרה. הן מאפשרות לסנן ב-Clarity בדיוק את אותה אוכלוסייה שמופיעה בשורה במשפך ב-GA4.
השלב הרביעי הוא זה שעושה את ההבדל. האינטגרציה הרשמית נותנת הקשר, אבל התגיות המותאמות הן שמייצרות את הפילוח המשותף שעליו כל האבחון נשען.
דוגמת דמו: נשירה בשלב התשלום עם שני הסברים סותרים
הנתונים הבאים הם נתוני דמו שנבנו לצורך ההדגמה, לא נתוני לקוח. אתר מסחר, 30 ימים, משפך סגור בארבעה שלבים. 10,000 משתמשים צפו במוצר, 3,400 הוסיפו לעגלה, 2,100 התחילו תשלום ו-840 רכשו. הנטישה בין begin_checkout לבין purchase עומדת על 60%, לעומת 45% בתקופה המקבילה הקודמת. השלב הבעייתי זוהה. עכשיו השאלה היא למה.
גרף משפך
משפך הרכישה ושלושת מקורות המידע שמסבירים את הנשירה
נתוני דמו, GA4, משפך סגור. הנשירה הגדולה בין begin_ ל-purchase היא השלב שנבדק.
view_item10,000 משתמשיםadd_to_cart3,400 משתמשיםbegin_checkout2,100 משתמשיםpurchase840 משתמשיםפילוח לפי מכשיר: מובייל 20% לעומת דסקטופ 62%
הסבר א': שגיאת ולידציה בשדה הטלפון, 9% מהסשנים
הסבר ב': כפתור התשלום מתחת לקו הגלילה, 54% לא הגיעו אליו
מה ההקלטות מראות
פותחים את Recordings ב-Clarity, מסננים לעמוד התשלום, למכשיר Mobile ולסינון Error clicks. בהקלטות חוזר תסריט אחד: המשתמש ממלא את הטופס, לוחץ על "לתשלום" ושדה הטלפון נצבע באדום עם הודעה על מספר לא תקין. חלק מנסים שוב, רובם יוצאים. ההסבר הראשון נראה משכנע: ולידציה שגויה של מספרי טלפון במובייל.
מה מפת החום מראה
פותחים את מפת הגלילה של אותו עמוד, מסוננת ל-Mobile. ה-Average fold נמצא מעל כפתור התשלום. לפי המפה רק 46% מהסשנים הגיעו לגובה שבו הכפתור מופיע. בשכבת ה-Dead clicks רואים ריכוז לחיצות על סיכום ההזמנה שאינו לחיץ, ממש מעל הקו. ההסבר השני נראה משכנע לא פחות: רוב המשתמשים במובייל לא ראו את הכפתור בכלל.
איך מכריעים
שני ההסברים נכונים ברמת ההקלטה הבודדת, אבל רק פילוח כמותי אומר איזה מהם מסביר את הנשירה. חוזרים למשפך ב-GA4 עם ה-Breakdown לפי מכשיר. בדמו, בדסקטופ 1,000 משתמשים התחילו תשלום ו-620 רכשו, שיעור השלמה של 62%. במובייל 1,100 התחילו ו-220 רכשו, שיעור השלמה של 20%. הבעיה היא בעיית מובייל. שני ההסברים עדיין חיים.
עכשיו מונים ב-Clarity באותו פילוח. מתוך סשני התשלום במובייל, 9% כוללים Error click. גם אם כל אחד מהם נטש, זה מסביר 9 נקודות מתוך פער של 42 נקודות מול הדסקטופ. מפת הגלילה אומרת ש-54% לא הגיעו לכפתור. זה סדר גודל שמתיישב עם הפער. הצלבה שלישית ב-GA4 סוגרת את העניין: הזמן הממוצע בין begin_checkout לבין היציאה במובייל קצר (38 שניות בדמו לעומת 2:40 דקות בדסקטופ). ב-Next action הערך הנפוץ הוא "(no next action)". משתמש שנלחם בטופס נשאר דקות, משתמש שלא מצא כפתור יוצא תוך חצי דקה. ההכרעה: ההסבר של מפת החום הוא העיקרי, שגיאת הטופס היא בעיה אמיתית אך משנית. שתיהן נכנסות לרשימת התיקונים בסדר הזה.
הנקודה המתודולוגית חשובה יותר מהמספרים. הקלטות מוטות לכיוון דרמה, כי הסינון לפי Error clicks או Rage clicks מביא קודם את הסשנים הסוערים. מפות חום מוטות לכיוון ממוצע, כי הן מערבבות את כל מי שהגיע לעמוד. רק מספר מהמשפך, מפולח לאותו מכשיר ולאותו עמוד, מאפשר לשקלל את שני הכיוונים.
מהן הטעויות הנפוצות באבחון משולב?
הטעות הראשונה היא להתחיל מההקלטות. צופים בעשרים הקלטות, מוצאים משהו מרגיז ומתקנים אותו, בלי לדעת כמה משתמשים זה נגע. השנייה היא להשוות משפך פתוח ב-GA4 למשפך ב-Clarity ולהתפלא שהמספרים שונים. GA4 סופר משתמשים במשפך סגור או פתוח לפי הבחירה. Clarity סופר סשנים. השוואה ישירה של אחוזים בין הכלים לא תקפה. השלישית היא לקרוא מפת גלילה בלי פילוח מכשיר. מפת גלילה של "כל המכשירים" ממצעת דסקטופ ומובייל. הקו הממוצע שהיא מראה לא קיים אצל אף משתמש אמיתי.
הטעות הרביעית קשורה לקיימות הנתונים. ההקלטות ב-Clarity נמחקות לפי מדיניות השמירה של הכלי. לכן ממצא שלא תועד בצילום מסך או במסמך נעלם. הטעות החמישית היא לפרש Rage clicks כנטישה. משתמש יכול ללחוץ בעצבים על אלמנט איטי ועדיין לרכוש. חובה להצליב תסכול עם נשירה. השישית היא לחבר את Clarity לפרופרטי GA4 אחד ולא לדאוג לתגיות מותאמות. אחר כך מגלים שאין איך לבודד ב-Clarity את אותה אוכלוסייה שרואים במשפך. השביעית היא לשכוח שחלק מהסשנים ב-Clarity לא כוללים כלל אירועי GA4 בגלל הסכמת משתמש או חוסמי פרסומות. לכן האוכלוסיות אינן זהות גם כשהפילוח זהה.
איך בודקים שזה עובד?
הבדיקה הראשונה היא בדיקת נתונים. במשפך ב-GA4 בודקים שכל אחד מארבעת האירועים נורה פעם אחת לכל פעולה ושאין שלב שבו מספר המשתמשים גבוה מהשלב שלפניו, מה שמעיד על בעיית הטמעה ולא על התנהגות. ב-Clarity בודקים שעמוד התשלום מופיע ברשימת העמודים עם מספר סשנים הגיוני ביחס ל-GA4, בסדר גודל של פי אחד עד פי שניים לכל כיוון. בודקים גם שהתגיות המותאמות מופיעות תחת Filters. לפי התיעוד, תגית חדשה מופיעה בפרויקט בתוך 30 דקות עד שעתיים. עד אז רואים אותה בפרטי האירועים של הקלטה בודדת.
הבדיקה השנייה היא בדיקת החיבור. בלוח Google Analytics בתוך Clarity בודקים שמספר הסשנים לפי מכשיר דומה למה שרואים ב-GA4 באותו טווח תאריכים. בודקים גם שסגמנט שהוגדר ב-GA4 מופיע בלשונית Recordings. הבדיקה השלישית היא בדיקת תוצאה. אחרי תיקון, למשל העלאת כפתור התשלום מעל הקו הממוצע במובייל, חוזרים למשפך ב-GA4 בתצוגת Trended funnel ובודקים שאחוז ההשלמה במובייל בשלב התשלום עולה לאורך שבועיים לפחות ולא רק ביום אחד. במקביל בודקים במפת הגלילה שהאחוז שמגיע לכפתור עלה ושה-Dead clicks על סיכום ההזמנה ירדו. אם המשפך לא זז אבל מפת החום השתפרה, ההסבר היה שגוי. חוזרים להקלטות עם השאלה הבאה.
אבחון כזה הוא הליבה של שירות שיפור המרות שלנו: הקמת משפכים ב-GA4, הטמעת Clarity ותגיות מותאמות דרך Tag Manager וניתוח משולב שמסתיים ברשימת תיקונים מסודרת לפי היקף הנשירה שכל אחד מהם מסביר. אם המשפך שלכם מראה נשירה שאתם לא מצליחים להסביר, אפשר לפנות אלינו דרך טופס הקשר.
עוד מדריכים בנושא שיפור המרות
מקורות
Google Analytics Help: [GA4] Funnel exploration, Microsoft Learn: Clarity semantic metrics (rage clicks, dead clicks, error clicks), Microsoft Learn: Clarity heatmaps overview, Microsoft Learn: Clarity GA4 integration, Microsoft Learn: Clarity custom tags
