ליקספיקס – גוגל אנליטיקס, גוגל תג מנג'ר ואופטימיזציה

#data_shorts – איך לעבוד עם סביבות פיתוח בתג מנג׳ר

הנה שאלה שחוזרת על עצמה לא מעט – איך לעבוד עם סביבת פיתוח בתג מנג׳ר.

סביבת פיתוח היא בעצם העתק של האתר שיושב בכתובת שונה, למשל staging.lixfix.co.il, והיא נועדה כדי שהמפתחים יוכלו לערוך שינויים באתר מבלי לשבור את סביבת הפרודקשן – שזמינה לציבור הרחב.

נגיד שאתם מטמיעים את האיקומרס של גוגל אנליטיקס 4 ואתם רוצים לבדוק שכל האיוונטים עובדים בצורה תקינה.

אתם מבקשים מהמתכנתים להכין לכם את ה-dataLayer, ואז עושים את מה שצריך בתג מנג׳ר, ורוצים לפבלש כדי לבדוק שהכל עובד תקין.

אתם לא רוצים לעבוד על ה-GTM של הפרודקשן, כי יכול להיות שיש שם שינויים שצוות המרקטינג עשה לאחד מהפיקסלים ועוד לא פיבלש, או שסתם יש שם תגים דומים שעלולים לשבור דברים אם תעשו בהם שינויים.

מה עושים בכזה מצב, ואיך הכי נכון לנהל את זה?

ובכן, קודם כל נתחיל בזה שצריך לפתוח פרופרטי שונה בגוגל אנליטיקס 4 – אחד לפרודקשן ועוד אחד לסביבת הפיתוח:

ומה עושים עם התג מנג׳ר?

פה יש כמה אופציות, אתחיל עם האופציה הפחות טובה לדעתי, ואמשיך לאופציות שאני באופן אישי מעדיף (יש פה גם עניין של נוחות).

אופציה 1: שני קונטיינרים שונים

פשוט לפתוח 2 קונטיינרים שונים בתג מנג׳ר. אחד יוטמע בפרודקשן ואחד בסביבת הפיתוח.

עשיתם שינוי בסביבת הפיתוח והוא תקין? מעולה. עכשיו תיצרו את אותם tags/triggers/variables בסביבת הפרודקשן ותפבלשו.

הסיבה שאני לא אוהב את זה היא בגלל שלדעתי לא נוח לתחזק את זה, וכל שינוי צריך לעשות פעמיים.

נכון שאפשר לעשות export-import אבל במידה ויש עוד אנשים שעובדים על התג מנג׳ר, דברים עלולים להישבר בכל פעולות הסנכרון הללו.

אופציה 2: קונטיינר אחד, עם סוויצ׳

באופציה הזו אני משתמש כשאני עובד עם חברות בגודל בינוני, או חברות שבהן השינויים בתג מנג׳ר הם בדרך כלל קטנים, או שאין הרבה צוותים שצריכים את התג מנג׳ר. כלומר זה רק אני והמרקטינג, ואין פרודקט, אנליסטים ועוד אנשים שיכולים לרצות/לעשות שינויים.

מה שאני עושה במקרה הזה זה יוצר variable שמשנה את ה-GA ID בהתאם ל-hostname. אם זה stage הוא מחזיר ID מסויים, ואם זה prod הוא מחזיר ID אחר.

את הוריאבל הזה אני שם בתג קונפיג הראשי שלי, ואז אם הגולש מבקר ב-stage הדאטה נשלח לפרופרטי של סביבת הפיתוח, ואם הוא מבקר בפרודקשן הדאטה נשלח לפרופרטי של סביבת הפרודקשן:

אופציה 3: שימוש ב-Environments

שתי הדרכים שהבאתי קודם הן לא פתרונות מובנים.

הפתרון הבא מובנה בתג מנג׳ר ומיועד בדיוק למצבים כאלו, אבל הוא דורש עבודה זהירה שאפרט עליה בהמשך.

קודם כל הולכים למסך האדמין ולוחצים על Environments:

לוחצים על New, ונותנים שם לסביבה. הנה הסביבה שאני יצרתי:

לאחר מכן לוחצים על Actions ואז Get Snippet:

מעתיקים את הקוד ושולחים למתכנת כדי שיטמיע בסביבת הפיתוח בלבד.

הקוד הזה משתמש באותו GTM ID כמו שיש לכם בקוד המקורי שמוטמע באתר שלכם, אבל יש בו תוספת קטנה שעוזרת לתג מנג׳ר לדעת שמדובר בסביבה שונה, כלומר מה שתפבלשו ל-Staging Environment יפעל רק שם, ולא בפרודקשן.

לאחר מכן, בכל פעם שאתם מפבלשים את הקונטיינר, תצטרכו ללחוץ על Publish to Environment ולבחור ב-Staging ואז זה יפבלש את כל השינויים שעשיתם, אבל רק לסביבת הסטייג׳ינג:

הסיבה שצריך פה המון זהירות היא מכיוון שברירת המחדל של הפיבלוש היא לגרסת ה-Live, כלומר זו שמוטמעת אצלכם בפרודקשן, ומספיק חוסר תשומת לב קטן כדי ללחוץ על Next-Next-Next כמו שהרבה רגילים לעשות, ואז כל השינויים שעשיתם יעלו לפרודקשן בניגוד לרצונכם.

מתי אני משתמש באופציה הזו? 

א. כשיש שינויים שדורשים בדיקה לאורך זמן. כלומר לא רק לראות אם התג נשלח (שזה אפשר לעשות גם באמצעות ה-Preview), אלא למדוד את הנתונים שהוא אוסף אחרי כמה ימים.

ב. כשיש שינויים שמישהו אחר מהצוות אמור לעבור עליהם. אפשר כמובן לעשות את זה בדרכים אחרות כמו שיתוף version, אבל יצירת Environments היא דרך טובה.

ג. חובה: רק אם אני באמת סומך על מי שמשתמש בתג מנג׳ר. אם זו סוכנות פרסום חיצונית ולא עובד חברה, אני לרוב אעדיף להשתמש בשתי האופציות הראשונות, פשוט כי יש פחות סיכוי לטעות עם פבלוש דברים לא רצויים ללייב.

זהו להפעם.

נהניתם? שלחו את הפוסט לחבריכם.