מדידה בצד השרת (server-side tracking) היא שיטה שבה הדפדפן של הגולש שולח את נתוני המדידה לשרת שבשליטתכם, והשרת הזה מחליט מה להעביר ל-Google Analytics, לפלטפורמות הפרסום ולשאר הכלים. במדידה הרגילה, כל תגית רצה בדפדפן ושולחת נתונים ישירות לספק שלה; בצד השרת יש תחנת ביניים אחת. היתרונות הם שליטה בנתונים ופחות קוד בדפדפן; המחיר הוא שרת נוסף להקים, לתחזק ולשלם עליו.
איך זה עובד
| מדידה בדפדפן | מדידה בצד השרת | |
|---|---|---|
| מי שולח לספקים | כל תגית, ישירות מהדפדפן | שרת התיוג שלכם |
| מי רואה את הנתונים הגולמיים | כל ספק שהתגית שלו רצה בעמוד | רק השרת שלכם, עד שהוא מעביר הלאה |
| קוד בדפדפן | סקריפט לכל כלי | לרוב תגית אחת שמזינה את השרת |
| תשתית | אין | שרת תיוג, בענן או אצל ספק |
המימוש הנפוץ הוא תיוג בצד השרת של Google Tag Manager. לפי התיעוד של גוגל, במקום שמכולת התגיות תרוץ בדפדפן, היא רצה על שרת: השרת מקבל בקשות מהמכשירים, הופך אותן לאירועים, והתגיות בשרת מעבדות ושולחות אותם הלאה. השרת רץ בפרויקט Google Cloud משלכם או בסביבה אחרת שתבחרו.
מה מרוויחים
שליטה בנתונים
זה היתרון המרכזי. לפי גוגל, "רק לכם יש גישה לנתונים בשרת עד שתבחרו לשלוח אותם למקום אחר". אפשר להסיר מהאירוע פרטים לפני שהוא יוצא — כתובת IP, פרמטרים בכתובת שמכילים מידע אישי, מזהים — ולהחליט לאיזה ספק עובר מה. בדפדפן, כל תגית רואה כל מה שהדפדפן רואה.
פחות קוד בעמוד
כשכמה כלים מקבלים את הנתונים דרך השרת, אפשר להוריד מהעמוד חלק מהסקריפטים שלהם. זה יכול לשפר את המהירות — אבל רק אם באמת מסירים תגיות מהדפדפן, ולא מוסיפים שרת מעל אותן תגיות. ראו סקריפטים חיצוניים.
דומיין משלכם
גוגל ממליצה בחום להתקין את שרת התיוג על תת-דומיין של האתר שלכם, ולא על הכתובת שהענן נותן. כך הבקשות נשארות בתוך הדומיין שלכם.
אירועים מהשרת של האתר
יש אירועים שהדפדפן לא תמיד רואה — תשלום שהושלם אחרי חזרה מחברת הסליקה, ביטול, החזר. האתר יכול לשלוח אותם ישירות מהשרת. זה העיקרון מאחורי Conversions API של Meta — ראו פיקסל פייסבוק ו-Conversions API.
מה זה לא
- זה לא עקיפה של הסכמה. אם הגולש סירב לעוגיות פרסום, לא שולחים את הנתונים שלו לפלטפורמות פרסום — בין אם מהדפדפן ובין אם מהשרת. מדידה בצד השרת צריכה לכבד את אותה בחירה, כולל Consent Mode. ראו Google Consent Mode.
- זה לא פתרון לחוסמי פרסומות כשיטה. מדידה שנועדה להסתיר מהגולש שהוא נמדד היא בעיה של אמון ושל פרטיות, לא יתרון טכני.
- זה לא חינם. השרת עולה כסף לפי נפח התנועה, ומישהו צריך לעדכן אותו, לנטר אותו ולתקן כשמשהו נשבר.
למי זה מתאים
- חנויות ואתרים עם תקציב פרסום משמעותי, שבהם דיוק ההמרות משפיע ישירות על הכסף.
- אתרים שאוספים מידע רגיש ורוצים לשלוט מה יוצא לספקים.
- אתרים עם הרבה תגיות שמכבידות על העמוד.
לאתר תדמית קטן עם Google Analytics בלבד, זו בדרך כלל מורכבות שלא מחזירה את עצמה. קודם כדאי לוודא שהמדידה הבסיסית נכונה — ראו מעקב המרות ואירועים ב-GA4.
מה צריך לבדוק לפני שמתחילים
- אילו כלים מקבלים היום נתונים, ואיזה מהם תומך בקבלה מצד השרת.
- מי יתחזק את השרת, ומה קורה כשהוא נופל — האם המדידה נעצרת לגמרי?
- אילו נתונים אישיים עוברים היום, ומה צריך להסיר.
- איך ההסכמה של הגולש עוברת לשרת.
- איך בודקים שהנתונים בשרת זהים למה שהיה בדפדפן, לפני שמכבים את התגיות הישנות.
שאלות נפוצות
האם מדידה בצד השרת מחליפה את Google Tag Manager?
לא, היא תוספת. בדרך כלל נשארת מכולה בדפדפן שמזינה את מכולת השרת.
זה משפר את המהירות?
רק אם מסירים תגיות מהדפדפן בעקבות המעבר. שרת תיוג שמתווסף מעל כל התגיות הקיימות לא יזרז כלום.
אני מקים מדידה בצד השרת כשהיא באמת מוצדקת, ומחבר אליה אירועים מהשרת של האתר — ראו אינטגרציות ו-API, או ספרו לי אילו כלים מודדים היום את האתר שלכם.
אהבתם את המאמר?
