מה מקימים בפועל כשמקימים Server-Side GTM?
לפי התיעוד של Google, קונטיינר שרת רץ על שרת שבשליטתכם ולא בדפדפן של הגולש. הוא מקבל בקשות מהמכשירים של הגולשים, הופך אותן לאירועים ומפעיל עליהם את אותו מודל שמוכר מקונטיינר רגיל: תגים, טריגרים ומשתנים. התיעוד מחלק את העבודה לשני שלבים. הראשון הוא הקמת שרת תיוג. השני הוא הגדרת התיוג עצמו: דומיין משלכם, הפניית התגים ובדיקה.
המדריך הזה עוסק רק בהקמה. השאלה אם בכלל כדאי לכם לעבור לצד שרת, כולל עלויות האירוח וההשוואה בין ספקים, נמצאת במדריך מתי צריך מדידה בצד שרת.
מסלול של בקשה אחת
מהדפדפן ועד הפלטפורמה, דרך קונטיינר השרת
איך יוצרים קונטיינר שרת ומה ההבדל בין הקצאה אוטומטית לידנית?
ב-Tag Manager בוחרים Create Container, נותנים שם, בוחרים Server ולוחצים Create. נפתח מסך הקמה עם שתי אפשרויות: Automatically provision tagging server להקצאה אוטומטית ו-Manually provision tagging server להקצאה ידנית. אם סגרתם אותו, אפשר לחזור אליו בלחיצה על מזהה הקונטיינר.
| נושא | הקצאה אוטומטית | הקצאה ידנית |
|---|---|---|
| מה קורה | Tag Manager פורס שרת תיוג ב-Cloud Run ומוסיף את הדומיין שלו ככתובת השרת | מקבלים מחרוזת Container Config ופורסים בעצמכם את ה-image של Google |
| מה צריך | חשבון Google Cloud עם חשבון חיוב והרשאות Project Creator ו-Billing Account User | סביבה שמריצה Docker, אצל כל ספק |
| אזור | תמיד us-central1 | לבחירתכם |
| תצורה | תצורת בדיקה. משנים אותה אחר כך ב-Cloud Run | אתם מגדירים שרת Preview ואשכול שרתי תיוג |
| מגבלה | אפשר להריץ את ההקצאה האוטומטית פעם אחת בלבד | כתובת HTTPS, איזון עומסים וקנה מידה באחריותכם |
בהקמה ידנית התיעוד מגדיר שני סוגי שרתים מאותו image. שרת Preview מפעיל את מצב התצוגה המקדימה של הקונטיינר: מריצים ממנו מופע אחד בדיוק, עם המשתנה RUN_AS_PREVIEW_SERVER. שרתי התיוג מטפלים בתנועה החיה, כשכל אחד מהם מקבל את אותו CONTAINER_CONFIG ואת PREVIEW_SERVER_URL שמצביע על שרת ה-Preview. התיעוד מדבר על אשכול של שרתי תיוג ולא על שרת בודד וקובע שלכל שרת יהיה לכל היותר vCPU אחד.
מה זה Client ובמה הוא שונה מתג?
Client הוא המתאם בין מה שרץ במכשיר של הגולש לבין הקונטיינר. לפי התיעוד הוא עושה ארבעה דברים: תופס את הבקשה, הופך אותה לאירוע אחד או יותר, מריץ עליהם את התגים, הטריגרים והמשתנים ואורז את התשובה שחוזרת למכשיר.
כל בקשה עוברת על ה-Clients לפי סדר עדיפות, כשב-Priority מספר גבוה יותר רץ קודם. ה-Client הראשון שמתאים לבקשה הופך ל-Client הפעיל שלה, כי רק Client אחד יכול לתפוס בקשה. לפי התיעוד ה-Client של Google Analytics מותקן מראש בכל קונטיינר שרת, כך שלאתר שמודד עם GA4 אין כאן מה להוסיף.
ההבדל מתג: Client מקבל נתונים, תג שולח אותם. תג בקונטיינר השרת לא יודע מאיפה הגיע האירוע: הוא רואה נתוני אירוע ונורה לפי טריגר. כדי להשתמש בפרמטר מסוים מהאירוע בתג אחר, יוצרים משתנה מסוג Event Data ומזינים את שם הפרמטר ב-Key Path. אירועים שלא מגיעים מאתר, למשל משרת או מאפליקציה, נכנסים דרך Client מסוג Measurement Protocol שמוסיפים ידנית ומגדירים לו Activation Path. את הפורמט עצמו פירטנו במדריך Measurement Protocol של GA4.
איזו כתובת נותנים לשרת: same origin, תת דומיין או ברירת המחדל?
שרת תיוג חדש מקבל כתובת מספק הענן. לפי התיעוד, בכתובת הזאת הנתונים מגיעים לקונטיינר אבל השרת רץ בהקשר צד שלישי. כדי לקבל את היתרונות של הקשר צד ראשון, כמו עוגיות עמידות יותר, השרת והאתר חייבים לרוץ על אותו דומיין.
| האפשרות | עוגיות שמוגדרות מהשרת | מה נדרש להקמה |
|---|---|---|
| Same origin, ההמלצה של Google. לדוגמה www.example.com/metrics | גישה מלאה ליתרונות האבטחה והעמידות | CDN או load balancer שמעביר בקשות לפי נתיב. לפעמים גם שינוי DNS |
| תת דומיין. לדוגמה metrics.example.com | גישה מלאה ליתרונות האבטחה והעמידות | עדכון רשומות DNS |
| דומיין ברירת המחדל. לדוגמה metrics.run.app | אין. רק עוגיות JavaScript | מוגדר מראש |
למה עוגייה שמוגדרת מהשרת שונה מעוגיית JavaScript, בעיקר ב-Safari, הסברנו במדריך ITP של Safari ועוגיות צד ראשון.
איך מחברים תת דומיין לשרת התיוג?
אלה השלבים שבתיעוד לשרת שרץ ב-Google Cloud. תת הדומיין חייב להיות שונה מזה שמגיש את האתר.
- ממפים את תת הדומיין לשירות. ב-Google Cloud Console פותחים Custom Domains בהגדרות השירות ולוחצים Add a custom domain. מוודאים שאתם בפרויקט שתואם למזהה הקונטיינר.
- מאמתים בעלות. אם הדומיין עוד לא מאומת, בוחרים Verify a new domain, מזינים את תת הדומיין ומשלימים את האימות.
- מוסיפים רשומות DNS. אצל רשם הדומיין מוסיפים את הרשומות שמוצגות בלשונית Custom Domains, מסוג A או AAAA. בשם הרשומה מזינים רק את תת הדומיין, למשל metrics.
- ממתינים להפצה. לפי התיעוד השינוי נכנס לתוקף בדרך כלל תוך דקות, אבל זה יכול לקחת כמה שעות. הנפקת תעודת ה-SSL יכולה לקחת עד שעה.
- מעדכנים את הכתובת ב-Tag Manager. בקונטיינר השרת, Admin ואז Container Settings, מדביקים את הכתובת בשדה Server container URL ושומרים.
- בודקים. לוחצים Preview. אם חלון הדיבוג נפתח, המיפוי עובד.
התיעוד מוסיף המלצה לפריסות Cloud Run: להשתמש ב-global external Application Load Balancer. באפשרות same origin העבודה נעשית ב-CDN או ב-load balancer במקום ב-DNS. בוחרים נתיב פנוי כמו /metrics ומנתבים את כל התנועה שמתחילה בו לשרת התיוג. לפי התיעוד הנתיב לא יכול להכיל את המחרוזת /gtm. צריך להעביר את כל העוגיות ואת מחרוזות השאילתה ולהגדיר את כותרת ה-Host לדומיין של שרת התיוג. ב-Container Settings מוחקים כתובות קודמות ומזינים את הכתובת המלאה כולל הנתיב, כי כל כתובות השרת חייבות לחלוק את אותו נתיב.
איך מפנים את התגים באתר אל השרת?
השרת קיים, אבל שום דבר לא יגיע אליו עד שהתג באתר ידע את הכתובת. ב-Google Tag Manager זה נעשה כך:
- יוצרים משתנה תצורה. בקונטיינר האתר יוצרים משתנה מסוג Google tag: Configuration settings ומוסיפים פרמטר בשם server_container_url. הערך הוא כתובת קונטיינר השרת.
- משייכים את המשתנה ל-Google tag. בתג, תחת Configuration settings, בוחרים את המשתנה.
- קובעים טריגר מוקדם. התיעוד מגדיר את הטריגר Initialization - All pages, כדי שהתג ירוץ לפני שאר הטריגרים.
- שומרים ומפרסמים. שומרים את התג ומפרסמים את קונטיינר האתר.
באתר שעובד עם gtag.js בלי Tag Manager מוסיפים את אותו מפתח לפקודת config:
gtag('config', 'TAG_ID', {
'server_container_url': 'https://analytics.example.com',
});שתי נקודות שהתיעוד מוסיף. הראשונה: Google ממליצה לשלוח את הנתונים לשרת דרך תג Google Analytics בעמוד. התג משתמש בכמה שיטות שליחה, ביניהן image pixel, Fetch API ו-service worker שנטען ב-iframe מהדומיין של השרת. לכן באתר עם Content Security Policy צריך להתיר את כתובת השרת בהנחיות img-src, connect-src ו-frame-src. השנייה: כדי לעבוד בהקשר צד ראשון מלא צריך גם לטעון את הסקריפטים של Google מהתשתית שלכם. זה נושא נפרד שפירטנו במדריך Google tag gateway.
איך בודקים שהשרת מקבל ושולח נתונים?
הבדיקה הראשונה היא בדיקת הבריאות: מוסיפים /healthy לכתובת השרת ופותחים בדפדפן. לפי התיעוד התשובה צריכה להיות ok.
הבדיקה השנייה היא מצב Preview של קונטיינר השרת. בצד שמאל מופיעות הבקשות הנכנסות. אם ה-Client שתפס את הבקשה יצר נתוני אירוע, האירועים מופיעים מתחתיה. בלשונית Request יש שלושה חלקים: Client מראה מי תפס את הבקשה, Incoming HTTP Request מראה את הבקשה המלאה ואמור להתאים למה שרואים בלשונית Network בדפדפן, Outgoing HTTP Requests מראה כל בקשה שתג שלח לספק ואת התשובה שחזרה, כולל קוד הסטטוס. הלשוניות Tags, Variables, Event Data ו-Console משלימות את התמונה: אילו תגים נורו, מה היו ערכי המשתנים, אילו שגיאות נרשמו.
אם בקשות לא מופיעות ב-Preview, התיעוד מפנה לשלוש בדיקות: שהפריסה באמת מקבלת תנועה לפי הלוגים בענן, שה-CDN או ה-load balancer מעביר עוגיות ושיש שרת Preview אחד בלבד. אם בקשות מגיעות אבל אף Client לא תופס אותן, בודקים שהכתובת ב-Container Settings כוללת את הנתיב שהוגדר.
מה צריך לסדר לפני שעולים לפרודקשן?
ההקצאה האוטומטית יוצרת תצורת בדיקה. לפי מדריך ההקמה של Google ל-Cloud Run, המינימום המומלץ לתנועה חיה הוא שני מופעים, כדי לצמצם את הסיכון לאובדן נתונים בזמן תקלה. הדוגמה בתיעוד מגדירה מינימום של 2 ומקסימום של 10 מופעים. את השינוי עושים ב-Cloud Run בפעולה Edit & Deploy New Revision.
עוד שלושה דברים. לוגים: התיעוד מזהיר שרישום בקשות יכול לעלות כסף משמעותי מעל מיליון בקשות בחודש ומסביר איך לכבות אותו ב-Logs Router. עדכונים: שרת התיוג לא מתעדכן לבד. פורסים גרסה חדשה של ה-image באותן הגדרות, לפחות בכל גרסה ראשית, כש-Tag Manager מבקש. התראת חיוב: התיעוד ממליץ להגדיר אחת כדי לא לגלות חריגה בדיעבד.
רק אחרי שהתשתית יציבה מוסיפים תגים של פלטפורמות. לדוגמה, אירועי מטא שנשלחים גם מהדפדפן וגם מהשרת דורשים מזהה משותף, כפי שהסברנו במדריך Meta Conversions API לצד הפיקסל.
שאלות נפוצות
מה זה קונטיינר שרת ב-Google Tag Manager?
לפי התיעוד של Google, קונטיינר שרת רץ על שרת שבשליטתכם ולא בדפדפן של הגולש. הוא מקבל בקשות מהמכשירים של הגולשים, הופך אותן לאירועים ומפעיל עליהם תגים, טריגרים ומשתנים כמו בקונטיינר רגיל. יוצרים אותו ב-Tag Manager דרך Create Container ובחירה בסוג Server.
מה זה Client ב-Server-Side GTM?
Client הוא מתאם בין המכשיר של הגולש לקונטיינר השרת. לפי התיעוד הוא תופס בקשה נכנסת, הופך אותה לאירוע אחד או יותר, מריץ עליהם את התגים ואורז את התשובה שחוזרת. ה-Clients רצים לפי Priority, מספר גבוה קודם. רק Client אחד תופס כל בקשה. ה-Client של Google Analytics מותקן מראש.
למה צריך דומיין צד ראשון לשרת התיוג?
לפי התיעוד של Google, שרת על הדומיין של ספק הענן רץ בהקשר צד שלישי ויכול להגדיר רק עוגיות JavaScript. כדי לקבל את יתרונות האבטחה והעמידות של עוגיות שמוגדרות מהשרת, השרת והאתר חייבים לרוץ על אותו דומיין. Google מגדירה same origin, כלומר נתיב על הדומיין הראשי, כשיטה המומלצת. תת דומיין נותן את אותה גישה לעוגיות בהקמה פשוטה יותר.
מה ההבדל בין same origin לתת דומיין ב-Server-Side GTM?
ב-same origin השרת יושב על נתיב בדומיין של האתר, למשל www.example.com/metrics. זה דורש CDN או load balancer שמנתב את הנתיב לשרת התיוג. בתת דומיין השרת יושב על כתובת כמו metrics.example.com ונדרש רק עדכון רשומות DNS. לפי התיעוד שתי האפשרויות נותנות גישה מלאה ליתרונות של עוגיות מהשרת.
איך מפנים את התגים באתר לקונטיינר השרת?
בפרמטר server_container_url. ב-Google Tag Manager יוצרים משתנה מסוג Google tag: Configuration settings עם הפרמטר הזה, משייכים אותו ל-Google tag ומפעילים את התג בטריגר Initialization - All pages. ב-gtag.js מוסיפים את אותו מפתח לפקודת config עם הכתובת של קונטיינר השרת.
איך בודקים שקונטיינר השרת עובד?
שתי בדיקות. הראשונה: פותחים את כתובת השרת עם הסיומת healthy. לפי התיעוד התשובה צריכה להיות ok. השנייה: מצב Preview של קונטיינר השרת, שמציג כל בקשה נכנסת, איזה Client תפס אותה, אילו תגים נורו ומה נשלח בכל בקשה יוצאת לספק, כולל קוד הסטטוס שחזר.
מה השורה התחתונה?
הקמה של Server-Side GTM היא לא לחיצה על Automatically provision: הלחיצה הזאת נותנת רק שרת בדיקה על דומיין של ספק הענן. מערך שעובד באמת דורש עוד שלושה דברים: כתובת על הדומיין שלכם, תגים באתר שמופנים אליה ו-Client שתופס את הבקשות. את שלושתם בודקים ב-Preview של קונטיינר השרת לפני שמוסיפים תג אחד של פלטפורמת פרסום. מי שמדלג על שלב הדומיין משלם על שרת ולא מקבל את היתרון של עוגיות שמוגדרות מהשרת. אנחנו מקימים ומתחזקים מערכים כאלה כחלק משירות מדידה מתקדמת, כולל הדומיין, התגים בשרת ו-Consent Mode. אם יש לכם קונטיינר שרת שהוקם ואף אחד לא בטוח מה עובר דרכו, כתבו לנו.
מקורות
Google for Developers: An introduction to server-side tagging, Google for Developers: Set up server-side tagging with Cloud Run, Google for Developers: Manual setup guide, Google for Developers: Custom domain configuration, Google for Developers: Send data to server-side Tag Manager, Google for Developers: Preview and debug server containers
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי