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