למה לא מתרגלים על הקונטיינר של אתר אמיתי?
כי ב-GTM המרחק בין ניסוי לבין שינוי שרץ אצל כל הגולשים הוא לחיצה אחת על Publish. תג שמוגדר לא נכון לא מפיל את האתר ברוב המקרים. הוא עושה משהו שקשה יותר לזהות: שולח אירוע כפול, מדווח המרה שלא קרתה או מפסיק לדווח המרה שכן קרתה. את הנזק הזה מגלים רק אחרי ימים, כשהמספרים בדוחות כבר לא מסתדרים.
יש גם סיבה לימודית. מי שמתרגל על קונטיינר אמיתי מפחד לשבור. לכן הוא לא מנסה. בסביבת תרגול אפשר לשבור תג בכוונה, לראות איך זה נראה ב-Tag Assistant ולתקן. ככה לומדים לדבג, לא רק להעתיק הגדרות.
מה צריך כדי להקים סביבת תרגול?
ארבעה רכיבים שמקימים פעם אחת ומשתמשים בהם לאורך כל הלמידה.
- אתר שאתם שולטים בקוד שלו. מספיק אתר קטן עם כמה עמודים, קישורים וטופס אחד. לפי התיעוד של Google, בחלון ההתקנה אפשר לבחור בהתקנה ידנית או באינטגרציה של פלטפורמה כמו WordPress, Shopify או Wix, כך שגם אתר תרגול על אחת מהן מתאים. אם יש לכם גישה לקוד, התקנה ידנית מלמדת יותר: רואים איפה בדיוק הקוד יושב.
- חשבון וקונטיינר נפרדים ב-GTM. נכנסים ל-tagmanager.google.com, יוצרים חשבון חדש וקונטיינר מסוג Web. התיעוד ממליץ על קונטיינר אחד לכל אתר, כך שלאתר התרגול מגיע קונטיינר משלו ולא פינה בקונטיינר של לקוח.
- התקנת הקונטיינר באתר. לפי התיעוד, בגרסה הנוכחית מדביקים את קטע הקוד בחלק ה-head של כל עמוד, גבוה ככל האפשר. בחלון ההתקנה מזינים את כתובת האתר ולוחצים Test כדי לוודא שהקונטיינר נטען.
- נכס GA4 נפרד לתרגול. יוצרים נכס חדש עם data stream מסוג Web ומקבלים Measurement ID שמתחיל ב-G-. כל אירוע שתשלחו בתרגול מגיע לנכס הזה בלבד ולא מתערבב בנתונים של אף עסק.
את מבנה הקונטיינר עצמו, תגים, טריגרים ומשתנים, הסברנו במדריך המלא ל-Google Tag Manager. כאן נשארים בשאלה איך מתרגלים בלי סיכון.
סביבת תרגול ל-GTM
ארבעת הרכיבים שמפרידים בין ניסוי לנזק
איך Preview מאפשר לבדוק בלי לפרסם?
לפי התיעוד של Google, מצב Preview מאפשר לגלוש באתר כאילו טיוטת הקונטיינר הנוכחית כבר פורסמה, כדי לבדוק את ההגדרות לפני הפרסום. לוחצים Preview ב-Workspace, מזינים את כתובת האתר ולוחצים Connect. האתר נפתח בחלון חדש עם הכיתוב Connected. Tag Assistant מציג אילו תגים נורו ובאיזה סדר.
שתי עובדות מהתיעוד שהופכות את Preview לכלי תרגול בטוח. הראשונה: ממשק הדיבוג מופיע רק בדפדפן שהפעיל את המצב או אצל מי ששיתפתם איתו. הוא לא גלוי לגולשים הרגילים. השנייה: אפשר לשתף את הטיוטה עם אדם אחר דרך More Actions ואז Share ב-Tag Assistant, שמייצר כתובת Preview ייעודית. אם האתר נשבר בגלל פרמטר הדיבוג שנוסף לכתובת, מבטלים את הסימון Include debug signal in the URL.
נקודה שמתחילים מפספסים: ב-Preview התגים באמת נורים מהדפדפן שלכם ושולחים נתונים ליעד שלהם. לכן גם בדיקה בלי פרסום מייצרת אירועים בנכס שאליו התג מצביע. בסביבת תרגול זה לא משנה, כי הנכס הוא שלכם. בקונטיינר אמיתי זאת הסיבה שבדיקות נעשות מול נכס בדיקה, או עם data filter מסוג Developer traffic, שלפי התיעוד של GA4 מסנן פעילות של מפתחים שעובדים במצב דיבוג. את האירועים עצמם רואים בזמן אמת ב-DebugView של GA4, כי Tag Assistant מוסיף לכתובת פרמטר שמפעיל את מצב הדיבוג. את תהליך הדיבוג המלא פירטנו במדריך על Preview ו-Tag Assistant.
מה ההבדל בין Workspace, גרסה וסביבה?
אלה שלושת מנגנוני הבטיחות של GTM. שווה לתרגל את שלושתם בסביבת התרגול לפני שפוגשים אותם בקונטיינר של לקוח.
| המנגנון | מה הוא נותן | מה כדאי לדעת לפי התיעוד |
|---|---|---|
| Preview | בדיקת הטיוטה בדפדפן שלכם בלי לפרסם | לא זמין לקונטיינרים של אפליקציות מובייל |
| Workspace | סט שינויים נפרד שלא מתערבב בעבודה של אחרים | בחשבון רגיל: ברירת מחדל ועוד שניים. ב-Tag Manager 360 בלי הגבלה |
| גרסה (Version) | צילום מצב של הקונטיינר שאפשר לחזור אליו | נוצרת בכל פרסום. אפשר ליצור גרסה גם בלי לפרסם |
| סביבה (Environment) | פרסום גרסה לשרת בדיקות בלי לגעת ב-Live | דורשת קטע קוד ייעודי ומיועדת לסביבות שאינן production |
| Export ו-Import | העתקת קונטיינר שלם כקובץ JSON | ב-Import בוחרים בין Overwrite ל-Merge |
כמה פרטים שכדאי לראות בעיניים. לפי התיעוד, כש-Workspace הופך לגרסה או מתפרסם הוא נמחק. השם, ההערות ורשימת השינויים שלו נשמרים עם הגרסה. בשאר ה-Workspaces מופיעה הודעה שהם לא מעודכנים. בסביבות, כל קונטיינר מגיע עם סביבת Live שמצביעה תמיד על הגרסה שפורסמה. שינוי שמפורסם לסביבה מותאמת לא מגיע לגרסה החיה של האתר. את שלושת המנגנונים פירטנו במדריך על Workspaces, גרסאות וסביבות.
איך מעתיקים קונטיינר אמיתי לסביבת התרגול?
התרגול הכי קרוב לעבודה אמיתית הוא על העתק של קונטיינר קיים. לפי התיעוד, קונטיינר מיוצא כקובץ JSON דרך Admin ואז Export Container, שם בוחרים גרסה או Workspace ומורידים. בקונטיינר התרגול נכנסים ל-Admin ואז Import Container, בוחרים את הקובץ, בוחרים Workspace חדש או קיים ומחליטים בין שתי אפשרויות. Overwrite מוחק את כל התגים, הטריגרים והמשתנים הקיימים ומחליף אותם במיובאים. לפני הייבוא נוצרת גרסה חדשה של הקונטיינר. Merge משאיר את הקיים. בהתנגשות של שמות אתם בוחרים אם לדרוס או לשנות שם.
האזהרה שלי כאן היא מקצועית ולא מהתיעוד: קונטיינר מיובא מגיע עם כל המזהים האמיתיים, ה-Measurement ID של GA4 ומזהי הפיקסלים של פלטפורמות הפרסום. לפני ה-Preview הראשון מחליפים אותם במזהים של סביבת התרגול. אחרת כל בדיקה שלכם נשלחת לחשבונות של העסק. מעבר לזה, קובץ JSON של קונטיינר הוא מידע של הלקוח. מעתיקים אותו רק באישור.
מה עושים כשחייבים לעבוד על קונטיינר אמיתי?
בשלב מסוים התרגול עובר לקונטיינר של עסק. שלושה הרגלים מקטינים את הסיכון כמעט לאפס.
הראשון הוא הרשאה מתאימה. לפי התיעוד של Google, משתמש עם הרשאת Edit יכול ליצור Workspaces ולערוך, אבל לא ליצור גרסאות ולא לפרסם. הרשאת Approve מוסיפה יצירת גרסאות. רק הרשאת Publish מאפשרת לפרסם. מי שלומד צריך לבקש Edit ולא יותר. ככה טעות נשארת טיוטה.
השני הוא Workspace משלכם עם שם שמתאר את השינוי, במקום לעבוד ב-Default Workspace שכולם נוגעים בו. השלישי הוא סקירה לפני פרסום: שולחים לבעל הקונטיינר קישור Preview משותף ונותנים לו לפרסם בעצמו. תהליך אישור מובנה, Request Approval, קיים לפי התיעוד רק ב-Tag Manager 360.
אם בכל זאת פורסם משהו שבור, לא מתקנים בלחץ. במסך Versions בוחרים את הגרסה הקודמת ומפרסמים אותה מחדש. האפשרות Set as Latest Version מחזירה את הטיוטה לתוכן של גרסה ישנה כדי להמשיך לערוך ממנה.
אילו תרגילים שווה לעשות ובאיזה סדר?
- תג ראשון ובדיקה כפולה. מגדירים Google tag עם ה-Measurement ID של נכס התרגול, מפעילים Preview ובודקים שהתג נורה ב-Tag Assistant ושהאירוע מופיע ב-DebugView.
- טריגר קליק. מודדים קליק על קישור יוצא או על כפתור. את ההבדלים בין סוגי הטריגרים הסברנו במדריך על סוגי הטריגרים.
- אירוע מ-dataLayer. דוחפים אירוע מותאם עם פרמטר, קוראים אותו ב-Data Layer Variable ושולחים ל-GA4. אפשר לייצר את הקוד במחולל dataLayer.push.
- שבירה מכוונת. משנים תנאי בטריגר כך שהתג לא יירה. אחר כך מאתרים את הסיבה ב-Tag Assistant בלי להסתכל בהגדרות. זה התרגיל שהכי דומה לעבודה אמיתית.
- גרסה וחזרה אחורה. מפרסמים גרסה, מפרסמים גרסה שנייה עם טעות ומחזירים את הקודמת ממסך Versions.
- שני Workspaces והתנגשות. משנים את אותו תג בשני Workspaces, מפרסמים אחד ופותרים את ההתנגשות בשני.
- Export ו-Import. מייצאים את הקונטיינר, מייבאים אותו ב-Merge לקונטיינר ריק ובודקים מה השתנה.
אחרי שהתגים עובדים, השלב הבא הוא לבדוק את הנתונים שהם מייצרים. לזה מתאים תרגיל איתור פערי מדידה ב-GA4.
אילו טעויות חוזרות אצל מי שמתרגל לבד?
אצל סטודנטים וצוותים שאני מדריך חוזרות שלוש טעויות. הראשונה היא לתרגל רק את המסלול שעובד. מי שלא שבר תג אף פעם לא יודע לקרוא את Tag Assistant כשמשהו לא נורה. השנייה היא לדלג על שמות ותיאורים לגרסאות. התיעוד ממליץ על שם ותיאור שמסבירים מה השתנה, כי בלעדיהם אי אפשר לדעת לאיזו גרסה לחזור. השלישית היא לשכוח שסביבת התרגול נקייה מדי: אין בה באנר הסכמה, אין עשרות תגים ישנים ואין מפתחים שמשנים את האתר. לכן אחרי התרגול הבסיסי כדאי לייבא קונטיינר אמיתי ולתרגל עליו קריאה והבנה לפני שמשנים בו משהו.
שאלות נפוצות
האם מצב Preview ב-Google Tag Manager משפיע על גולשים אמיתיים?
לא. לפי התיעוד של Google, ממשק הדיבוג והטיוטה של הקונטיינר מוצגים רק בדפדפן שהפעיל את Preview או אצל מי שקיבל קישור Preview משותף. הם לא גלויים לגולשים הרגילים. עם זאת התגים באמת נורים מהדפדפן שלכם ושולחים נתונים ליעד שלהם. לכן בדיקות כדאי לעשות מול נכס GA4 של תרגול או בדיקות.
איך מקימים סביבת תרגול ל-GTM?
יוצרים חשבון וקונטיינר נפרדים ב-tagmanager.google.com, מתקינים את הקונטיינר באתר קטן שאתם שולטים בקוד שלו ומחברים אותו לנכס GA4 נפרד. לפי התיעוד, בחלון ההתקנה אפשר לבחור בהתקנה ידנית בחלק ה-head של העמוד או באינטגרציה של פלטפורמה כמו WordPress, Shopify או Wix.
כמה Workspaces אפשר לפתוח בקונטיינר GTM?
לפי התיעוד של Google, בחשבון רגיל יש Workspace של ברירת מחדל ואפשר להוסיף עוד שניים, כלומר שלושה במקביל. בחשבון Tag Manager 360 אין הגבלה על המספר. כש-Workspace הופך לגרסה או מתפרסם הוא נמחק. השם, ההערות ורשימת השינויים שלו נשמרים עם הגרסה.
איזו הרשאה כדאי לבקש כשלומדים על קונטיינר של עסק?
הרשאת Edit. לפי התיעוד של Google, משתמש עם Edit יכול ליצור Workspaces ולערוך תגים, אבל לא ליצור גרסאות ולא לפרסם. הרשאת Approve מוסיפה יצירת גרסאות. רק הרשאת Publish מאפשרת פרסום. עם Edit כל טעות נשארת טיוטה עד שמישהו מורשה בודק ומפרסם.
איך מעתיקים קונטיינר GTM קיים לקונטיינר תרגול?
מייצאים את הקונטיינר כקובץ JSON דרך Admin ואז Export Container. אחר כך מייבאים אותו בקונטיינר התרגול דרך Import Container. בייבוא בוחרים בין Overwrite, שמוחק את כל התגים, הטריגרים והמשתנים הקיימים, לבין Merge שמשאיר אותם. לפני הבדיקה הראשונה חובה להחליף את המזהים האמיתיים, כמו Measurement ID, במזהים של סביבת התרגול.
מה ההבדל בין Preview לבין סביבה (Environment) ב-GTM?
Preview מציג את הטיוטה רק בדפדפן שלכם, בלי קוד נוסף באתר. סביבה היא יעד פרסום נפרד עם קטע קוד ייעודי שמותקן בשרת בדיקות. אליה מפרסמים גרסה שלמה. לפי התיעוד, שינוי שמפורסם לסביבה מותאמת לא מגיע לגרסה החיה. היכולת מיועדת לסביבות שאינן production.
מה השורה התחתונה?
תרגול בטוח של GTM נשען על הפרדה: אתר משלכם, קונטיינר משלכם ונכס GA4 משלכם. בתוך ההפרדה הזאת מותר לשבור הכול. זה בדיוק מה שמלמד לדבג. כשעוברים לקונטיינר של עסק, שלושה הרגלים שומרים עליכם: הרשאת Edit בלי פרסום, Workspace משלכם ובדיקה ב-Preview מול נכס בדיקה לפני שמישהו לוחץ Publish. הדרכות GTM ואנליטיקס לצוותים ולארגונים מרוכזות בעמוד הקורסים וההדרכות שלנו. אם אתם רוצים הדרכת GTM מעשית לצוות שלכם, כתבו לנו.
מקורות
Tag Manager Help: Preview and debug containers, Tag Manager Help: Workspaces, Tag Manager Help: Environments, Tag Manager Help: Publishing, versions, and approvals, Tag Manager Help: Managing users and permissions, Tag Manager Help: Container export and import
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי