למה שולחים את אותו אירוע גם מהפיקסל וגם מה-Conversions API?
מטא ממליצה על מה שהיא מכנה redundant setup: להשתמש ב-Conversions API בנוסף לפיקסל ולשלוח את אותם אירועים דרך שני הערוצים. הפיקסל רץ בדפדפן ותלוי בו, בעוד שהשרת שולח את האירוע בלי תלות במה שקרה בדפדפן. כשאחד מהם מפספס, השני משלים.
המחיר של הכפילות הזאת הוא שכל אירוע מגיע פעמיים, כך שבלי דה-דופליקציה מטא תספור שתי רכישות על כל רכישה אחת. לפי התיעוד דה-דופליקציה נדרשת רק לאירועים שנשלחים בשני הערוצים: אירוע שנשלח רק מהשרת, כמו סטטוס ליד מה-CRM, לא צריך אותה. את התרחיש הזה פירטנו במדריך Meta CAPI ללידים מה-CRM.
אירוע אחד, שני ערוצים
איך מזהה משותף מונע ספירה כפולה
איך מטא מזהה ששני אירועים הם אותו אירוע?
התיעוד מתאר שתי שיטות. הראשונה היא המומלצת.
| נושא | event_id ושם האירוע | fbp או external_id |
|---|---|---|
| מה משווים | eventID מהפיקסל מול event_id מהשרת, יחד עם שם האירוע | שם האירוע יחד עם fbp, external_id או שניהם |
| מה צריך לשלוח | מזהה ייחודי זהה בשני הערוצים | אותם ערכים באופן עקבי בדפדפן ובשרת |
| תלות בסדר ההגעה | אירועים שמגיעים בתוך 48 שעות מהראשון מאוחדים | עובד בדרך כלל רק כשאירוע הדפדפן הגיע לפני אירוע השרת |
| מגבלה | דורש שהמזהה ייווצר במקום אחד ויעבור לשני הצדדים | לא מאחד אירועים שהגיעו מאותו מקור |
| המעמד | השיטה המומלצת | שיטה חלופית |
בדף הפרמטרים של אירועי השרת event_id מסומן כרשות, אבל מטא מציינת שם שהוא מומלץ לדה-דופליקציה. לכן שולחים אותו בכל אירוע שיוצא משני הערוצים, גם כששולחים בנוסף external_id ו-fbp.
איך בונים event_id נכון?
לפי התיעוד event_id הוא כל מחרוזת ייחודית שתבחרו. לאירועים שיש להם מזהה טבעי, כמו רכישה, מספר ההזמנה או מזהה העסקה מתאים. לאירועים בלי מזהה טבעי אפשר להשתמש במספר אקראי, בתנאי שאותו ערך נשלח מהדפדפן ומהשרת.
בצד הדפדפן המזהה נשלח בארגומנט הרביעי של הקריאה ל-fbq:
fbq('track', 'Purchase', {value: 12, currency: 'USD'}, {eventID: 'EVENT_ID'});לאירוע בלי פרמטרים משאירים אובייקט ריק בארגומנט השלישי. בצד השרת אותו ערך נשלח בשדה event_id, לצד שם אירוע זהה. מבנה סכמטי של אירוע שרת, עם ערכים לדוגמה:
{
"event_name": "Purchase",
"event_time": 1794304800,
"event_id": "EVENT_ID",
"action_source": "website",
"event_source_url": "https://www.example.com/thank-you",
"user_data": { ... }
}- מחליטים איפה המזהה נוצר. מקום אחד בלבד: צד השרת של האתר, ה-dataLayer או משתנה ב-Tag Manager. משם הוא עובר לשני הערוצים.
- שולחים אותו מהפיקסל. בארגומנט הרביעי, במפתח eventID.
- שולחים אותו מהשרת. בשדה event_id, עם event_name זהה לשם האירוע בפיקסל.
- מוודאים ייחודיות. ערך שונה לכל אירוע. מזהה קבוע שחוזר בכל האירועים הוא לא מפתח.
- בודקים ב-Events Manager. לפני שסומכים על המספרים.
את המימוש ב-Google Tag Manager, כולל משתנה אחד שמזין גם את תג הפיקסל וגם את התג בשרת, הסברנו במדריך פיקסלים ב-GTM בתבנית ולא ב-Custom HTML. את צד השרת עצמו פירטנו במדריך הקמת Server-Side GTM.
מה חלון הזמן של הדה-דופליקציה ואיזה אירוע נשמר?
לפי התיעוד אירועים מאוחדים רק אם הגיעו בתוך 48 שעות מהאירוע הראשון עם אותו event_id. אירועים נוספים עם אותו מפתח שמגיעים לאותו פיקסל בחלון הזה נזרקים. כשאין הבדל משמעותי בתוכן בין אירוע הדפדפן לאירוע השרת, מטא מעדיפה בדרך כלל את האירוע שהתקבל ראשון.
לצד חלון הדה-דופליקציה יש מגבלה נפרדת על גיל האירוע. השדה event_time הוא חותמת זמן של Unix בשניות שמתארת מתי האירוע קרה בפועל. לפי התיעוד הוא יכול להיות עד 7 ימים לפני רגע השליחה. אם אירוע אחד בבקשה ישן מ-7 ימים, מטא מחזירה שגיאה על כל הבקשה ולא מעבדת אף אירוע ממנה. בקשה אחת יכולה להכיל עד 1,000 אירועים, לכן אירוע אחד ישן מדי בקבוצה מפיל את כולה.
המלצת התיעוד היא לשלוח אירועי שרת מיד כשהם קורים, רצוי בתוך שעה מהאירוע. לאירועי אתר יש גם שני שדות חובה מעבר לזמן ולשם: event_source_url עם כתובת העמוד שבו האירוע קרה ו-client_user_agent בתוך user_data.
מה זה Event Match Quality ומה משפיע עליו?
דה-דופליקציה עונה על השאלה אם שני אירועים הם אותו אירוע. Event Match Quality עונה על שאלה אחרת: האם מטא מצליחה לשייך את האירוע לאדם. לפי התיעוד זה ציון מתוך 10 שמציין עד כמה פרטי הלקוח שנשלחו מהשרת יעילים בהתאמת האירוע לחשבון במטא. לפי מדריך האימות, אירוע שהותאם לחשבון מנוצל טוב יותר לייחוס ולאופטימיזציה של המודעות. הציון זמין כרגע רק לאירועי אתר. מדריך האימות של מטא ממליץ לכוון לציון של 6.0 ומעלה.
מה שמעלה את הציון הוא יותר פרמטרים של פרטי לקוח באירוע. התיעוד מחלק אותם לכאלה שחייבים גיבוב ולכאלה שאסור לגבב.
| הפרמטר | מה הוא מכיל | גיבוב |
|---|---|---|
| em | אימייל | SHA256 אחרי הסרת רווחים בקצוות והמרה לאותיות קטנות |
| ph | טלפון | SHA256 אחרי הסרת סימנים, אותיות ואפסים מובילים. חייב לכלול קידומת מדינה |
| fn, ln, ge, db | שם פרטי, שם משפחה, מגדר, תאריך לידה | SHA256 |
| ct, st, zp, country | עיר, מדינה או מחוז, מיקוד, ארץ | SHA256 |
| external_id | מזהה לקוח משלכם | גיבוב מומלץ |
| client_ip_address, client_user_agent | כתובת ה-IP ומחרוזת הדפדפן של הגולש | לא מגבבים |
| fbp, fbc | מזהה הדפדפן ומזהה הקליק | לא מגבבים |
התיעוד מדגיש במיוחד ש-client_ip_address לעולם לא מגובב. טעות נפוצה היא פונקציית גיבוב אחת שעוברת על כל האובייקט, כולל ה-IP וערכי העוגיות. התוצאה היא ערכים שמטא לא יכולה להשתמש בהם להתאמה.
מה התפקיד של fbp ו-fbc?
אלה שני ערכי עוגיות שהפיקסל יוצר ושכדאי להעביר גם באירועי השרת. לפי התיעוד, כשהפיקסל מותקן ומשתמש בעוגיות צד ראשון הוא שומר אוטומטית מזהה ייחודי בעוגייה _fbp. העוגייה _fbc מכילה את ה-ClickID, הערך שמטא מוסיפה לכתובת בפרמטר fbclid כשגולש לוחץ על מודעה.
המבנה של שתיהן דומה: fb, אינדקס של תת הדומיין, זמן היצירה באלפיות שנייה ואחריו מספר אקראי ב-fbp או ערך ה-fbclid ב-fbc. שלושה כללים מהתיעוד. מטא ממליצה לשלוח את fbc עם כל אירוע שנשלח ל-Conversions API. ערך ה-ClickID רגיש לאותיות גדולות וקטנות ואסור לשנות אותו. הערכים יכולים להשתנות בין סשנים, לכן קוראים אותם מהעוגיות בכל אירוע ולא שומרים פעם אחת לתמיד. כשאין פיקסל אפשר לבנות את fbc בעצמכם מהפרמטר fbclid שבכתובת.
איך בודקים דה-דופליקציה ואיכות התאמה ב-Events Manager?
- שולחים אירוע בדיקה. בכלי Test Events מקבלים קוד ומוסיפים אותו לבקשה בפרמטר test_event_code. לפי התיעוד גם אירועים עם הקוד נכנסים ל-Events Manager ומשמשים למדידה. לכן מסירים אותו לפני המעבר לפרודקשן.
- מוודאים קליטה. לפי התיעוד אפשר לראות את האירועים בתוך 20 דקות מהשליחה. בלשונית Overview של מקור הנתונים, תחת Connection Method, רואים מאיזה ערוץ הגיע כל אירוע.
- פותחים את Event Deduplication. לוחצים על Event Details של סוג האירוע ועוברים ללשונית. Rate of Events Deduplicated מציג את אחוז האירועים שאוחדו בכל מקור. Rate of Deduplication Key Usage מציג כמה מהאירועים כוללים כל מפתח. Overlap מציג כמה מהאירועים עם מפתח מסוים הגיעו משני המקורות.
- מפרשים Overlap נמוך. לפי התיעוד זה מצביע על מפתחות לא ייחודיים באחד המקורות או על מפתח שנשלח רק ממקור אחד.
- בודקים את הציון ואת הטריות. לחיצה על ציון ה-Event Match Quality פותחת פירוט והמלצות. הלשונית Event Freshness מציגה את ההשהיה הממוצעת בסולם שנע מ-Real Time עד Weekly.
אילו טעויות יוצרות ספירה כפולה או אירועים שלא נספרים?
מזהה שנוצר פעמיים. הדפדפן מגריל ערך אחד והשרת מגריל ערך אחר, כך ששני האירועים תקינים ומטא סופרת את שניהם. זאת טעות שחוזרת בבדיקות.
שם אירוע שונה בין הערוצים. המזהה זהה, אבל הפיקסל שולח שם אחד והשרת שם אחר. לפי התיעוד ההתאמה דורשת את שניהם.
הסתמכות על fbp בלבד. השיטה החלופית עובדת בדרך כלל רק כשאירוע הדפדפן הגיע קודם. לפי התיעוד, אירוע שרת לא ייזרק אם לא התקבל אירוע דפדפן ב-48 השעות שלפניו, גם אם אירוע דפדפן זהה מגיע אחריו.
שליחה באיחור. אירוע שרת שנשלח אחרי יותר מ-48 שעות מאירוע הדפדפן כבר מחוץ לחלון האיחוד. אחרי 7 ימים הוא נדחה לגמרי, יחד עם כל הבקשה שבה נשלח.
שאלות נפוצות
מה זה event_id ב-Meta Conversions API?
event_id הוא מחרוזת ייחודית שמזהה אירוע אחד. לפי התיעוד של מטא, כשאותו אירוע נשלח גם מהפיקסל וגם מה-Conversions API, ה-eventID מהפיקסל חייב להיות זהה ל-event_id מהשרת. גם שם האירוע חייב להיות זהה. מספר הזמנה או מזהה עסקה מתאימים. לאירועים בלי מזהה טבעי אפשר להשתמש במספר אקראי שנשלח זהה משני הצדדים.
מה חלון הזמן של דה-דופליקציה במטא?
לפי התיעוד של מטא אירועים מאוחדים רק אם הגיעו בתוך 48 שעות מהאירוע הראשון עם אותו event_id. אירועים נוספים עם אותו מפתח שמגיעים לאותו פיקסל בחלון הזה נזרקים. כשאין הבדל משמעותי בתוכן, מטא מעדיפה בדרך כלל את האירוע שהתקבל ראשון.
האם חייבים דה-דופליקציה בכל אירוע של Conversions API?
לא. לפי התיעוד של מטא דה-דופליקציה נדרשת רק כשאותו אירוע נשלח גם מהפיקסל וגם מה-Conversions API. אירוע שנשלח רק מהשרת, למשל שינוי סטטוס של ליד ב-CRM, לא צריך אותה. בדף הפרמטרים event_id מסומן כרשות, אבל מטא מציינת שהוא מומלץ לדה-דופליקציה.
מה זה Event Match Quality?
Event Match Quality הוא ציון מתוך 10 שמטא מציגה ב-Events Manager. לפי התיעוד הוא מציין עד כמה פרטי הלקוח שנשלחו מהשרת יעילים בהתאמת האירוע לחשבון במטא. אירוע שהותאם לחשבון מנוצל טוב יותר לייחוס ולאופטימיזציה. מדריך האימות של מטא ממליץ לכוון לציון של 6.0 ומעלה. הציון זמין כרגע רק לאירועי אתר.
אילו פרמטרים מגבבים ואילו לא ב-Conversions API?
לפי התיעוד של מטא חובה לגבב ב-SHA256 את em, ph, fn, ln, ge, db, ct, st, zp ו-country. ל-external_id הגיבוב מומלץ. את client_ip_address, client_user_agent, fbp ו-fbc לא מגבבים. התיעוד מדגיש שכתובת ה-IP לעולם לא מגובבת. אימייל מנרמלים לפני הגיבוב: מסירים רווחים בקצוות וממירים לאותיות קטנות.
איך בודקים שהדה-דופליקציה עובדת?
ב-Events Manager לוחצים על Event Details של סוג האירוע ופותחים את הלשונית Event Deduplication. היא מציגה את אחוז האירועים שאוחדו, את השימוש בכל מפתח ואת ה-Overlap, כלומר כמה מהאירועים עם אותו מפתח הגיעו משני המקורות. לפי התיעוד Overlap נמוך מצביע על מפתחות לא ייחודיים או על מפתח שנשלח רק ממקור אחד.
מה השורה התחתונה?
שליחה כפולה מהפיקסל ומה-Conversions API שווה משהו רק כשמטא יודעת לאחד את שני האירועים וגם לשייך אותם לאדם. הראשון תלוי במזהה אחד שנוצר במקום אחד ונשלח בשני הערוצים עם אותו שם אירוע. השני תלוי בפרטי הלקוח שמצורפים לאירוע השרת, מגובבים נכון, יחד עם fbp, fbc, כתובת IP ו-user agent שלא מגובבים. את שניהם רואים ב-Events Manager, לכן אין סיבה לנחש. אנחנו מקימים ובודקים מערכים כאלה כחלק משירות מדידה מתקדמת, כולל צד השרת וההסכמה. אם מספר הרכישות במטא גבוה מהמספר במערכת ההזמנות או שציון ההתאמה נמוך, כתבו לנו.
מקורות
Meta for Developers: Handling Duplicate Pixel and Conversions API Events, Meta for Developers: Server Event Parameters, Meta for Developers: Using the API, Meta for Developers: Customer Information Parameters, Meta for Developers: ClickID and the fbp and fbc Parameters, Meta for Developers: Verifying Your Setup, Meta for Developers: Dataset Quality API
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי