למה צריך ניטור אם כבר נעשה אודיט?
אודיט הוא צילום מצב שאומר שביום הבדיקה המדידה הייתה תקינה. מאותו יום האתר ממשיך להשתנות: עולה גרסה חדשה, מישהו מפרסם שינוי בקונטיינר של Google Tag Manager, באנר ההסכמה מוחלף, ספק הסליקה משנה את עמוד התודה. כל אחד מהשינויים האלה יכול לשבור אירוע בלי שאף אחד ישים לב.
נתונים שלא נאספו לא חוזרים. אם אירוע הרכישה הפסיק להישלח ביום שלישי והתגלה כעבור חודש, אין דרך לשחזר את החודש הזה ב-GA4. לכן ניטור הוא ההמשך הטבעי של האודיט. את הבדיקות החד פעמיות עצמן ריכזנו בצ'קליסט אודיט GA4, בעוד שכאן מדובר במה שרץ אחר כך באופן קבוע.
מה ההבדל בין Automated insights ל-Custom insights?
לפי התיעוד של Google, ב-Analytics Insights יש שני סוגים. Automated insights נוצרים בלי הגדרה: המערכת מזהה שינויים חריגים או מגמות חדשות ומציגה אותם בלוח ה-Insights. Custom insights הם תנאים שאתם מגדירים לשינויים שחשובים לכם. כשתנאי מתקיים התובנה מופיעה בלוח ואפשר גם לקבל עליה מייל.
ההבדל המעשי: ב-Automated insights המערכת מחליטה בעצמה מה מעניין. התיעוד מתאר התראות במייל רק עבור Custom insights, לכן הם שכבת ההתראות האמיתית. את שני הסוגים מוצאים בכרטיס Insights בעמוד הבית של הנכס, דרך הקישור View all insights. לפי התיעוד התובנות נשמרות שנה. רק משתמש בתפקיד Editor או Administrator יכול ליצור, לערוך ולשתף אותן.
שתי שכבות של ניטור
מהאיסוף ועד התיקון: מי תופס מה
איך יוצרים Custom Insight?
השלבים לפי התיעוד של Google:
- פותחים את רשימת התובנות. בכרטיס Insights לוחצים על View all insights ואז על Create.
- בוחרים נקודת פתיחה. אפשר לסמן תובנות מוצעות וללחוץ Create selected, או לבחור Create new תחת Start from scratch.
- קובעים תדירות בדיקה. Hourly, Daily, Weekly או Monthly, כשלפי התיעוד בדיקה שעתית זמינה רק לנתוני web.
- בוחרים סגמנט. ברירת המחדל היא All Users. דרך Change בוחרים מימד וערכים ומחליטים אם לכלול או להחריג אותם.
- בוחרים מדד, תנאי וסף. הדוגמה בתיעוד היא התראה כשמספר המשתמשים הפעילים ב-30 הימים האחרונים יורד ביותר מ-20%. בתנאי Has anomaly לא מזינים ערך, כי המערכת קובעת בעצמה מה חריג.
- נותנים שם ומגדירים נמענים. כברירת מחדל כל משתמשי הנכס רואים את התובנה בלוח. כדי לקבל מייל מזינים כתובות.
- שומרים ב-Create. אחר כך מנהלים את הרשימה דרך Manage: מדליקים ומכבים את Email Notifications לכל תובנה או מוחקים אותה.
אילו התראות כדאי להגדיר?
חמישים זה הרבה יותר ממה שצריך, כי התראה שקופצת כל יום מפסיקה להיקרא בתוך שבועיים. מומלץ להתחיל עם חמש עד שמונה התראות על המדדים שהעסק נשען עליהם ולהוסיף רק אחרי תקלה שלא נתפסה. הטבלה מציגה את נקודת הפתיחה. את המדד המדויק בוחרים מתוך הרשימה שבמסך היצירה.
| מה מנטרים | התנאי והתדירות | מה זה בדרך כלל אומר |
|---|---|---|
| סך אירועי המפתח | Has anomaly בבדיקה יומית | תג שנשבר, טופס שהוחלף או קמפיין שנעצר |
| הכנסה או רכישות | ירידה באחוזים מעל סף בבדיקה יומית | תקלה בצ'קאאוט או באירוע purchase |
| סשנים באתר | Has anomaly בבדיקה שעתית, רק לנתוני web | התג ירד מעמודים או שהאתר לא זמין |
| סשנים בסגמנט של ערוץ בתשלום | ירידה באחוזים מעל סף בבדיקה יומית | תיוג קמפיינים, קישור חשבונות או תקציב שנגמר |
| מדד מרכזי בסגמנט של סוג מכשיר | Has anomaly בבדיקה יומית | תקלה בגרסה אחת של האתר |
| משתמשים פעילים | ירידה באחוזים מעל סף בבדיקה שבועית | שחיקה איטית שבדיקה יומית לא מבליטה |
שימו לב שאנומליה עובדת לשני הכיוונים. קפיצה חדה במספר הרכישות היא סימן אזהרה באותה מידה כמו ירידה, כי לעיתים קרובות המשמעות שלה היא אירוע שנשלח פעמיים. את המקרה הזה פירטנו ברכישות כפולות ב-GA4.
איך GA4 מחליט מה נחשב אנומליה?
לפי התיעוד של Google, זיהוי האנומליות מפעיל על הנתונים ההיסטוריים מודל סדרות עתיות מסוג Bayesian state-space ומפיק תחזית לנקודת הנתונים האחרונה, יחד עם טווח אמינות (credible interval). נקודה מסומנת כאנומליה כשהערך בפועל נופל מחוץ לטווח הזה. תקופת האימון תלויה בתדירות: שבועיים לאנומליות שעתיות, 90 יום לאנומליות יומיות ו-32 שבועות לאנומליות שבועיות.
מזה נגזרות שתי מסקנות מעשיות. הראשונה: המודל נשען על היסטוריה. בנכס חדש או אחרי שינוי גדול במדידה כדאי להוסיף לצד Has anomaly גם תנאי של אחוז שינוי קבוע, שאינו תלוי בהיסטוריה. השנייה: מודל שמשווה כל נקודה לעבר הקרוב שלה בנוי לתפוס שינוי חד. שחיקה איטית לאורך חודשים הופכת בהדרגה לחלק מההיסטוריה. לכן שווה להחזיק גם התראה שבועית או חודשית עם סף באחוזים.
מה בודקים ידנית כל שבוע?
ההתראות תופסות שינוי במדד, אבל הן לא תופסות נתון שגוי שנראה יציב. לזה נועדה בדיקה של רבע שעה, ביום קבוע, על שבעת הימים שהסתיימו לפני יומיים לפחות. הסיבה למרווח: לפי התיעוד על Data freshness, עיבוד הנתונים יכול להימשך 24 עד 48 שעות ובפרק הזמן הזה המספרים עוד משתנים.
- (not set) במקור ובמדיום של הסשן. לפי התיעוד, (not set) הוא ערך שמופיע כש-GA4 לא קיבל מידע למימד. במימד Session source / medium הסיבה היא אירוע session_start חסר, מה שקורה למשל כשהטריגר של תג ה-Google ב-Tag Manager אינו מסוג Initialization. הסשנים האלה מופיעים כ-Unassigned בקיבוץ הערוצים.
- (not set) בעמוד הנחיתה. לפי התיעוד זה קורה כשבסשן אין אירוע page_view.
- (not set) במימדים של Google Ads. הסיבות שהתיעוד מונה: החשבון לא מקושר לנכס, auto-tagging כבוי או תיוג ידני חלקי.
- מחוון איכות הנתונים. האייקון Data quality מופיע ליד כותרת הדוח ובפינת ה-Exploration. הוא מציין אם הדוח מבוסס על כל הנתונים, אם הופעל thresholding או אם הנתונים דגומים. את המשמעות של כל מצב פירטנו בספי נתונים, דגימה ושורת (other) ב-GA4.
- השוואה למקור האמת. מספר הרכישות וההכנסה מול מערכת ההזמנות, מספר הלידים מול ה-CRM. לא מצפים לזהות מלאה אלא לפער יציב. לדוגמה, בנתוני דמו: אם GA4 מציג בדרך כלל כ-93% מההזמנות שבמערכת, שבוע שבו הוא מציג 80% הוא תקלה גם אם אף התראה לא קפצה.
- אירועים ופרמטרים חדשים. שמות אירועים שלא היו בשבוע שעבר, פרמטרים שמגיעים ריקים. לפי התיעוד, פרמטר מותאם שנרשם זה עתה עשוי להציג (not set) ב-24 השעות הראשונות, כך שלא כל ערך ריק הוא תקלה.
- לוח ה-Insights. מעבר מהיר על ה-Automated insights של השבוע, שלא הוגדרו אצלכם כהתראה במייל.
מה GA4 לא יתריע עליו?
כדאי להכיר את הגבולות של הכלי. Custom Insights בודקים מדדים של הנכס, לכן הם עיוורים לכמה סוגי תקלות. טעות שקיימת מהיום הראשון, למשל אירוע שתמיד נשלח פעמיים, אינה שינוי ולכן אינה אנומליה. ערך שגוי בתוך פרמטר, כמו מחיר בלי מע"מ או מטבע לא נכון, לא משנה את ספירת האירועים. פער מול מערכת ההזמנות נמצא מחוץ ל-GA4 לגמרי. בנתוני אפליקציה, כאמור, אין בדיקה שעתית.
מי שצריך ניטור עמוק יותר מייצא את הנתונים ל-BigQuery וכותב בדיקות משלו ברמת האירוע הבודד, כפי שהסברנו בייצוא GA4 ל-BigQuery. לרוב האתרים השילוב של חמש עד שמונה התראות עם הבדיקה השבועית מספיק.
מה עושים כשהתראה קופצת?
קודם מוודאים שזאת לא אזעקת שווא. בודקים שהתאריך כבר עבר עיבוד מלא ושאין חג או אירוע שמסביר את השינוי. אחר כך מצמצמים: האם זה כל האתר או רק מכשיר, דפדפן, ערוץ או עמוד מסוים. משם הולכים ליומן השינויים: גרסת הקונטיינר האחרונה שפורסמה, עליית גרסה לאתר, שינוי בבאנר ההסכמה. סדר האבחון המלא מופיע בירידה פתאומית בתנועה או בהמרות.
אחרי התיקון מתעדים. ב-GA4 אפשר להוסיף הערה (Annotation) על הגרף עם התאריך והסיבה, כך שמי שיראה את הבור בנתונים בעוד חצי שנה יבין מה קרה. לפי התיעוד, GA4 עשוי גם ליצור בעצמו הערה כשיש בעיה שמשפיעה על הנתונים בתאריך מסוים, שאותה אי אפשר לערוך או למחוק. הצעד האחרון הוא לשאול איזו התראה הייתה תופסת את התקלה מוקדם יותר ולהוסיף אותה.
שאלות נפוצות
כמה Custom Insights אפשר להגדיר בנכס GA4?
לפי התיעוד של Google כל נכס יכול להחזיק עד 50 Custom Insights. לכל אחד מגדירים תדירות בדיקה, סגמנט, מדד, תנאי ונמענים למייל. בפועל חמש עד שמונה התראות על המדדים המרכזיים מספיקות לרוב האתרים, כי התראות שקופצות לעיתים קרובות מדי מפסיקות להיקרא.
מה ההבדל בין Automated insights ל-Custom insights ב-GA4?
Automated insights נוצרים בלי הגדרה: GA4 מזהה שינויים חריגים או מגמות חדשות ומציג אותם בלוח ה-Insights. Custom insights הם תנאים שהמשתמש מגדיר. כשתנאי מתקיים התובנה מופיעה בלוח, עם אפשרות לקבל עליה מייל. לפי התיעוד רק Editor או Administrator יכולים ליצור, לערוך ולשתף תובנות.
באיזו תדירות Custom Insight יכול לבדוק את הנתונים?
לפי התיעוד של Google אפשר לבחור בין Hourly, Daily, Weekly ו-Monthly. בדיקה שעתית זמינה רק לנתוני web ולא לנתוני אפליקציה. לתקלות חדות באתר מתאימה בדיקה שעתית או יומית, לשחיקה איטית מתאימה בדיקה שבועית עם סף באחוזים.
איך GA4 מזהה אנומליה בנתונים?
לפי התיעוד של Google, המערכת מפעילה על הנתונים ההיסטוריים מודל סדרות עתיות מסוג Bayesian state-space ומפיקה תחזית לנקודה האחרונה יחד עם טווח אמינות (credible interval). נקודה מסומנת כאנומליה כשהערך בפועל נופל מחוץ לטווח הזה. תקופת האימון היא שבועיים לאנומליות שעתיות, 90 יום ליומיות ו-32 שבועות לשבועיות.
למה מופיע (not set) במקור ובמדיום של הסשן?
לפי התיעוד של Google, (not set) מופיע כש-GA4 לא קיבל מידע למימד. במימד Session source / medium הסיבה היא אירוע session_start חסר, מה שקורה למשל כשהטריגר של תג ה-Google ב-Tag Manager אינו מסוג Initialization. הסשנים האלה מופיעים כ-Unassigned בקיבוץ הערוצים. עלייה בשיעור שלהם משבוע לשבוע היא סימן לתקלה בהטמעה.
מה Custom Insights לא יכולים לזהות?
הם בודקים שינוי במדדים, לכן הם לא מזהים טעות שקיימת מהיום הראשון, למשל אירוע שתמיד נשלח פעמיים. הם גם לא מזהים ערך שגוי בתוך פרמטר, כמו מטבע לא נכון, כי ספירת האירועים לא משתנה. פער מול מערכת ההזמנות או ה-CRM נמצא מחוץ ל-GA4. את אלה תופסים בבדיקה ידנית שבועית.
מה השורה התחתונה?
איכות נתונים לא נשמרת מעצמה. הגדירו השבוע חמש עד שמונה Custom Insights על אירועי המפתח, ההכנסה והסשנים, עם מייל לאדם שבאמת יפתח אותו. קבעו רבע שעה קבועה בשבוע לבדיקה ידנית של (not set), של מחוון איכות הנתונים ושל הפער מול מערכת ההזמנות או ה-CRM. כל תקלה שהתגלתה מסתיימת בהערה על הגרף ובהתראה חדשה. הניטור השוטף הזה, כולל הטיפול בתקלה מול המפתחים והסוכנות, הוא חלק קבוע מהעבודה בשירות ליווי אנליטי שוטף שלנו. אם גיליתם תקלת מדידה באיחור של שבועות, כתבו לנו.
מקורות
Google Analytics Help: Analytics Insights, Google Analytics Help: [GA4] Anomaly detection, Google Analytics Help: What the value (not set) means in your reports, Google Analytics Help: Data quality, Google Analytics Help: Data freshness, Google Analytics Help: About annotations
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי