המרות API: מה זה נותן ומה זה לא מחליף

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

בקצרה

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

מה בעצם עושה המרות API

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

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

מכאן מגיע הערך האמיתי: אירועים שלא היו מגיעים בכלל, מגיעים. לא "יותר טוב", אלא פשוט מגיעים.

למה הפיקסל נשאר במקום

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

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

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

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

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

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

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

מה בודקים אחרי חיבור Conversions API

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

הסדר שעובד בפועל:

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

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

מה לא מחליף המרות API

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

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

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

Conversions API של Meta מול Measurement Protocol ב-⁠GA4

אלה שני כלים עם אותו רעיון, אבל יעד שונה ומסלול שונה. Conversions API של Meta שולח אירועים ישירות לחשבון המודעות של Meta. Measurement Protocol שולח אירועים מהשרת ל-⁠GA4, ולא ישירות ל-⁠Google Ads.

ההבחנה הזו חשובה כי היא מונעת בלבול נפוץ: מי שמחבר Measurement Protocol ומצפה לראות המרות ב-⁠Google Ads לא יראה אותן משם. ייבוא מ-⁠GA4 והעברה דרך Google Ads API או Data Manager הם מסלולים אחרים, ולא אותה פעולה.

מה קורה לקמפיין אחרי חיבור

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

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

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

איך נראה חיבור תקין בפועל

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

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

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

איך זה מתחבר לשאר שרשרת המדידה

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

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

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

הצעד הבא

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

אם אתם כבר עובדים עם מערכת שמייצרת המרות מהשרת מתוך שלבי ה-⁠CRM, בדקו שהמזהים תואמים לפני שאתם מוסיפים עוד שכבות.