המאמר מיועד למי שמנהל את Google Tag Manager באתר של עסק, או מפקח על ספקים שעובדים בו. הוא מתאר שגרת עבודה שמבוססת על המנגנונים שקיימים בכלי עצמו: סביבות עבודה, גרסאות, תצוגה מקדימה והרשאות. בסופו תוכלו לבדוק את המכולה הקיימת ולקבוע כללים לכל מי שעובד בה.
Google Tag Manager (GTM) הוא כלי לניהול תגים: קטעי קוד של מדידה, פרסום וכלים אחרים שנטענים באתר. במקום לשנות את קוד האתר בכל פעם, מתקינים מכולה (Container) אחת, ומנהלים בה את התגים, את הטריגרים שקובעים מתי הם פועלים, ואת המשתנים שהם משתמשים בהם.
הגמישות הזו היא גם הסיכון: שינוי שפורסם בלי בדיקה יכול לשבור את המדידה, לספור אירועים פעמיים, או להכניס קוד לא רצוי לאתר. המאמר מתאר שגרת עבודה שמצמצמת את הסיכונים האלה, לפי מנגנונים שקיימים בכלי עצמו.
המושגים הבסיסיים
- תג (Tag): הקוד שרץ, למשל תג Google לאנליטיקס או תג המרה של פלטפורמת פרסום.
- טריגר (Trigger): התנאי שבו התג פועל, למשל צפייה בעמוד או לחיצה על כפתור מסוים.
- משתנה (Variable): ערך שהתג או הטריגר משתמשים בו, כמו כתובת העמוד או מזהה מדידה.
סביבות עבודה (Workspaces)
לפי התיעוד, לכל מכולה יש סביבת עבודה ברירת מחדל, ובחשבון רגיל אפשר ליצור עוד שתיים (ב-Tag Manager 360 אין הגבלה). כל סביבת עבודה היא מקום נפרד לשינויים, כך שכמה אנשים או כמה משימות לא מתערבבים.
כללי עבודה:
- סביבת עבודה לכל משימה, עם שם שמתאר אותה: "מדידת טופס צור קשר", ולא "שינויים".
- כשהמכולה השתנתה מאז שסביבת העבודה נוצרה, GTM מסמן אותה כלא מעודכנת, וצריך למזג ולפתור התנגשויות לפני שממשיכים.
- לא להשאיר סביבות עבודה פתוחות לאורך זמן; הן מתיישנות.
גרסאות ופרסום
גרסה היא תמונת מצב של המכולה. לפי התיעוד, כל פרסום יוצר גרסה, ואפשר גם לשמור גרסה בלי לפרסם. יצירת גרסה מחייבת הרשאת Approve לפחות, ופרסום מחייב הרשאת Publish.
כללי עבודה:
- לכל גרסה שם ותיאור שמסבירים מה השתנה ולמה. התיאור הוא התיעוד שיעזור בעוד חצי שנה להבין מה קרה.
- פרסום אחד לכל שינוי לוגי, ולא אוסף של שינויים שאינם קשורים.
- אם משהו נשבר, אפשר לחזור לגרסה קודמת: להגדיר אותה כגרסה האחרונה או לפרסם אותה ישירות.
תצוגה מקדימה ובדיקה לפני פרסום
מצב התצוגה המקדימה (Preview) מאפשר לראות באתר עצמו אילו תגים פועלים בכל פעולה, לפני שהשינוי מגיע לגולשים. מה בודקים:
- שהתג החדש פועל בדיוק בפעולה שהוא אמור למדוד, ולא בפעולות אחרות.
- שהוא פועל פעם אחת, ולא פעמיים.
- שהנתונים מגיעים לכלי היעד, למשל ל-DebugView של GA4.
- שתגים קיימים לא הושפעו.
ל-GTM יש גם סביבות (Environments), כמו סביבת בדיקות, שכל אחת מהן יכולה להצביע על גרסה אחרת. לפי התיעוד, פרסום לסביבה כזו אינו משפיע על המכולה החיה. זה שימושי כשיש לאתר סביבת בדיקות נפרדת.
מוסכמות שמות
GTM לא מחייב מבנה שמות, אבל מכולה עם עשרות פריטים בלי שיטה הופכת מהר לבלתי קריאה. שיטה פשוטה:
- תגים: כלי – סוג – פעולה. למשל: "GA4 – אירוע – שליחת טופס צור קשר".
- טריגרים: סוג – תנאי. למשל: "קליק – קישור טלפון".
- משתנים: סוג – תוכן. למשל: "קבוע – מזהה מדידה GA4".
דוגמה בדיונית: במכולה של חנות היו שלושה תגים בשם "GA4 Event", ואיש לא ידע מה כל אחד מהם מודד. אחרי שינוי שמות לפי השיטה, התברר שאחד מהם היה כפילות של אירוע שכבר נמדד במדידה המשופרת של GA4, והוא הוסר בגרסה מתועדת.
הרשאות
ברמת המכולה יש ארבע רמות: Read, Edit, Approve ו-Publish. מכיוון שהרשאת Publish מאפשרת להכניס קוד לאתר, כדאי להגביל אותה לאנשים מעטים ואמינים, ולהחזיק יותר ממנהל אחד לחשבון, כפי ש-Google ממליצה. פירוט במאמר על בעלות והרשאות.
שגרה תקופתית
- סקירת תגים שאינם בשימוש: כלים שהעסק הפסיק לעבוד איתם, קמפיינים שהסתיימו.
- בדיקה שאין תגים בהתאמה אישית (Custom HTML) שאיש לא יודע מי הוסיף ולמה.
- סקירת משתמשים והרשאות, במסגרת בקרת הגישה התקופתית.
רשימת בדיקה לפני כל פרסום
- השינוי נעשה בסביבת עבודה ייעודית עם שם ברור.
- סביבת העבודה עודכנה ואין התנגשויות.
- השינוי נבדק בתצוגה מקדימה: פועל פעם אחת, בפעולה הנכונה.
- הנתונים הגיעו לכלי היעד.
- לגרסה יש שם ותיאור שמסבירים מה השתנה ולמה.
- ידוע לאיזו גרסה חוזרים אם משהו נשבר.
ל-GA4 עצמו ראו הקמת נכס GA4 נכון.
הצעד הבא
פתחו את רשימת הגרסאות במכולה, ובדקו אם יש לגרסאות האחרונות שם ותיאור שמסבירים מה השתנה. אם לא, קבעו מהיום את הכלל: אין פרסום בלי תיאור ובלי בדיקה בתצוגה מקדימה. לליווי בהגדרת המדידה אפשר להיעזר בעמוד חשבון Google לעסק.
מקורות
- Tag Manager Help – Workspaces
- Tag Manager Help – Publishing, versions, and approvals
- Tag Manager Help – Preview and debug containers
- Tag Manager Help – Environments
- Tag Manager Help – Managing users and permissions
שאלות ותשובות
IBASTOM.CO.IL
למה לבדוק בתצוגה מקדימה ולא פשוט לפרסם?
כי טעות בתג משפיעה מיד על כל המבקרים: מדידה כפולה, אירוע שלא נשלח או סקריפט ששובר עמוד. התצוגה המקדימה מראה אילו תגים הופעלו ובאיזה סדר, לפני שמישהו מהגולשים רואה את השינוי.
פרסמנו גרסה עם טעות. איך חוזרים?
בוחרים את הגרסה הקודמת שעבדה ומפרסמים אותה שוב. כך המיכל חוזר למצב שלפני הטעות, ואת התיקון ממשיכים לבנות בסביבת עבודה בלי לחץ. זו הסיבה לתת לכל גרסה שם ותיאור ברורים.
מתי צריך יותר מסביבת עבודה אחת?
כששני אנשים עובדים על המיכל באותו זמן, או כששינוי גדול נבנה לאורך זמן ובינתיים צריך לפרסם תיקון קטן. כל סביבה מתבססת על הגרסה האחרונה שפורסמה, ושינויים בסביבות שונות מתמזגים בפרסום.
מוסכמת שמות באמת משנה?
כן, ברגע שיש יותר מכמה תגים. שם שמתאר כלי, סוג ופעולה, למשל "GA4 – אירוע – שליחת טופס", מאפשר להבין מה כל תג עושה בלי לפתוח אותו, ומונע כפילויות כשאדם אחר מצטרף לעבודה.
מי צריך הרשאת פרסום?
מעט אנשים: מי שאחראי על המדידה בעסק ואולי ספק אחד. אחרים יכולים לקבל הרשאת עריכה, ולהכין שינויים שמישהו אחר בודק ומפרסם. כך כל פרסום עובר עוד זוג עיניים.
