מה זה בעצם Server-Side GTM ומה הוא משנה?
במדידה רגילה, הדפדפן של הגולש שולח ישירות את האירועים ל-GA4, ל-Meta ול-Google Ads. כל פיקסל רץ בדפדפן, כותב עוגיות בדומיין צד שלישי וחשוף לחוסמי פרסומות, למדיניות העוגיות של Safari ולכל הפרעה ברשת. בארכיטקטורת צד שרת, לפי התיעוד הרשמי של Google, הדפדפן שולח את האירועים לקונטיינר שרת שרץ בסביבה שבבעלותכם, בדומיין first-party שלכם (למשל data.yoursite.co.il). שם רכיבים שנקראים Clients מקבלים את הבקשה, הופכים אותה לאירוע, מריצים אותו דרך התגים והטריגרים של הקונטיינר ושולחים אותו הלאה לפלטפורמות.
המשמעות המעשית היא שלושה דברים. ראשית, הדפדפן טוען פחות סקריפטים, כי רוב הפיקסלים עוברים לשרת. שנית, העוגיות נכתבות מהשרת שלכם ולכן נחשבות first-party. חייהן ארוכים יותר. שלישית, זה הנימוק החשוב לארגונים עם דרישות פרטיות, הנתונים עוברים דרך נקודה אחת שאתם שולטים בה. אפשר למחוק, לגבב או להסיר פרמטרים לפני שהם מגיעים לצד שלישי. Google מציינת במפורש שרק אתם ניגשים לנתונים בשרת עד שאתם מחליטים לשלוח אותם הלאה.
ארכיטקטורה
ארכיטקטורת מדידה בצד שרת (sGTM)
הדפדפן שולח אירועים עם event_id ומצב הסכמה לקונטיינר השרת בדומיין שלכם. עוגיות first-party נכתבות מהשרת.
event_idמתי מדידה בצד שרת מתאימה לארגון ומתי לא?
השאלה הנכונה היא לא "האם זה טכנולוגית אפשרי" אלא "האם הפער במדידה עולה לארגון יותר מהעלות של לסגור אותו". הפער הזה גדל ככל שיש יותר תקציב מדיה שמוכוון לפי המרות, יותר תנועה מ-iOS ומ-Safari, יותר גולשים שדוחים עוגיות ויותר רגולציה. אנחנו משתמשים במסגרת הבאה בפגישות ההיכרות שלנו. הספים הם כלל אצבע ולא חוק. הם משתנים לפי מרווח הרווח של העסק.
| פרופיל ארגון | תקציב מדיה חודשי (כלל אצבע) | סוג אתר | דרישות פרטיות | האם מומלץ |
|---|---|---|---|---|
| עסק קטן, אתר תדמית | עד 15 אלף ש"ח | WordPress או Wix, טופס יצירת קשר | רגילות, הודעת פרטיות בסיסית | לא. השקיעו במדידה בסיסית נכונה בדפדפן וב-GA4 |
| מערך לידים עם פרסום פעיל | 30 עד 150 אלף ש"ח | דפי נחיתה, טפסים, CRM | רגילות עד בינוניות | כן. התועלת העיקרית: Enhanced Conversions, Meta CAPI והמרות מה-CRM |
| איקומרס בינוני-גדול | מעל 100 אלף ש"ח | Shopify, WooCommerce, Magento, פיתוח עצמי | בינוניות, תשלומים ופרטי לקוח | כן, בעדיפות גבוהה. ההמרות הן הדלק של האלגוריתמים |
| ארגון מפוקח: פיננסים, ביטוח, בריאות | כל תקציב | אתר שירות, אזור אישי, טפסי בקשה | מחמירות: DPO, תיקון 13, לקוחות באירופה | כן, בעיקר בגלל השליטה בנתונים. חובה ליווי משפטי במקביל |
| אתר תוכן או מדיה עם תנועה גדולה | נמוך או ללא | מיליוני צפיות עמוד בחודש | רגילות | תלוי. נפח הבקשות גבוה והתועלת העסקית נמוכה, לרוב לא בשלב ראשון |
| אפליקציה בלבד, בלי אתר משמעותי | כל תקציב | iOS ו-Android | לפי החנויות | לא רלוונטי. הפתרון הוא MMP כמו AppsFlyer ולא sGTM |
יש גם מצבי ביניים. חברת B2B עם מחזור עסקה גדול ומעט לידים בחודש יכולה להצדיק צד שרת גם בתקציב מדיה צנוע, כי כל ליד שנעלם מהמדידה שווה הרבה. לעומת זאת, אתר מסחר שעובד כמעט רק על תנועה אורגנית ועל דיוור ירוויח פחות, כי הערך העיקרי של הארכיטקטורה הוא בשיפור הנתונים שחוזרים לפלטפורמות הפרסום.
כמה עולה לארח קונטיינר שרת: Stape מול Google Cloud Run
לקונטיינר שרת צריך שרת. שתי האפשרויות הנפוצות הן שירות אירוח מנוהל כמו Stape, שבו משלמים מנוי לפי נפח בקשות, או פריסה ישירה ב-Google Cloud Run, שבה משלמים ל-Google לפי משאבי מחשוב. חשוב להבין את יחידת המדידה: אצל Stape בקשה היא כל פנייה שקונטיינר השרת מקבל, כולל טעינות של gtm.js ו-gtag.js ולא רק אירועי GA4. Stape עצמה מציעה להעריך את מספר הבקשות כמספר אירועי GA4 בחודש ועוד כ-30 אחוז. ב-Cloud Run, לפי מדריך ההתקנה הרשמי של Google, כל מופע שרת (1 vCPU, 0.5GB זיכרון, מעבד מוקצה תמיד) עולה כ-45 דולר בחודש, Google ממליצה על שני מופעים לפחות בפרודקשן כדי לא לאבד נתונים בתקלה. שניים עד עשרה מופעים מטפלים ב-35 עד 350 בקשות בשנייה.
הטבלה הבאה משווה את עלות האירוח בלבד, לפי המחירונים הרשמיים כפי שנבדקו ב-24.10.2026 (stape.io/pricing ו-cloud.google.com/run/pricing). המחירים בדולר ארה"ב, לפני מע"מ. מחירי Stape מוצגים בחיוב חודשי. בסוגריים המחיר החודשי בחיוב שנתי. הערכת Cloud Run היא חישוב לדוגמה לאזור Tier 1 (ובו גם me-west1 תל אביב) לפי המודל שבמדריך של Google, לפני ניצול השכבה החינמית ובלי שרת התצוגה המקדימה (preview) שנפרס בנפרד.
| נפח בקשות חודשי | Stape (מנוי) | Google Cloud Run (הערכה לדוגמה) | מה כדאי לדעת |
|---|---|---|---|
| עד 10 אלף | Free, 0 דולר | כ-90 עד 100 דולר (2 מופעים מינימום) | ב-Stape הקונטיינר מושבת כשמגיעים לתקרה ולא מתאפס. מתאים לבדיקות, לא לפרודקשן |
| עד 500 אלף | Pro, 20 דולר (17 בשנתי) | כ-90 עד 100 דולר | ב-Pro הקונטיינר נעצר ב-110 אחוז מהתקרה בלי תקופת חסד |
| עד 5 מיליון | Business, 100 דולר (83 בשנתי) | כ-90 עד 100 דולר | כאן העלויות נפגשות. Business כולל תקופת חסד חד-פעמית של 30 יום בחריגה |
| עד 20 מיליון | Enterprise, 200 דולר (167 בשנתי) | כ-100 עד 150 דולר (2 עד 3 מופעים בשיאים) | Cloud Run מתחיל להיות זול יותר, בתנאי שיש מי שמנהל את הפרויקט ב-Google Cloud |
| מעל 20 מיליון | Custom, במשא ומתן | לפי מספר המופעים בפועל, גדל עם התנועה | בנפחים כאלה בודקים גם פיצול קונטיינרים, סינון בוטים וקיצור רשימת הפרמטרים |
כמה הערות לקריאת הטבלה. ב-Cloud Run העלות כמעט קבועה עד נפחים גדולים, כי משלמים על מופעים שרצים כל הזמן ולא על בקשות. במודל החיוב לפי מופע אין חיוב נפרד לבקשה. במודל החיוב לפי בקשה, שבו המעבד מוקצה רק בזמן טיפול בבקשה, המחיר הוא 0.40 דולר למיליון בקשות ועוד זמן מעבד וזיכרון, עם שכבה חינמית של 2 מיליון בקשות ו-180 אלף שניות vCPU בחודש. Google עצמה ממליצה במדריך על מעבד מוקצה תמיד בשביל יציבות. לכן זה המודל שבטבלה. אצל Stape המחיר כולל גם את מה שב-Cloud Run צריך לבנות לבד: דומיין מותאם, CDN גלובלי, לוגים, ניטור והתראות על קרבה לתקרה. לארגון בלי צוות DevOps זה שווה כסף אמיתי.
והערה חשובה אחת: הטבלה מתארת את עלות האירוח בלבד. העבודה המקצועית, כלומר ההקמה, ההעברה של התגים לצד השרת, הבדיקות והתחזוקה השוטפת, מתומחרת בנפרד ולפי היקף המערך: כמה פלטפורמות, כמה אירועים, האם יש CRM ו-Enhanced Conversions ואיזו רמת ניטור נדרשת. אנחנו לא מפרסמים מחירי שירות במדריכים, כי שני אתרים עם אותו נפח בקשות יכולים לדרוש היקפי עבודה שונים מאוד.
מה כוללת התחזוקה השוטפת של מערך בצד שרת?
הטעות השכיחה בתמחור היא להתייחס ל-sGTM כפרויקט הקמה חד-פעמי. בפועל נוסף לארגון רכיב תשתית חי עם שלושה סוגי תחזוקה. הראשון הוא תפעולי: מעקב אחרי חשבון האירוח, התראות על חריגה מתקרת הבקשות או מתקציב Google Cloud, עדכון גרסת הקונטיינר כשה-image של Google מתעדכן ושמירה על תוקף רשומת ה-DNS של הסאב-דומיין. השני הוא מדידתי: כל פיקסל חדש או שינוי באירוע דורש עכשיו עבודה בשני קונטיינרים במקום אחד. בכל שינוי צריך לבדוק שוב את הדה-דופליקציה מול Meta ואת ההמרות ב-Google Ads. השלישי הוא רגולטורי: שינוי בבאנר ההסכמה, בנוסח הפרטיות או במדיניות של הפלטפורמות מחייב לבדוק שהשרת עדיין מכבד את מצב ההסכמה ושלא נשלחים פרמטרים שהוחלט לא לשלוח.
בפרויקטים שלנו אנחנו מגדירים מראש מי אחראי על כל אחד מהשלושה. אירוח וחיוב נשארים לרוב בבעלות הלקוח, כדי שהנתונים והחשבון יהיו שלו. המדידה והבדיקות הן העבודה המקצועית שלנו. הרגולציה היא עבודה משותפת עם היועץ המשפטי. אנחנו מספקים לו תיעוד של מה נשלח, לאן ובאיזה תנאי.
איך מחליטים בין Stape ל-Google Cloud Run?
ההחלטה נגזרת פחות ממחיר ויותר מיכולת תפעול. Stape מתאימה לרוב הארגונים שאין להם צוות ענן פעיל: ההקמה קצרה, הדומיין המותאם מוגדר דרך הממשק ויש תמיכה. Cloud Run מתאים לארגון שכבר עובד ב-Google Cloud, רוצה שהנתונים יישארו בפרויקט שלו ויש מי שינהל IAM, התראות תקציב וגרסאות. בשני המקרים הקונטיינר עצמו הוא אותו קונטיינר שרת של Google Tag Manager. אפשר לעבור בין שני הספקים בלי לבנות את התגים מחדש. ההבדל הוא בשכבת האירוח ובמי שמחזיק את הביפר כשמשהו נופל בשתיים בלילה.
טעויות נפוצות
הטעות הראשונה היא להריץ את השרת על דומיין ברירת המחדל של הספק במקום על סאב-דומיין של האתר. בלי דומיין first-party העוגיות לא נכתבות מהדומיין שלכם ורוב התועלת של הארכיטקטורה נעלמת. Google ממליצה במפורש להתקין את השרת על דומיין first-party לפני ששולחים אליו תנועת פרודקשן.
הטעות השנייה היא כפילות אירועים מול Meta. כשהפיקסל בדפדפן וה-CAPI בשרת שולחים את אותה רכישה בלי event_id זהה ובלי שם אירוע זהה, Meta סופרת אותה פעמיים, ה-ROAS מתנפח והאלגוריתם לומד על נתונים שגויים. לפי התיעוד של Meta, הדה-דופליקציה עובדת רק כששני האירועים מגיעים עם אותו מזהה בחלון של 48 שעות.
הטעות השלישית היא להשאיר את פיקסל ההמרות הישן של Google Ads בדפדפן אחרי שהעבירו אותו לשרת. Google מציינת שאחרי שהתג בשרת אומת צריך להסיר את התגים המקבילים מקונטיינר האינטרנט, אחרת ההמרות נספרות פעמיים. הטעות הרביעית היא להתייחס לצד השרת כפתרון עוקף הסכמה. מצב ההסכמה חייב לעבור לשרת ולהיות מכובד שם, אחרת הארגון שולח נתונים של גולשים שדחו עוגיות, רק מכתובת אחרת. הטעות החמישית היא לבחור תוכנית Stape לפי מספר הביקורים ולא לפי מספר הבקשות. אחר כך מגלים באמצע החודש שהקונטיינר נעצר ואין נתונים.
איך בודקים שזה עובד?
אחרי ההקמה אנחנו מריצים סבב קבלה קבוע ולא מסתפקים בזה שהתגים "ירוקים" בתצוגה המקדימה. הסדר שלנו:
- בדיקת הדומיין. כתובת האיסוף של GA4 בכרטיסיית Network מפנה לסאב-דומיין שלכם. העוגיות של GA4 ושל Google Ads נכתבות עם Domain של האתר ועם תוקף של שנה ולא של שבעה ימים.
- תצוגה מקדימה בשני הקונטיינרים. כל אירוע שנשלח מהדפדפן מופיע גם בתצוגה המקדימה של קונטיינר השרת, עם כל הפרמטרים ועם מצב ההסכמה.
- דה-דופליקציה. ב-Events Manager של Meta בודקים שהאירוע מגיע משני המקורות, Browser ו-Server. העמודה של Deduplicated צריכה להראות שכפילות הוסרה. לכל אירוע יש event_id זהה בשני הצדדים.
- תרחיש דחייה. גולש שדחה עוגיות בבאנר: בודקים מה בדיוק נשלח מהשרת ושהפרמטרים המזהים לא יוצאים.
- השוואה לאמת. אחרי שבוע משווים את מספר הרכישות או הלידים ב-GA4, ב-Meta וב-Google Ads מול מערכת ההזמנות או ה-CRM. פער סביר קיים תמיד, אבל הוא צריך לקטון לעומת לפני ההקמה ולא לגדול.
- ניטור שוטף. מגדירים התראה על ירידה חדה באירועים שמגיעים לשרת, התראת תקציב ב-Google Cloud או התראת תקרה ב-Stape. בנוסף בדיקה חודשית של נפח הבקשות מול התוכנית.
אז מה ההחלטה הנכונה?
אם הארגון שלכם משקיע תקציב מדיה משמעותי שמנוהל לפי המרות, או כפוף לדרישות פרטיות שמחייבות שליטה בנתונים, מדידה בצד שרת היא לא מותרות אלא תשתית. עלות האירוח קטנה יחסית לתקציב המדיה. הערך בא מהנתונים שחוזרים לפלטפורמות ומהשליטה במה שיוצא מהאתר. אם אתם אתר תדמית קטן בלי פרסום ממומן, התשובה הישרה היא לא עכשיו. עדיף להשקיע במדידה בסיסית נכונה. אנחנו מלווים ארגונים בהחלטה הזו ובהקמה, מהבחירה בין Stape ל-Cloud Run ועד בדיקות הקבלה והניטור, במסגרת שירות המדידה המתקדמת שלנו. אם תרצו לבדוק מה מתאים למערך שלכם, כתבו לנו.
עוד מדריכים בנושא מדידה מתקדמת
מקורות
Google: An introduction to server-side tagging, Google: Server-side tagging Cloud Run setup guide, Google Cloud Run pricing, Stape pricing, Meta: Handling duplicate Pixel and Conversions API events
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי