Google Tag Gateway ומצב First-Party: המדריך למדידה בעולם ללא קוקיז

הבעיה שאף אחד לא סיפר לכם עליה: המדידה שלכם דולפת

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

הסיבה הטכנית פשוטה, וקיימת כמעט בכל אתר בישראל. כשגולש נכנס לאתר שלכם, הדפדפן שלו טוען את תגיית גוגל (Google Tag, מה שהיה פעם gtag.js) מדומיין של גוגל, בדרך כלל googletagmanager.com. אחרי שהתגית נטענת, היא שולחת את בקשות המדידה, צפיות, אירועים, המרות, חזרה לשרתים של גוגל, שוב דרך דומיין של גוגל.

וכאן מתחיל האיבוד. חוסמי פרסומות, הרחבות פרטיות בדפדפן, רשימות סינון ברמת ה-DNS ומנגנוני הגנה מובנים בדפדפנים כמו Safari ו-Firefox מזהים את הבקשה לדומיין של גוגל ופשוט חוסמים אותה. מבחינת הדפדפן זו בקשה של "צד שלישי", וצד שלישי היום נחסם כברירת מחדל אצל חלק גדל והולך מהגולשים. הקוקי שגוגל מנסה לשמור בהקשר הזה מוגבל בתוחלת חיים קצרה, לפעמים שבעה ימים ולפעמים פחות, בגלל מנגנון ה-ITP של אפל. התוצאה: חלון הייחוס מתקצר, ההמרות שחוזרות אחרי כמה ימים לא מיוחסות, והאלגוריתם של גוגל מקבל פחות אותות לעבוד איתם.

מי שמנהל קמפיינים לפי ההנחה ש"מה שהמערכת מציגה זה מה שקרה" עובד עם מפה חלקית. ה-Smart Bidding של גוגל לומד מהאותות שהוא מקבל. פחות אותות, פחות המרות מיוחסות, אופטימיזציה חלשה יותר, מחיר גבוה יותר לכל לקוח. זו לא בעיה שיווקית, זו בעיה בתשתית המדידה. ופה בדיוק נכנס Google Tag Gateway.

מה זה Google Tag Gateway ומצב First-Party

Google Tag Gateway (בעבר נקרא First-Party Mode) הוא מנגנון שמאפשר להגיש את תגיות גוגל ולשלוח את בקשות המדידה דרך התשתית והדומיין שלכם, במקום דרך הדומיין של גוגל. גוגל השיקה אותו באופן רשמי במאי 2025, והוא חינמי לחלוטין.

הרעיון פשוט להסבר וחכם בביצוע. במקום שהדפדפן יפנה ל-googletagmanager.com, הוא פונה לכתובת על הדומיין שלכם, למשל example.co.il/metrics. התשתית שלכם, ה-CDN או ה-load balancer, מקבלת את הבקשה בנתיב הזה ומעבירה אותה מאחורי הקלעים לשרת של גוגל שמחזיק את מכל התגיות של האתר. גוגל מעבד את הבקשה ומחזיר תשובה לדפדפן, שוב דרך אותו נתיב ואותו דומיין. מבחינת הדפדפן, כל התקשורת קורית מול הדומיין שאתם נמצאים בו כרגע. זה צד ראשון לכל דבר.

מה זה משנה בפועל? שלושה דברים קורים ברגע שהבקשה נראית "מקומית":

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

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

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

חשוב שיהיה ברור מה Tag Gateway הוא לא. הוא לא server-side tagging מלא, הוא לא עוקף את הצורך בהסכמת המשתמש (Consent Mode עדיין חובה), והוא עובד רק עם תגיות של גוגל: Google Analytics 4, מעקב המרות של Google Ads, Floodlight של Campaign Manager 360 והתגית הכללית. אם אתם מריצים גם פיקסל של מטא, טיקטוק או לינקדאין, ה-Gateway לא נוגע בהם. לזה יש פתרון אחר שנגיע אליו.

למה דווקא תת-תיקייה ולא תת-דומיין: הנקודה שקובעת הכל

זו הנקודה הטכנית שהכי הרבה אנשים מפספסים, ובלעדיה כל היתרון מתפוגג. Google Tag Gateway דורש שהתגיות יוגשו דרך תת-תיקייה על הדומיין הראשי שלכם, כלומר נתיב כמו example.co.il/metrics, ולא דרך תת-דומיין כמו metrics.example.co.il.

ההבדל נשמע זניח אבל הוא מהותי. הדפדפן מבחין בין שני מושגים: same-site ו-same-origin. תת-דומיין נחשב same-site אבל cross-origin. תת-תיקייה נחשבת same-site וגם same-origin, כלומר אותו מקור בדיוק כמו הדף שהגולש נמצא בו. רק כשהבקשה היא same-origin אמיתי, הקוקי מטופל בביטחון המלא של צד ראשון, בלי ההגבלות שהדפדפנים מפעילים על הקשרים חוצי-מקור. זו הסיבה שגוגל מתעקשת על תת-תיקייה: זה מה שמעניק את תוחלת החיים המלאה לקוקי ואת העמידות מול מנגנוני הפרטיות.

יש לזה מחיר בהקמה. תת-דומיין אפשר להפנות בעזרת רשומת DNS פשוטה בלבד, בלי לגעת בתשתית. תת-תיקייה, לעומת זאת, לא ניתן להגדיר דרך DNS. DNS עובד ברמת הדומיין, לא ברמת הנתיב. כדי להגיש נתיב מסוים, האתר עצמו חייב לרוץ דרך אותה שכבת ניתוב שמזהה את הבקשות ל-/metrics ומעבירה אותן לגוגל. זו בדיוק הסיבה שצריך CDN, load balancer, edge service או שרת proxy שיושב לפני האתר. אם האתר שלכם כבר עובר דרך Cloudflare או דרך CDN אחר, חצי מהעבודה כבר נעשה.

נקודה נוספת שכדאי להכיר: הנתיב שאתם בוחרים, בין אם /metrics או כל שם אחר, חייב להיות נתיב שלא בשימוש לשום דבר אחר באתר. אם יש לכם כבר עמוד או תיקייה בשם הזה, בחרו שם אחר. הנתיב הזה נשמר בלעדית לתעבורת המדידה.

שלוש הדרכים למדוד: קלאסי מול Tag Gateway מול Server-Side GTM

לפני שמחליטים, כדאי להבין את שלוש הארכיטקטורות ומה כל אחת פותרת. הבלבול הכי נפוץ שאני נתקל בו הוא בין Tag Gateway לבין server-side tagging מלא. הם לא מתחרים, הם פותרים בעיות שונות. Tag Gateway עונה על השאלה "מאיפה התגית מוגשת". Server-Side GTM עונה על השאלה "איך הנתונים מעובדים ולאן הם נשלחים".

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

חלק מהעסקים הבשלים מריצים את שניהם יחד: Server-Side GTM לניהול זרימת הנתונים הרחבה, ו-Tag Gateway כדי שגם טעינת התגית עצמה תבוא מהדומיין שלהם. הם משלימים, לא סותרים.

למה זה משפר עמידות וייחוס: המנגנון מאחורי המספרים

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

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

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

מי באמת צריך את זה, ומי עדיין לא

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

מי שכדאי לו להטמיע עכשיו: כל מי שמריץ Google Ads עם מעקב המרות ו/או GA4, ובמיוחד מי שכבר עובד מאחורי CDN כמו Cloudflare. אם האתר שלכם כבר עובר דרך Cloudflare, ההטמעה היא עניין של דקות, בלי עלות ובלי סיכון. אין סיבה אמיתית לוותר. עסקים עם תקציב מדיה משמעותי, שכל אחוז של דיוק בייחוס שווה להם כסף אמיתי, נמצאים בראש הרשימה.

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

מי שיכול לחכות: עסקים קטנים מאוד עם נפח המרות זעום בחודש. השיפור באחוזים קיים, אבל על נפח נמוך התוספת האבסולוטית קטנה, ולפעמים עדיף להשקיע קודם בבסיס: מעקב המרות תקין, Enhanced Conversions ו-Consent Mode מוגדרים כמו שצריך. גם מי שהאתר שלו לא עובר דרך CDN ואין לו גישה לתשתית ניתוב, יצטרך קודם לפתור את זה, ולפעמים זו החלטה שדורשת מעורבות של גורם טכני.

מי שצריך יותר מזה: אם אתם מריצים תקציבים כבדים על כמה פלטפורמות, מטא, טיקטוק, גוגל יחד, ורוצים שליטה מלאה בנתונים, Tag Gateway לבדו לא יספיק לכם. שם הפתרון הוא Server-Side GTM, ואפשר לשלב את שניהם.

הכלל שאני עובד לפיו: קודם מוודאים שהבסיס תקין, מעקב המרות, Enhanced Conversions, Consent Mode. אחרי שהבסיס יציב, Tag Gateway הוא הצעד הבא הכי משתלם ביחס מאמץ-תמורה.

הטמעה מעשית לפי סוג התשתית

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

דרך Cloudflare (הפשוט ביותר)

Cloudflare היא שותפת ההשקה של גוגל, ויש לה אינטגרציה ישירה. אם האתר שלכם כבר מאחורי Cloudflare, זה הנתיב המהיר ביותר, לרוב כמה קליקים בלבד. נכנסים ללוח הבקרה של Cloudflare, אל האזור של Google tag gateway, מחברים לחשבון Google Ads או Google Tag Manager הרלוונטי, ובוחרים את הדומיין ואת נתיב המדידה. אם כבר יש קטע קוד של תגית גוגל על הדף, אין צורך לשנות אותו בכלל. נקודה חשובה למי שמודאג מעלויות: הבקשות שעוברות דרך ה-Gateway לא נספרות לחיוב של מוצרי Cloudflare האחרים כמו CDN, WAF או Bot Management.

כך נראה תהליך ההפעלה של Google Tag Gateway דרך Cloudflare בפועל, החל מגוגל אדס וצעד אחר צעד (הפרטים המזהים של החשבון טושטשו):

דרך CDN אחר או שרת proxy

אם אתם על CDN אחר, למשל Akamai או Fastly, או מנהלים proxy משלכם, העיקרון זהה אבל ההגדרה ידנית יותר. צריך להגדיר כלל שמזהה בקשות לנתיב שבחרתם, למשל /metrics, ומעביר אותן אל שרת התגיות של גוגל, כולל טיפול נכון בכותרות הבקשה (headers). גוגל מספקת את כתובת היעד להעברה כחלק מתהליך ההגדרה בממשק. זה דורש מישהו עם גישה לתצורת ה-CDN, אבל זו עבודה חד-פעמית.

דרך Google Cloud Load Balancer

מי שמריץ את התשתית שלו על Google Cloud יכול להשתמש ב-load balancer כדי לבצע את הניתוב, ולהגדיר backend שמפנה את נתיב המדידה אל שרת התגיות. זה מתאים לארגונים שכבר מנוסים ב-Google Cloud ורוצים לשמור הכל באותה סביבה.

דרך Google Tag Manager (בלי CDN ייעודי)

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

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

אימות: איך יודעים שזה באמת עובד

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

פותחים את האתר בדפדפן Chrome, לוחצים F12 כדי לפתוח את כלי המפתחים, ועוברים ללשונית Network. מרעננים את הדף. בשדה הסינון מקלידים את שם הנתיב שהגדרתם, למשל metrics. אם הכל עובד, תראו בקשות שיוצאות אל הדומיין שלכם, example.co.il/metrics, ולא אל googletagmanager.com. סטטוס הבקשה צריך להיות תקין (200). זו ההוכחה שהתגית מוגשת ושבקשות המדידה עוברות דרך צד ראשון.

בדיקה שנייה, לקוקי. עוברים ללשונית Application (או Storage), ובצד שמאל בוחרים Cookies ואת הדומיין שלכם. מוודאים שקוקי המדידה של גוגל, כמו _ga, רשומים תחת הדומיין שלכם ולא תחת דומיין של גוגל. כשהם רשומים תחת הדומיין שלכם, זה מאשר שהם מטופלים כצד ראשון ויקבלו תוחלת חיים ארוכה. שווה לשים לב: גוגל מעבירה דרך ה-Gateway רק קוקי צד ראשון של גוגל. קוקי אחרים שאינם של גוגל נזרקים בדרך, וזה מכוון, כדי שהמערכת של גוגל לא תיגע בנתונים שלא שייכים לה.

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

איך זה מתחבר ל-Enhanced Conversions ול-Consent Mode

Tag Gateway לא עובד בחלל ריק. הוא חלק ממערך מדידה, ושתי החוליות שהוא הכי משתלב איתן הן Enhanced Conversions ו-Consent Mode.

Enhanced Conversions (המרות משופרות) שולחות לגוגל נתוני צד ראשון מגובבים (hashed) של הלקוח, כמו כתובת מייל, כדי לחבר המרה גם כשהקוקי לבדו לא מספיק. Tag Gateway ו-Enhanced Conversions מחזקים זה את זה: ה-Gateway מוודא שהבקשה בכלל מגיעה לגוגל ולא נחסמת, וה-Enhanced Conversions מוודאים שגם כשהמרה מתרחשת מזוהה הלקוח בצורה עמידה. ביחד הם משחזרים חלק ניכר מהנתונים שאבדו במעבר לעולם ללא קוקי צד שלישי. אני ממליץ להפעיל את שניהם, לא לבחור אחד.

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

שאלות נפוצות

האם Google Tag Gateway עולה כסף?

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

האם זה יבלבל את המדידה או ישבור המרות קיימות?

לא אם מבצעים נכון ומאמתים. את קטע קוד התגית עצמו לרוב לא צריך לשנות. אחרי ההטמעה בודקים ב-DevTools שהבקשות עוברות ושההמרות ממשיכות להירשם. בגלל זה שלב האימות הוא חובה ולא המלצה.

מה ההבדל בין Tag Gateway ל-Server-Side GTM, ואיזה מהם לבחור?

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

חייבים דווקא Cloudflare?

לא. Cloudflare היא הדרך הפשוטה ביותר בזכות האינטגרציה הישירה, אבל אפשר להטמיע גם דרך CDN אחר כמו Akamai או Fastly, דרך Google Cloud Load Balancer או דרך שרת proxy. מה שחייב להיות הוא שכבת ניתוב שיושבת לפני האתר ויכולה להפנות נתיב מסוים.

למה תת-תיקייה ולא תת-דומיין? מה זה משנה לי בפועל?

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

האם זה עוקף חוסמי פרסומות לגמרי?

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

זה חוקי ותקין מבחינת פרטיות?

כן, כשמשלבים אותו עם Consent Mode כמו שצריך. Tag Gateway לא אוסף מידע חדש ולא עוקף הסכמה, הוא רק משנה את המסלול שבו נתוני המדידה המורשים ממילא עוברים. ההסכמה של הגולש נשארת התנאי המקדים לכל מדידה.

כמה זמן לוקח לראות שיפור בנתונים?

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

שורה תחתונה

בעולם שבו הדפדפנים חוסמים יותר, הקוקי חיים פחות זמן וכל אות המרה שווה כסף, המדידה הפכה ליתרון תחרותי בפני עצמה. Google Tag Gateway הוא אחד המהלכים היחידים שבהם התמורה גבוהה, העלות אפסית והסיכון נמוך. הוא לא מחליף מעקב המרות תקין, Enhanced Conversions או Consent Mode, הוא מתיישב מעליהם ומחזק אותם.

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

רוצים שנבדוק את תשתית המדידה שלכם ונטמיע את Tag Gateway נכון, כולל Enhanced Conversions ו-Consent Mode? דברו איתנו בבוסטיט. נעבור על החשבון, נאתר איפה אתם מאבדים נתונים, ונסגור את הפערים.