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