שרת ביניים שמקבל אירוע אחד ומפזר אותו לכל הפלטפורמות.
Server-Side GTM הוא קונטיינר שרץ על שרת משלכם ומקבל אירועים — מהאתר, מהמערכת, או משניהם — ומפזר אותם לפלטפורמות הפרסום מצד השרת. במקום לבנות חיבור נפרד למטא, לגוגל ולטיקטוק, שולחים אירוע אחד והקונטיינר מטפל בשאר. היתרון גדל ככל שיש יותר יעדים; לעסק עם פלטפורמה אחת הוא לרוב מיותר.
שכבה שיושבת ביניכם לבין הפלטפורמות.
בלי שכבה כזו, כל פלטפורמה מחייבת חיבור משלה. האתר או המערכת צריכים לדעת מה מטא מצפה לקבל, מה גוגל מצפה לקבל, ואיך כל אחת מהן רוצה שהערכים ייראו.
עם שכבה כזו, המקור שולח דבר אחד — קרתה המרה, אלה הפרטים — והקונטיינר הוא זה שיודע לתרגם אותו לכל יעד. הידע על הפלטפורמות עובר ממי ששולח למי שמנתב.
חשוב להבין מה הוא לא: הוא אינו מודד שום דבר בעצמו ואינו מייצר מידע. הוא מקבל את מה שנשלח אליו, ומעביר הלאה.
הדימוי המדויק הוא מרכזייה. שיחה אחת נכנסת, והיא זו שיודעת לאן להעביר אותה ובאיזה נוסח. המרכזייה אינה יודעת יותר מהמתקשר — היא רק חוסכת ממנו להכיר את כל הפנימיות.
וכמו מרכזייה, היא גם נקודת כשל אחת. כשהיא עובדת, הכל זורם דרכה; כשהיא נופלת, אף יעד אינו מקבל דבר. זה שיקול אמיתי, והוא מצדיק שמישהו יהיה אחראי עליה.
שינוי אחד במקום שלושה, ושליטה על מה יוצא לאן.
| חיבור נפרד לכל יעד | דרך הקונטיינר | |
|---|---|---|
| הוספת יעד חדש | חיבור נוסף מאפס | הגדרה בקונטיינר |
| שינוי בשם שדה | בכל חיבור בנפרד | במקום אחד |
| שליטה על מה יוצא | בכל קצה לחוד | מרוכזת |
| מורכבות ההקמה | נמוכה ליעד אחד | גבוהה יותר |
היתרון המעשי מתגלה בתחזוקה ולא בהקמה. כשמשנים שם של שדה בטופס, או מוסיפים סוג המרה חדש, מי שבנה חיבור נפרד לכל פלטפורמה עושה את אותה עבודה שוב ושוב — ושוכח מקום אחד.
יש כאן גם שליטה שקשה להשיג אחרת: אפשר להחליט שיעד מסוים מקבל פחות פרטים מאחר, או שאירוע מסוים לא יוצא אליו בכלל. כשכל חיבור עומד בפני עצמו, החלטות כאלה מתפזרות ואיש אינו יודע מה בדיוק יוצא לאן.
יש גם יתרון שקט בעקביות. כשכל היעדים מקבלים את האירוע מאותו מקור ובאותו רגע, ההבדלים בין הדוחות שלהם נובעים מהם ולא ממה ששלחתם — וזה הופך את ההשוואה ביניהם למועילה יותר.
ולעומת זאת, כשכל חיבור נבנה בנפרד ובזמן אחר, כמעט תמיד מתגלה בסוף שיעד אחד מקבל שדה שהאחר לא מקבל. איש לא החליט על כך; זה פשוט מה שקורה כשאין מקום אחד.
שרת, תת-דומיין, וקונפיגורציה. זה לא "להדביק קוד".
השרת הוא הדרישה שמפתיעה הכי הרבה אנשים. הקונטיינר אינו קטע קוד שיושב בעמוד — הוא תוכנה שרצה במקום כלשהו, וצריך שיהיה לה איפה לרוץ.
תת-הדומיין הוא מה שמאפשר לו לקבל את האירועים תחת הכתובת שלכם ולא תחת כתובת חיצונית. זו הגדרה חד-פעמית, אבל היא דורשת גישה למקום שבו מנוהל הדומיין.
והקונפיגורציה היא העבודה האמיתית: להגדיר אילו אירועים מתקבלים, איך הם נראים, לאן כל אחד מהם נשלח, ומה בדיוק יוצא בכל אחד. זה לא קשה, אבל זה גם לא משהו שנגמר בהעתקה של קטע קוד לעמוד.
וזו גם הסיבה שהמעבר אינו מיידי. יש שלב שבו החיבורים הישנים עדיין פועלים והחדש כבר פועל, וצריך להחליט מתי מכבים את הישן — אחרת אותו אירוע יוצא פעמיים.
מבחינת מי שמתחזק, זו אינה עבודה יומיומית אבל היא גם לא נגמרת בהקמה. כל שינוי במה שנשלח, בכל אחד מהיעדים, מתורגם לשינוי בקונטיינר — ומישהו צריך להיות זה שעושה אותו.
השורה התחתונה של הסעיף הזה היא ציפייה נכונה: זה פרויקט קטן, לא הגדרה. מי שניגש אליו כאילו מדובר בהדבקת קוד יגלה את זה באמצע.
SGTM אינו משפר מדידה בפני עצמו. הוא צינור. אם האירועים שנכנסים אליו חסרים מזהי קליק או פרטי זיהוי — הוא יפזר בדיוק את אותו חוסר לשלוש פלטפורמות במקום לאחת.
זו הטעות היקרה ביותר בתחום, כי היא נראית כמו התקדמות. מקימים שרת, מגדירים קונטיינר, האירועים זורמים — ואיכות ההתאמה נשארת בדיוק איפה שהייתה.
הסיבה פשוטה: איכות המדידה נקבעת במקור, לא בדרך. אם מזהה הקליק לא נשמר על הפנייה כשהיא נכנסה, שום שכבת ניתוב לא תמציא אותו.
אותו היגיון חל גם בכיוון ההפוך. אם הנתונים שנכנסים שלמים, הם היו משפרים את השיוך גם בלי שכבת ביניים — הקונטיינר לא הוסיף להם דבר, הוא רק חסך עבודה בדרך.
ולכן הסימן שמישהו התבלבל הוא כשהשאלה הראשונה שנשאלת היא אצל איזה ספק להקים קונטיינר. השאלה הראשונה צריכה להיות מה בדיוק ייכנס אליו, וממי.
לכן הסדר הנכון הוא הפוך ממה שרוב האנשים עושים: קודם לוודא שמה שנכנס שלם — מזהי הקליק ופרטי הזיהוי — ורק אחר כך לשאול איך מפזרים אותו ליעדים.
המערכת שולחת לכתובת הקונטיינר, והוא מנתב. מה שקובע זה ששמות השדות יישארו יציבים.
מבחינת המערכת שלכם זה נראה כמו יעד אחד במקום כמה. במקום להכיר את מטא ואת גוגל בנפרד, היא שולחת לכתובת אחת ומפסיקה להתעניין במה שקורה אחריה.
בזכות זה אפשר להוסיף או להחליף יעד בלי לגעת במערכת בכלל. השינוי מתרחש בקונטיינר, והמקור ממשיך לשלוח בדיוק את מה ששלח קודם.
מה שכן קריטי הוא היציבות של השמות. הקונטיינר מזהה כל שדה לפי שמו, ושינוי שם שנראה תמים במערכת מפיל את המיפוי בשקט — האירוע ימשיך לצאת, בלי השדה שהשתנה.
לכן שווה להסכים על שמות השדות פעם אחת ולהתייחס אליהם כאל חוזה. מי שמשנה שם במערכת צריך לדעת שהוא נוגע במשהו שמישהו אחר מסתמך עליו.
וכשמשהו כן משתנה, הדרך היחידה לגלות היא לבדוק את היעד ולא את המקור. הקונטיינר ימשיך לדווח שהוא שלח, והפלטפורמה היא זו שתראה שהגיע אליה פחות ממה שציפתה.
שווה למי שמפרסם בכמה פלטפורמות. לא שווה למי שרק התחיל.
ההיגיון הוא היגיון של חזרתיות. כשיש יעד אחד, שכבת ביניים מוסיפה עבודה בלי לחסוך אותה. כשיש כמה, היא חוסכת את אותה עבודה שוב ושוב, וגם מונעת את המצב שבו יעד אחד נשאר מאחור.
ולכן השאלה הראשונה אינה "כמה זה טוב" אלא "כמה יעדים יש". עסק שמפרסם במקום אחד, בתקציב קטן, ואין לו מי שיתחזק את השרת — יקבל יותר מהשקעת אותו זמן בשלמות של מה שנכנס למדידה.
ויש גם דרך ביניים שקל לפספס: אפשר להתחיל בדיווח ישיר מהמערכת ליעד אחד, ולעבור לשכבת ביניים רק כשמצטרף היעד השני או השלישי. זה אינו צעד שמבטלים אותו אחר כך — מה שנבנה נכון במקור ממשיך לשמש.
וכך ההשקעה מתחלקת לפי הצורך: עסק שרק התחיל משקיע בשלמות של מה שנמדד, ועסק שכבר מפזר לכמה מקומות משקיע בדרך שבה זה מפוזר.
ומי שכבר מפרסם בכמה מקומות בדרך כלל יודע את זה בעצמו, כי הוא כבר מכיר את הכאב: אותו שינוי, שלוש פעמים, ופעם אחת ששכחו.
ככה עושים את זה ידנית.
וככה זה נראה כשהמערכת עושה את זה בשבילך.