מדידה בצד שרת, רק כשיש לה הצדקה
חלק מאירועי ההמרה לא מגיעים לפלטפורמות הפרסום. חוסמי פרסומות, הגבלות של דפדפנים והגדרות פרטיות חותכים אותם בדפדפן, והדיווח לקמפיינים ול־GA4 הופך חלקי. מדידה בצד שרת יכולה לסגור חלק מהפער, אבל היא מוסיפה תשתית, עלות ותחזוקה. לכן אצלנו היא מתחילה באבחון שבודק אם היא בכלל נחוצה.
מה זה בפועל
במדידה רגילה, הדפדפן של הגולש שולח את הנתונים ישירות לכל כלי: GA4, Google Ads ופיקסל של מטא. כל כלי כזה הוא קוד נוסף שרץ בדפדפן, וכל אחד מהם יכול להיחסם.
במדידה בצד שרת, הדפדפן שולח את הנתונים לנקודה אחת, שרת שעובד תחת דומיין של העסק. השרת מעביר את הנתונים הלאה לכל פלטפורמה. בגוגל עושים את זה עם קונטיינר שרת של Google Tag Manager. במטא קיים גם Conversions API, ממשק שמקבל אירועים ישירות מהשרת.
כשאותו אירוע נשלח גם מהדפדפן וגם מהשרת, צריך לדאוג שהפלטפורמה תזהה שזה אירוע אחד ולא תספור אותו פעמיים. זה חלק מההטמעה.
מתי זה מוצדק, ומתי לא
מדידה בצד שרת היא שכבה מעל הטמעת GA4 ו־GTM, לא תחליף לה. אם האירועים לא מוגדרים נכון בדפדפן, השרת רק יעביר הלאה את אותה טעות.
היא מוצדקת כשיש כבר מדידה בסיסית תקינה, והפער בין מה שקורה באתר לבין מה שהפלטפורמות מדווחות כבר מפריע להחלטות. למשל, כשמספר הרכישות שמטא רואה רחוק ממספר ההזמנות בחנות, וההחלטות על תקציב הקמפיינים במטא נשענות על הנתון הזה.
היא לא מוצדקת כקישוט טכני, באתר בלי מדידה בסיסית, או בעסק שלא מפרסם ולא משתמש בנתוני המרות. אם השאלה שלכם היא למה מבקרים לא פונים, התשובה נמצאת בשיפור יחס המרה, לא בשרת. את כל השירותים בתחום תמצאו בעמוד SEO, מדידה והמרות.
למי זה מתאים ולמי לא
מתאים אם
- חשבונות עם מדידת דפדפן קיימת, שבהם אמינות האירועים כבר מפריעה להחלטות תקציב
- חנויות וקמפיינים שבהם הפלטפורמה לומדת מהמרות, ונתון חסר פוגע באופטימיזציה
פחות מתאים אם
- אתר בלי מדידה בסיסית בכלל
- עסק בלי צורך בפרסום או בהמרות מדידות
- מי שמצפה לשחזור מלא של כל האירועים
מה מקבלים
- אבחון הצדקה: מה הפער היום, מאיפה הוא נובע, והאם מדידה בצד שרת תסגור אותו
- ארכיטקטורה להעברת אירועים: GTM Server, Conversions API או שילוב, לפי הערוץ ומגבלות החשבון
- הטמעה ובדיקות התאמה מול מדידת הדפדפן, כולל מניעת ספירה כפולה
- תיעוד של מה הוטמע, מה הגבולות שלו ומי אחראי על מה
איך עובדים
- הצדקה בודקים את המדידה הקיימת ואת הפער מול הפלטפורמות. אם אין הצדקה, אומרים את זה ועוצרים כאן.
- תכנון בוחרים ארכיטקטורה ותשתית שרת, ומציגים לכם את העלות השוטפת של התשתית לפני שמתחילים.
- הטמעה מקימים את השרת, מחברים את הערוצים ומגדירים זיהוי של אירועים כפולים.
- אימות משווים בין מה שנשלח מהדפדפן למה שנשלח מהשרת, עם לוגים ובדיקות התאמה.
- תיעוד מסמך שמסביר מה רץ, איפה ומה לבדוק כשמשהו משתנה.
רואים פער בין ההזמנות באתר למה שמטא או גוגל מדווחות? ספרו לנו מה אתם רואים, ונבדוק אם מדידה בצד שרת היא באמת הפתרון.
לאבחון מדידה בצד שרתשאלות נפוצות
מתי בכלל צריך מדידה בצד שרת?
רק אחרי שיש GA4 ו־GTM בסיסיים, והפער מול פלטפורמות הפרסום כבר ברור ומפריע להחלטות. לא כקישוט טכני.
GTM Server או CAPI?
לפי הערוץ ומגבלות החשבון. מחליטים באבחון, לא מראש.
זה כולל הסכמה לעוגיות?
ההטמעה הטכנית מכבדת את מנגנון ההסכמה הקיים באתר. ניסוח מדיניות משפטי הוא באחריות העסק. מדידה בצד שרת לא מחליפה את מדיניות העוגיות וההסכמה.
זה יחזיר את כל האירועים שחסרים?
לא. מדידה בצד שרת יכולה לסגור חלק מהפער, אבל אין שחזור מלא, ואנחנו לא מבטיחים שיפור בביצועי הקמפיין.
יש לזה עלות שוטפת?
כן. השרת רץ על תשתית ענן שיש לה עלות חודשית, בנוסף לעבודת ההטמעה. מציגים אותה לפני שמתחילים, כדי שתוכלו להחליט אם זה משתלם.
קודם בודקים אם צריך
ספרו לנו מה מותקן אצלכם היום ואיזה פער אתם רואים. אם הבסיס עוד לא שם, נתחיל בהטמעת GA4 ו־GTM. אם הוא שם, נבדוק אם צעד נוסף מוצדק.
בואו נבדוק את הפער