מה זה Google tag gateway ומה הוא משנה?
בהטמעה רגילה הדפדפן מבקש את הסקריפט של התג מדומיין של Google ושולח את אירועי המדידה ישירות ל-Google. עם ה-gateway שני הדברים עוברים דרך הדומיין שלכם. לפי מרכז העזרה, התג נטען מהדומיין שלכם ושולח את אירועי המדידה לדומיין שלכם, שמעביר אותם הלאה ל-Google.
התיעוד למפתחים מגדיר את זה כפריסה של Google tag על תשתית צד ראשון משלכם, שמתארחת על הדומיין של האתר. ארבעת היתרונות שמופיעים שם הם שיפור בהמרות הנמדדות, צמצום הפניות לצד שלישי, פרטיות כברירת מחדל והקמה אוטומטית.
מספר אחד כן מופיע, בעמוד ההכרזה שבמרכז העזרה של Google Ads: מפרסמים שהגדירו את ה-gateway ראו עלייה של 11% באותות (signals). לפי הערת השוליים שם, זה חציון של 7 ימים מנתוני Google מאפריל 2025, שמשווה טעינות של סקריפט התג עם gateway ובלי. כלומר זה נתון על טעינות של התג ולא הבטחה ל-11% יותר המרות בחשבון שלכם. מי שמבטיח אחוז שיפור מסוים בהמרות לא מסתמך על התיעוד.
מה שלא משתנה: התגים עצמם, הטריגרים וההגדרות בקונטיינר. ה-gateway מחליף את הדרך שבה הסקריפט והבקשות נוסעים, לא את מה שנמדד.
איך זה עובד מאחורי הקלעים?
בוחרים נתיב שמור בדומיין, בדוגמאות של Google זה /metrics/. ה-CDN או ה-load balancer מעביר כל בקשה לנתיב הזה אל כתובת של Google שבנויה ממזהה התג, בתבנית כמו G-12345.fps.goog או gtm-abcdef.fps.goog לקונטיינר. הבקשה המועברת צריכה לשאת כותרת Host עם אותה כתובת.
יש כאן פרט שקל לפספס. לפי מרכז העזרה, בתצורה הזאת Google מקבלת את כתובת ה-IP של ה-CDN שלכם ולא את הכתובת המקורית של המשתמש. לכן ה-CDN חייב לצרף כותרות מיקום. האפשרות המועדפת היא X-Forwarded-CountryRegion בפורמט ISO 3166-2. החלופה היא הצמד X-Forwarded-Country ו-X-Forwarded-Region. בלי הכותרות Google לא יכולה לקבוע במדויק את האזור של המשתמש. התוצאה היא נתוני מיקום לא מדויקים בדוחות ובעיה אפשרית בברירות מחדל אזוריות של Consent Mode.
מסלול הבקשה
איך תג ואירוע עוברים דרך הדומיין שלכם
מה ה-gateway לא עושה?
ארבע מגבלות שמופיעות בתיעוד וכדאי להכיר לפני שמחליטים.
הראשונה היא עוגיות. לפי מרכז העזרה, ה-gateway מעבד רק עוגיות צד ראשון של Google שנדרשות למדידה. עוגיות צד ראשון אחרות שמועברות דרכו נזרקות. השנייה היא האזור הכלכלי האירופי: עבור משתמשים שם, נתוני המדידה של Google Analytics נשלחים ישירות לנקודות קצה אזוריות של Google. לפי אותו עמוד, החריג הזה לא חל על המרות של Google Ads.
השלישית היא תגית noscript. ה-gateway לא תומך בה, כך שקטע ה-noscript נשאר עם הכתובת הרגילה של googletagmanager.com. הרביעית היא הנתיב עצמו: ההגדרה מנתבת את כל התנועה לנתיב שנבחר, לכן הוא חייב להיות נתיב שלא נמצא בשימוש באתר, שאינו נתיב השורש ושאורכו עד 100 תווים.
מה ההבדל בין tag gateway ל-Server-Side GTM?
השאלה שאני שומע הכי הרבה מלקוחות היא אם זה מחליף מדידה בצד שרת. התשובה הקצרה היא לא: ה-gateway הוא ניתוב, בעוד שקונטיינר שרת הוא מקום שבו אירועים מתקבלים, מעובדים ונשלחים הלאה.
| נושא | Google tag gateway | Server-Side GTM |
|---|---|---|
| מה זה | טעינת התג ושליחת המדידה דרך נתיב בדומיין שלכם | קונטיינר שרת שמקבל אירועים ומריץ תגים בצד השרת |
| איפה זה רץ | ב-CDN, ב-load balancer או בשרת האתר הקיים | בשרת תיוג ייעודי עם דומיין מותאם |
| מה נדרש | תג קיים באתר וגישה לתשתית שמנתבת בקשות | קונטיינר שרת, שרת תיוג והגדרת דומיין |
| למי מתאים | אתר עם CDN שרוצה הקשר של צד ראשון לתגי Google | מי שצריך שליטה בנתונים ושליחה לפלטפורמות מהשרת |
השניים לא מתחרים. התיעוד למפתחים מציג שני צעדים למי שעובד עם קונטיינר שרת: מיפוי דומיין מותאם לשרת התיוג וטעינת הסקריפטים דרך ה-gateway. ההמלצה שם היא להשלים את שניהם כדי לקבל את ההטמעה העמידה ביותר. מתי בכלל שווה להקים קונטיינר שרת הסברנו במתי צריך מדידה בצד שרת. את ההקמה עצמה פירטנו בהקמת Server-Side GTM.
באיזה מסלול הקמה לבחור?
מרכז העזרה של Google Ads מציג סדרת שאלות שמובילה למסלול המתאים. הסדר הוא זה:
| המצב שלכם | המסלול לפי Google |
|---|---|
| יש Server-Side GTM | מפעילים את ה-gateway בקונטיינר השרת |
| האתר ב-Google Cloud מאחורי Load Balancer | מפעילים ישירות מההגדרות של Google Cloud |
| האתר בנוי ומאוחסן ב-Webflow | הנחיות ייעודיות ל-Webflow |
| CDN כמו Akamai, Cloudflare או Fastly, עם תג אחד או קונטיינר אחד | האינטגרציה של ה-CDN |
| CDN עם כמה קונטיינרים | הקמה עצמית |
| אין גישה ל-CDN | לפי העמוד, אי אפשר לאמץ את ה-gateway |
ההבדל המעשי בין אינטגרציה להקמה עצמית הוא הקוד באתר. ב-Cloudflare, לפי מרכז העזרה, ההקמה האוטומטית מגדירה את הסקריפטים בעצמה ואין צורך לתייג מחדש את האתר. ההקמה המודרכת כן דורשת להחליף את מקור הסקריפט בכל העמודים. סייג אחד מאותו עמוד: מי שמשתמש ב-Consent Mode חייב לכבות את הגדרת הסקריפטים האוטומטית ולתייג בעצמו. את ההגדרה מוצאים תחת Admin בהגדרות של Google tag, באפשרות Google tag gateway.
ב-Google Cloud נדרש Global External Application Load Balancer, כי לפי העמוד הייעודי ה-Application Load Balancer הקלאסי לא נתמך. האינטגרציה עצמה ללא עלות ומשלמים רק על השימוש הרגיל ב-Load Balancer.
איך מקימים ידנית, צעד אחר צעד?
זה המסלול למי שה-CDN שלו לא מזוהה או שיש לו כמה קונטיינרים. התנאים המקדימים לפי התיעוד: Google tag או קונטיינר GTM שכבר מותקן באתר ותשתית שיודעת להעביר בקשות ליעד חיצוני.
- בוחרים נתיב מדידה. נתיב ייחודי שלא בשימוש. תגים באותו קונטיינר GTM צריכים הקמה אחת. קונטיינרים נפרדים או תגים עצמאיים צריכים נתיב לכל אחד.
- מגדירים origin ל-Google. יוצרים יעד לכתובת של התג בדומיין fps.goog ודורסים את כותרת ה-Host כך שתתאים לה.
- מעבירים את כל מה שהתג צריך. לפי התיעוד מעבירים את כל העוגיות ואת כל פרמטרי הכתובת. מוסיפים את כותרות המיקום.
- יוצרים כלל ניתוב לנתיב. כלל כמו
/metrics/*שמקבל עדיפות על כלל ברירת המחדל. - מחליפים את מקור הסקריפט באתר. בכל עמוד, הסקריפט נטען מהנתיב החדש במקום מ-www.googletagmanager.com. קטע ה-noscript נשאר כמו שהוא.
- בודקים. רק אחרי שהבדיקות עוברות מפרסמים לכל האתר.
איך בודקים שה-gateway עובד?
התיעוד נותן שלוש בדיקות. שתי הראשונות הן כתובות שפותחים בדפדפן ושתיהן אמורות להחזיר את המילה ok, כשהשנייה מאשרת שנתוני המיקום עוברים:
https://example.com/metrics/healthy
https://example.com/metrics/?validate_geo=healthyהבדיקה השלישית היא ב-Tag Assistant. פותחים תצוגה מקדימה של הקונטיינר, מפעילים אירועים ובודקים תחת Summary, Output, Hits Sent שהבקשות נשלחות לנתיב המדידה שלכם. בממשק ההקמה כל דומיין מקבל סטטוס: First-party כשהוא פעיל, Not started, Paused או Pending. לפי מרכז העזרה, Pending פירושו שה-gateway הופעל אבל עוד לא התקבל מידע אבחוני. איך עובדים עם תצוגה מקדימה באופן כללי הסברנו במצב Preview ו-Tag Assistant ב-GTM.
מה כדאי לבדוק לפני שמפעילים?
הדבר הראשון הוא הסכמה. מרכז העזרה מציין שהפעלת התכונה משפיעה על התנהגות ההפעלה של תגי Google, לכן ההמלצה שם, אם התגים שלכם תלויים בהסכמת המשתמש, היא לאמץ Consent Mode ולעבור על הגדרות ההסכמה. מי שעוד לא החליט איך להטמיע הסכמה יכול להתחיל בעץ ההחלטה ל-Consent Mode.
הדבר השני הוא בעלות. ההקמה נוגעת ב-CDN או ב-load balancer, כלומר בתשתית שצוות השיווק בדרך כלל לא מנהל. לפני שמתחילים צריך לדעת מי מחזיק בהרשאות, מי מאשר שינוי בכללי הניתוב ומי יתחזק את הכלל הזה כשהאתר יעבור תשתית.
שאלות נפוצות
מה זה Google tag gateway for advertisers?
זאת דרך לטעון את Google tag או את קונטיינר GTM מהדומיין שלכם במקום מדומיין של Google. לפי התיעוד של Google, התג נטען מנתיב באתר שלכם ושולח את אירועי המדידה לאותו דומיין, שמעביר אותם ל-Google. ההעברה נעשית ב-CDN, ב-load balancer או בשרת האתר הקיים.
האם Google tag gateway מחליף Server-Side GTM?
לא. ה-gateway מנתב את הסקריפט ואת בקשות המדידה דרך הדומיין שלכם. קונטיינר שרת מקבל אירועים ומריץ תגים בצד השרת. התיעוד של Google למפתחים ממליץ למי שעובד עם קונטיינר שרת להשלים את שני הצעדים, מיפוי דומיין מותאם וטעינת הסקריפטים דרך ה-gateway, כדי לקבל את ההטמעה העמידה ביותר.
מה צריך כדי להקים Google tag gateway?
לפי התיעוד צריך Google tag או קונטיינר GTM שכבר מותקן באתר, לצד CDN או load balancer שיודע להעביר בקשות ליעד חיצוני. בוחרים נתיב שלא נמצא בשימוש באתר, שאינו נתיב השורש ושאורכו עד 100 תווים. לפי מרכז העזרה של Google Ads, מי שאין לו גישה ל-CDN לא יכול לאמץ את ה-gateway.
למה צריך כותרות מיקום ב-Google tag gateway?
כי בתצורה הזאת Google מקבלת את כתובת ה-IP של ה-CDN ולא את הכתובת המקורית של המשתמש. לפי מרכז העזרה, ה-CDN צריך לצרף את הכותרת X-Forwarded-CountryRegion או את הצמד X-Forwarded-Country ו-X-Forwarded-Region. בלעדיהן נתוני המיקום בדוחות עלולים להיות לא מדויקים. גם ברירות מחדל אזוריות של Consent Mode עלולות להיפגע.
איך בודקים ש-Google tag gateway עובד?
לפי התיעוד פותחים בדפדפן את נתיב המדידה עם הסיומת healthy ואת אותו נתיב עם הפרמטר validate_geo=healthy. שתי הכתובות אמורות להחזיר ok. אחר כך פותחים את Tag Assistant, מפעילים אירועים ובודקים תחת Summary, Output, Hits Sent שהבקשות נשלחות לנתיב המדידה שלכם.
האם צריך לשנות את הקוד באתר כדי להפעיל את ה-gateway?
תלוי במסלול. לפי מרכז העזרה, בהקמה האוטומטית עם Cloudflare הסקריפטים מוגדרים אוטומטית ואין צורך לתייג מחדש את האתר. בהקמה מודרכת או ידנית מחליפים בכל העמודים את מקור הסקריפט לנתיב המדידה החדש. קטע ה-noscript נשאר עם הכתובת של googletagmanager.com, כי ה-gateway לא תומך בו.
מה השורה התחתונה?
Google tag gateway הוא שינוי תשתית קטן יחסית: נתיב אחד בדומיין שלכם שמעביר את תגי Google ואת המדידה שלהם בהקשר של צד ראשון. הוא לא מחליף קונטיינר שרת ולא פותר לבד בעיות של הסכמה או של איכות נתונים. אם יש לכם CDN נתמך וגישה אליו, ההקמה האוטומטית היא נקודת פתיחה סבירה. אם יש כמה קונטיינרים או תשתית מורכבת, ההקמה הידנית דורשת תיאום עם מי שמנהל את ה-CDN ובדיקה מסודרת של כותרות המיקום. אנחנו מלווים הקמות כאלה כחלק משירות מדידה מתקדמת, כולל בדיקה שהמספרים לא השתנו אחרי המעבר. אם אתם שוקלים את המעבר ולא בטוחים איזה מסלול מתאים לתשתית שלכם, כתבו לנו.
מקורות
Google for Developers: Google tag gateway for advertisers, Google for Developers: Set up Google tag gateway for advertisers, Google Ads Help: Enhance your conversion measurement and ad performance with Google tag gateway for advertisers, Google Ads Help: Google tag gateway for advertisers implementation flow, Google Ads Help: How Google tag gateway for advertisers sets location, Google Ads Help: Set up Google tag gateway for advertisers in the Google tag with Cloudflare, Tag Manager Help: Set up Google tag gateway for advertisers with Google Cloud Load Balancer
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי