[עודכן ביולי 2016]
אם שמעתם על Google Tag Manager, ומישהו אמר לכם שזה חובה (זה לא..) ומישהו אמר לכם שכדאי (לא תמיד), ואתם לא בטוחים, אז קחו נשימה עמוקה וקראו את המאמר הזה בעיון. מומלץ להעביר אותו גם בתוך הארגון, בעיקר לאנשי ה Security וה IT.
#1 – Google Tag Manager זה לא כלי אנליטיקס
תתפלאו, אבל מכיוון ששני המוצרים באים מבית גוגל ורוב השימושים שנעשים היום הם סביב עניין האנליטיקס, רוב המשתמשים החדשים בטוחים שזה סוג של מערכת משלימה לגוגל אנליטיקס. אז לא.
Google Tag Manager זו מערכת פיתוח לכל דבר. אינה בינה לבין גוגל אנליטיקס שום קשר. עם זאת, היא חוסכת המון עבודת הטמעה עבור גוגל אנליטיקס, ובמקום שמישהו ישלח אוונט או כל פיסת מידע אחרת לגוגל אנליטיקס באמצעות כתיבת קוד בגוף האתר, הוא יכול לעשות זאת דרך GTM. אבל, באותה המידה הוא יכול לשלוח את המידע הזה למערכות אנליטיקס אחרות לגמרי. המערכת יושבת על משפחת המוצרים הקרויים Tag Management System ולא תחת משפחת מערכות האנליטיקס.
#2 – Google Tag Manager לא מיועד לכל אחד
יש כל מיני שימושים ל GTM.
חלק משתמשים במערכת רק כדי לשים פיקסלים של מערכות פרסום שונות. חלק משתמשים במערכת על מנת להטמיע מעקב מתקדם יותר של גוגל אנליטיקס או בכלל מערכות אחרות (לא רק כלי אנליטיקס). חלק מריצים סקריפטים מורכבים ולוקחים את המערכת לקצה.
כך או כך, רמת הידע הנדרשת שונה לחלוטין בכל שימוש. יש דברים שאנשי שיווק יכולים לעשות בפשטות אם רק ילמדו איך. מהעבר השני, יש שימושים ל GTM שאולי אנליסט יכול "להמציא" או "לתכנן" אבל רק מפתח יכול לבצע ב GTM. ייתכן והאנליסט יודע קצת לפתח, ייתכן שאיש השיווק הוא גם אנליסט, וייתכן שאיש הפיתוח הוא גם איש שיווק. בחברות קטנות מאד, לעיתים האנליסט או איש השיווק נאלץ לדעת גם פיתוח. כך או כך, אלו אוכלוסיות שונות, עם צרכים שונים וכולם עובדים על אותה המערכת.
האם כולם צריכים לעבוד עליה? האם לכל אחד בחברה שיש לו גישה לאנליטיקס, או כל אחד שהוא ה Webmaster של האתר או חלק מצוות הפיתוח שלו – צריכה להיות גישה ל GTM? שאלה מצויינת.
התשובה הקצרה – לא. התשובה הארוכה – מישהו צריך להחליט למי תהיה הרשאה.
#3 -זו בעצם מערכת שעושה Code Injection
אם לא היה ברור לכם עד עכשיו, מערכות כמו GTM ו – GTM בעצמה מסווגות בעולם הפיתוח כ Code Injection Platforms. המונח Code Injection מקושר בדר"כ באופן שלילי לתוכנות או פרצות המאפשרות למישהו מבחוץ לשתול קוד זדוני באתר או במערכת כלשהי, ממש כמו סוס טרויאני. לא משנה באיזה כותרות תעטפו את GTM, בליבה שלו, זה מוצר להזרקת קוד מבחוץ. בדר"כ כשאנשי IT שומעים את המונח Code Injection הם ישר נעמדים על הרגליים האחוריות. בעיקר אלו ממחלקות אבטחת המידע.
לדוגמא, יש לזכור שכיום המערכת אינה מפרידה בין סוגים שונים של תגיות למשל. כלומר, ברור לכולם שלשים פיקסל המרות של Adwords, שמגיע ממש מוכן מהקופסא, זהו טאג פשוט שאינו מצריך כמעט ידע ויכול באופן עקרוני להיות נגיש באופן מלא לאנשי השיווק ומנהלי הקמפיינים. מהצד השני, אותה המערכת, באותה מידה של זמינות, מאפשרת למשתמש לדחוף קוד מורכב ומסובך שאיש אינו יודע מה הוא עושה (Custom HTML למשל) שיכול לשנות את עיצוב האתר, להשפיע על תפקודו, לדרוס ערכים ומשתנים, לייצר חדשים, לייצר עוגיות במחשב המשתמש וכל דבר כמעט שתוכלו לחשוב עליו. Code Injection כבר אמרתי, כן?
למערכת GTM קשה להפריד בין רמות שונות של "מורכבות" או של ידע וגם כשהיא עושה את ההפרדה הזו, ההפרדה עלולה לשבש תפקוד תקין של המערכת (לקריאה על איך חוסמים קודים זדוניים ב GTM). כך או כך, היתרון בגמישות עלול להפוך לחיסרון ואיש שאינו מיומן במערכת עלול לייצר נזק ונתקלתי כבר ביותר ממקרה אחד כזה.
Google Tag Manager אינה מגרש משחקים, מדובר במערכת המהווה חלק אינטרגלי מסביבת הייצור וככזו יכולה להשפיע על תפקוד האתר וסביבתו. שקלו בכובד ראש למי בארגון יש הרשאה למערכת.
#4 – מה שנכתב ב GTM – נשאר ב GTM ורק ב GTM
אני אסביר בדוגמה פשוטה מאד. בעזרת GTM יצרתי Event של גוגל אנליטיקס כאשר משתמש לוחץ על כפתור מסויים. לצערי, על הכפתור לא היה ID ייחודי, אז שלפתי את ה Class שלו שכן היה ייחודי. באותה המידה הייתי למשל יכול לזהות הקלקה על הכפתור בתנאי שלינק היעד הוא כתובת מסוימת. כך או כך, זיהיתי אלמנט מסויים בקוד על מנת לזהות את הכפתור באופן ספציפי. הכל עבד כשורה וכולם היו מאושרים (עד כמה שאוונטים גורמים למישהו אושר).
לאחר כמה שבועות הספירה של ה Event צנחה לאפס. התברר כי אחד מהמפתחים ביצע כמה שינויים בדף ושינה את שם ה Class של הכפתור. כלומר, קוד הליבה – השתנה. המפתח לא ידע שיש מישהו שמסתמך על תצורת הקוד. המפתח לא יכל לראות בקוד של האתר ש GTM קורא מידע מהכפתור הזה. בניגוד לסעיף הקודם, בו GTM יכול לשבור את קוד האתר, כאן הטמעות באתר יכולות "לשבור" את ה GTM.
בעולם ללא GTM, היינו יוצרים את ה Event בשינוי קוד האתר. Hard Coded פשוטו כמשמעו. במידה והמפתח היה רוצה לשנות את תפקוד הכפתור, הוא מיד היה רואה בקוד שיש איזו פונקציה או אירוע שמתרחש בעת הלחיצה, והוא היה דואג לשמר אותו. כלומר, גם אם הוא לא ידע בדיוק מה עושה הפקודה הזו, היא הייתה גלויה בקוד. כש GTM מתחיל להיות אחראי על המידע הנשלח מהאתר, הפעילות נעשית למעשה באופן "שקוף" ולא נראית בעין בלתי מזויינת. ככל ש GTM יהפוך לכלי מרכזי בפיתוח ובמעקב אחר האתר, כך המפתחים יצטרכו להיות זהירים בכל מה שכרוך בשינויים בקוד האתר וכמובן להיות מעורבים או לפחות להיות מודעים למה שנעשה בתוך ה GTM.
#5 – לא תומך ב Workflow (עדיין)
בעולם הפיתוח האידיאלי, המאפיין לא מפתח, המפתח לא בודק והבודק לא מעלה לייצור. לכל אחד יש את התפקיד שלו ובסיום עבודתו, מעביר את זה לבא בתור. בסוף השרשת יושב האינטגרטור שאחראי על ההעלאה לייצור ומוודא שהכל פותח ונבדק כמו שצריך. השרשרת הזו, ה Workflow הוא כלי הכרחי בפיתוח, אבל ב GTM אין למעשה היררכיה או תמיכה ב Workflow. יש במסך ההרשאות יכולת למנוע ביצוע Publish ממשתמשים אבל זה חלק קטן מהעניין. הרעיון הוא בתהליך תקין של מסירת קוד אחד לשני לצורך בקרה טובה יותר.
אצל אחד הלקוחות הגדרנו את ה Workflow ברמת נוהל, כלומר הקצנו מטמיע, בודק ואינטגרטור, ולמשתמשים אסור לעשות מה שהם לא אמורים לעשות, אבל זה כמובן רק ברמת הנוהל ואין באמת מניעה טכנית מלעשות הכל. לשמחתי, יש את ה Changelog שמתעד כל פעולה שנעשתה, אבל זה עלול להיות מאוחר מדי.
#6 – פרסום יותר מדי תגיות בבת אחת – Agile GTM
ביצעתם שינויים, הוספתם תגיות ומשתנים – קחו את זה לאט. אל תפרסמו הכל בבת אחת ואל תחכו לסיום העבודה על מנת לפבלש את הכל. ההמלצה היא לפרסם ולעדכן את הקונטיינר במנות קטנות. יצרתם עשרה משתנים? ה Debug עבר טוב? שנייה לפני שאתם רצים לייצר תגיות, שחררו את הגרסה. בדקו שהמשתנים מקבלים ערכים נכונים וממשיכים לעבוד גם אחרי ה Publish. עכשיו אפשר לעבור לתגיות ולהמשיך משם, וגם כאן, אל תייצרו חמש תגיות ותפבלשו. צרו אחת או שתיים, תדבגו ופרסמו. לא יקרה אסון אם תחכו כמה שעות או אפילו יום-יומיים לפני שאתם ממשיכים הלאה (אלא אם כן הלקוח ממש בלחץ). זה יתן לכם זמן להעמיק בבדיקות. ישנן כל מיני שיטות לפרסם תגית אחת מתוך כמה, אבל מבחינתי זה מיותר. עודף גרסאות עוד לא פגע באף אחד, אבל לעשות רולבק (Rollback) ולנסות להבין איזו תגית לא עברה טוב – יכול לקחת המון זמן יקר. חשבו Agile – העלו לייצר גרסאות קטנות ורזות.
#7 – לא ממש מסתדר עם טכנולוגיות Front End מתקדמות
בשנתיים האחרונות לא מעט מפתחים נוטים לפתח את צד ה Front End בשפה הקרויה AngularJS. שבפשטות נאמר שזו סביבת פיתוח (Framework) מבוססת Java Script ומצוינת לפיתוח אפליקציות ווב. אבל ההתנהגות שלה היא כמו של One Page Application, קרי, כתובת האתר לא מתחלפת, ולמרות שהגולש מתקדם בתהליכים ומסכים מתחלפים, זה נראה ומרגיש כאילו הכל מתקדם על המקום ללא טעינה נוספת. מבחינת חווית משתמש זה נראה ומתנהג נהדר. מבחינת אנליטיקס, GTM, כלי A/B Testing וכלים נוספים, זה יכול להיות קטסטרופה ובלתי אפשרי למדידה. ייתכן ומבנה מסויים של אתר לא יטען בכלל את הקוד של GTM בכלל ושום דבר לא יעבוד. זה מאד תלוי באיך הקוד נכתב.
על מנת לפתור את זה, יש לערב את הפיתוח שוב וזה קצת מוציא מהעוקץ של ה GTM שאמור לשחרר אותנו מהעול הזה. זה לא אומר אגב, שתמיד כל סביבת Angular היא בעייתית, אבל סביר מאד שכן. קחו בחשבון לפני שאתם רצים קדימה.
#8 – לחשוב שזה פשוט
יש משהו מפתה בממשק האסתטי ובתגיות המוכנות. משהו שעלול לגרום למשתמש הנפוץ לחשוב שעבודה ב GTM סוגה בשושנים. ממשקים מזמינים מדי עלולים לייצר אשלייה שמדובר בסך הכל במערכת נורא קלילה, ולא כך הדבר (קראו שוב את סעיף 1 במאמר הזה). בקורסי האנליטיקס שלי ובהדרכות ארגוניות אני מדבר על GTM כשעה לפני שאני בכלל מציג אותה. המטרה היא לייצר סוג של "יראת כבוד" או לכל הפחות הבנה עמוקה של יכולות המערכת (לטובה ולרעה) וזאת על מנת שאנשים יכנסו אליה במלוא הרצינות ובמלוא הזהירות. זה לא משחק ילדים.
#9 – חוסר ידע
אין צורך להסביר. יש בלוגים (מעט), קבוצות תמיכה ופורומים והמערכת עדיין חדשה ובהרבה מובנים עדיין לא הורידו ממנה את כל הפצפצים. יש באגים, יש גליצ'ים, יש הרבה "בטא". אל תתיימרו לדעת הכל. תשאלו, תחקרו, תלמדו ותקראו. Trial&Error זו אחלה דרך ללמוד דברים אבל וודאו שהניסויים שלכם מושכלים ולא מבוססים הערכות וניחושים.
#10 – הקוד של האתר שלכם צריך להיות כתוב טוב. ממש טוב
אתם רוצים למדוד לחיצה על כפתור מסויים, או לתפוס איזה טופס. נכנסים לקוד, מוצאים את הכפתור ועכשיו אתם רוצים ללמד את GTM לזהות את הכפתור הזה. אך המפתח של האתר לא ממש השקיע באפיון הכפתור או מתן זהות ייחודית לכפתור הזה, ואתם נאלצים להתחכם עם כל מיני פטנטים. רגע אולי נזהה לפי הצבע של הכפתור וגם אם יש לו class מסויים ואולי אם הוא מפנה לדף מסויים או עושה פעולה מסויימת. לו רק המפתח היה נותן איזה ID פשוט זה היה לוקח חצי שנייה. אבל במקום זה אתם מחפשים קומבינציה מופלאה של תנאים כדי לזהות כפתור פשוט.
בצורה הזו, Google Tag Manager, במקום להיות כלי אלגנטי הופך להיות הפלסטר של המפתח. כל מה שאין בקוד, אנו מנסים לחשוב איך להוציא ולשלוף את המידע הזה, וזה דורש המון יצירתיות ולעיתים היצירתיות הזו מוגזמת לגמרי. מלבד העניין שזה פשוט יכול לא לעבוד טוב, זה פשוט נראה רע ומגדיל את הסיכונים לבעיות בעתיד, ראו סעיף #4.
נכון, אפשר מהמפתח לבקש לשפר את הקוד וכו', אבל תמיד יהיה זה שיגיד, "רגע, רציתם GTM כדי שלא ניגע בקוד, נכון?"
#11 – אתם עדיין תזדקקו לפיתוח
כן. מה לעשות. לא כל דבר אפשר לעשות ב Google Tag Manager מבלי לבקש סיוע מהמפתח. אם חשבתם שתצאו לדרך עצמאית, תשכחו מזה. בטח באתרים בעלי מורכבות טכנולוגית אלו כאלו שזקוקים למידע מצד השרת. אך אליה וקוץ בה. ברגע שאתם מבקשים מהמפתח לתמוך בכל מיני דברים ולהטמיע חלק מהדברים בעצמו, אתם מגיעים לבעיה הבאה:
#12 – הטמעות של Google Tag Manager באופן היברידי עם קוד באתר
כאשר חלק מהדאטה הנשלח למשל לגוגל אנליטיקס מתבסס על טריגרים ומידע הנשלף בחלקו מעבודה שעשיתים ב GTM בכוחות עצמכם וגם על מידע שנזדקקתם לאיש פיתוח שיעשה איזה "תיקון" או התאמה באתר – אתם טיפ'לה בבעיה. זה אומר שאם מחר בבוקר מגיע מישהו חדש ל GTM הוא יצטרך להבין שחלק מהדברים שעובדים הם תוצר של שיתוף פעולה של הפיתוח ושל GTM. זה לא טריוויאלי ובטח שיכול להיות בעייתי לתחזוקה עתידית שוטפת ללא תקלות.
#13 – יש לכם אנליטקיס באתר וחושבים להסב ל GTM? חשבו שוב.
מי שהטמיע באתר שלו גוג לאנליטיקס בצורה הקלאסי תוהנפוצה, קרי – Hard Coded של דפים, אוונטים, אי-קורמס וכל מה שאפשר, ורוצה להסב ל GTM, חייב להסב את כל עבודת הקוד שתעבוד עכשיו דרך GTM. הוספת הסקריפט של אנליטיקס דרך GTM ממש לא מספקת, וכתוצאה מכך כל האוונטים שלכם וכל עבודת ההטמעה שעשיתם Hard Coded פשוט תפסיק לעבוד עד שלא תמירו אותה לעבודה דרך GTM.
#14 – אבטחה
רגע רגע..מערכת שעושה Code Injection והיא יושבת בכלל ב Cloud?? אם האתר חשוב לכם, מלבד לצמצם הרשאות מיותרות, אני ממליץ להסב את שיטת הלוגאין שלכם לגוגל ל Two Steps Verification, כלומר גם סיסמה וגם קוד שקיבלתם מגוגל ב SMS. על מנת להכנס לשירותים של גוגל. אין דבר כזה אבטחה מיותרת. תוכלו לעשות זאת ברמת הגדרות ה Google Account שלכם או ב Account Settings של ה GTM.
#15 – חוסר בסדר וארגון
קיבלתי לידי מה שנראה כמו חשבון ה GTM המופרך ביותר שניתן היה ליצור. מעל 400(!) תגיות (Tags), כמחצית מזה כמות הטריגרים ואלוהים יודע כמה Variables. טרם סיימנו לספור.
מניתוח ה Change Log החשבון עבר בערך עשרים זוגות ידיים בשנה האחרונה, מעל 15 איש מעובדי החברה יש הרשאת עריכה ו Publish כולל לפחות שלושה יועצים חיצוניים שאני מכיר אישית. לכולם מותר לעשות הכל. אין סדר ואין מתודה, וכל אחד נותן איזה שמות שהוא רוצה.
הבעיה החלה לפני חצי שנה כשלא מעט נתונים הופסקו לשלוח למערכות שונות והנהלה הבינה שבוצעו שינויים בקוד המונעים מ GTM לרוץ באופן תקין ושחלק מהתגים כבר לא רלוונטיים ודורשים עדכון. החיפוש אחרי התגיות שאמורות לעבוד התברר כסיוט. כשהתג שאמור לשלוח את קוד ההמרה של מערכת מסויימת נקרא Pi_Con_LR10, אין סיכוי שמישהו ימצא אותו או יבין ש Pi_Con זה קיצור מעוברת של Conversion Pixel מסוג כלשהו. מה קורה כשיש מעל 80 פיקסלים כאלה?
הפרוייקט שלנו הוא סוג של סידור ותיקוף כל החשבון מחדש. אז כצעד ראשון, סוג של צעד מניעתי, הורדנו את ההרשאות לכל המשתמשים כמעט וכל הבקשות עוברות דרכנו. במקביל, אנו כותבים מסמך תיעוד GTM שיהיה נגיש לכולם ויעשה שם סדר לפי נושאים על מנת להסביר כל תג, מה הוא אמור לעשות ומה הלוגיקה המופעלת עליו ובאיזה חלקים של האתר הוא אמור לרוץ. בין היתר, שינוי שמות והגדרת קונבנציה אחידה. רק שתבינו את סדרי הגודל, הפרוייקט הזה מתומחר בכחודש עבודה ועוד לא התחלנו את העבודה האמיתית של האופטמיזציה. בקיצור, סלט.
יש לכם משהו להוסיף? להזהיר את כולם? אני מחכה לתגובות שלכם!
