מה זה Measurement Protocol ולמה הוא משמש?
התג באתר רואה רק את מה שקורה בדפדפן. עסקה שאושרה במערכת הסליקה, ליד שהפך ללקוח ב-CRM או חידוש מנוי שקרה בלי שהמשתמש נכנס לאתר לא מגיעים ל-GA4 דרך התג. Measurement Protocol סוגר את הפער הזה: השרת שלכם שולח את האירוע ישירות לשרתי Google Analytics.
התיעוד מונה ארבעה שימושים: חיבור בין התנהגות אונליין לאופליין, מדידה של אינטראקציות בצד הלקוח ובצד השרת, שליחת אירועים שקורים מחוץ לאינטראקציה רגילה של משתמש (כמו המרות אופליין) ושליחה ממכשירים שאין בהם איסוף אוטומטי, כמו קיוסקים ושעונים.
המשפט הכי חשוב בתיעוד הוא שהפרוטוקול נועד להרחיב את האיסוף האוטומטי של gtag, של Tag Manager ושל Firebase, לא להחליף אותו. התיעוד קובע שחייבים תיוג כדי להשתמש בפרוטוקול, כך שמי ששולח אירועים רק דרכו יקבל דיווח חלקי בלבד.
מה חובה לשלוח בכל בקשה?
הבקשה נשלחת ב-HTTPS בשיטת POST לכתובת https://www.google-analytics.com/mp/collect. מי שרוצה שהנתונים ייאספו באיחוד האירופי משתמש ב-region1.google-analytics.com. ב-stream של אתר, אלה השדות:
| שדה | איפה | חובה או רשות ומה הוא |
|---|---|---|
| api_secret | בכתובת | חובה. סוד שנוצר בממשק של GA4 לכל stream |
| measurement_id | בכתובת | חובה ב-stream של אתר. מזהה ה-stream, בדרך כלל מתחיל ב-G- |
| client_id | בגוף הבקשה | חובה. המזהה שהתג של Google Analytics יצר באתר |
| events | בגוף הבקשה | חובה. מערך אירועים, לכל אחד name ו-params |
| user_id | בגוף הבקשה | רשות. מזהה משתמש משלכם |
| timestamp_micros | בגוף הבקשה | רשות. זמן האירוע במיקרו-שניות |
| consent | בגוף הבקשה | רשות. ad_user_data ו-ad_personalization, כל אחד GRANTED או DENIED |
ב-stream של אפליקציה השדות מתחלפים: firebase_app_id בכתובת ו-app_instance_id בגוף הבקשה. שדות אופציונליים נוספים הם user_properties, user_data, user_location, ip_override ו-device. כך נראית בקשה מינימלית:
POST /mp/collect?measurement_id=G-XXXXXXX&api_secret=YOUR_SECRET
{
"client_id": "CLIENT_ID_FROM_THE_SITE",
"events": [{
"name": "lead_qualified",
"params": {
"session_id": "SESSION_ID",
"engagement_time_msec": 100,
"lead_source": "crm"
}
}]
}שם האירוע lead_qualified והפרמטר lead_source הם דוגמה בלבד. שאר המבנה הוא מה שהתיעוד מגדיר.
מסלול האירוע
איך אירוע מהשרת מתחבר למשתמש שביקר באתר
איך מקימים שליחה ראשונה?
- יוצרים API secret. ב-GA4 נכנסים ל-Admin, משם ל-Data collection and modification, ל-Data streams, בוחרים את ה-stream ונכנסים ל-Measurement Protocol API secrets. לוחצים Create, נותנים כינוי ומעתיקים את הערך.
- שומרים את הסוד בשרת בלבד. התיעוד מדגיש שה-api_secret פרטי ואסור לחשוף אותו בקוד צד לקוח. לכן הפרוטוקול מיועד לשרת או לסביבה מהימנת. אירועים מהדפדפן שולחים עם gtag.js או עם Tag Manager.
- שומרים את ה-client_id מהאתר. לפי התיעוד, ה-client_id צריך להתאים למזהה שהתג יצר באתר. בפועל שומרים אותו ליד הליד או ההזמנה, לדוגמה בשדה נסתר בטופס, יחד עם מזהה הסשן.
- בונים את הבקשה. שם אירוע, פרמטרים, client_id ושני הפרמטרים המומלצים session_id ו-engagement_time_msec.
- מאמתים מול שרת הבדיקה. שולחים את אותה בקשה לנתיב
/debug/mp/collectומתקנים כל הודעה שחוזרת. - שולחים לייצור ובודקים בדוחות. מוודאים שהאירוע מופיע ושהוא לא נספר פעמיים לצד אירוע זהה שהתג שולח.
הנקודה האחרונה היא טעות נפוצה במיוחד: purchase שנשלח גם מהדפדפן וגם מהשרת. איך מזהים ומונעים את זה פירטנו ברכישות כפולות ב-GA4.
למה session_id ו-engagement_time_msec חשובים?
שניהם לא חובה מבחינת הבקשה, אבל התיעוד ממליץ לכלול אותם בכל אירוע, כי בלעדיהם האירועים לא ייספרו נכון במדדים כמו Average engagement time או Engaged sessions. ה-session_id הוא ערך מספרי חיובי שמייצג חותמת זמן. לפי התיעוד, session_id חדש יוצר סשן חדש בלי שצריך לשלוח session_start.
גם נתוני המיקום והמכשיר תלויים בחיבור הזה. לפי התיעוד, Google Analytics מצרף לאירועים מהפרוטוקול את נתוני המיקום והמכשיר העדכניים ביותר שנאספו בתיוג עבור אותו client_id. כדי שהאירוע ישקף את הנתונים של סשן מסוים, כוללים את ה-session_id של אותו סשן ושולחים בתוך 24 שעות מתחילתו. כשאין נתוני מכשיר בכלל, ברירת המחדל ב-stream של אתר היא desktop.
מה המגבלות על אירועים ופרמטרים?
| מה | המגבלה לפי התיעוד |
|---|---|
| אירועים בבקשה אחת | עד 25 |
| פרמטרים לאירוע | עד 25 |
| מאפייני משתמש | עד 25 |
| שם אירוע ושם פרמטר | עד 40 תווים: אותיות, ספרות וקו תחתון, מתחיל באות |
| ערך של פרמטר | עד 100 תווים בנכס רגיל, עד 500 בנכס 360 |
| מאפיין משתמש | שם עד 24 תווים, ערך עד 36 תווים |
| גוף הבקשה | קטן מ-130kB |
| תיארוך לאחור | עד 72 שעות |
יש גם שמות שמורים. אירועים כמו first_visit, session_start ו-user_engagement שמורים לאיסוף האוטומטי ואי אפשר לשלוח אותם דרך הפרוטוקול. שמות פרמטרים לא יכולים להתחיל בקו תחתון או באחת מהקידומות firebase_, ga_, google_ או gtag. האירועים screen_view, ad_impression ו-in_app_purchase מותרים רק ב-stream של אפליקציה.
מה קורה עם חותמת הזמן ואירועים שמגיעים באיחור?
בלי timestamp_micros האירוע מקבל את הזמן שבו הבקשה התקבלה. עם חותמת זמן אפשר לתארך אירוע לאחור עד 72 שעות. סדר העדיפות לפי התיעוד: קודם חותמת הזמן של האירוע עצמו, אחריה זאת של הבקשה ורק בסוף זמן הקבלה.
מה קורה לאירוע ישן יותר תלוי בשדה validation_behavior. במצב ברירת המחדל RELAXED האירוע מתקבל, אבל חותמת הזמן שלו נדרסת ל-72 שעות אחורה. במצב ENFORCE_RECOMMENDATIONS הוא נדחה. המשמעות המעשית: תהליך לילי שמעלה עסקאות מלפני שבוע לא ידווח אותן בתאריך הנכון. מי שצריך חלון ארוך יותר לקמפיינים צריך ערוץ אחר, כפי שהסברנו בייבוא המרות אופליין ל-Google Ads.
איך יודעים שהאירוע התקבל?
לא לפי קוד התגובה. לפי התיעוד, הפרוטוקול מחזיר קוד 2xx כשהבקשה התקבלה. הוא לא מחזיר קוד שגיאה כשהתוכן פגום או כשחסר פרמטר חובה. קוד תקין לא אומר שהאירוע יופיע בדוחות.
לכן יש שרת בדיקה. שולחים את אותה בקשה לנתיב /debug/mp/collect ומקבלים מערך validationMessages. בכל הודעה שלושה שדות: fieldPath, description ו-validationCode. בקשה תקינה מחזירה מערך ריק. שני סייגים מהתיעוד: אירועים שנשלחים לשרת הבדיקה לא מופיעים בדוחות. בנוסף, שרת הבדיקה לא מאמת את ה-api_secret ואת ה-measurement_id. את אלה בודקים בנפרד: לכל stream יש סוד משלו, הערך תלוי באותיות גדולות וקטנות ואפשר לבטל אותו בממשק.
מה Measurement Protocol לא עושה?
שלוש נקודות שכדאי לדעת לפני שמתכננים עליו ארכיטקטורה. הראשונה: כללים ליצירה או לשינוי שם של אירועים בממשק של GA4 לא מופעלים על אירועים מהפרוטוקול, כך שאת הלוגיקה הזאת מממשים בצד שלכם. השנייה: רימרקטינג באותו מכשיר נתמך כש-Google signals מופעל, בעוד שלרימרקטינג חוצה מכשירים נדרש User ID. השלישית: אירועים בפורמט של הפרוטוקול שנשלחים לקונטיינר שרת לא מועברים לנקודת הקצה של הפרוטוקול, לכן חלק מהיכולות, כמו גזירת מיקום ומכשיר מנתוני התיוג, לא נתמכות שם.
לגבי העתיד: לפי התיעוד, הפרוטוקול נמצא במצב בשל וסופי, ימשיך לפעול ואין תוכנית להפסיק אותו. עם זאת Google ממליצה לבנות אינטגרציות חדשות משרת לשרת על Data Manager API, לכן בתחילת פרויקט שווה לבדוק את שתי האפשרויות. את השיקול הרחב יותר של מה מעבירים לשרת סקרנו במתי צריך מדידה בצד שרת.
שאלות נפוצות
מה זה Measurement Protocol של GA4?
Measurement Protocol הוא ממשק HTTP לשליחת אירועים ל-Google Analytics ישירות מהשרת, בבקשת POST לכתובת www.google-analytics.com/mp/collect. לפי התיעוד של Google הוא נועד להשלים את האיסוף האוטומטי של gtag, של Tag Manager ושל Firebase ולא להחליף אותו. השימושים הנפוצים הם המרות אופליין ואירועים שקורים בצד השרת.
מה חובה לשלוח בבקשה ל-Measurement Protocol?
ב-stream של אתר שולחים בכתובת את api_secret ואת measurement_id. בגוף הבקשה חובה לשלוח client_id ומערך events שבו לכל אירוע יש name. ב-stream של אפליקציה משתמשים ב-firebase_app_id וב-app_instance_id. התיעוד ממליץ להוסיף לכל אירוע גם session_id ו-engagement_time_msec.
איפה יוצרים API secret ל-Measurement Protocol?
ב-GA4 נכנסים ל-Admin, משם ל-Data collection and modification, ל-Data streams, בוחרים את ה-stream ונכנסים ל-Measurement Protocol API secrets. לוחצים Create ונותנים כינוי. לפי התיעוד הסוד פרטי ואסור לחשוף אותו בקוד צד לקוח. לכל stream יש סוד משלו והערך תלוי באותיות גדולות וקטנות.
עד כמה אחורה אפשר לשלוח אירוע ב-Measurement Protocol?
עד 72 שעות, בעזרת השדה timestamp_micros. לפי התיעוד, אירוע ישן יותר שנשלח במצב ברירת המחדל RELAXED מתקבל, אבל חותמת הזמן שלו נדרסת ל-72 שעות אחורה. במצב ENFORCE_RECOMMENDATIONS האירוע נדחה. בלי חותמת זמן האירוע מקבל את זמן קבלת הבקשה.
האם אפשר למדוד ב-GA4 רק עם Measurement Protocol בלי תג באתר?
לא מומלץ. התיעוד של Google קובע שחייבים להשתמש בתיוג, כלומר gtag, Tag Manager או Firebase, כדי להשתמש בפרוטוקול. מי ששולח אירועים רק דרכו יקבל דיווח חלקי בלבד. נתוני המיקום והמכשיר, לדוגמה, מצורפים לאירוע מתוך מה שהתג אסף עבור אותו client_id.
איך בודקים אירוע של Measurement Protocol לפני ששולחים אותו?
שולחים את אותה בקשה לשרת הבדיקה, בכתובת www.google-analytics.com/debug/mp/collect. התשובה היא מערך validationMessages עם השדות fieldPath, description ו-validationCode. בקשה תקינה מחזירה מערך ריק. לפי התיעוד, אירועים שנשלחים לשרת הבדיקה לא מופיעים בדוחות. שרת הבדיקה גם לא מאמת את ה-api_secret ואת ה-measurement_id.
מה השורה התחתונה?
Measurement Protocol הוא כלי השלמה: הוא מצוין לאירוע שהדפדפן לא רואה, כמו עסקה שאושרה או ליד שהתקדם ב-CRM, בתנאי ששמרתם את ה-client_id מהביקור באתר ושהאירוע נשלח בתוך 72 שעות. הוא לא תחליף לתג וגם לא מודיע כשמשהו שגוי, כי קוד התגובה תקין גם כשהתוכן פגום. לכן כל הטמעה מתחילה בשרת הבדיקה ומסתיימת בבדיקת כפילויות מול התג. אנחנו מתכננים ובודקים הטמעות כאלה כחלק משירות מדידה מתקדמת, כולל ההחלטה אילו אירועים שייכים לשרת ואילו נשארים בדפדפן. אם יש לכם אירועים מהשרת שלא מופיעים ב-GA4 או שנספרים פעמיים, כתבו לנו.
מקורות
Google for Developers: Measurement Protocol, Google for Developers: Measurement Protocol reference, Google for Developers: Send Measurement Protocol events to Google Analytics, Google for Developers: Validate events, Google for Developers: Troubleshooting
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי