איך לבדוק שמדידת ההמרות מקמפיין ChatGPT פועלת?

בדיקת המרות מפרסום ב־ChatGPT אינה מסתכמת בכך שתג נדלק בדפדפן. צריך לוודא שאירוע נשלח רק כשהפעולה העסקית אכן הושלמה, שמקור הביקור נשמר ככל שהמערכות מאפשרות, ושהספירה אינה מכפילה לידים. לפני שמסיקים שהקמפיין מצליח, בודקים את המסלול כולו: מודעה, מעבר לאתר, פעולה באתר, קליטה בכלי המדידה ושיוך במערכת הלקוחות.

התשובה הקצרה: הגדירו פעולה אחת ברורה לכל המרה, בצעו בדיקת ניסיון מבוקרת, עקבו אחרי האירוע בכל מערכת בנפרד והשוו בין מספר הפניות האמיתי למספר האירועים. פערים אינם תמיד תקלה; הם עשויים לנבוע מהסכמה לעוגיות, מחלונות ייחוס שונים, מחסימת דפדפן או ממשתמש שחזר מאוחר יותר. בדיקה טובה מתעדת גם את הפער וגם את הסיבה האפשרית.

מה בדיוק נחשב המרה בקמפיין?

המרה היא פעולה שהוגדרה כבעלת משמעות עסקית, למשל שליחת טופס, שיחת טלפון שהחלה, רכישה שהושלמה או פנייה שנקלטה במערכת. לחיצה על כפתור היא לעיתים רק שלב ביניים. אם הכפתור פותח טופס אך המשתמש אינו שולח אותו, ספירת הקלקה כהמרה מנפחת את הנתונים. לכן מתחילים מהגדרה מדויקת של רגע ההשלמה, לפני התקנת תג כלשהו.

לצורך בדיקה אפשר להבחין בין אירוע ראשוני לבין תוצאה עסקית. למשל, פתיחת חלון WhatsApp מעידה על כוונת פנייה, אך אינה מוכיחה שנשלחה הודעה. שליחת טופס עם הודעת הצלחה מוכיחה יותר, אך אינה מעידה שהפנייה מתאימה לשירות. ההבחנה הזאת חשובה במיוחד כאשר משווים בין דוח הקמפיין, GA4 ומערכת ניהול הלקוחות. לכל מערכת תפקיד אחר, ולכן לא נכון לדרוש זהות מלאה בכל מספר.

במערכת הפרסום של OpenAI יש לבחון את סוג ההמרות והאופטימיזציה הזמינים בפועל בחשבון, במקום להניח שתכונה מסוימת מופיעה בכל שוק. התיעוד הרשמי של מדידת המרות הוא נקודת מוצא; את היישום הספציפי בודקים מול הממשק הפעיל והגדרות החשבון.

מפה קצרה של מסלול המדידה

לפני בדיקה צרו טבלה פשוטה שמראה היכן כל אות נוצר. כך קל לאתר שלב חסר בלי לשנות את כל המערכת בבת אחת. הדוגמה הבאה היא להמחשה בלבד ואינה מתארת חשבון מסוים.

הטבלה אינה דורשת שכל שלב ישמור מזהה אישי של האדם. למעשה, יש להימנע מהעברת מידע אישי כגון שם, טלפון או כתובת אימייל בפרמטרים של כתובת האתר. מקור הקמפיין יכול להישמר בתוויות כלליות, ואילו פרטי הפונה יטופלו רק במערכת המתאימה ובהתאם למדיניות הפרטיות.

מכינים סביבת בדיקה בלי לזהם נתונים

קבעו מראש מועד בדיקה, מי מבצע אותה, באיזה דף נחיתה ובאיזה מכשיר. השתמשו בפרטי ניסיון שאינם פרטים של לקוח אמיתי, וסמנו את הרשומה במערכת הפנימית כניסוי כדי שלא תיספר כמכירה. אם האתר שולח הודעות למוקד, תאמו זאת עם הצוות לפני שליחת טופס. במקרה שבו אי אפשר ליצור פנייה ניסיונית בלי להפעיל תהליך שירות אמיתי, בדקו רק את שלבי הטעינה והאירועים שניתן לבחון בבטחה ודווחו שהשלמת המסלול לא אומתה.

פתחו את דף הנחיתה מקישור הבדיקה שהמערכת מאפשרת, ושמרו את כתובת היעד לאחר המעבר. אם משתמשים ב־UTM, ודאו שהפרמטרים נשארים בכתובת או נקלטים במנגנון המקור הרלוונטי. המדריך לבניית קישורי UTM לפרסום ב־ChatGPT מסביר איך לבחור שמות קבועים ולבדוק מעבר בין דפים בלי לכלול מידע אישי.

רשמו גם מצב הסכמה לעוגיות. אותה בדיקה במצב שהמשתמש אישר מדידה ובמצב שלא אישר עשויה להפיק תוצאות שונות. אין לעקוף בחירה של המשתמש רק כדי לגרום לדוח להציג מספר גבוה יותר. המטרה היא להבין מה נמדד כדין, לא לייצר התאמה מלאכותית בין מערכות.

בודקים שהאירוע מופעל ברגע הנכון

בטופס, האירוע הרצוי הוא בדרך כלל הצלחת שליחה אמיתית, לא הקלקה על כפתור שליחה. בדקו מקרה תקין וגם מקרה של שדה חסר או שגיאת אימות. אם האירוע מופיע בשני המצבים, הטריגר רחב מדי. בטופס אסינכרוני, שינוי כתובת אינו תמיד מתרחש; ייתכן שהאות הנכון הוא הודעת הצלחה או אירוע ייעודי של הטופס. הבחירה תלויה בבנייה בפועל של האתר.

ברכישה, בדקו שהאירוע מחובר לאישור עסקה ולא רק לכניסה לדף התשלום. בחזרה או רענון של דף תודה, ודאו שלא נוצרת רכישה שנייה. מזהה עסקה ייחודי יכול לסייע למערכת שתומכת בו למנוע כפילויות, אבל אין לשלוח מזהים רגישים או נתוני לקוח ללא צורך. לפנייה ב־WhatsApp או לטלפון, הגדירו במפורש אם אתם מודדים פתיחת ערוץ, הקלקה או שיחה שהושלמה. אלו לא אותה תוצאה.

בכל כלי בדיקה הסתכלו על שם האירוע, זמן ההתרחשות, כתובת הדף ותנאי ההפעלה. ב־GA4 אפשר לבדוק אירועים זמינים בדוחות זמן אמת ובכלי הבדיקה המתאימים להגדרה. הופעה שם מאשרת שהתקבל אות מסוים, אך לא בהכרח שהוא ייוחס למודעה לאחר עיבוד הנתונים. לכן בדיקה בזמן אמת היא שלב ראשון ולא חתימת איכות מלאה.

מזהים כפילויות לפני שמסיקים מסקנות

כפילות נפוצה כאשר אותו אירוע נשלח פעם אחת דרך Tag Manager ופעם נוספת דרך תוסף WordPress, או כאשר גם קליק וגם דף תודה מוגדרים כהמרה הראשית. מקרה אחר הוא אירוע שחוזר בכל טעינה של דף תודה. התחילו מרשימת כל מקורות ההטמעה הפעילים, ללא מחיקה חפוזה. בדקו האם קיימים שמות אירועים דומים, טריגרים זהים או יעדים כפולים באותה מערכת.

השוו בין מספר הפעולות שבוצעו בפועל לבין האירועים שנקלטו בסבב בדיקות קטן ומזוהה. אם ביצעתם ניסיון אחד ונרשמו שני אירועים זהים באותו זמן, יש סיבה לבדוק כפילות. אם רק כלי אחד מדווח שתיים ומערכת הלקוחות מדווחת אחת, בדקו גם את כללי הספירה של אותו כלי. שינוי בהגדרת המרה עלול להשפיע על אופטימיזציה של קמפיין פעיל, ולכן מתעדים מצב קודם לפני עריכה ומבודדים את התיקון הדרוש.

לא כל פער הוא כפילות. אדם יכול ללחוץ על מודעה במכשיר אחד ולפנות ממכשיר אחר, או לחזור דרך ערוץ שונה. מערכות שונות עשויות להשתמש בחלונות ייחוס, אזורי זמן וכללי שיוך שונים. אל תכפו זהות מספרית כשההגדרות שונות; הציגו הסבר עקבי לפער והחליטו איזה מדד משמש לאיזו החלטה.

בודקים את הקשר בין הקמפיין ל־GA4

אם הקמפיין והתנועה תומכים בפרמטרים, בדקו ששם המקור, אמצעי ההגעה ושם הקמפיין מופיעים לפי מוסכמה קבועה. תיעוד Google לפרמטרים של קמפיין מסביר כיצד GA4 קורא פרמטרים ידניים; הוא אינו מבטיח שכל מעבר מכל מוצר ישמור אותם. בדקו גם הפניות בין דומיינים, מעבר לדף תודה ותוסף שמסיר פרמטרים, לפי מבנה האתר שלכם.

הסתכלו על כמה דגימות זמן ולא רק על ביקור אחד. ביקור ישיר מאותו דפדפן מיד לאחר בדיקת הקישור עלול לבלבל את פרשנות המקור. השתמשו בסימון ברור לניסוי, תעדו תאריך ושעה, ואל תסיקו מסקנה מקמפיין אמיתי על סמך אירוע בדיקה בודד. אם יש בקרת הסכמה, בחנו בנפרד מה מופיע במצב הסכמה שונה והסבירו בדוח את מגבלת הכיסוי.

אין לשים מזהה אדם, כתובת אימייל או מספר טלפון ב־UTM או בפרמטר אחר. כתובות כאלה נשמרות בלוגים, בדפדפן ולעיתים בכלי צד שלישי. מדיניות Google Analytics לגבי מידע מזהה אישי מחייבת זהירות גם כאשר המטרה היא לשפר שיוך. השתמשו בתוויות קמפיין כלליות ובהרשאות גישה מתאימות למערכות הלקוחות.

בודקים איכות פנייה בנפרד מהאות הטכני

אירוע שליחה יכול להיות תקין גם כאשר הפנייה היא ספאם או אינה מתאימה לשירות. לכן לאחר בדיקת התגים, הסתכלו על הרשומה העסקית: האם נוצר ליד חדש, האם נציג יכול לחזור אליו, והאם מקור הפנייה נשמר ברמת פירוט שימושית. המאמר על בחירת יעד עסקי לקמפיין ChatGPT מסייע להפריד בין עצם הפנייה לבין ליד איכותי או רכישה.

לבדיקת איכות ארוכת טווח צריך הגדרות סטטוס פשוטות במערכת הלקוחות: חדש, מתאים, נקבעה שיחה, נסגר או לא מתאים, למשל. אלה דוגמאות ולא סטנדרט מחייב. רצוי להגדיר מי משנה סטטוס ומתי, כדי שלא כל נציג יפרש את אותו ליד אחרת. מאמר נפרד בסדרה יעסוק במדידת איכות הלידים; כאן המוקד הוא לוודא שההמרה הטכנית נשלחת ונקלטת באופן אמין.

תיעוד תוצאה והחלטה על תיקון

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

אפשר להשתמש בשלוש רמות מסקנה: תקין במסלול שנבדק, תקין חלקית עם מגבלת ייחוס ידועה, או לא אומת. המילים ״תקין לחלוטין״ אינן מתאימות כאשר נבדק רק טופס אחד בדסקטופ ולא נבדקו מובייל, מצב הסכמה וערוצי פנייה אחרים. לאחר שינוי תג או טופס, חזרו על אותה בדיקה. אם הקמפיין כבר רץ, עקבו גם אחרי היום הראשון שלאחר התיקון כדי לזהות שינוי חריג במספר האירועים.

שאלות ותשובות

סיכום

בדיקת המרות טובה מתחילה בהגדרה עסקית מדויקת ומסתיימת בהשוואה שקופה בין האירוע הטכני לפנייה האמיתית. בדקו פעם אחת את המסלול מקצה לקצה, בדקו שגיאות וכפילויות, וכתבו בבירור מה אומת ומה עדיין אינו ידוע. אם אתם בונים קמפיין חדש או בוחנים תשתית קיימת, עמוד השירות קידום ממומן בצ'אט ג'י פי טי מסביר כיצד אפשר לקבל ליווי בתכנון, בהקמה ובמדידה, לפי היכולות הזמינות בחשבון שלכם.