LinkedIn Insight Tag ו-Conversions API: מדידת המרות ב-B2B

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

מה ההבדל בין Insight Tag ל-Conversions API?

שני הכלים מזינים את אותו מקום, דוחות ההמרות ב-Campaign Manager, אבל הם רואים דברים שונים: התג רואה את מה שקורה בדפדפן, בעוד שה-API מקבל את מה שהשרת שלכם יודע.

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

מה Insight Tag נותן ואיך מגדירים בו המרה?

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

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

מי שמתקין דרך Google Tag Manager צריך להשתמש בתבנית הייעודית של התג ולא בקוד מודבק. את הסיבות הסברנו בפיקסלים ב-GTM בתבנית ולא ב-Custom HTML.

למה ב-B2B התג לבד לא מספיק?

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

ה-API בנוי לזה. בין סוגי ההמרה שהתיעוד מונה יש QUALIFIED_LEAD, MARKETING_QUALIFIED_LEAD ו-SALES_QUALIFIED_LEAD. כדי שהמרות ייחשבו לאופטימיזציה של לידים איכותיים, התיעוד דורש לבחור בסוג QUALIFIED_LEAD. הנתונים צריכים להגיע ל-LinkedIn בתוך 30 יום כדי להיכלל באופטימיזציה. ההמלצה שם היא לשתף חמישה לידים איכותיים או יותר בתוך שבועיים כדי לקצר את שלב הלמידה.

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

איך Conversions API עובד?

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

האירועים נשלחים בבקשת POST לנתיב /rest/conversionEvents. כך נראה אירוע בסיסי, לפי המבנה שבתיעוד:

{
  "conversion": "urn:lla:llaPartnerConversion:123",
  "conversionHappenedAt": 1590739275000,
  "conversionValue": { "currencyCode": "USD", "amount": "50.0" },
  "user": {
    "userIds": [
      { "idType": "SHA256_EMAIL", "idValue": "HASHED_EMAIL" },
      { "idType": "LINKEDIN_FIRST_PARTY_ADS_TRACKING_UUID", "idValue": "LI_FAT_ID" }
    ]
  },
  "eventId": "abc12345"
}

שני שדות הם חובה. conversionHappenedAt הוא זמן ההמרה באלפיות שנייה והוא חייב להיות בתוך 90 הימים האחרונים. גם userIds חובה. אפשר לשלוח עד 5,000 אירועים בבקשת batch אחת, אבל אם רשומה אחת שגויה כל הרשומות ב-batch נכשלות.

אילו מזהים שולחים כדי שההמרה תותאם למשתמש?

LinkedIn יכולה לייחס רק המרות שהותאמו לחבר ברשת, לכן איכות המזהים קובעת כמה מההמרות שלכם בכלל ייספרו. לפי התיעוד, בכל בקשה חייב להיות לפחות מזהה תקף אחד. הרשימה כוללת מייל מגובב (SHA256_EMAIL), מזהה קליק (LINKEDIN_FIRST_PARTY_ADS_TRACKING_UUID), כתובת IP, שם פרטי יחד עם שם משפחה ומזהה של טופס לידים של LinkedIn בשדה lead. ההמלצה היא לשלוח גם מייל מגובב וגם מזהה קליק.

הגיבוב הוא SHA-256 בלי salt, כשהתיעוד ממליץ להמיר את המייל לאותיות קטנות לפני הגיבוב כדי לשפר את שיעור ההתאמה.

מזהה הקליק נקרא li_fat_id. כשמופעל Enhanced conversion tracking ב-Insight Tag, המזהה מצורף אוטומטית לכתובת דף הנחיתה בכל קליק על מודעה. לפי התיעוד, ההגדרה פעילה כברירת מחדל בתגים חדשים. יש שתי דרכים לתפוס אותו: לקרוא את הפרמטר מהכתובת או לקרוא את העוגייה li_fat_id שהתג כותב. העוגייה נשמרת 30 יום מהקליק האחרון על מודעה. המיפוי בין המזהה לפרופיל נשמר אצל LinkedIn 365 יום, כך שאפשר להשתמש בו להתאמה גם אחרי שהעוגייה פגה. בפועל שומרים את הערך בשדה נסתר בטופס ומעבירים אותו ל-CRM יחד עם הליד.

איך מונעים ספירה כפולה בין התג ל-API?

כששולחים את אותה המרה משני הערוצים, צריך דה-דופליקציה. לפי התיעוד של LinkedIn הכללים הם אלה:

יוצרים כלל המרה נפרד לכל מקור נתונים, אחד לדפדפן ואחד לשרת, משייכים את שניהם לקמפיין ושולחים את אותו eventId מהדפדפן ומהשרת. כש-LinkedIn מקבלת מאותו חשבון אירוע של Insight Tag ואירוע של Conversions API עם אותו eventId, היא זורקת את האירוע של ה-API וסופרת רק את האירוע של התג.

בצד הדפדפן יש שתי דרכים להעביר את המזהה. להמרה בטעינת עמוד מגדירים את המשתנה window._linkedin_event_id לפני קוד הבסיס של התג. להמרה לפי אירוע מעבירים את הארגומנט event_id בקריאה ל-lintrk("track", ...) יחד עם conversion_id. בתבנית של התג ב-GTM יש שדה Event ID שממפים אליו משתנה מה-Data Layer.

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

איך מקימים, צעד אחר צעד?

1. מוודאים שה-Insight Tag מותקן בכל האתר. תג אחד לחשבון, בכל העמודים, עם Enhanced conversion tracking פעיל.
2. מגדירים המרות בתג. כלל URL לעמוד תודה או המרה לפי אירוע לטופס שנשלח בלי מעבר עמוד.
3. שומרים את li_fat_id ואת המייל עם הליד. שדה נסתר בטופס שנכנס ל-CRM. בלי זה אין לשרת מה לשלוח.
4. בוחרים מסלול אינטגרציה. לפי התיעוד יש שתי אפשרויות: שותף כמו Google Tag Manager, Zapier או Tealium, או חיבור ישיר שלפי התיעוד לוקח בממוצע שבוע עד שבועיים של פיתוח.
5. יוצרים כלל המרה ל-API ומשייכים קמפיינים. כלל נפרד מזה של התג, עם סוג המרה שמתאים לשלב במשפך.
6. מזרימים אירועים עם eventId. התיעוד ממליץ לשלוח בזמן אמת, או רצוי בתוך יום מההמרה.

במסלול של קונטיינר שרת ב-GTM, התשתית עצמה היא מה שתיארנו בהקמת Server-Side GTM.

מה בודקים אחרי ההקמה?

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

אחר כך בודקים שלושה דברים. הראשון הוא שיעור ההתאמה: ב-Campaign Manager מופיע סימון Low Match Rate כשהסיכוי להתאים אירועים לפרופילים נמוך. הפתרון הוא לשלוח יותר מזהים בכל אירוע. השני הוא הספירה: רוב סוגי ההמרה נספרים פעם אחת לחבר בתוך חלון הייחוס, בעוד Purchase ו-Add to Cart נספרים כל פעם. השלישי הוא מכסות: עד 600 בקשות בדקה ו-500,000 ביום לטוקן גישה. מי שמתקרב למכסה עובר לבקשות batch.

שאלות נפוצות

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

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

מקורות

Microsoft Learn: Conversions API - LinkedIn, Microsoft Learn: Conversion Tracking - LinkedIn, Microsoft Learn: Deduplication - LinkedIn, Microsoft Learn: Enabling Click IDs - LinkedIn, Microsoft Learn: Conversions FAQ - LinkedIn, Microsoft Learn: Conversions API Use Cases - LinkedIn

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