הפער שאתם לא מודדים
כשמישהו משאיר פרטים באתר שלכם, שני דברים צריכים לקרות. הראשון: הפרטים נשמרים אצלכם — במייל, ב-CRM, בגיליון. השני: הדפדפן של אותו אדם צריך להצליח לשלוח למטא הודעה שאומרת שכאן קרתה המרה. הראשון עובד כמעט תמיד. השני הוא ניסיון, לא הבטחה.
הדרך לראות את הפער אצלכם פשוטה. קחו טווח של שבועיים, ספרו כמה לידים נכנסו בפועל למערכת שלכם, וספרו כמה המרות מדווחות באותו טווח במנהל המודעות. נניח שבמערכת שלכם יש 40 ובמנהל המודעות מופיעות 31 — המספרים האלה הם דוגמה להמחשה, אבל הפער שיצא לכם הוא הנתון האמיתי. אין אחוז נורמלי שאפשר להעתיק ממאמר.
חלק מהפער תמיד יישאר, וזה בסדר: יש לידים שהגיעו מערוצים אחרים, יש הבדלי חלונות ייחוס, יש אזורי זמן. המטרה היא לא לאפס את הפער אלא לדעת כמה הוא גדול, ולוודא שהוא לא גדל בשקט.
למה הדפדפן מפספס
מעקב מבוסס דפדפן תלוי בכך שקוד ירוץ במכשיר של הגולש, יזוהה מול מטא, ולא ייחסם בדרך. יש הרבה נקודות שבהן זה נופל, והן מצטברות זו על זו ולא מתחלפות.
השורה האחרונה ברשימה היא החשובה. בהרבה עסקים ישראליים ההמרה האמיתית לא קורה בדפדפן בכלל — היא קורה בשיחה. הדפדפן לא יכול לדעת עליה, כמה שלא תשפרו את ההטמעה.
- הגדרות פרטיות במכשיר ובדפדפן שמגבילות מעקב בין אתרים
- חוסמי פרסומות שחוסמים את סקריפט הפיקסל לגמרי
- קוקיז שנמחקים או פגים אחרי זמן קצר, כך שביקור חוזר נראה כמו אדם חדש
- מעבר מדפדפן פנימי של אפליקציה לדפדפן רגיל באמצע התהליך
- גולש שסוגר את הדף לפני שהקוד הספיק לרוץ, במיוחד באתר איטי בסלולר
- טופס שמוביל לדומיין אחר או למערכת חיצונית שאין בה פיקסל
- כל מה שקורה אחרי האתר: שיחת טלפון, וואטסאפ, פגישה, עסקה שנסגרה
הנזק מתחיל באופטימיזציה, לא בדוח
הטעות הנפוצה היא להתייחס לזה כאל בעיית דיווח. אם רק הדוח היה חסר, אפשר היה לחיות עם זה — סופרים ידנית במערכת וממשיכים. הבעיה עמוקה יותר: מטא לומדת למי להראות את המודעות מתוך אותם אירועים בדיוק.
כשחלק מההמרות לא מגיעות, המערכת מקבלת מדגם חלקי. המדגם הזה לא אקראי — הוא מוטה לכיוון סוג מסוים של משתמשים ומכשירים, אלה שכן מאפשרים מעקב. במילים אחרות, האלגוריתם לומד לחפש עוד אנשים שדומים למי שהצליח להיספר, ולא למי שבאמת השאיר פרטים.
בקמפיינים עם נפח נמוך — וזה מה שקורה כשהתקציב היומי קטן — כל אירוע שנעלם עולה כסף. פחות אירועים משמעם יציאה איטית יותר משלב הלמידה, פחות אותות לכל קבוצת מודעות, והחלטות שמתקבלות על סמך רעש.
ולבסוף ההשלכה הישירה: עלות הליד המדווחת נראית גבוהה יותר ממה שהיא באמת. מי שסוגר קבוצת מודעות על סמך המספר הזה עלול לסגור דווקא את זו שעובדת.
מה מעקב צד-שרת עושה בפועל
הרעיון פשוט. במקום שרק הדפדפן של הגולש ידווח למטא, גם השרת שלכם מדווח — ישירות, מחשב אל מחשב, דרך ממשק ייעודי שנקרא Conversions API, או בקיצור CAPI.
לשרת שלכם אין את הבעיות של הדפדפן. חוסם פרסומות לא חוסם אותו, קוקי שנמחק לא מעניין אותו, והוא יודע דברים שהדפדפן לעולם לא ידע: שהליד ענה לטלפון, שהוא הפך ללקוח, שהעסקה בוטלה. אלה בדיוק האירועים ששווים לכם הכי הרבה.
חשוב להבין נקודה אחת: זה לא מחליף את הפיקסל. הפרקטיקה המקובלת היא ששניהם רצים במקביל — הדפדפן מדווח מה שהוא יכול, השרת מדווח את השאר, והדיווחים מתאחדים. וזה מוביל ישר לבעיה הבאה.
דדופליקציה — למה שולחים פעמיים בכוונה
אם גם הדפדפן וגם השרת מדווחים על אותו ליד, מטא עלולה לספור שתי המרות במקום אחת. עכשיו יש לכם מספר מנופח, עלות ליד שנראית מצוינת, ואופטימיזציה שרודפת אחרי נתון שגוי. זה מצב גרוע יותר מאשר לא להטמיע כלום.
הפתרון נקרא דדופליקציה: שני הדיווחים על אותו אירוע נושאים את אותו שם אירוע ואת אותו מזהה ייחודי. כשמטא מקבלת שני דיווחים עם אותו מזהה בטווח זמן קצר, היא שומרת אחד. המזהה הזה צריך להיווצר פעם אחת ולעבור לשני הצדדים, וזה בדיוק החלק שהכי קל לפספס בהטמעה חפוזה.
סימן אזהרה מעשי: אם מיד אחרי ההטמעה מספר ההמרות קפץ בחדות בזמן שנפח הלידים האמיתי בעסק לא השתנה, אל תחגגו. בדקו כפילויות לפני שאתם נוגעים בתקציב.
איכות ההתאמה, ולמה מספרי טלפון ישראליים חשובים
כדי שמטא תוכל לשייך אירוע שהגיע מהשרת למשתמש, היא צריכה פרטי זיהוי. ככל שתשלחו יותר שדות תקינים — מייל, טלפון, שם, עיר, וגם מזהי הקליק והדפדפן אם יש לכם אותם — ההתאמה טובה יותר. שדות הזיהוי האישיים לא אמורים להישלח כטקסט גלוי אלא מגובבים (hashed) — מי שמטמיע צריך לוודא שזה באמת מה שקורה אצלו.
כאן יש מלכודת ישראלית ספציפית. מספר ששמור אצלכם בפורמט מקומי שמתחיל ב-05 לא נראה כמו אותו מספר בפורמט בינלאומי. אם השדה נשלח לא מנורמל, ההתאמה נחלשת בלי שתקבלו שום שגיאה. נרמלו את הטלפונים לפורמט בינלאומי אחיד לפני השליחה, ונקו רווחים ומקפים.
בממשק ניהול הנתונים של מטא מוצג בדרך כלל מדד לאיכות ההתאמה של כל אירוע. אל תתייחסו אליו כציון בתעודה אלא כמד לחץ: אם הוא נמוך במיוחד באירוע מסוים, סביר שאתם שולחים פחות שדות ממה שאתם חושבים.
ועוד דבר: שלחו רק נתונים שאתם רשאים לשלוח, ודאגו שמדיניות הפרטיות באתר תשקף את מה שקורה בפועל. זה נושא למי שמלווה אתכם משפטית, לא משהו שסוגרים בתוסף.
המחיר האמיתי — זה לא כפתור
זה החלק שרוב המאמרים מדלגים עליו. מעקב צד-שרת דורש מישהו שיודע לגעת בקוד או בפלטפורמה, ודורש תחזוקה כשהאתר משתנה. יש שלושה מסלולים מעשיים, וההבדל ביניהם הוא בעיקר כמה שליטה אתם מקבלים תמורת כמה זמן פיתוח.
ומי שלא צריך את זה עכשיו: אם כל הלידים שלכם מגיעים מטופס מיידי בתוך פייסבוק ואף אחד לא נוגע באתר, אירועי אתר הם לא הבעיה שלכם. מה שכן שווה לכם לבחון הוא לדווח בחזרה על מה שקרה ללידים אחרי הטופס — מי ענה, מי קנה. שם נמצא הערך.
- אינטגרציה מובנית בפלטפורמה: אם מערכת האתר או דפי הנחיתה שלכם מציעה חיבור מובנה, זה הכי זול והכי מהיר, בדרך כלל חיבור חשבון והדבקת מזהה. בתמורה אתם מקבלים את מה שהיא מחליטה לשלוח, לא בהכרח את האירועים המדויקים שרציתם.
- שכבת ביניים: מערכת תיוג בצד שרת או כלי אוטומציה שמחובר ל-CRM ושולח אירוע כשסטטוס הליד משתנה. גמיש מאוד, מאפשר לדווח גם על סגירת עסקה, ועולה תשלום חודשי בנוסף לזמן ההקמה.
- קוד ייעודי בשרת: הכי מדויק, הכי יקר בשעות פיתוח, והכי רגיש לשינויים באתר. מתאים כשכבר יש מפתח בסביבה.
איך לבדוק שזה באמת עובד
הטמעה בלי מדידה לפני ואחרי היא בזבוז כסף, כי לא תדעו אם היא הצליחה. עשו את זה בסדר הזה.
מה נחשב הצלחה: פער קטן יותר, יציב, ושאתם יודעים להסביר אותו. לא זהות מוחלטת בין המספרים — היא לא תקרה, וגם לא אמורה לקרות.
- לפני: תעדו לשבועיים אחורה את מספר הלידים במערכת שלכם מול המספר במנהל המודעות, ורשמו את שיטת הספירה המדויקת.
- אחרי ההטמעה: ודאו שכל אירוע מגיע משני המקורות ומזוהה כמדופלק, ולא נספר כשתי המרות.
- בדקו אילו שדות זיהוי נשלחים בפועל, לא מה שהתכוונתם לשלוח.
- חכו שבועיים בלי לשנות תקציבים, קהלים או מבנה קמפיין. אחרת לא תדעו מה השפיע על מה.
- השוו שוב את אותו פער, באותה שיטת ספירה בדיוק.
מה זה לא פותר
מעקב צד-שרת לא הופך את הייחוס לוודאי. הוא משפר את כמות האותות שמגיעים למערכת, לא את היכולת לדעת בביטחון מלא איזה ערוץ הביא את הלקוח. מי שמבטיח לכם ודאות בייחוס מוכר משהו אחר.
הוא גם לא מתקן הצעה חלשה, דף נחיתה שלא ממיר, או לידים שלא עונים לטלפון. אם הבעיה שלכם היא באיכות הליד ולא בספירה שלו, CAPI רק יראה לכם את אותה בעיה בפוקוס טוב יותר.
ולמי שמנהל כמה חשבונות במקביל, הקושי המעשי הוא אחר לגמרי: לשים לב שאצל לקוח מסוים האירועים פשוט הפסיקו להגיע. Admozy קוראת את נתוני מטא בלבד ומציגה את כל הלקוחות במסך אחד כדי שדבר כזה ייתפס באותו יום. היא לא מטמיעה CAPI ולא משנה שום דבר בחשבון.