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