איחוד אירועים כפולים: איך מונעים ספירה כפולה בין הפיקסל לשרת
שם אירוע, מזהה משותף ובדיקת הזמנה: איך מאתרים כפילות בלי לבלבל אותה עם פערי ייחוס.
איחוד אירועים כפולים ב־Meta: מתחילים בעסקה אחת שניתן לבדוק
פער בין מספר הרכישות ב־Meta לבין ההזמנות בחנות מצדיק בדיקה, אך אינו מוכיח כפילות. לפני שינוי בהטמעה בוחרים רכישת בדיקה ומבררים אילו מערכות דיווחו עליה. המטרה היא שפעולת רכישה אחת תזוהה כאירוע אחד גם כאשר היא נשלחת מהדפדפן ומהשרת.
שלוש תקלות שדורשות טיפול שונה
- הדפדפן והשרת מדווחים על אותה רכישה: מגדירים התאמה ביניהם באמצעות שם ומזהה אירוע משותפים.
- שתי התקנות מדווחות מאותו מקור: ממפים תוסף, תג במנהל תגים וקוד בתבנית. קובעים מי אחראי לכל אירוע ומסירים רק את ההפעלה העודפת לאחר בדיקה. אין להסתמך על איחוד בין דפדפן לשרת כדי לתקן כל שליחה כפולה.
- רענון או ניסיון חוזר מייצרים רכישה חדשה: מתקנים את תנאי ההפעלה ושומרים את הזהות של העסקה המקורית. פתיחת דף תודה אינה בהכרח אישור לתשלום חדש.
מה בדיוק צריך להתאים
לפי תיעוד האיחוד של Meta, השיטה המומלצת משווה את שם האירוע ואת מזהה האירוע. בפיקסל השם הוא למשל Purchase והמזהה נשלח באפשרות eventID; ב־Conversions API השדות המקבילים הם event_name ו־event_id. שני הדיווחים צריכים להגיע לאותו Pixel ID. התיעוד מציין חלון קבלה של 48 שעות מהאירוע הראשון בעל אותו מזהה.
הבדלי אותיות, רווחים או מזהים שנוצרו בנפרד עלולים למנוע התאמה. אין צורך ששתי הבקשות יגיעו באותה שנייה. גם משלוח באצווה בסוף היום אינו מוכיח חריגה מחלון האיחוד; עם זאת, עדיף לטפל בעיכוב ולבדוק את זמני האירוע והקבלה. חלון איחוד אינו המלצה להמתין 48 שעות לפני דיווח.
דוגמת מיפוי להמחשה, לא קוד להתקנה
| פעולה עסקית | בדפדפן | בשרת |
|---|---|---|
| רכישה מאושרת של הזמנה לדוגמה 731 | Purchase, eventID = purchase_731 | event_name = Purchase, event_id = purchase_731 |
| שליחה חוזרת של אותו אישור | אין יצירת זהות רכישה חדשה | אותו מזהה שנשמר להזמנה |
| רכישה אחרת, הזמנה 732 | Purchase, eventID = purchase_732 | event_name = Purchase, event_id = purchase_732 |
מספר הזמנה יכול להיות בסיס למזהה אם הוא ייחודי במערכת המדווחת, נשמר בשני הצדדים ואינו כולל מידע אישי. בחיבור כמה חנויות צריך למנוע התנגשות בין מספרי הזמנות. אין להשתמש באותו מזהה לכל הרכישות של לקוח או לכל רכישות היום. מפתח סודי של השרת אינו שייך לקוד הדפדפן.
מזהה אירוע, מזהה מוצר וזיהוי אדם הם דברים שונים
event_id מזהה פעולה מסוימת. content_ids מזהה את המוצרים שאליהם הפעולה מתייחסת, וצריך להתאים לקטלוג כפי שמוסבר ב־חיבור הקטלוג לפיקסל. אותו מוצר יכול להירכש בהזמנות רבות, ולכן מזהה המוצר לבדו אינו מזהה ייחודי לרכישה. פרטי התאמה לאדם משמשים תפקיד נוסף; ציון התאמה גבוה אינו הוכחה שאיחוד האירועים תקין.
ספירת אירוע פעמיים גם אינה אומרת שאותו אדם מופיע פעמיים בקהל רוכשים. תקינות החברות בקהל תלויה בכללי הקהל, באיסוף ובהתאמה, כפי שמוסבר ב־מדריך קהל מבקרי האתר.
בדיקת קבלה שאפשר למסור למי שמטמיע
- רשמו את ההתקנות הפעילות, ה־Pixel ID ותנאי ההפעלה של Purchase. בדקו אותם מול ההגדרה הבסיסית של הפיקסל לפני הוספת קוד נוסף.
- בסביבת בדיקה מתאימה בצעו הזמנה אחת בנתוני בדיקה, וצפו בפרטי האירוע באמצעות כלי הבדיקה של Meta והאינטגרציה. השוו שם, מזהה, מקור, זמן, ערך ומטבע. אל תשתפו פרטי לקוח או אסימוני גישה בצילום האבחון.
- בדקו רענון דף תודה, שליחה חוזרת מהשרת ורכישה שנייה. שתי הזמנות אמיתיות חייבות להישאר שתי פעולות שונות; ניסיון חוזר לא אמור להפוך להזמנה חדשה.
- בדקו תשלום שנכשל ותשלום שממתין לאישור. ודאו ש־Purchase מייצג את השלב העסקי שהוגדר, ולא כל ביקור בקופה.
- תעדו את התוצאה, את שינוי ההטמעה ואת מועדו. בדקו אבחון ואיחוד גם לאחר שהמידע עובד במערכות; תצוגת שתי בקשות גולמיות לבדה אינה הוכחה לשתי המרות מעובדות.
למה משאירים שני מקורות, ומה הם אינם פותרים
הפיקסל והשרת יכולים להשלים דיווח זה של זה, אך אף מקור אינו מבטיח כיסוי מלא. CAPI אינו דרך לעקוף סירוב להסכמה או מגבלות שימוש בנתונים. דרישות הפרטיות של Meta חלות על שני המקורות; בדיקת הקבלה צריכה לכלול גם מצב שבו אין הסכמה נדרשת ולא נשלח מידע אסור.
לאחר התיקון השוו בנפרד אירועים שהתקבלו, רכישות שיוחסו למודעות והזמנות ששולמו בפועל. אזור זמן, ייחוס, ביטולים, החזרים ואירועים חסרים יכולים להסביר פערים נוספים. אין לאבחן את הסיבה לפי יחס של פי שניים בלבד. לחישוב המדד העסקי ראו חישוב אחוז המרה בקמפיין, ולהפרדת מקורות שיווק ראו מעקב מקור פנייה. ירידה בספירה אחרי תיקון אינה כשלעצמה ירידה במכירות.
שאלות נפוצות
אם הפיקסל והשרת שולחים את אותו אירוע, למה בכלל להשאיר את שניהם?
הם עשויים להשלים את הדיווח זה של זה. כששניהם שולחים אותה פעולה צריך לאחד אותה לפי התנאים של Meta. CAPI אינו מבטיח כיסוי מלא ואינו עוקף סירוב להסכמה; דרישות הפרטיות חלות גם על השרת.
מה יכול לשמש כמזהה אירוע?
מזהה ייחודי לפעולה עסקית אחת, שנשמר ומועבר זהה לשני המקורות. מספר הזמנה יכול להתאים לרכישה אם הוא ייחודי במערכת ואינו כולל מידע אישי. מוצר, לקוח או תאריך לבדם אינם מזהים רכישה יחידה. בניסיון חוזר של אותה רכישה אין ליצור מזהה חדש.
האם האיחוד עובד גם אם הדיווחים לא מגיעים באותו רגע?
כן. תיעוד Meta מציין התאמת eventID ו־event_id יחד עם שם האירוע, לאותו Pixel ID, כאשר האירועים מתקבלים בתוך 48 שעות מהראשון עם אותו מזהה. זה אינו יעד לעיכוב מכוון. משלוח בסוף היום אינו לבדו ראיה לחריגה; בודקים את הזמנים וההגדרה בפועל.
המספרים עדיין שונים אחרי התיקון. זו עדיין כפילות?
אי אפשר לקבוע מהסכום בלבד. בודקים עסקאות לדוגמה ואז מפרידים בין אירועים שהתקבלו, המרות שיוחסו לפרסום והזמנות ששולמו. ייחוס, אזור זמן, ביטולים, החזרים ואירועים חסרים יכולים ליצור פער נוסף. בדיקת איחוד תקינה אינה מבטיחה התאמה מלאה בין הדוחות.
