מה בודקים באודיט של קונטיינר GTM?
קונטיינר לא מתלכלך ביום אחד. כל קמפיין מוסיף פיקסל וכל ספק מוסיף תג. אף אחד לא מוחק. אחרי שנתיים יש בקונטיינר עשרות רכיבים שאיש לא יודע אם הם פעילים. האודיט ממפה את המצב לפי חמישה תחומים. לכל אחד מהם יש עמוד בתיעוד הרשמי של Tag Manager.
| תחום | השאלה שבודקים | הכלי או ההמלצה של Google |
|---|---|---|
| שמות | האם אפשר להבין מהשם מה הרכיב עושה ולאיזו מערכת הוא שייך | תבנית שם של סוג הפריט, שם האתר או האפליקציה ופירוט |
| תיקיות | האם יש חלוקה לפי פרויקט, צוות או סוג תג | Folders בתפריט הצד |
| רכיבים מיותרים | אילו תגים, טריגרים ומשתנים לא משמשים אף אחד | הסרה של מה שלא נחוץ ואיחוד תגים דומים |
| קוד מותאם | כמה Custom HTML ו-Custom JavaScript יש ומה אפשר להחליף בתבנית | לצמצם או לבטל, להעדיף תבניות מובנות |
| הרשאות | מי מנהל את החשבון ומי יכול לפרסם | לפחות שני מנהלים, חשבון בבעלות הארגון |
אודיט קונטיינר הוא לא אודיט מדידה. הוא עונה על השאלה אם הקונטיינר מסודר ובטוח, לא אם הנתונים נכונים. את הבדיקה של הנתונים עצמם ריכזנו בצ'קליסט אודיט GA4.
איך קובעים מוסכמת שמות לתגים, טריגרים ומשתנים?
Google ממליצה בתיעוד על תבנית בת שלושה חלקים: סוג הפריט, שם האתר או האפליקציה ופירוט. הדוגמאות שלה: Google Ads conversions - Ecommerce website - 2018-01 campaign או Analytics pageviews - Info site + blog. ההיגיון פשוט: כשממיינים את הרשימה לפי שם, כל התגים של אותה מערכת מופיעים יחד.
המוסכמה המומלצת כאן בנויה על אותו עיקרון. זאת דוגמה ולא תקן רשמי:
| רכיב | תבנית | דוגמה |
|---|---|---|
| תג אירוע | פלטפורמה - סוג - פעולה | GA4 - Event - generate_lead |
| תג המרה | פלטפורמה - סוג - פעולה | Google Ads - Conversion - Purchase |
| טריגר | סוג הטריגר - תיאור | Custom Event - purchase |
| משתנה | קיצור סוג המשתנה - שם המפתח | DLV - transaction_id |
שלושה כללים שמחזיקים את המוסכמה לאורך זמן. הראשון: שם הטריגר מתאר מתי הוא נורה ולא איזה תג משתמש בו, כי אותו טריגר ישרת כמה תגים. השני: אין רכיב בשם "Untitled", "test" או "copy". השלישי: המוסכמה כתובה במסמך שכל מי שנוגע בקונטיינר מכיר. את מה שנמצא כרגע בעבודה מתעדים בשדה התיאור של ה-Workspace. התיעוד מייעד אותו להסבר למה הקונטיינר משמש ומה השינויים שבתהליך.
אותו עיקרון חל על שמות של Workspaces ושל גרסאות, נושא שפירטנו במדריך Workspaces, גרסאות וסביבות.
איך מארגנים את הקונטיינר בתיקיות?
תיקיות ב-GTM מקבצות תגים, טריגרים ומשתנים לקבוצות לוגיות. מנהלים אותן במסך Folders שבתפריט הצד: יוצרים תיקייה, מסמנים רכיבים ומעבירים אותם אליה.
Google מציעה שלוש שיטות חלוקה: לפי פרויקט, למשל מיקרו-אתר או קמפיין, לפי צוות, למשל תיקייה לסוכנות, או לפי סוג, למשל תיקייה לתגי Google Analytics, תיקייה ל-Google Ads ותיקייה לתגי צד שלישי. החלוקה לפי סוג היא בדרך כלל היציבה ביותר, כי היא לא תלויה בשאלה מי עבד על מה. אני מוסיף לה תיקייה נפרדת לתגי Custom HTML, כדי שכל הקוד המותאם יהיה גלוי במקום אחד. חלוקה לפי ספק שימושית כשכמה סוכנויות עובדות על אותו קונטיינר.
תיקייה היא סידור בלבד. היא לא משנה מתי תג נורה ולא מחליפה מוסכמת שמות. בקונטיינר טוב אין רכיבים מחוץ לתיקיות, כך שכל רכיב חדש שנשאר בחוץ בולט מיד.
איך מזהים תגים מיותרים ומה עושים איתם?
לפי התיעוד של Tag Manager, בקונטיינרים עם הרבה תגים, טריגרים ומשתנים, או עם תגי Custom HTML גדולים, עשוי להופיע בעמוד Versions מחוון Size. כשהערך שלו מעל 70% צריך לייעל את הקונטיינר. ההמלצות של Google לניקוי:
לאחד תגים דומים. עשרה תגים כמעט זהים, שכל אחד מהם נורה בעמוד אחר, הופכים לתג אחד עם טריגר אחד ומשתנה Lookup Table שקובע את הערכים. התיעוד מוסיף סייג: טבלת Lookup ארוכה מדי פוגעת בביצועים בעצמה. ברוב המקרים אפשר לקצר אותה עם RegEx Table. על שני סוגי הטבלאות כתבנו במדריך המשתנים ב-GTM.
להסיר מה שלא בשימוש. תג, טריגר או משתנה שאף פעם לא משמש תופס מקום בקונטיינר בלי סיבה. המועמדים הרגילים: תגים בלי טריגר, טריגרים שאף תג לא מחובר אליהם, משתנים שאף רכיב לא קורא, פיקסלים של קמפיינים שהסתיימו ותגים של מערכות שהארגון הפסיק לעבוד איתן.
לצמצם קוד מותאם. התיעוד ממליץ לצמצם או לבטל שימוש בתגי Custom HTML ובמשתני Custom JavaScript, כי ברוב המקרים תבנית נתמכת יעילה יותר. קוד JavaScript סטטי עדיף להגיש מקובץ חיצוני, שם הוא נשמר במטמון הדפדפן. את הנימוקים המלאים הסברנו בפיקסלים ב-GTM בתבנית ולא ב-Custom HTML.
לפצל קונטיינר גדול מדי. קונטיינר שמשרת כמה אתרים אפשר לפצל לקונטיינרים קטנים. הנוהג הנפוץ לפי Google הוא קונטיינר ייחודי לכל אתר או אפליקציה. ללקוחות 360 קיימת גם האפשרות Zones.
לא מוחקים תג חשוד מיד. ל-GTM יש פונקציית Pause שמשביתה תג זמנית בלי למחוק אותו ובלי לגעת בטריגרים. פותחים את התג, לוחצים על תפריט שלוש הנקודות ובוחרים Pause. לפי התיעוד, ההשהיה נכנסת לתוקף רק אחרי שמירה ופרסום. תג מושהה מסומן באייקון ברשימה, כך שקל לחזור אליו.
סדר הניקוי
ארבעה שלבים שמונעים מחיקה של תג שעוד צריך
מי צריך איזו הרשאה בקונטיינר?
ב-Tag Manager יש שתי רמות הרשאה. ברמת החשבון משתמש הוא Admin או User. מנהל יכול ליצור קונטיינרים ולשנות הרשאות. ברמת הקונטיינר יש חמש אפשרויות: No access, Read, Edit, Approve ו-Publish. באודיט עוברים על רשימת המשתמשים ב-Admin תחת User Management ושואלים על כל שורה שלוש שאלות: האם האדם עדיין עובד עם הארגון, האם הוא באמת צריך לפרסם, האם זה חשבון אישי או משותף.
ארבע נקודות מהתיעוד שהופכות לסעיפים קבועים בדוח האודיט:
לפחות שני מנהלים פעילים. חשבון עם מנהל יחיד עלול להינעל אם אותו אדם מחליף תפקיד. לפי התיעוד, כלי Tag Diagnostics מציג התראה כשמזוהה חשבון עם מנהל יחיד.
החשבון שייך לארגון. Google ממליצה שהחשבון ינוהל על ידי מישהו מתוך הארגון ולא על ידי סוכנות חיצונית. היא ממליצה גם על חשבונות משתמש אמיתיים במקום כניסה משותפת.
חשבון בלי מנהל נמחק. לפי התיעוד, חשבון או קונטיינר שנשאר בלי מנהל נמחק אוטומטית. למשתמשים עם הרשאת קריאה יש 30 יום לייצא את המידע מסל המחזור. אם לאף אחד אין הרשאת קריאה, מתחילים מאפס ומתייגים את האתר מחדש.
אימות דו-שלבי לפעולות רגישות. מנהל יכול להפעיל ב-Account Settings את האפשרות Require 2-step login verification for certain operations. מרגע ההפעלה, Tag Manager בודק שלמשתמש יש אימות דו-שלבי לפני שינוי של משתני Custom JavaScript, של תגי Custom HTML ושל הגדרות משתמשים. אלה בדיוק המקומות שבהם אפשר להזריק קוד לאתר.
איך מגבים את הקונטיינר לפני שמתחילים למחוק?
לפי התיעוד, אפשר לייצא קונטיינר כקובץ JSON, להשוות אותו, לשמור אותו במערכת ניהול גרסאות ולייבא אותו בחזרה. נכנסים ל-Admin, בוחרים Export Container בחלק של הקונטיינר, בוחרים גרסה או Workspace ולוחצים Download.
בייבוא חוזר יש שתי אפשרויות שכדאי להבין לפני שלוחצים. Overwrite מסיר את כל התגים, הטריגרים והמשתנים הקיימים ומחליף אותם בתוכן הקובץ. לפני הייבוא נוצרת גרסה חדשה של הקונטיינר. Merge ממזג את הקובץ עם הקיים. בוחרים בו אם לדרוס רכיבים בעלי אותו שם ותוכן שונה או לשנות להם שם. לפני האישור מוצג סיכום של כמה רכיבים יתווספו, ישתנו או יימחקו.
הגיבוי השני הוא היסטוריית הגרסאות עצמה: כל פרסום יוצר גרסה שאפשר לפרסם מחדש. קובץ ה-JSON שימושי בעיקר כשרוצים עותק מחוץ ל-GTM או להעתיק רכיבים בין קונטיינרים.
באיזה סדר מבצעים את הניקוי?
- מייצאים גיבוי. קובץ JSON של הגרסה החיה, שמור מחוץ ל-GTM עם תאריך.
- ממפים את הקונטיינר. רשימה של כל התגים עם שלוש עמודות: לאיזו מערכת התג שולח, מי הבעלים העסקי שלו, האם הוא עדיין נחוץ. תג שלאף אחד אין תשובה לגביו נכנס לרשימת החשודים.
- מתקנים שמות ומסדרים בתיקיות. זה שינוי בלי השפעה על המדידה, לכן מתחילים ממנו. מפרסמים אותו כגרסה נפרדת.
- משהים את החשודים. Pause לכל תג ברשימה, שמירה ופרסום בגרסה עם שם ברור, לדוגמה "השהיית תגים לא מזוהים".
- עוקבים. נותנים לתקופה סבירה לעבור, לדוגמה מחזור דיווח חודשי אחד. בודקים שאף דוח, קמפיין או ספק לא איבד נתונים.
- מוחקים ומאחדים. מוחקים את מה שלא חסר לאף אחד. מאחדים תגים דומים עם Lookup Table. מחליפים Custom HTML בתבנית איפה שאפשר.
- מסדרים הרשאות. מסירים משתמשים שעזבו, מורידים הרשאות Publish מיותרות ומוודאים שיש שני מנהלים מתוך הארגון.
- מתעדים. מוסכמת השמות, מבנה התיקיות ורשימת מה שנמחק נשמרים במסמך אחד שמצורף לדוח האודיט.
שאלות נפוצות
מה כולל אודיט של קונטיינר GTM?
אודיט קונטיינר בודק חמישה תחומים: שמות הרכיבים, הסידור בתיקיות, רכיבים שלא בשימוש, כמות הקוד המותאם (Custom HTML ו-Custom JavaScript) והרשאות המשתמשים בחשבון ובקונטיינר. התוצאה היא רשימת פעולות לניקוי לפי סדר עדיפות. האודיט בודק אם הקונטיינר מסודר ובטוח, לא אם הנתונים שנאספים נכונים.
איזו מוסכמת שמות Google ממליצה עליה ב-GTM?
לפי התיעוד של Tag Manager, התבנית המומלצת היא סוג הפריט, שם האתר או האפליקציה ופירוט, מופרדים במקף. הדוגמאות בתיעוד הן Google Ads conversions - Ecommerce website - 2018-01 campaign או Analytics pageviews - Info site + blog. המטרה היא שכל הרכיבים של אותה מערכת יופיעו יחד ברשימה.
מתי קונטיינר GTM נחשב גדול מדי?
לפי התיעוד של Tag Manager, בקונטיינרים עם הרבה תגים, טריגרים ומשתנים או עם תגי Custom HTML גדולים עשוי להופיע בעמוד Versions מחוון Size. כשהערך שלו מעל 70% Google ממליצה לייעל: לאחד תגים דומים, להסיר רכיבים שלא בשימוש, לצמצם קוד מותאם ולפצל קונטיינרים שמשרתים כמה אתרים.
האם למחוק תג ישן או להשהות אותו?
קודם משהים. פונקציית Pause משביתה תג זמנית בלי למחוק אותו ובלי לשנות טריגרים. לפי התיעוד ההשהיה נכנסת לתוקף רק אחרי שמירה ופרסום של הקונטיינר. אם אחרי תקופת מעקב אף דוח או קמפיין לא איבד נתונים, מוחקים את התג. אם משהו נשבר, מבטלים את ההשהיה ומפרסמים שוב.
כמה מנהלים צריכים להיות בחשבון GTM?
לפחות שניים. לפי התיעוד של Google, חשבון עם מנהל יחיד עלול להינעל אם אותו אדם מחליף תפקיד או שהחשבון שלו נמחק. חשבון או קונטיינר שנשאר בלי מנהל נמחק אוטומטית. למשתמשים עם הרשאת קריאה יש 30 יום לייצא את המידע מסל המחזור. Google ממליצה גם שהחשבון ינוהל מתוך הארגון ולא על ידי סוכנות חיצונית.
איך מגבים קונטיינר GTM?
נכנסים ל-Admin, בוחרים Export Container, בוחרים גרסה או Workspace ומורידים קובץ JSON. את הקובץ אפשר לשמור, להשוות ולייבא בחזרה דרך Import Container. בייבוא, האפשרות Overwrite מחליפה את כל הרכיבים הקיימים בתוכן הקובץ, בעוד Merge ממזג ושואל מה לעשות עם רכיבים בעלי אותו שם ותוכן שונה.
מה השורה התחתונה?
קונטיינר מסודר הוא לא עניין של אסתטיקה. בקונטיינר עם שמות ברורים, תיקיות והרשאות מצומצמות, כל שינוי לוקח דקות וכל תקלה מאותרת מהר. בקונטיינר מבולגן אף אחד לא מעז למחוק, לכן הוא רק גדל. הסדר שעובד: גיבוי, מיפוי, שמות ותיקיות, השהיה, מעקב, מחיקה, הרשאות ותיעוד. ניקוי אחד יסודי ואחריו מוסכמה כתובה מחזיקים שנים. אודיט כזה, עם דוח ממצאים ורשימת פעולות לפי עדיפות, הוא חלק משירות הטמעת Google Tag Manager שלנו. התמונה המלאה של העבודה עם הכלי נמצאת במדריך המלא ל-Google Tag Manager. אם ירשתם קונטיינר שאף אחד לא יודע מה רץ בו, כתבו לנו.
מקורות
Tag Manager Help: Organize your containers, Tag Manager Help: Manage container size and efficiency, Tag Manager Help: Pause tags, Tag Manager Help: Managing users and permissions, Tag Manager Help: Container export and import, Tag Manager Help: Tag Manager and 2-step verification
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי