Conversions API למותגי אופנה: מדריך הטמעה ומדידה

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

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

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

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

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

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

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

למי שרוצה להבין את ההקשר הרחב יותר של שינויי המדידה והחשיבות של מידע בבעלות העסק, מומלץ לקרוא גם את המדריך על First-Party Data למותגי אופנה.

מהו Conversions API ואיך הוא שונה מפיקסל Meta?

הדרך הפשוטה ביותר להבין את ההבדל היא לחשוב על שני נתיבים שונים שבהם מידע על אותה פעולה יכול להגיע ל-Meta.

פיקסל Meta – מידע מהדפדפן

פיקסל Meta פועל בצד המשתמש, כלומר בתוך האתר והדפדפן.

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

• צפייה במוצר – ViewContent
• הוספה לסל – AddToCart
• התחלת תשלום – InitiateCheckout
• רכישה – Purchase

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

החיסרון הוא שהעברת המידע תלויה גם בסביבת הדפדפן ובאפשרות של הקוד לפעול ולהעביר את האירוע.

Conversions API – מידע מהשרת או ממערכת מחוברת

CAPI מאפשר להעביר אירועים ל-Meta דרך חיבור server-to-server או באמצעות מערכת שותפה שמבצעת את החיבור.

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

לדוגמה, כאשר הזמנה הושלמה בחנות, מערכת המסחר יכולה להיות מקור נוסף לאירוע Purchase.

בפשטות:

• Pixel = browser-side
• CAPI = server-side או חיבור ממערכת עסקית או שותף

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

למה כדאי להפעיל CAPI לצד הפיקסל ולא במקום הפיקסל?

אחת הטעויות הנפוצות בהבנת Conversions API היא לחשוב שהמטרה היא להסיר את פיקסל Meta ולעבור למדידה server-side בלבד.

ברוב אתרי המסחר זו אינה נקודת המוצא הנכונה.

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

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

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

הפיקסל יכול לדווח על ViewContent ועל AddToCart.

בהמשך היא משלימה הזמנה. האירוע Purchase יכול להגיע דרך הפיקסל וגם דרך החיבור של מערכת החנות ל-Conversions API.

כאן עולה שאלה חשובה: אם שני המקורות שולחים Purchase, האם המערכת תספור שתי רכישות?

לא אמורה להיות ספירה כפולה כאשר מנגנון ה-Deduplication, כלומר מניעת הכפילויות, הוגדר נכון.

אילו אירועים חשובים למדוד באתר אופנה?

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

טעות נפוצה היא להתחיל מהטכנולוגיה במקום להתחיל ממסלול הקנייה.

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

צפייה במוצר – ViewContent

ViewContent הוא אחד האירועים המרכזיים באתר אופנה.

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

כדאי שהאירוע יכלול, בהתאם למימוש ולצרכים:

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

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

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

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

צפייה בקטגוריה

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

לדוגמה:

• שמלות ערב
• ג'ינסים
• בגדי ים
• קולקציית קיץ
• SALE
• New Collection

אבל חשוב להבדיל בין צורך עסקי לבין אירוע Meta סטנדרטי.

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

המטרה אינה לייצר כמה שיותר Events, אלא לבנות מערך שבו לכל אירוע יש משמעות ברורה.

הוספה לסל – AddToCart

AddToCart מסמן מעבר מצפייה והתעניינות לפעולה שמצביעה על כוונת רכישה ברורה יותר.

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

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

כדאי גם לבדוק שהמוצר והווריאנט הנכונים מועברים באירוע.

התחלת תשלום – InitiateCheckout

אירוע InitiateCheckout מייצג את המעבר מהעגלה לתהליך הרכישה.

חשוב להגדיר בצורה ברורה באיזו נקודה הוא מופעל.

• האם ברגע שהמשתמש לוחץ "לתשלום"?
• האם כאשר עמוד ה-Checkout נטען?
• האם רק בשלב מאוחר יותר בתהליך?

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

אחרת קשה לנתח בצורה מסודרת את המעבר בין AddToCart, InitiateCheckout ו-Purchase.

רכישה – Purchase

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

Purchase צריך לייצג הזמנה אמיתית שהושלמה.

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

כדאי לבדוק במיוחד:

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

ומה לגבי קופונים?

קופון יכול להיות מידע עסקי חשוב, אבל לא כל מידע חשוב חייב להפוך לאירוע נפרד שמועבר ל-Meta.

אם מנהלי השיווק רוצים לנתח שימוש בקופונים, כדאי להחליט היכן הנתון צריך להישמר ולהיבחן: במערכת החנות, ב-GA4, ב-BI או כחלק מפרמטרים שמצורפים לאירועים רלוונטיים.

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

ומה לגבי החזרות וביטולים?

כאן יש הבחנה חשובה במיוחד בעולם האופנה.

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

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

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

מהי מדידה server-side?

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

אפשר לחשוב על זה בצורה פשוטה:

במדידה browser-side, הדפדפן יכול לדווח: "משתמש ביצע רכישה."

במדידה server-side, מערכת ההזמנות יכולה לדווח: "הזמנה מסוימת הושלמה."

היתרון הוא שהאירוע אינו תלוי רק ביכולת של קוד בדפדפן לפעול ולהעביר את המידע.

אבל חשוב לא להפוך את היתרון הזה להבטחה מוגזמת.

Server-side לא אומר:

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

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

מדריך מעשי להטמעת Conversions API

שלב ראשון: מיפוי האירועים

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

המפה צריכה להיות מותאמת לחנות עצמה, ולא מועתקת אוטומטית ממימוש של חנות אחרת.

שלב שני: בחירת שיטת ההטמעה

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

אינטגרציה מובנית בפלטפורמת e-commerce

בחלק מהמערכות קיימת אינטגרציה רשמית או אינטגרציית Partner שמחברת בין החנות ל-Meta.

Shopify היא דוגמה נפוצה, ולכן בחנות Shopify כדאי לבדוק קודם את האינטגרציה הרשמית של Facebook & Instagram by Meta לפני שבונים פתרון Custom נוסף.

אפשר לקרוא גם את המדריך הטכני לפרסום חנות Shopify ב-Meta וב-Google.

אינטגרציה ישירה

אפשר לחבר את מערכת האתר או השרת ישירות ל-Conversions API באמצעות פיתוח.

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

פתרון server-side או Gateway

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

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

כדאי להתחשב ב:

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

שלב שלישי: הגדרת הנתונים שמועברים

אירוע הוא לא רק שם.

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

בהתאם לאירוע ולמימוש, יכולים להיות פרמטרים כמו:

• זמן האירוע
• כתובת המקור
• מקור הפעולה
• מזהי מוצר
• Value
• Currency
• מזהה אירוע
• פרטי התאמה מותרים

חלק מהמידע שמשמש להתאמה עשוי לדרוש פורמט מסוים או עיבוד בהתאם להנחיות Meta.

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

כדאי לשאול לגבי כל נתון:

• האם הוא נחוץ?
• האם הוא נכון?
• האם הוא מגיע ממקור אמין?
• האם מותר להעביר אותו?

שלב רביעי: מניעת כפילויות בין Pixel ל-CAPI

זה אחד החלקים החשובים ביותר בכל ההטמעה.

נניח שלקוחה ביצעה רכישה אחת.

הפיקסל שלח Purchase, וגם השרת שלח Purchase.

בלי Deduplication תקין, אותה פעולה עלולה להיראות כשני אירועים נפרדים.

המטרה של Deduplication היא לאפשר ל-Meta לזהות ששני הדיווחים מתארים את אותה פעולה.

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

בין היתר נעשה שימוש ב-event_name וב-event_id.

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

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

שלב חמישי: בדיקות איכות

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

כדאי לבדוק בין היתר:

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

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

שלב שישי: עלייה לאוויר ומעקב

גם אם בדיקות ההשקה עברו בהצלחה, העבודה לא הסתיימה.

חנות אופנה משתנה לאורך הזמן:

• מחליפים Theme.
• משנים Checkout.
• מתקינים אפליקציות.
• מחליפים מערכת Consent.
• מוסיפים שיטות תשלום.
• משיקים שוק חדש.
• משנים מבנה מוצרים או קטלוג.

כל אחד מהשינויים האלה יכול להשפיע על המדידה.

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

טעויות נפוצות בהטמעת Conversions API למותגי אופנה

הפעלת CAPI בלי להבין מה כבר מותקן

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

כדאי לבדוק:

• איזה Pixel קיים.
• כיצד הוא הותקן.
• האם הוא מותקן דרך Partner.
• האם יש GTM.
• האם יש קוד ידני.
• האם אפליקציה נוספת שולחת אירועים.
• האם CAPI כבר פעיל בדרך אחרת.

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

שליחת Purchase פעמיים

אם Browser Purchase ו-Server Purchase אינם מזוהים כאותו אירוע, נתוני ההמרות עלולים להיות מנופחים.

לכן Deduplication אינו תוספת טכנית שולית. הוא חלק מרכזי מההטמעה.

אירועים שאינם תואמים למציאות באתר

AddToCart צריך להיות AddToCart אמיתי.

Purchase צריך להיות רכישה אמיתית.

InitiateCheckout צריך להיות מוגדר בנקודה קבועה וברורה.

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

מזהי מוצרים שאינם תואמים לקטלוג

במותגי אופנה זו תקלה שכדאי להקדיש לה תשומת לב מיוחדת.

חנויות רבות מנהלות במקביל:

• Parent Product
• Variants
• צבעים
• מידות
• SKU
• מזהה פנימי
• מזהה פיד

אם Pixel, CAPI והקטלוג אינם משתמשים במבנה מזהים עקבי, קשה יותר לחבר את האירועים למוצרים הנכונים.

העברת Value לא נכון

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

כדאי להגדיר מראש:

• האם Value נשלח לפני הנחה או אחריה?
• האם משלוח כלול?
• כיצד קופון משפיע על הערך?
• איזה מטבע מועבר?

אין הגדרה אחת שמתאימה לכל חנות. מה שחשוב הוא שהלוגיקה תהיה ידועה, עקבית ומתועדת.

התעלמות מהחזרות וביטולים

עבור הנהלת המותג, Purchase אינו סוף הסיפור.

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

CAPI אינו מחליף מערכת BI, מערכת הזמנות או דוח פיננסי.

התעלמות מהסכמה ופרטיות

Server-side אינו היתר להעביר כל מידע שקיים במערכת.

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

העיקרון צריך להיות פשוט: להעביר מידע שיש לו סיבה עסקית וטכנית ברורה ושמותר להעביר.

איך בודקים שהמדידה נכונה לאחר ההטמעה?

בדיקת CAPI אינה מסתכמת בכך שרואים שהאירוע Purchase מתקבל.

כדאי לעבוד בכמה שכבות.

Events Manager

בדקו שהאירועים מגיעים ממקורות המדידה שתכננתם.

אם אתם מפעילים Pixel לצד CAPI, צריך לוודא שהמבנה בפועל תואם למבנה שתכננתם.

כדאי לבדוק גם הודעות Diagnostics או התראות רלוונטיות שמופיעות במערכת.

בדיקת Event Matching

Meta משתמשת במידע שמגיע עם האירועים לצורך התאמת הפעולות למשתמשים במערכות שלה.

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

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

השוואה למערכת החנות

בחרו טווח זמן לבדיקה והשוו בין המערכות.

כדאי לבדוק:

• מספר הזמנות בחנות.
• אירועי Purchase.
• ערכי העסקאות.
• מטבע.
• הזמנות בדיקה.
• עסקאות שבוטלו.

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

המטרה היא לזהות פערים שאי אפשר להסביר.

בדיקה ברמת מוצר

במותג אופנה חשוב לא לעצור רק ברמת Purchase.

בדקו שמזהי המוצרים שנשלחים ב-ViewContent, AddToCart ו-Purchase תואמים למבנה הקטלוג.

כדאי לבחור כמה סוגי מוצרים שונים, לדוגמה:

• שמלה עם מספר מידות.
• מוצר עם כמה צבעים.
• מוצר במבצע.
• מוצר חדש.

עברו ידנית על מסלול הקנייה ובדקו איזה מידע נשלח בכל שלב.

בדיקה אחרי שינויים באתר

כל שינוי משמעותי באתר צריך לעורר את השאלה: האם השינוי הזה יכול להשפיע על המדידה?

כדאי לבצע בדיקות מחדש במיוחד אחרי:

• החלפת Theme.
• שינוי Checkout.
• מעבר פלטפורמה.
• החלפת אפליקציית Cookie Consent.
• שינוי מבנה הקטלוג.
• התקנת אינטגרציה חדשה של Meta.
• שינוי במערכת התשלום.

Conversions API הוא חלק ממערך מדידה, לא פתרון קסם

הערך של Conversions API אינו בכך שהוא "מתקן את כל המדידה".

הערך הוא בבניית תשתית שבה העסק אינו מסתמך רק על מידע שמגיע מהדפדפן.

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

ViewContent, AddToCart, InitiateCheckout ו-Purchase צריכים לתאר מסלול עקבי.

פיקסל Meta ו-CAPI צריכים לעבוד יחד בלי ליצור כפילויות.

מזהי המוצרים צריכים להתאים למבנה הקטלוג.

Value ו-Currency צריכים לשקף את לוגיקת המדידה שהעסק הגדיר.

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

אם אתם בונים מחדש את מערך המדידה כחלק מפעילות רחבה יותר, אפשר לקרוא גם על שירותי ה-Paid Media והשיווק של nonetime.

סקירת Paid Media חינמית למותגי אופנה

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

להזמנת סקירת Paid Media חינמית

שאלות נפוצות

האם Conversions API מחליף את פיקסל Meta?

לא. ברוב אתרי ה-e-commerce נכון יותר לראות ב-Conversions API ובפיקסל Meta מקורות נתונים משלימים. הפיקסל שולח אירועים מהדפדפן ו-CAPI יכול לשלוח אירועים מהשרת או ממערכת מחוברת.

מה ההבדל בין CAPI למדידה server-side?

CAPI הוא פתרון של Meta להעברת אירועים ונתונים למערכות Meta. מדידה server-side היא מושג רחב יותר שמתאר מדידה שבה מידע עובר דרך שרת או מערכת backend ולא רק דרך הדפדפן.

איך מונעים ספירה כפולה של Purchase בפיקסל וב-CAPI?

יש להגדיר Deduplication כך שאירוע ה-Purchase מהדפדפן והאירוע המקביל מהשרת יזוהו כאותה פעולה, בין היתר באמצעות event name ומזהה event_id עקבי עבור אותו אירוע.

אילו אירועים חשובים במיוחד באתר אופנה?

ברוב חנויות האופנה כדאי להתחיל ממיפוי נכון של ViewContent, AddToCart, InitiateCheckout ו-Purchase, ולהוסיף אירועים נוספים כאשר יש להם שימוש עסקי ומדידתי ברור.

איך יודעים שהטמעת Conversions API עובדת נכון?

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