Measurement Protocol: לשלוח אירועים ל-GA4 בלי דפדפן

הלקוח שילם, אבל התשלום אושר בשרת אחרי שהדף כבר נסגר. או שהעסקה נסגרה בטלפון, בכלל לא באתר. איך האירועים האלה מגיעים ל-GA4, אם אין דפדפן שיירה את התגית? Measurement Protocol הוא הדרך להכניס גם את האירועים האלה לתוך המדידה.

איפה אנחנו נמצאים במערכת · פרק 7 מתוך 20

אתר←מדידה←ניהול לידים←אוטומציה←עסקה←Offline Conversion←למידת האלגוריתם

מסלול קריאה מומלץ: מהי מדידה ← מדידה בצד השרת ← Server-Side GTM ← Measurement Protocol (כאן)

בקצרה: Measurement Protocol הוא הערוץ שדרכו אירועים מהשרת מגיעים ל-GA4, בלי דפדפן. במקום סקריפט שרץ אצל המשתמש, השרת שולח בקשת HTTP ישירה ל-GA4 עם פרטי האירוע. כך אירועים שקורים מחוץ לדפדפן (רכישה בשרת, עסקה שנסגרה, החזר) מגיעים למדידה.

משתמש נכנס לאתר

▼

GA4 בדפדפןclient_id = ABC123המזהה נוצר כאן

▼ה-client_id נשמר אצלכם (למשל ב-CRM)

עסקה נסגרה בשרתיום אחר כך, מחוץ לאתר

▼

Measurement Protocolclient_id = ABC123אותו מזהה, לא חדש

▼

GA4: אותו משתמש, מסע אחד

Measurement Protocol אינו מודד את מה שקורה בדפדפן.
הוא מכניס ל-GA4 את מה שקורה מחוץ לו.

הבעיה: אירועים בלי דפדפן

תגית GA4 חיה בדפדפן, ולכן היא רואה רק מה שקורה בו. אבל הרבה מהאירועים החשובים ביותר קורים איפה שאין דפדפן: רכישה שמאושרת בשרת התשלומים, עסקה שנסגרת בטלפון, החזר כספי, חידוש מנוי, או ליד שהפך ללקוח שבוע אחרי הביקור. הדפדפן כבר מזמן נסגר, אז איך האירועים האלה מגיעים ל-GA4? כאן נכנס Measurement Protocol.

מה זה Measurement Protocol

Measurement Protocol (בקיצור MP) הוא ה-API של GA4 לשליחת אירועים ישירות מהשרת, בבקשת HTTP. השרת שולח מנה (payload) עם שם האירוע, הפרמטרים, ומזהים. כדי שזה יעבוד צריך ארבעה דברים: measurement_id (מזהה ה-property), api_secret (מפתח סודי שנשמר רק בשרת), client_id (המזהה שמחבר לסשן), והאירוע עצמו. התוצאה: האירוע מהשרת מופיע ב-GA4 לצד אירועי הדפדפן. אפשר לחשוב עליו כמו על API רשמי שמאפשר לכל מערכת שלכם לדבר ישירות עם GA4.

החוליה הקריטית: client_id

זו הנקודה שהכי קל לפספס, והיא קריטית. כדי שאירוע מהשרת יתחבר לאותו משתמש שגלש באתר, חייבים לשלוח את אותו client_id שה-GA4 השתמש בו בדפדפן. בפועל: תופסים את ה-client_id מהדפדפן (מהקוקי של GA4), שומרים אותו (למשל ב-CRM), ומצרפים אותו לקריאת ה-MP.

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

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

ה-client_id הוא הדבק. בלעדיו, אירוע השרת והביקור באתר נשארים שני סיפורים נפרדים, וכל הערך של המדידה המשולבת הולך לאיבוד.

MP מול Server-Side GTM

שני המונחים מתערבבים, אבל הם לא מתחרים, הם שכבות שונות:

Measurement Protocol

הפרוטוקול הגולמי: בקשת HTTP ישירה מהשרת ל-GA4. עוצמתי וגמיש, אבל דורש קוד, טיפול ידני ב-client_id, ואימות קפדני. מתאים כשצריך שליטה מלאה.

Server-Side GTM

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

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

מה זה לא עושה

חשוב לא פחות ממה שהוא כן:

זה לא מחליף את התגית בדפדפן, אלא משלים אותה לאירועים שהיא לא רואה.
זה לא מאמת בשבילכם, אנדפוינט השליחה מחזיר 204 גם ל-JSON שגוי. חובה לאמת מול ה-debug endpoint.
זה לא מונע כפילויות, אם גם הדפדפן וגם השרת שולחים את אותה רכישה, היא נספרת פעמיים. צריך מקור אמת אחד לכל אירוע, או דדופליקציה לפי transaction_id.
זה לא עובד לכל היעדים, MP הוא ספציפי ל-GA4 בלבד.
זה לא שומר את ה-client_id בשבילכם, אם לא תפסתם אותו בזמן הביקור באתר, אי אפשר להמציא אותו אחר כך.

מבחינת D-Office, זו החוליה שמכניסה ל-GA4 את מה שקורה בצד השרת וב-עולם האמיתי, וסוגרת את המעגל יחד עם מקור אמת יחיד.

מושגים שהוזכרו

Measurement Protocol (MP)client_idapi_secretmeasurement_idstitching (איחוי)debug endpoint204 No Contenttransaction_idServer-Side GTMGA4

קשור

Server-Side GTM · מדידה בצד השרת · המרות אופליין · ארכיטקטורת המדידה

שאלות נפוצות

שאלות ותשובות על Measurement Protocol

למה לא פשוט לשלוח הכל מהשרת?

כי התגית בדפדפן אוספת המון הקשר שהשרת לא רואה: מקור התנועה, המכשיר, דפי הגלישה. Measurement Protocol נועד למלא את מה שהדפדפן לא יכול לתפוס (אירועי שרת, אופליין, החזרים), לא להחליף אותו. שילוב נכון = הכי טוב משני העולמות.

מה קורה אם ה-client_id לא נכון?

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

זה עובד רק ל-GA4?

כן. Measurement Protocol הוא ספציפי ל-GA4. ל-Meta יש CAPI, ולגוגל אדס יש ייבוא המרות ו-Enhanced Conversions. לכל יעד יש הדלת שלו, וזו של GA4.

אני חייב Server-Side GTM כדי להשתמש ב-Measurement Protocol?

לא. אפשר לשלוח קריאות MP ישירות מהשרת שלכם, בלי Server-Side GTM. אבל sGTM עושה את זה קל בהרבה: הוא מפעיל את MP מאחורי הקלעים ומטפל בחלק מהמורכבות, כך שלא צריך לכתוב את הקריאות ביד.

איך יודעים שזה בכלל עבד?

זו נקודה מסוכנת: אנדפוינט השליחה מחזיר 204 (הצלחה טכנית) כמעט לכל בקשה, גם אם ה-JSON שגוי. לכן חובה לאמת מול ה-debug endpoint, שמחזיר דוח שגיאות, ולוודא בדוח הבזמן-אמת של GA4.

Measurement Protocol או Server-Side GTM?

הם לא מתחרים. MP הוא המנגנון, ו-Server-Side GTM הוא דרך מנוהלת להפעיל אותו (הוא שולח ל-GA4 דרך MP מתחת למכסה). רוב העסקים ישתמשו ב-sGTM; MP ישיר מתאים כשצריך שליטה מלאה בקוד.