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