Meta Conversions API ללידים מה-CRM: איך מחזירים למטא את איכות הלידים ולא רק את כמות הטפסים

נכתב על ידי דני צ'רניאק, DigiKnowledge. נבדק לאחרונה: 24.10.2026

למה מטא רואה רק את כמות הטפסים ומה זה עושה לקמפיין?

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

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

מה ההבדל בין CAPI לאירועי אתר לבין Conversions API for CRM?

שני המסלולים משתמשים באותו ממשק API של Meta, אבל הם שתי אינטגרציות שונות עם פרמטרים שונים ומקור נתונים שונה. Meta מציינת זאת במפורש בתיעוד: הפרמטרים הנדרשים שונים והנתונים מגיעים מה-CRM ולא משרתי האתר. ההבחנה הזו קובעת איך בונים את החיבור ומה הוא מאפשר.

CAPI לאירועי אתר משכפל את אירועי הפיקסל מצד השרת. הגולש ממלא טופס באתר, הפיקסל שולח Lead מהדפדפן והשרת שולח את אותו Lead עם אותו event_id. מטא מסירה את הכפילות ומשתמשת באירוע השרת כשהדפדפן נחסם. כאן המזהים הם אימייל וטלפון מגובבים, העוגיות fbc ו-fbp, כתובת IP ו-User Agent. Conversions API for CRM, לעומת זאת, נועד ללידים שנוצרו ב-Instant Forms של פייסבוק ואינסטגרם. שם המזהה המרכזי הוא Lead ID של מטא, מספר בן 15 עד 17 ספרות שמגיע עם הליד בהורדה ל-CRM. האירועים נשלחים עם action_source בערך system_generated, עם custom_data.event_source בערך crm ולדאטהסט נפרד שמיועד ל-CRM. רק המסלול הזה פותח את יעד הביצועים Conversion Leads בקמפיין.

הכלל המעשי שלנו: אם רוב הלידים מגיעים מ-Instant Forms, בונים את מסלול ה-CRM לפי תנאי הסף של Meta. אם רוב הלידים מגיעים מטפסים באתר, בונים CAPI לאירועי אתר ושולחים את שלבי המשפך כאירועי שרת לאותו דאטהסט של האתר, כפי שמוסבר בהמשך. כשיש שני המקורות, לרוב מנהלים שני חיבורים נפרדים ולא מערבבים ביניהם.

איך נראית מפת סטטוסים משישה שלבים ממילוי הטופס ועד העסקה?

הטבלה הבאה היא מפת סטטוסים לדוגמה שאנחנו בונים עם הלקוח לפני שכותבים שורת קוד אחת. השלבים והערכים הם נתוני דמו של עסק שירותים עם עסקה ממוצעת של 3,000 ש"ח. בכל ארגון השמות שונים, אבל העיקרון קבוע: לכל סטטוס ב-CRM יש אירוע אחד, רגע שליחה מוגדר וערך שמשקף את הסבירות לעסקה.

כמה כללים שנגזרים ישירות מהתיעוד של Meta. חובה לשלוח את השלב הראשון, הליד הגולמי, תמיד. Meta דורשת לפחות שני שלבים כולל השלב הראשון וממליצה על שלושה או יותר. שולחים כל שינוי סטטוס כאירוע נפרד, כך שליד אחד מייצר כמה אירועים עם אותו lead_id. ערך event_time חייב להיות מאוחר מזמן יצירת הליד, אחרת האירוע נזרק. שלב היעד שבוחרים לאופטימיזציה צריך להתרחש בתוך 28 יום מיצירת הליד ושיעור ההמרה אליו צריך להיות בין 1 ל-40 אחוז מהלידים. בדוגמה שלמעלה, שלב "ליד מוכשר" הוא לרוב המועמד הנכון: הוא קרוב מספיק לטופס כדי לקרות בתוך השבועות הראשונים ורחוק מספיק כדי לסנן טפסים חסרי ערך. אם רק חצי אחוז מהלידים מגיעים לעסקה, אופטימיזציה ישירה לעסקה לא תעבוד, כי אין למערכת מספיק אותות ללמוד מהם.

על סטטוסים שליליים, כמו "לא רלוונטי" או "לא עונה", אנחנו לא שולחים אירוע. ההיעדר של אירוע qualified הוא האות שהמערכת צריכה. עמודת הערך משמשת לדיווח ולמסלול אירועי האתר. ביעד Conversion Leads המערכת לומדת מהשלב עצמו ולא מהערך.

מה עושים כשהלידים מגיעים מטופס באתר ולא מ-Instant Form?

זה המצב הנפוץ אצל רוב הארגונים בישראל: המודעה במטא מובילה לדף נחיתה, הטופס באתר, הליד נכנס ל-CRM דרך האתר ואין Lead ID של מטא. יעד הביצועים Conversion Leads לא זמין כאן, כי לפי Meta הוא תואם רק ל-Instant Forms. עדיין אפשר להחזיר את איכות הלידים, בדרך אחרת.

העיקרון: אוספים את מזהי ההתאמה ברגע מילוי הטופס ושומרים אותם ב-CRM לצד הליד. אימייל וטלפון נשמרים כרגיל. בנוסף שומרים את ערך העוגייה _fbc, שנוצרת מפרמטר fbclid שבכתובת הנחיתה והמבנה שלה הוא fb.1.זמן_יצירה.fbclid, את העוגייה _fbp ואת כתובת העמוד. מומלץ גם מזהה פנימי של הליד כ-external_id. בשדות נסתרים בטופס או דרך ה-dataLayer ב-Google Tag Manager זה נעשה בלי מעורבות של נציג. כשהסטטוס משתנה ב-CRM, שולחים אירוע שרת לאותו דאטהסט של האתר עם user_data שכולל את em ו-ph מגובבים ואת fbc ו-fbp כפי שהם. Meta מתאימה את האירוע למשתמש ולקליק על המודעה גם בלי Lead ID.

הגיבוב חייב להיעשות לפי כללי הנרמול של Meta, אחרת ההתאמה נכשלת. אימייל: מסירים רווחים בתחילה ובסוף וממירים לאותיות קטנות. טלפון: מסירים סימנים, אותיות ואפסים מובילים ומוסיפים קידומת מדינה. מספר ישראלי 050-1234567 הופך ל-972501234567 לפני הגיבוב ב-SHA-256. את fbc, fbp, lead_id, כתובת IP ו-User Agent לא מגבבים בכלל. אירוע הליד הגולמי נשלח עם action_source בערך website, עם event_source_url ו-client_user_agent שהם חובה לאירועי אתר ועם event_id זהה לזה שהפיקסל שלח. השלבים הבאים לא קרו באתר, לכן אנחנו שולחים אותם עם action_source שמתאר את הערוץ האמיתי, למשל phone_call לשיחת סינון או system_generated לסטטוס שהמערכת מסמנת. Meta דורשת שהפרמטר הזה יהיה מדויק למיטב ידיעתכם.

על בסיס האירועים האלה מגדירים ב-Events Manager המרה מותאמת, למשל על qualified. בוחרים אותה כאירוע האופטימיזציה בקמפיין. זה לא Conversion Leads, אבל זו אופטימיזציה לשלב עמוק במשפך במקום לטופס. שתי מגבלות חשובות: event_time יכול להיות עד 7 ימים לפני רגע השליחה, אחרת Meta מחזירה שגיאה לכל הבקשה. אירוע שמגיע אחרי חלון השיוך שהוגדר בסט המודעות ייקלט בדאטהסט אבל לא ישויך לקמפיין.

איך מיישמים את זה בפועל?

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

1. מגדירים את המשפך ב-CRM. שדה סטטוס אחיד עם ערכים קבועים, חותמת זמן לכל שינוי סטטוס ושדות ייעודיים ל-lead_id, fbc, fbp ולכתובת הנחיתה. בלי חותמת זמן אין event_time אמין.
2. מחברים את הורדת הלידים. ל-Instant Forms: Webhook, Graph API או אינטגרציית שותף, בתנאי ש-Lead ID בן 15 עד 17 הספרות נשמר בכל רשומה. Meta לא ממליצה על הורדה ידנית. לטפסים באתר: שדות נסתרים או dataLayer שמעבירים את המזהים ל-CRM.
3. פותחים דאטהסט נפרד ל-CRM ב-Events Manager. Meta ממליצה על דאטהסט חדש כדי להפריד אירועי CRM מאירועי האתר ולהקל על איתור תקלות. אם ממירים דאטהסט קיים, נותנים לאירועי ה-CRM שמות חדשים. אחרי שהאינטגרציה הושלמה לא מחליפים פיקסל.
4. בונים את השליחה. ישירות מהשרת, דרך Zapier או דרך אינטגרציית שותף כמו Salesforce. כל אירוע כולל event_name לפי מפת הסטטוסים, event_time, user_data.lead_id או em, ph ו-fbc, action_source בערך system_generated, custom_data.event_source בערך crm ו-lead_event_source עם שם ה-CRM. שולחים לפחות פעם ביום, רצוי כל שעה, עד 1,000 אירועים בבקשה. שגיאה אחת מפילה את כל הבקשה, לכן עובדים בבאצ'ים קטנים עם מנגנון ניסיון חוזר.
5. מאמתים עם Test Events. שולחים אירועי בדיקה עם test_event_code מ-Events Manager ובודקים שהם מגיעים עם כל הפרמטרים. מסירים את הקוד לפני פרודקשן.
6. מגדירים את שלבי המשפך ומשיקים. ב-Events Manager מסדרים את שלבי המשפך ובוחרים את שלב היעד. בקמפיין בוחרים Leads עם Instant Forms ויעד ביצועים Conversion Leads. Meta מעריכה תקופת למידה של 2 עד 4 שבועות ואומדת זמן כולל של כחודש עד שרואים את מלוא השיפור.

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

הטעות הראשונה היא לשלוח רק את הליד הגולמי. בלי שלב שני לפחות, אין למערכת מה ללמוד ואין יעד Conversion Leads. הטעות השנייה היא event_time שגוי: חותמת זמן של שינוי הסטטוס שמוקדמת מיצירת הליד גורמת לזריקת האירוע. אירוע שהשתנה ב-CRM לפני יותר מ-7 ימים ונשלח רק עכשיו מפיל את כל הבקשה. זו הסיבה שסנכרון שבועי לא עובד.

הטעות השלישית היא גיבוב שגוי: מגבבים את fbc או את lead_id, שולחים טלפון בלי קידומת 972 או אימייל עם אות גדולה. כל אחד מאלה מוריד את שיעור ההתאמה בלי שום הודעת שגיאה. הטעות הרביעית היא ערבוב: שולחים את אירועי ה-CRM לדאטהסט של האתר עם אותם שמות אירועים. אחר כך אי אפשר להבדיל בין Lead מהטופס ל-Lead מה-CRM. הטעות החמישית היא בחירת שלב יעד לא מתאים: עסקה שנסגרת אחרי 60 יום או שלב שרק חצי אחוז מהלידים מגיעים אליו לא עומדים בתנאי הסף של Meta. הקמפיין נשאר בלמידה. הטעות השישית, בטפסים באתר, היא לשלוח Lead מהשרת בלי event_id בזמן שהפיקסל שולח את אותו אירוע מהדפדפן. התוצאה היא ספירה כפולה של לידים ועלות לליד שנראית נמוכה ממה שהיא.

איך בודקים שזה עובד?

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

הבדיקה השנייה היא איכות ההתאמה. בטפסים באתר בודקים את ציון Event Match Quality של כל אירוע ואת העמודה שמראה כמה אירועים הוסרו כדה-דופליקציה. אם ה-Lead מהשרת לא מוסר מול הפיקסל, event_id או event_name לא זהים. הבדיקה השלישית היא בקמפיין עצמו: אחרי תקופת הלמידה משווים את העלות לליד מוכשר, לא את העלות לטופס, לתקופה שלפני החיבור. גם מחיר לטופס גבוה יותר הוא תוצאה טובה אם המחיר לליד מוכשר ירד. הבדיקה הרביעית היא תפעולית: התראה על יום בלי אירועים מה-CRM ועל שגיאות בתגובת ה-API. חיבור שנופל בשקט חוזר להזין את מטא בטפסים בלבד.

עדכון לאתרי מסחר: מ-12 בנובמבר 2026 מטא מתחילה למדוד חלק מהרכישות במכשיר הלקוח, מה שישנה את מספר הרכישות המשויכות בדוחות. מה ידוע ומה לבדוק לפני: מדידת המרות במכשיר הלקוח במטא.

מה השורה התחתונה?

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

מדריכים קשורים

מקורות

Meta: Conversions API for CRM integration, Meta: Conversions API for CRM, payload and upload requirements, Meta: Handling duplicate Pixel and Conversions API events, Meta: Customer information parameters, Meta: Using the Conversions API

דני צ'רניאק
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי