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