מה ההבדל בין Workspace, גרסה וסביבה?
שלושת המושגים מתבלבלים כי כולם נוגעים ל"מה חי באתר". בפועל כל אחד עונה על שאלה אחרת. Workspace עונה על השאלה מי עובד על מה. גרסה עונה על השאלה מה היה מצב הקונטיינר בנקודת זמן מסוימת. סביבה עונה על השאלה איזה שרת מקבל איזו גרסה.
| המנגנון | מה הוא | מה חשוב לדעת |
|---|---|---|
| Workspace | מקום לעבוד על סט שינויים שיהפוך לגרסה | בחשבון רגיל: Workspace ברירת מחדל ועוד שניים. ב-Tag Manager 360 אין הגבלה |
| Version | צילום מצב של הגדרות הקונטיינר בנקודת זמן | נוצרת בכל פרסום. אפשר ליצור אותה גם בלי לפרסם |
| Environment | יעד פרסום: Live או סביבה מותאמת כמו QA | לכל קונטיינר יש Live כברירת מחדל. סביבות מותאמות מיועדות לשרתים שאינם פרודקשן |
לפי התיעוד של Tag Manager, לכל קונטיינר יש רצף גרסאות אחד. זה המשפט שמסביר את רוב ההפתעות: לא משנה כמה Workspaces פתוחים, כולם מתנקזים לאותו רצף. כל פרסום של אחד מהם הופך את האחרים ללא מעודכנים.
כמה Workspaces אפשר לפתוח ומתי פותחים חדש?
כל קונטיינר נוצר עם Workspace ברירת מחדל. לפי התיעוד, בחשבון רגיל אפשר להוסיף עד שניים נוספים, כלומר שלושה במקביל. בחשבונות Tag Manager 360 המספר לא מוגבל.
פותחים Workspace חדש כשרוצים לפתח ולבדוק שינוי בנפרד מהתצורה הראשית, או כשכמה אנשים עובדים על דברים שונים. ההמלצות של Google עצמה פשוטות: שינויים קטנים, Workspace אחד לכל קבוצת שינויים שקשורים זה לזה ויפורסמו יחד, הפרדה בין צוותים או ספקים. הדוגמה שבתיעוד היא סוכנות שעובדת גם על תגי Google Analytics וגם על תגי Floodlight. שני Workspaces נפרדים מאפשרים לפרסם בסדר מבוקר ומשאירים היסטוריית גרסאות קריאה.
שם ה-Workspace והתיאור שלו עשויים להפוך לשם הגרסה ולתיאור שלה. לכן שם כמו "test" או "דני" הוא בזבוז. שם טוב מתאר את המטרה, לדוגמה "מעקב טפסים בעמודי נחיתה".
פרט שמבלבל משתמשים חדשים: אחרי ש-Workspace הופך לגרסה או מתפרסם, השם, ההערות ורשימת השינויים שלו נרשמים עם הגרסה. ה-Workspace עצמו מוסר. ה-Workspace של ברירת המחדל נוצר מחדש אוטומטית.
מה קורה כשמישהו אחר פרסם לפניכם?
ברגע שנוצרת גרסה חדשה, כל Workspace אחר מציג הודעה שהוא לא מעודכן ומציע לעדכן. גם בניסיון לפרסם תופיע ההודעה "This workspace is out of date". לחיצה על Update Workspace מציגה את רשימת הגרסאות שעוד לא מוזגו. אפשר לפתוח כל אחת ולראות מה השתנה בה. העדכון מביא ל-Workspace שלכם את כל השינויים שנעשו בגרסאות אחרות מאז העדכון האחרון.
אם שינוי שהגיע מתנגש בשינוי שלכם, עמוד ה-Overview יציג "Conflict found" וייפתח כלי לפתרון קונפליקטים. בצד אחד מוצגת התצורה של הגרסה האחרונה שסונכרנה. בצד השני מוצגת התצורה ב-Workspace הנוכחי. לכל קונפליקט מחליטים אם להתעלם מהשינוי שהגיע או להעתיק אותו.
כאן נמצאת המלכודת. לפי התיעוד, הכפתור Resolve All מתעלם מכל השינויים של הגרסה שסונכרנה. כשה-Workspace יתפרסם, כל שינוי שהתעלמתם ממנו יידרס על ידי התצורה שלכם. במילים אחרות: לחיצה אחת על Resolve All יכולה למחוק תיקון שעמית פרסם אתמול. עוברים על הקונפליקטים אחד אחד.
מה ההבדל בין Create Version ל-Publish?
לחיצה על Submit פותחת שתי אפשרויות. Publish and Create Version מפרסם את השינויים והופך אותם לפעילים בסביבה שנבחרה. Create Version שומר צילום מצב בלי לפרסם. לפי התיעוד, כל פרסום רושם גרסה. אפשר לשמור גרסה בכל רגע גם בלי לפרסם.
ההבדל הזה מתחבר להרשאות ברמת הקונטיינר:
| הרשאה | לערוך וליצור Workspaces | ליצור גרסה | לפרסם |
|---|---|---|---|
| Read | לא, צפייה בלבד | לא | לא |
| Edit | כן | לא | לא |
| Approve | כן | כן | לא |
| Publish | כן | כן | כן |
מכאן נגזר תהליך עבודה פשוט גם בלי Tag Manager 360: מי שבונה מקבל Edit או Approve, שומר גרסה ומעביר לבעל הרשאת Publish שבודק ומפרסם. תהליך אישורים מובנה, עם האפשרות Request Approval ולשונית Approvals, קיים לפי התיעוד רק ב-Tag Manager 360. את חלוקת ההרשאות עצמה פירטנו במדריך האודיט וניקוי הקונטיינר.
מסלול השינוי
מהעריכה ועד שהגרסה חיה באתר
איך משתמשים בסביבות לבדיקה לפני פרסום?
סביבות מתאימות לארגונים שעובדים עם שרת פיתוח, שרת בדיקות ושרת פרודקשן. לפי התיעוד אפשר להגדיר כמה סביבות שצריך ולפרסם כל גרסה לכל סביבה. סביבת Live קיימת בכל קונטיינר ותמיד מצביעה על הגרסה שמפורסמת כרגע.
- יוצרים סביבה. Admin, אחר כך Environments בעמודת הקונטיינר, אחר כך New. נותנים שם, לדוגמה QA. אפשר להוסיף תיאור וכתובת יעד.
- מחליטים על Enable Debugging by Default. הסימון גורם לסביבה לעבוד תמיד במצב Preview.
- מפרסמים גרסה לסביבה. בסיום היצירה מופיעה ההצעה Publish Now. בתפריט Version בוחרים איזו גרסה תיטען. פרסום לסביבה מותאמת לא משנה את הגרסה החיה.
- מתקינים את ה-snippet של הסביבה. בתפריט Actions של הסביבה בוחרים Get Snippet ומתקינים את הקוד בשרת המתאים. זה קוד שונה מה-snippet הרגיל, לכן צריך מפתח.
- מפרסמים דרך תפריט הסביבה. ברגע שיש סביבות מותאמות, חלון הפרסום מוסיף תפריט Environment שבו בוחרים לאן השינוי הולך.
שלוש נקודות מהתיעוד שכדאי לזכור. הראשונה: הסביבות מיועדות לשרתים שאינם פרודקשן. באתר החי משאירים את ה-snippet הרגיל, לטובת הביצועים. השנייה: מי שלא רוצה להתקין קוד נוסף יכול להשתמש ב-Share Link של הסביבה ולשלוח קישור Preview, אבל צריך לזכור להפעיל את מצב ה-Preview. השלישית: Reset Link מבטל את הקישורים שנשלחו, אבל גם את ה-snippets שכבר הותקנו. אחרי איפוס צריך להתקין snippet מעודכן בשרת של אותה סביבה.
המשתנה המובנה Environment Name מחזיר את שם הסביבה שממנה נטען הקונטיינר. לסביבות המובנות הוא מחזיר Live, Latest או Now Editing. שימוש מועיל במיוחד: טבלת Lookup שנשענת עליו שולחת נתוני בדיקות לנכס GA4 נפרד, כך שנכס הפרודקשן נשאר נקי. על טבלאות Lookup הרחבנו במדריך המשתנים ב-GTM.
מה סדר הפרסום הבטוח?
- מעדכנים את ה-Workspace. אם מופיעה הודעה שהוא לא מעודכן, מושכים קודם את השינויים של אחרים ופותרים קונפליקטים אחד אחד.
- בודקים ב-Preview. מצב Preview מציג את האתר כאילו טיוטת הקונטיינר כבר פורסמה, רק בדפדפן שלכם. את שיטת הבדיקה תמצאו במדריך Preview ו-Tag Assistant.
- עוברים על Workspace Changes. במסך Submit מופיעה רשימת כל השינויים. מהתפריט More Actions אפשר לראות את ההבדלים של כל רכיב מול הגרסה הקודמת או לבטל שינוי. אם מופיע שם תג שלא נגעתם בו, עוצרים.
- כותבים שם ותיאור לגרסה. הדוגמה מהתיעוד: שם
GA page view tag - initial launchותיאור שמסביר מה הושק ואיפה. בעוד חצי שנה זה יהיה המידע היחיד על מה שנעשה כאן. - מפרסמים לסביבת בדיקה אם יש. בודקים שם שהתגים נורים ושהאתר לא נפגע.
- מפרסמים ל-Live ובודקים מיד. גולשים באתר החי, מבצעים את הפעולה שנמדדת ומוודאים שהנתון הגיע ליעד.
שני כללים שאינם בתיעוד ושווים הרבה: לא מפרסמים רגע לפני שעוזבים את המחשב ולא מפרסמים שינוי גדול ביום של עלייה לאוויר של קמפיין.
איך מחזירים גרסה קודמת כשמשהו נשבר?
זאת הסיבה שגרסאות קיימות. לפי התיעוד, אם מישהו פרסם בטעות גרסה שלא הייתה מוכנה, אפשר לחזור לגרסה מוקדמת ולפרסם אותה. נכנסים ל-Versions, בוחרים את הגרסה הרצויה ולוחצים Publish מתפריט הפעולות. ברשימה מופיעה גם האפשרות Publish To לבחירת סביבה.
פעולה שנייה, שונה במהות, היא Set as Latest Version. היא מחליפה את טיוטת הקונטיינר הנוכחית בתוכן של הגרסה שנבחרה. היא לא מפרסמת כלום. משתמשים בה כשרוצים להמשיך לעבוד מנקודת מוצא ישנה ואז לפרסם.
Tag Manager שומר היסטוריית פרסומים. בעמוד Versions, גרסאות שפורסמו מופיעות עם תאריך בעמודת Published, כך שרואים מתי כל גרסה הייתה חיה ומי פרסם אותה. כשמספר יורד בפתאומיות בדוחות, זה המקום הראשון שבודקים: האם התאריך של הירידה תואם תאריך של פרסום.
שאלות נפוצות
כמה Workspaces אפשר לפתוח ב-Google Tag Manager?
לפי התיעוד של Tag Manager, כל קונטיינר נוצר עם Workspace ברירת מחדל. בחשבון רגיל אפשר להוסיף עד שניים נוספים, כלומר שלושה במקביל. בחשבונות Tag Manager 360 אפשר ליצור מספר בלתי מוגבל של Workspaces.
מה ההבדל בין Create Version ל-Publish ב-GTM?
Create Version שומר צילום מצב של ה-Workspace בלי לשנות את מה שרץ באתר. Publish and Create Version הופך את השינויים לפעילים בסביבה שנבחרה ורושם גרסה באותה פעולה. לפי התיעוד, הרשאת Approve מאפשרת ליצור גרסאות אבל לא לפרסם. רק הרשאת Publish מאפשרת לפרסם.
איך מחזירים גרסה קודמת ב-GTM?
נכנסים ל-Versions, בוחרים את הגרסה הרצויה ולוחצים Publish מתפריט הפעולות. הגרסה הישנה הופכת לגרסה החיה. האפשרות Set as Latest Version עושה דבר אחר: היא מחליפה את טיוטת הקונטיינר בתוכן של הגרסה שנבחרה בלי לפרסם, כדי שאפשר יהיה להמשיך לערוך ממנה.
מה זה Environment ב-GTM ומתי צריך אותו?
Environment הוא יעד פרסום. לכל קונטיינר יש סביבת Live שמצביעה תמיד על הגרסה המפורסמת. אפשר להגדיר סביבות מותאמות, למשל Dev או QA, להתקין בשרת הבדיקות snippet ייעודי ולפרסם אליהן כל גרסה בלי לגעת באתר החי. לפי התיעוד הן מיועדות לשרתים שאינם פרודקשן. באתר החי משאירים את ה-snippet הרגיל.
מה קורה ל-Workspace אחרי שמפרסמים אותו?
לפי התיעוד, כש-Workspace הופך לגרסה או מתפרסם, השם, ההערות ורשימת השינויים שלו נרשמים יחד עם הגרסה. ה-Workspace עצמו מוסר. ה-Workspace של ברירת המחדל נוצר מחדש אוטומטית. שאר ה-Workspaces הפתוחים מקבלים הודעה שהם לא מעודכנים.
מה עושים כשמופיעה ההודעה This workspace is out of date?
ההודעה אומרת שגרסה חדשה נוצרה מ-Workspace אחר מאז העדכון האחרון שלכם. לוחצים Update Workspace, עוברים על רשימת הגרסאות שלא מוזגו ומאשרים את העדכון. אם יש התנגשות ייפתח כלי לפתרון קונפליקטים. לפי התיעוד, Resolve All מתעלם מכל השינויים שהגיעו, כך שפרסום ה-Workspace ידרוס אותם. לכן עדיף לעבור על הקונפליקטים אחד אחד.
מה השורה התחתונה?
קונטיינר לא נשבר בגלל תג אחד שגוי. הוא נשבר כי השינוי השגוי פורסם יחד עם עשרה שינויים אחרים, בלי בדיקה ובלי שם, כך שאף אחד לא יודע לאיזו גרסה לחזור. שלושת המנגנונים של GTM פותרים בדיוק את זה: Workspace קטן לכל שינוי, גרסה עם שם ותיאור בכל פרסום, סביבת בדיקה כשיש שרת staging. מי שמקפיד על שלושתם יכול לתקן כל תקלה בפרסום מחדש של הגרסה הקודמת. הקמת תהליך כזה, כולל הרשאות וסביבות, היא חלק משירות הטמעת Google Tag Manager שלנו. את שאר יסודות הכלי ריכזנו במדריך המלא ל-Google Tag Manager. אם אצלכם כולם מפרסמים מאותו Workspace ואף אחד לא בטוח מה חי באתר, כתבו לנו.
מקורות
Tag Manager Help: Workspaces, Tag Manager Help: Publishing, versions, and approvals, Tag Manager Help: Environments, Tag Manager Help: Managing users and permissions, Tag Manager Help: Preview and debug containers, Tag Manager Help: Built-in variables for web containers
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי