בדיקה מסודרת מהפעולה באתר אל התג ואל GA4, עם זיהוי פערים בין Preview, קליטת אירוע ודוח רגיל.
Tag Assistant ו־DebugView עונים על שאלות שונות. הראשון עוזר לבדוק מה קרה לתגים בדפדפן, והשני מציג אירועי אבחון שהתקבלו בנכס Analytics. סימון Fired אינו הוכחה שכל הדוחות כבר עודכנו. במדריך נבנה בדיקה שניתן לחזור עליה: פעולה אחת, אירוע צפוי אחד, שם ופרמטרים מוסכמים. כך אפשר לאתר את התחנה שבה יש תקלה במקום לשנות כמה הגדרות יחד.
מה מכינים לפני שמתחילים
כתבו איזה אירוע בודקים, באיזה עמוד ואילו פרמטרים צפויים. הכינו הרשאות צפייה למכל ולנכס, ואת מזהה יעד המדידה הצפוי. בחרו פרטי בדיקה לא אישיים וסגרו חלונות אבחון שאינם קשורים. בדקו שמנגנון ההסכמה מוצג ופועל לפי ההגדרות המאושרות; אין להסיר אותו כדי לקבל תוצאה ירוקה.
בדיקה מתחילת הפעולה ועד הנכס
ב־GTM פתחו את סביבת העבודה הנכונה ולחצו Preview. הזינו את כתובת עמוד הבדיקה והשלימו את החיבור ב־Tag Assistant. ודאו שהמכל המזוהה הוא זה שנועד לבדיקה ושחלון האתר המחובר נשאר פתוח. חיבור לעמוד אחר אינו מוכיח שהעמוד המתוכנן מכיל את אותו קוד.
בצעו פעם אחת את הפעולה שהוגדרה. בזרם האירועים בחרו את האירוע המדויק, למשל קליק או אירוע מותאם של הצלחת טופס. בדקו גם Tags Fired וגם Tags Not Fired. בתג שלא נורה פתחו את תנאי ההפעלה ובדקו איזה ערך בפועל לא התאים.
פתחו את Variables ואת נתוני האירוע ובדקו שם, יעד וערכים. אם משתנה ריק, תקנו את מקור הנתון ולא את הדוח. אם התג נורה פעמיים, חפשו שני אירועי מקור או שני תגים. בצעו תרחיש שלילי כגון ניסיון שליחת טופס לא תקין: אירוע הצלחה לא אמור להופיע.
בנכס GA4 הנכון פתחו Admin ואז DebugView באזור תצוגת הנתונים, בהתאם לממשק הזמין. בחרו מכשיר אבחון אם מופיעים כמה. חפשו את האירוע לפי זמן הפעולה, פתחו אותו ובדקו פרמטרים. נתון רגיש שנשלח בטעות מחייב עצירה ותיקון המקור, לא צילום ושיתוף שלו.
התנתקו מחיבור Tag Assistant כשסיימתם ותעדו את הגרסה שנבדקה. אם הוספתם debug_mode ידנית לתג או לקוד, הסירו את הפרמטר בסיום; הגדרתו ל־false אינה מכבה את מצב האבחון לפי תיעוד Google. אם נדרש פרסום מכל, עשו זאת רק לאחר אישור ובדקו גם את הגרסה שפורסמה. אחר כך בדקו דוח רגיל בטווח מתאים; היעדר מיידי בו אינו לבדו כישלון של בדיקת האבחון.
דוגמה היפותטית לאיתור התחנה שנכשלה
באתר דמיוני נשלח generate_lead אחרי אישור טופס. ב־Tag Assistant התג נורה, אך היעד שלו שייך לנכס ניסיון ולא לנכס המתוכנן. התיקון הוא יעד התג, לא יצירת אירוע נוסף ב־GA4. בדיקה מתועדת עם מזהה יעד הייתה חוסכת ניסיון לתקן את הטופס שעבד כראוי.
כש־DebugView נשאר ריק
בדקו מצב אבחון, נכס, מכשיר, חיבור רשת והסכמה. תוספי חסימה יכולים להשפיע על קליטה, אבל אין לעקוף בחירה של משתמש. ייתכן שהתג שלח אירוע בלי סימון אבחון או שנבחר מכשיר אחר. אם מופיע אירוע בלי פרמטר, בדקו אם הפרמטר הוגדר בתג הנכון ולא רק במשתנה שלא מחובר אליו.
מתחילים מהגדרת תוצאה צפויה
לפני חיבור האבחון כתבו תסריט שאפשר לבצע בלי לפרש כוונה. למשל: פתיחת עמוד קשר, מילוי שדות בדיקה, שליחה מוצלחת וקבלת אירוע generate_lead עם form_id מאושר. כתבו גם את התסריט ההפוך: שדה חובה חסר, הודעת שגיאה וללא אירוע הצלחה. בלי תוצאה צפויה, כל הופעת אירוע יכולה להיראות כמו הצלחה אף שהיא קשורה לפעולה אחרת.
השתמשו בשם בדיקה כללי ובכתובת בשליטתכם במקום פרטי לקוח. ודאו מראש מי מנקה את הפנייה ממערכת הניסיון ומי מקבל את המייל. תגי מדידה אינם צריכים לכלול את התוכן שהוזן. אם כבר רואים מידע אישי בפרמטר, עצרו את הפצת ההגדרה ותעדו את הבעיה בלי להעתיק את המידע לצילומים.
קוראים את רצף האירועים ולא רק את התג
ב־Tag Assistant רצף טעינה, לחיצה ואירוע מותאם מסביר מתי היו הנתונים זמינים. משתנה יכול להיות ריק בטעינת העמוד ומלא רק אחרי הצלחה. לכן יש לפתוח את האירוע המדויק שבו התג אמור לפעול, ולא לבדוק ערך באירוע אחר. אם התג נורה מוקדם מדי, שינוי שם המשתנה לא יתקן את עיתויו.
ב־Tags Not Fired בדקו את התנאים שמוצגים לכל תג. השוו את הערך בפועל לערך שהתנאי דורש, כולל אותיות, נתיב וסוג אירוע. ערך שנראה דומה יכול לכלול קו נטוי נוסף או פרמטר. אל תחליפו תנאי מדויק בתנאי שמכיל מילה כללית לפני שהבנתם את ההבדל. צמצום נכון מונע ירי על פעולות שלא נועדו להימדד.
מזהים יעד וגרסה לפני חיפוש ב־GA4
אתר יכול לכלול נכס ניסיון ונכס ייצור, ולעיתים גם כמה מכלים. רשמו מראש לאיזה יעד מצפים שהאירוע יישלח. בדקו שהמזהה בתג תואם לנכס שנפתח ושאתם בודקים את המכל המתאים. אין לפרסם מזהים או הרשאות שאינם דרושים לדוח הבדיקה, אך לבודק עצמו חייב להיות מיפוי ברור בין הסביבות.
סביבת העבודה ב־GTM יכולה להכיל שינוי שטרם פורסם, ובאתר הרגיל עדיין פעילה גרסה אחרת. לכן תוצאה מוצלחת ב־Preview אינה מסירת עבודה שלמה. אחרי אישור פרסום, התחברו לבדיקה חדשה או בדקו את הגרסה המפורסמת לפי נוהל הצוות. רשמו במפורש את מספר הגרסה ואת השעה, כדי שיהיה אפשר להבין תלונה שהגיעה לפני הפרסום לעומת אחריו.
מפרידים פרמטר שנשלח מהגדרה לדיווח
ב־DebugView אפשר לראות שם אירוע ופרמטרים, אבל זה אינו אומר שכל פרמטר כבר זמין בכל דוח סטנדרטי. אם התכנון דורש ממד מותאם, צריך להגדיר אותו בהיקף המתאים ולבדוק את זמינותו בניתוח הרצוי. אל תיצרו עשרות הגדרות רק משום שהן הופיעו פעם אחת במהלך אבחון; שמרו רק מה שנחוץ לשאלות העסקיות.
בדקו גם סוג ומשמעות: ערך מספרי, קוד קטגוריה וטקסט חופשי אינם אותה בחירה. מילון ערכים קטן עוזר לזהות סטייה. אם מצפים contact_form ורואים שם טכני אחר, בררו אם השינוי מכוון או תקלה. העדיפו תיקון במקור על פני הסבר ידני שכל ערך חריג בעצם אומר אותו דבר.
רישום כשל שמאפשר טיפול ממוקד
כאשר אין אירוע ב־DebugView, רשמו אם התג נורה, באיזה יעד, האם מצב אבחון היה פעיל ומה היה מצב ההסכמה. מידע זה מאפשר להפריד כשל טריגר מכשל שליחה או בחירת נכס. אפשר לבדוק בקשות רשת בכלי המפתח כאשר יש ידע מתאים, אך עצם קיום בקשה אינו אישור של כל שלבי העיבוד.
אין להשבית מנגנון הסכמה או לעקוף חסימת משתמש כדי לייצר צילום מוצלח. אם בדיקה לא נתמכת בתנאים מסוימים, כתבו זאת. בתיעוד הסופי ציינו עמוד, מכשיר ותרחישים שנבדקו, ולא טענה גורפת שכל המדידה באתר תקינה. בדיקת תג חדש בעמוד אחד לא מכסה אוטומטית טפסים אחרים, תתי־דומיינים או תהליך בתוך iframe.
בדיקת סיום והצעד הבא
סמנו בנפרד: פעולה בוצעה, תג נורה, אירוע נקלט ופרמטרים תואמים. צרפו תרחיש שלילי ומגבלות הבדיקה. אל תכתבו שהמערכת כולה תקינה אם נבדק רק עמוד אחד או רק מצב הסכמה אחד. העבירו את התוצאה לבעל המדידה עם שם גרסה ומועד.
שאלות ותשובות על איך לבדוק אירועים ב־Tag Assistant וב־GA4 DebugView
Preview מפרסם שינויים?
לא. הוא מאפשר לבדוק טיוטה בדפדפן המחובר. משתמשים אחרים אינם בהכרח מקבלים את אותה גרסה עד פרסום מאושר.
Fired אומר שהנתון התקבל?
לא בהכרח. זהו סימן בצד התג. בדיקת קליטה בנכס ובדיקת הדוח הן תחנות נפרדות שצריך לתעד בנפרד.
חייבים נתוני לקוח אמיתי?
לא. השתמשו בפעולות ובנתוני בדיקה מסומנים. הם מספיקים לבדיקת התנאים והמבנה בלי לחשוף מידע פרטי או ליצור פניות אמיתיות מיותרות.
מה מגדירים בתסריט הבדיקה לפני חיבור GTM ו־DebugView?
כתבו איזה אירוע בודקים, באיזה עמוד ואילו פרמטרים צפויים. הכינו הרשאות צפייה למכל ולנכס, ואת מזהה יעד המדידה הצפוי. בחרו פרטי בדיקה לא אישיים וסגרו חלונות אבחון שאינם קשורים. בדקו שמנגנון ההסכמה מוצג ופועל לפי ההגדרות המאושרות; אין להסיר אותו כדי לקבל תוצאה ירוקה.
איך מתחברים ל־Preview במכל ובעמוד הנכונים?
ב־GTM פתחו את סביבת העבודה הנכונה ולחצו Preview. הזינו את כתובת עמוד הבדיקה והשלימו את החיבור ב־Tag Assistant. ודאו שהמכל המזוהה הוא זה שנועד לבדיקה ושחלון האתר המחובר נשאר פתוח. חיבור לעמוד אחר אינו מוכיח שהעמוד המתוכנן מכיל את אותו קוד.
איך בודקים את האירוע המדויק ואת Tags Fired ו־Tags Not Fired?
בצעו פעם אחת את הפעולה שהוגדרה. בזרם האירועים בחרו את האירוע המדויק, למשל קליק או אירוע מותאם של הצלחת טופס. בדקו גם Tags Fired וגם Tags Not Fired. בתג שלא נורה פתחו את תנאי ההפעלה ובדקו איזה ערך בפועל לא התאים.
מה בודקים במשתנים כשערך חסר או תג נורה פעמיים?
פתחו את Variables ואת נתוני האירוע ובדקו שם, יעד וערכים. אם משתנה ריק, תקנו את מקור הנתון ולא את הדוח. אם התג נורה פעמיים, חפשו שני אירועי מקור או שני תגים. בצעו תרחיש שלילי כגון ניסיון שליחת טופס לא תקין: אירוע הצלחה לא אמור להופיע.
איך בוחרים את נכס GA4 ומכשיר האבחון הנכונים ב־DebugView?
בנכס GA4 הנכון פתחו Admin ואז DebugView באזור תצוגת הנתונים, בהתאם לממשק הזמין. בחרו מכשיר אבחון אם מופיעים כמה. חפשו את האירוע לפי זמן הפעולה, פתחו אותו ובדקו פרמטרים. נתון רגיש שנשלח בטעות מחייב עצירה ותיקון המקור, לא צילום ושיתוף שלו.
איך מסיימים חיבור אבחון ומסירים debug_mode שהוגדר ידנית?
התנתקו מחיבור Tag Assistant כשסיימתם ותעדו את הגרסה שנבדקה. אם הוספתם debug_mode ידנית לתג או לקוד, הסירו את הפרמטר בסיום; הגדרתו ל־false אינה מכבה את מצב האבחון לפי תיעוד Google. אם נדרש פרסום מכל, עשו זאת רק לאחר אישור ובדקו גם את הגרסה שפורסמה. אחר כך בדקו דוח רגיל בטווח מתאים; היעדר מיידי בו אינו לבדו כישלון של בדיקת האבחון.
איך מזהים מצב שבו התג נורה אבל שולח לנכס בדיקה במקום לנכס היעד?
באתר דמיוני נשלח generate_lead אחרי אישור טופס. ב־Tag Assistant התג נורה, אך היעד שלו שייך לנכס ניסיון ולא לנכס המתוכנן. התיקון הוא יעד התג, לא יצירת אירוע נוסף ב־GA4. בדיקה מתועדת עם מזהה יעד הייתה חוסכת ניסיון לתקן את הטופס שעבד כראוי.
איך כותבים תסריט הצלחה ותסריט שלילי שאפשר לחזור עליהם?
לפני חיבור האבחון כתבו תסריט שאפשר לבצע בלי לפרש כוונה. למשל: פתיחת עמוד קשר, מילוי שדות בדיקה, שליחה מוצלחת וקבלת אירוע generate_lead עם form_id מאושר. כתבו גם את התסריט ההפוך: שדה חובה חסר, הודעת שגיאה וללא אירוע הצלחה. בלי תוצאה צפויה, כל הופעת אירוע יכולה להיראות כמו הצלחה אף שהיא קשורה לפעולה אחרת.
למה צריך לקרוא את המשתנים באירוע שבו הנתונים כבר זמינים?
ב־Tag Assistant רצף טעינה, לחיצה ואירוע מותאם מסביר מתי היו הנתונים זמינים. משתנה יכול להיות ריק בטעינת העמוד ומלא רק אחרי הצלחה. לכן יש לפתוח את האירוע המדויק שבו התג אמור לפעול, ולא לבדוק ערך באירוע אחר. אם התג נורה מוקדם מדי, שינוי שם המשתנה לא יתקן את עיתויו.
איך משווים תנאי תג שלא נורה לערך שהתקבל בפועל?
ב־Tags Not Fired בדקו את התנאים שמוצגים לכל תג. השוו את הערך בפועל לערך שהתנאי דורש, כולל אותיות, נתיב וסוג אירוע. ערך שנראה דומה יכול לכלול קו נטוי נוסף או פרמטר. אל תחליפו תנאי מדויק בתנאי שמכיל מילה כללית לפני שהבנתם את ההבדל. צמצום נכון מונע ירי על פעולות שלא נועדו להימדד.
איך בודקים יעד נכון כשבאתר יש כמה נכסים או מכלים?
אתר יכול לכלול נכס ניסיון ונכס ייצור, ולעיתים גם כמה מכלים. רשמו מראש לאיזה יעד מצפים שהאירוע יישלח. בדקו שהמזהה בתג תואם לנכס שנפתח ושאתם בודקים את המכל המתאים. אין לפרסם מזהים או הרשאות שאינם דרושים לדוח הבדיקה, אך לבודק עצמו חייב להיות מיפוי ברור בין הסביבות.
איזה מידע מתעדים כשאירוע אינו מופיע ב־DebugView?
כאשר אין אירוע ב־DebugView, רשמו אם התג נורה, באיזה יעד, האם מצב אבחון היה פעיל ומה היה מצב ההסכמה. מידע זה מאפשר להפריד כשל טריגר מכשל שליחה או בחירת נכס. אפשר לבדוק בקשות רשת בכלי המפתח כאשר יש ידע מתאים, אך עצם קיום בקשה אינו אישור של כל שלבי העיבוד.
