Google Ads ו־Meta מציגות יותר המרות מהזמנות. איך משווים נכון?

בסוף החודש מחברים את הרכישות שמדווחות Google Ads ו־Meta, ומגלים שהסכום גבוה ממרישום ההזמנות בחנות. זה רגע מתסכל, אבל לפני שמשנים את התיוג כדאי לבדוק מה בדיוק כל מספר מייצג. מערכת ההזמנות מתעדת עסקאות; כל פלטפורמת פרסום מייחסת תוצאות למודעות לפי הכללים שלה.

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

איך אותה הזמנה מופיעה בשתי פלטפורמות?

לקוח עשוי ללחוץ על מודעה ב־Google, לראות בהמשך מודעה ב־Meta ולבסוף לקנות. אם הרכישה עומדת בכללי הייחוס של שתיהן, כל אחת עשויה לספור אותה כתוצאה שלה. לכן סכום ההמרות המדווחות לא בהכרח שווה למרישום ההזמנות הייחודיות. פער כשלעצמו אינו הוכחה להונאה או לתקלה במדידה.

שליחה כפולה של אותו אירוע רכישה היא בעיה אחרת. למשל, כששולחים מהדפדפן ומהשרת, צריך לבדוק את הגדרת מניעת הכפילויות לפי תיעוד המימוש. ב־Google השדה transaction_id יכול לסייע במניעת ספירה חוזרת בתוך אותה פעולת המרה, אך אינו מסיר חפיפה בין Google ל־Meta. מזהה ההזמנה צריך להיות ייחודי ויציב, ללא פרטים אישיים.

אילו הגדרות צריך ליישר לפני ההשוואה?

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

עמודות ההמרה הרגילות ב־Google Ads מבוססות על מועד האינטראקציה עם המודעה. בהשוואה לרישום הזמנות לפי מועד הרכישה, כדאי לבדוק גם עמודות לפי זמן ההמרה. גם כשהתאריכים תואמים, הבדלי הייחוס נשארים. הנתונים עשויים להתעדכן בעקבות עיבוד או הערכה, ולכן חשוב לדעת מתי נמשכו.

Meta הודיעה ב־2026 על שינויים במדידה דרך קליקים ואינטראקציות, ומועד כניסתם לתוקף עשוי להשתנות בין מפרסמים. בדקו בייצוא שלכם את ההגדרות העדכניות של קליק, צפייה ואינטראקציה ואת החלונות בפועל. אין צורך להניח שקיימת הגדרת ברירת מחדל אחת שמתאימה לכולם.

שש הזמנות, שבע המרות: דוגמה שאפשר לבדוק

כל הנתונים הבאים בדיוניים ונועדו להמחשה. שש ההזמנות שולמו ועומדות בתנאי הספירה. תאריך כולן הוא 1 בספטמבר 2026, אזור הזמן UTC והמטבע אירו. הסכומים אינם כוללים מס ומשלוח ואין החזרים. הקישור בין כל הזמנה לפלטפורמות סופק במיוחד לדוגמה; זו אינה הבטחה שאפשר לקבל מיפוי כזה בייצוא רגיל ממערכות הפרסום.

ברישום ההזמנות יש 6 הזמנות בשווי 700 אירו. Google מייחסת לעצמה 4 בשווי 570 אירו, ו־Meta מייחסת לעצמה 3 בשווי 300 אירו. חיבור פשוט נותן 7 המרות ו־870 אירו. ההזמנות A100 ו־A103 נכללות אצל שתיהן, ולכן החפיפה היא 2 הזמנות בשווי 220 אירו.

מרישום ההזמנות שמופיעות אצל לפחות אחת מהפלטפורמות הוא 4 ועוד 3 פחות 2, כלומר 5, בשווי 650 אירו. מוסיפים את A104, הזמנה אחת בשווי 50 אירו שאין לה תיעוד ייחוס לאף אחת מהן, ומגיעים ל־6 הזמנות ול־700 אירו. גם בכסף: 570 ועוד 300 פחות 220 ועוד 50 הם 700.

הפער בין 7 ל־6 הוא 1, אבל החפיפה היא 2. אי אפשר להסיק את החפיפה מההפרש בין הסכומים הכוללים. החישוב מתאים כאן כי יש תיעוד מלא ובר־השוואה ברמת ההזמנה. אין להחיל אותו ישירות על נתונים מצרפיים, המרות מחושבות במודל או ייחוס חלקי בשברים, שאין להם מיפוי תואם להזמנות.

בלי תיעוד מספק, משאירים את הקישור כלא ידוע

התחילו ברישום ההזמנות או במערכת ניהול קשרי הלקוחות. החילו את כללי התשלום, הביטול וההחזר שסוכמו, וספרו מזהי הזמנה ייחודיים ואת שוויים. זהו בסיס למרישום ההזמנות ולסכום במסגרת העסקית שהוגדרה. הוא אינו מוכיח איזו מודעה גרמה לקנייה; ייחוס ותוספת מכירות שנגרמה בזכות הפרסום הם שאלות נפרדות.

אם יש מידע ממקורות העסק שמותר להשתמש בו, התאימו רק את ההזמנות שהוא תומך בהן וציינו את המקור. דוח Google Ads רגיל אינו מספק בהכרח מפת ייחוס מלאה לכל הזמנה, וגם transaction_id אינו שדה זמין בדוח הזמנות סטנדרטי. חוסר ראיה לקישור אינו ראיה לכך שלפרסום לא הייתה השפעה.

בדוגמה, 1 מציין ייחוס שאומת ו־0 מציין שאומת שאין ייחוס לפלטפורמה בתוך התיעוד שנבדק. בתבנית האמיתית תא ריק מציין מידע לא ידוע או תיעוד לא מספיק. ערכו את הקובץ מקומית, בלי שמות לקוחות או כתובות דוא״ל, ואל תפרסמו נתוני לקוחות.

איפה בינה מלאכותית יכולה לחסוך עבודה?

אפשר להיעזר בה למיפוי עמודות, לאיתור שדות חסרים ולניסוח הסבר על בסיס נתונים שכבר נבדקו. עדיין נדרשת בדיקה: שתי עמודות בשם ״הכנסה״ ו״שווי רכישה״ עשויות לחשב מס, משלוח או החזרים באופן שונה. התאמה בשם אינה מספיקה.

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

דוח שההנהלה יכולה להבין ולבדוק

הציגו לצד נתוני ההזמנות של העסק את נתוני Google ואת נתוני Meta בנפרד. כשיש תיעוד מתאים, הוסיפו את החפיפה שאומתה ואת היקף ההתאמה. ציינו בבירור מה לא הותאם, מה חושב במודל ומה קיים רק כסכום כולל, לצד ההנחות ששימשו אתכם.

1. תקופה, אזור זמן, בסיס התאריך ומועד הפקת הנתונים.
2. תנאי הכללת ההזמנות, מטבע, מס, משלוח והחזרים.
3. אירועים, חלונות ייחוס, מודלים והגדרות האינטראקציה העדכניות, כולל הגדרת פעולות ההמרה הראשיות והמשניות ב־Google.
4. בדיקת אירועים כפולים, בנפרד מחפיפה מוכחת בין הפלטפורמות.
5. שאלות פתוחות, אחריות לכללים ותיעוד של הבדיקה.

אם ההתאמה חוזרת מדי חודש, אפשר להתחיל בתהליך אחד מוגדר במסגרת השקת תהליך עבודה עם בינה מלאכותית (AI Workflow Launch) של MindVerve. קובעים מקורות וכללים, בודקים גם מקרים חריגים, ועוברים סקירה והעברה מסודרת לצוות.