Facebook CAPI לעומק: איך מטא באמת מקבלת את ההמרות

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

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

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

מסלול קריאה מומלץ: מהי מדידה ← Server-Side GTM ← CAPI (כאן)

CAPI היא לא עוד פיקסל. היא ערוץ מדידה שני, שלא נשבר יחד עם הדפדפן.

בקצרה: Facebook CAPI (Conversions API) הוא ערוץ שרת-לשרת שמשלים את הפיקסל: הוא שולח אירועים למטא ישירות מהשרת, עם Event ID משותף לדדופליקציה, ומזהי fbp/fbc ופרמטרים מוצפנים לשיפור Event Match Quality. המדריך הזה מתמקד ב-CAPI עצמו, על התשתית הרחבה (sGTM, Consent) יש מדריך נפרד.

פיקסל מול CAPI

למטא יש שני ערוצים לקבל אירועים, והם משלימים זה את זה:

Meta Pixel רץ בדפדפן. מהיר, אבל נחסם על ידי חוסמי פרסום, iOS/ATT ומגבלות דפדפן.
Conversions API (CAPI) רץ בשרת. שולח את אותם אירועים ישירות למטא, ולא תלוי בדפדפן.

אירוערכישה · ליד

←

פיקסלדפדפן

CAPIשרת

←

דדופEvent ID

←

Meta לומדת

כשמטא רואה רק חלק מהאירועים, האלגוריתם לומד מתמונה חלקית, ולכן קשה לו יותר למצוא אנשים שדומים למי שבאמת המיר. (על התשתית הרחבה, sGTM, Consent Mode והכל, יש את מדריך המדידה server-side. כאן נצלול ל-CAPI עצמו.)

אילו אירועים כדאי לשלוח

מטא תומכת בשורת אירועים סטנדרטיים:

PageViewViewContentAddToCartInitiateCheckoutLeadCompleteRegistrationPurchase

אבל לא חייבים לשלוח הכול. עדיף לשלוח מעט אירועים בצורה נכונה, עם דדופליקציה ו-EMQ גבוה, מאשר הרבה אירועים באיכות נמוכה. בחרו את האירועים שבאמת מייצגים ערך עסקי (בדרך כלל Purchase ו-Lead).

Event ID ודדופליקציה

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

דדופליקציה שבורה (Event ID שונה בין הערוצים) היא הטעות הכי נפוצה ביישום CAPI, והיא מנפחת את כל הנתונים.

fbp ו-fbc

שני מזהים שהפיקסל שומר בדפדפן, ושחשוב להעביר גם ל-CAPI:

fbp (Facebook Browser ID): מזהה את הדפדפן/המשתמש.
fbc (Facebook Click ID): נגזר מ-fbclid, ומזהה מאיזו מודעה הגיע הקליק.

העברת fbp ו-fbc ל-CAPI היא אחד הדברים שהכי משפרים את ההתאמה, ובלעדיהם CAPI מאבד הרבה מהעוצמה שלו.

Event Match Quality (EMQ)

מטא צריכה להתאים כל אירוע למשתמש. ככל שתשלחו יותר פרמטרים, אימייל וטלפון מוצפנים, fbp, fbc, שם ועיר, כך ההתאמה טובה יותר, וזה נמדד כ-Event Match Quality (ציון פר-אירוע ב-Events Manager).

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

First Party Data: למה בכלל מצפינים ושולחים פרטים

מטא כבר לא מסתמכת רק על Cookies, הם נחסמים ונמחקים. היום היא נשענת בעיקר על First Party Data: מידע שהעסק אסף בהסכמה (אימייל, טלפון), שנשלח מוצפן (Hashing) כדי לשמור על פרטיות. ההצפנה הופכת את הפרטים לחתימה שמטא יכולה להתאים בלי לחשוף את הנתון עצמו.

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

איך בודקים שה-CAPI באמת עובד

זו השאלה שכל מי שמקים CAPI שואל, וכאן בודקים אותה, ב-Meta Events Manager:

האם האירוע הגיע? רואים אותו נכנס ב-Overview.
דרך Browser וגם Server? עמודת המקור מראה משני הערוצים.
בוצעה דדופליקציה? מטא מסמנת אירועים שאוחדו.
מה ציון ה-EMQ? ציון ההתאמה מוצג פר-אירוע.
יש אזהרות ב-Diagnostics? לשונית ה-Diagnostics מתריעה על בעיות (פרמטרים חסרים, דדופ שבור).

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

טעויות נפוצות

Event ID שונה בין הערוצים, שמוביל לספירה כפולה.
EMQ נמוך, כי לא שולחים מספיק פרמטרים מוצפנים.
לא מעבירים fbp/fbc ל-CAPI, ומאבדים התאמה.
שליחת אירועים בלי הסכמה (Consent).
ערכי המרה שגויים, שמלמדים את האלגוריתם דבר לא נכון.
לשלוח יותר מדי אירועים באיכות נמוכה במקום מעט נכון.

מעבר לאתר: עסקאות אופליין

CAPI לא חייב לעצור באתר. כשמחברים אותו ל-CRM, אפשר לשלוח למטא גם עסקאות שנסגרו מאוחר יותר, בטלפון או בסניף, כ-Offline Conversions:

מודעה

←

אתר

←

Lead

←

CRM

←

עסקה

←

Offline Conversion

←

מה CAPI לא עושה (החלק הכן)

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

איך מתחילים

מקימים CAPI דרך Server-side GTM (למשל Stape).
מריצים פיקסל + CAPI עם Event ID משותף (דדופ), ומעבירים fbp/fbc.
שולחים פרמטרים מוצפנים לשיפור ה-EMQ.
בודקים ב-Events Manager (Test Events + Diagnostics) שהכל תקין.
מחברים ל-CRM לעסקאות אופליין.

מושגים שהוזכרו במדריך

Meta PixelConversions API (CAPI)Event IDדדופליקציה (Deduplication)Event Match Quality (EMQ)fbpfbcTest EventsEvents ManagerDiagnosticsFirst Party DataHashingOffline ConversionsConsent

מקורות וקישורים

Meta · Conversions API · Stape · מדידה server-side · ניהול לידים

שאלות נפוצות

שאלות ותשובות על Facebook CAPI

מה זה Facebook CAPI?

Conversions API הוא חיבור שרת-לשרת ששולח אירועי המרה ישירות מהשרת שלכם למטא, במקביל לפיקסל שבדפדפן, כדי שמטא תקבל גם את מה שהדפדפן מפספס.

האם CAPI עובד גם בלי Pixel?

טכנית כן, אבל לא מומלץ. הפיקסל מספק את fbp/fbc ואת האיתות בזמן אמת מהדפדפן, ו-CAPI משלים אותו. הכי טוב להריץ את שניהם יחד עם דדופליקציה.

האם Shopify כבר כולל CAPI?

כן, ל-Shopify יש אינטגרציה מובנית ל-CAPI דרך Meta. עדיין כדאי לוודא דדופליקציה ואיכות התאמה טובה.

האם WooCommerce תומך ב-CAPI?

כן, דרך תוספים או דרך Server-side GTM. ההקמה דרך sGTM נותנת יותר שליטה על דדופליקציה ו-EMQ.

האם אפשר לשלוח Events מה-CRM?

כן. זה בדיוק הבסיס ל-Offline Conversions: כשעסקה נסגרת ב-CRM, שולחים אותה למטא עם נתוני המשתמש, כדי שהאלגוריתם ילמד מעסקאות אמיתיות.

האם צריך לבצע Hash ידני?

לא. כלים כמו Server-side GTM מבצעים את ההצפנה (Hashing) של האימייל והטלפון אוטומטית לפני השליחה למטא.

איך מונעים ספירה כפולה?

דרך Event ID משותף לפיקסל ול-CAPI, יחד עם fbp/fbc. מטא מזהה שזה אותו אירוע וסופרת פעם אחת.

מה זה Event Match Quality?

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

איך יודעים שה-CAPI באמת עובד?

בודקים ב-Meta Events Manager: האם האירוע הגיע, האם דרך Browser וגם Server, האם בוצעה דדופליקציה, מה ציון ה-EMQ, והאם יש אזהרות ב-Diagnostics. כלי Test Events מראה אירועים בזמן אמת.