מדידת המרות ב-ChatGPT: למה GA4 מראה אחרת

קמפיין ראשון ב-ChatGPT רץ שלושה ימים. בממשק ניהול המודעות מופיע מספר המרות אחד, וב-GA4, באותו טווח תאריכים ועל אותו אתר, מופיע מספר נמוך יותר. מכאן מתחיל תסריט מוכר: פותחים את קוד האתר, בודקים את הפיקסל, שולחים הודעה למפתח, ושורפים שבוע על חיפוש תקלה. ברוב המקרים אין שם תקלה. יש שתי מערכות שסופרות את אותו דבר בשתי שיטות שונות, ו-OpenAI מפרטת בתיעוד שלה בדיוק מאילו סיבות זה קורה.
בקצרה: מדידת המרות ChatGPT Ads נשענת על מזהה קליק בשם oppref שנוסף לכתובת דף הנחיתה, על פיקסל שקולט אותו ושומר אותו בעוגיית צד ראשון, ועל אפשרות לדווח את ההמרה גם משרת לשרת דרך Conversions API. פער בין המספר שהמערכת מדווחת לבין המספר שרואים באנליטיקס הוא התנהגות מתועדת ולא באג, והוא נובע מחמש סיבות ידועות מראש. מה שכן שווה לוודא לפני שמחפשים אשם: ש-oppref שורד את כל הדרך מהקליק ועד הטופס, כי אם הוא נופל באמצע, ההמרה לא תיזקף לקמפיין בכלל.
מה המערכת בכלל מודדת
ממשק ניהול המודעות מציג שבעה מדדים: חשיפות, קליקים, הוצאה, CTR (אחוז הקליקים מתוך החשיפות), CPC ממוצע (העלות הממוצעת לקליק), CPM ממוצע (העלות הממוצעת לאלף חשיפות), והמרות.
ששת הראשונים עובדים מעצמם. השביעי, המרות, הוא היחיד שלא יופיע אם לא הקימו אותו מראש. המערכת יודעת שמישהו לחץ על המודעה, אבל כל מה שקורה אחרי הקליק קורה אצלכם באתר, מחוץ לשליטתה. צריך להחזיר לה את המידע הזה באופן פעיל. בלי הצעד הזה עמודת ההמרות תישאר ריקה, גם כשבפועל נכנסו לידים דרך הקמפיין.
oppref: מספר הקבלה של הקליק
כשמישהו לוחץ על המודעה, נוסף לסוף כתובת דף הנחיתה פרמטר בשם oppref, בצורה הזאת: https://example.com/?oppref=gAAAAAb123. זה מזהה הקליק, מין מספר קבלה שמלווה את המבקר מהרגע שעזב את הצ׳אט.
הפיקסל של OpenAI, קטע קוד קצר שמתקינים בדפי האתר, קולט את הערך הזה ושומר אותו בעוגיית צד ראשון, כלומר קובץ קטן שהאתר שלכם שומר בדפדפן של המבקר בשמו שלו. מרגע שהערך שמור, כל פעולה שהמבקר יעשה בהמשך יכולה להתחבר בחזרה לקליק שהביא אותו.
כאן נשברת השרשרת אצל רוב מי שנתקל בבעיה. oppref חייב לשרוד את כל הדרך. כל הפניה אוטומטית באתר שמנקה פרמטרים מהכתובת מוחקת אותו, וכך גם מעבר בין שלבים בדף שמחליף את הכתובת בלי לטעון אותה מחדש. הבדיקה פשוטה ולוקחת שתי דקות: מדביקים בדפדפן את כתובת דף הנחיתה עם ?oppref=test בסוף, עוברים את כל המסלול עד הטופס, ובודקים שהערך עדיין בכתובת. אם הוא נעלם באמצע, זו הבעיה, והיא באתר ולא במערכת.
שתי הדרכים להחזיר המרה, ולמה לפעמים מחברים אותן
הדרך הראשונה היא הפיקסל. הוא רץ בדפדפן של המבקר ומדווח מה קרה בדף, למשל טופס שנשלח או רכישה שהושלמה. הדרך השנייה היא Conversions API, ערוץ משרת לשרת: המערכות שלכם מדווחות ישירות למערכת הפרסום בלי לעבור דרך הדפדפן. זה הפתרון לעסק שההמרה האמיתית שלו לא קורית על האתר, למשל ליד שנכנס בטופס והופך לעסקה רק אחרי שיחת מכירה, כשהסטטוס מתעדכן ב-CRM.
ההבחנה הפרקטית פשוטה: הפיקסל מספיק כשההמרה נגמרת על האתר. ברגע שהכסף האמיתי נסגר רק אחר כך, הפיקסל מודד את תחילת הדרך בלבד.
אפשר להפעיל את שניהם יחד, ולעיתים קרובות זה גם הדבר הנכון. יש תנאי אחד: שני הערוצים חייבים לשלוח את אותו מזהה אירוע (event ID). המזהה הזה הוא מה שמאפשר למערכת לזהות שהמרה אחת דווחה פעמיים ולמחוק את העותק, פעולה שנקראת דה-דופליקציה, בעברית פשוט ניקוי כפילויות. בלי מזהה זהה, כל המרה נספרת פעמיים, והמספרים ייראו מצוינים בדיוק עד הרגע שתשוו אותם למכירות בפועל.
בתוך הפיקסל פועלת גם התאמה מתקדמת אוטומטית. הוא מזהה לבד פרטים שהלקוח מילא בטופס באתר, מנרמל אותם ומגבב אותם בשיטת SHA-256 עוד בדפדפן. גיבוב הוא הפיכת ערך לקוד באורך קבוע שאי אפשר לפענח ממנו חזרה את המקור. המשמעות המעשית: מה שנשלח ל-OpenAI הוא הקוד המגובב, לא הפרט הגולמי.
נקודה שלא כדאי לדלג עליה: שליחת נתוני המרה למערכת פרסום מחייבת יידוע והסכמה לפי דין. העיקרון פשוט. המבקר צריך לדעת מה נאסף ולאן זה נשלח לפני שזה קורה, ומדיניות הפרטיות של האתר צריכה לשקף את זה במדויק. הניסוח המחייב הוא עניין לבעל מקצוע בתחום, לא לדף במגזין.
מה נסגר בהקמה ולא נפתח אחר כך
אירוע ההמרה נבחר פעם אחת, בהקמת הקמפיין, וננעל. הוא גם לא לבד: מטרת הקמפיין ומודל החיוב נסגרים באותו רגע ואינם ניתנים לשינוי אחר כך, וגם סוג התקציב, שכן מעבר מתקציב כולל לתקציב יומי אינו הפיך. יש אירוע המרה אחד לקמפיין, ואירועי המרה מותאמים אישית אינם נתמכים כרגע. רוצים למדוד משהו אחר, פותחים קמפיין חדש.
ועוד נקודה שמבלבלת מפרסמים חדשים: בקמפיין ממוקד המרות לא משלמים לפי המרה. החיוב הוא לפי קליק תקף או לפי אלף חשיפות, בהתאם למודל שנבחר, וההמרה היא היעד שהמערכת מתכווננת אליו ולא יחידת החיוב. מי שמצפה לשלם רק כשנכנס ליד, יופתע בחשבון הראשון.
עד כאן מה שהמערכת עושה. מהנקודה הזאת והלאה, ההבדל בין מדידה שאפשר לסמוך עליה לבין שבוע של חיפוש אשם הוא שני דברים בלבד: באיזה סדר מקימים את המדידה, וטבלה שאומרת מראש איזה פער בין המערכות הוא צפוי ואיזה באמת מצדיק בדיקה.
סולם המדידה בארבעה שלבים
הסולם בנוי מהמינימום ועד המלא, ואפשר לעצור בכל שלב, ובלבד שיודעים מה עדיין חסר בו.
| שלב | מה מתקינים | למי זה מספיק | מתי עוברים הלאה |
|---|---|---|---|
| 1. פיקסל בלבד | קוד הפיקסל בכל דפי האתר, כולל דף התודה | מי שרוצה רק לדעת שהקמפיין מייצר פעולות באתר, בלי לחבר את זה למערכת נוספת | ברגע שהמספר בממשק לא מסתדר עם התחושה בשטח ורוצים לראות איפה הוא נשבר |
| 2. פיקסל עם שמירת oppref | לוודא שהפרמטר שורד הפניות וניווט בדף, ונשמר בעוגיית צד ראשון | כמעט כל עסק קטן עם טופס ליד או רכישה שנסגרת באתר. זה מינימום הבריאות האמיתי, לא שלב 1 | כשרוצים לנתח את התנועה גם בכלי האנליטיקס שלכם ולא רק בממשק המודעות |
| 3. הוספת UTM לכתובת | פרמטרים סטטיים קבועים בכתובת דף הנחיתה, שנשמרים בקליק ונקראים בכל כלי אנליטיקס | מי שרוצה לראות את ChatGPT כמקור תנועה נפרד, להשוות אותו לערוצים אחרים ולבנות דוח אחד | כשההמרה שבאמת שווה כסף נסגרת מחוץ לאתר |
| 4. הוספת Conversions API | דיווח משרת לשרת מהמערכת שבה ההמרה נסגרת, עם אותו event ID של הפיקסל | עסק שההמרה שלו היא עסקה שנסגרת ב-CRM, בטלפון או בפגישה, ולא לחיצה על כפתור | זה השלב המלא |
שלב 2 הוא הנקודה שבה רוב העסקים חושבים שהם נמצאים ובפועל לא: מתקינים פיקסל, רואים שהוא יורה, ומניחים שהכול מחובר. הוספת UTM בשלב 3 עוזרת לאבחן את זה. כשהאנליטיקס רואה תנועה מהקמפיין וממשק המודעות לא רואה המרות, החשד הראשון הוא השרשרת של מזהה הקליק.
טבלת יישוב הפערים: למה המספרים לא מסתדרים
לפני שמתקשרים למפתח, שווה לעבור על חמש הסיבות שבגללן שתי מערכות יראו מספרים שונים על אותו קמפיין. כולן מתועדות רשמית, וכולן ניתנות לבדיקה בעצמכם.
| הסיבה | מה זה אומר בפועל | מה לבדוק לפני שמכריזים על תקלה |
|---|---|---|
| חלונות ושיטות שיוך שונים | שיוך הוא ההחלטה לאיזה מקור לזקוף המרה. לכל מערכת יש חלון זמן משלה ושיטה משלה | להשוות את חלון השיוך של שתי המערכות. חלונות שונים מייצרים מספרים שונים תמיד, גם כששני הכלים תקינים |
| חותמות זמן ואזורי זמן | אותה המרה יכולה ליפול על ימים שונים בשתי המערכות | לוודא שאזור הזמן של חשבון המודעות ושל חשבון האנליטיקס זהה, ולהשוות טווח של שבוע שלם ולא של יום בודד |
| תנאי דפדפן והסכמה | חסימת עוגיות, גלישה פרטית, באנר הסכמה ותוספים חוסמים משפיעים על כל כלי בעוצמה אחרת | לבדוק מה קורה כשהמבקר לא נותן הסכמה, ובאיזו נקודה כל כלי מפסיק לאסוף |
| דה-דופליקציה שונה | כל מערכת מנקה כפילויות לפי הכללים שלה | לוודא שהפיקסל ו-Conversions API שולחים אותו event ID, ולבדוק שההמרה לא נורית פעמיים על אותו דף |
| הגדרת אירועים שונה | “המרה” בממשק המודעות ו“המרה” באנליטיקס יכולות להיות שתי הגדרות שונות לגמרי | לכתוב במילים פשוטות מה בדיוק נספר בכל מערכת. אם ההגדרות לא זהות, אין שום סיבה שהמספרים יהיו |
הכלל שמסדר את כל זה: לא משווים בין המערכות כדי לקבוע מי צודקת. בוחרים אחת כמקור אמת להחלטות על הקמפיין, ומשתמשים בשנייה לזיהוי מגמות. כן כדאי להיבהל כשהפער קופץ בבת אחת בלי ששינו הגדרה, או כשמערכת אחת מציגה אפס לאורך ימים.
שני דברים שמפתיעים בפעם הראשונה
הראשון: חלק מההמרות המדווחות מוערכות סטטיסטית ולא נמדדות בפועל, מנגנון שנקרא modeled measurement. כשהמערכת לא מצליחה לראות המרה, היא עשויה להשלים אותה בהערכה. זו לא שגיאה, אבל גם לא ספירה מדויקת, ולכן שווה להצליב את המספר מול המערכת שבה העסקאות נסגרות.
השני: דיווח ההוצאה מתעכב. חשיפות, קליקים ו-CTR מופיעים תוך דקות, ההוצאה לא. קמפיין שמציג אפס בשעות הראשונות אינו בהכרח קמפיין שלא הוציא כלום, ואין סיבה לכבות אותו או להעלות לו תקציב על סמך המספר הזה.
מה עושים עם זה
סדר הפעולות שמונע את רוב הכאב: מחליטים מה נחשב המרה ורושמים את זה במילים, מקימים את ארבעת השלבים לפי הסדר, בודקים ש-oppref שורד את המסלול, ורק אז מדליקים תקציב. את ההשוואה בין המערכות עושים פעם בשבוע, לא כל בוקר.
הרקע המלא על הפלטפורמה, מי רואה את המודעות ומה מותר לפרסם, יושב בסקירה מלאה של הפרסום הממומן ב-ChatGPT. החיבור בין מספר ההמרות לבין מה שהוא שווה בשקלים מפורק במדריך למדידת החזר ההשקעה על שיווק מבוסס AI, ועקרונות ניהול הקמפיינים הממומנים עם כלי AI יושבים במדריך הקמפיינים הממומנים מבוססי AI. ואם הצוואר האמיתי הוא דף הנחיתה ולא המדידה, שווה לעבור על הדרכים להעלות את כמות הלידים מהדף.
מי שמעדיף לא להחזיק את השרשרת הזאת לבד, מוצא גם ליווי חיצוני קצר שמקים ומאמת את ארבעת השלבים.
שאלות נפוצות
למה מספר ההמרות ב-ChatGPT Ads שונה מהמספר ב-GA4?
כי שתי המערכות סופרות את אותו דבר בשתי שיטות. OpenAI מפרטת חמש סיבות מתועדות לפער: חלונות ושיטות שיוך שונים, חותמות זמן ואזורי זמן שונים, תנאי דפדפן והסכמה שמשפיעים על כל כלי אחרת, דה-דופליקציה שמתבצעת לפי כללים שונים, והגדרת אירועים שונה. זו התנהגות צפויה ולא תקלה. הפער הופך לחשוד רק כשהוא קופץ בבת אחת בלי שינוי בהגדרות, או כשמערכת אחת מציגה אפס לאורך זמן.
מה זה oppref ולמה הוא חשוב?
oppref הוא מזהה הקליק של ChatGPT Ads. כשמישהו לוחץ על המודעה, הוא נוסף לסוף כתובת דף הנחיתה בצורה כמו example.com/?oppref=gAAAAAb123. זה מין מספר קבלה שמלווה את המבקר, והפיקסל קולט אותו ושומר אותו בעוגיית צד ראשון. בלי הערך הזה אין חוט שמחבר בין הקליק לבין הפעולה שהמבקר עשה באתר, וההמרה פשוט לא תיזקף לקמפיין.
האם חובה להתקין פיקסל כדי לפרסם ב-ChatGPT?
אפשר להריץ קמפיין חשיפות או קמפיין תנועה בלי פיקסל, ולראות חשיפות, קליקים ו-CTR. אבל ברגע שרוצים לדעת מה קרה אחרי הקליק, או להריץ קמפיין ממוקד המרות, צריך להחזיר למערכת את המידע. זה נעשה דרך הפיקסל, דרך Conversions API, או דרך שילוב של השניים. בלי אחד מהם, עמודת ההמרות תישאר ריקה גם כשבפועל נכנסו לידים.
מה ההבדל בין פיקסל לבין Conversions API?
הפיקסל הוא קטע קוד שרץ בדפדפן של המבקר ומדווח מה קרה בדף, למשל טופס שנשלח או רכישה שהושלמה. Conversions API הוא ערוץ משרת לשרת: המערכות שלכם מדווחות ישירות למערכת הפרסום בלי לעבור דרך הדפדפן. הפיקסל מספיק כשההמרה קורית על האתר. Conversions API נחוץ כשההמרה האמיתית נסגרת מחוץ לאתר, למשל ליד שהופך לעסקה רק אחרי שיחת מכירה, כשהסטטוס מתעדכן ב-CRM.
איך מונעים ספירה כפולה כששולחים גם מהדפדפן וגם מהשרת?
על ידי שליחת אותו מזהה אירוע (event ID) משני הערוצים. המזהה הזה הוא מה שמאפשר למערכת לזהות שהמרה אחת דווחה פעמיים ולמחוק את העותק, פעולה שנקראת דה-דופליקציה. כשהמזהים לא זהים, המערכת רואה שני אירועים נפרדים וסופרת את שניהם. התוצאה היא מספרים שנראים מצוינים בדיוק עד הרגע שמשווים אותם למכירות בפועל.
האם אפשר להשתמש ב-UTM במקום פיקסל?
לא במקום, אלא לצד. פרמטרים סטטיים בכתובת דף הנחיתה נשמרים בקליק וניתנים לקריאה בכל כלי אנליטיקס, ולכן UTM מאפשר לראות את ChatGPT כמקור תנועה נפרד ולהשוות אותו לערוצים אחרים. מה ש-UTM לא עושה: הוא לא מחזיר את ההמרה למערכת הפרסום, ולכן הוא לא מזין את האופטימיזציה. לקמפיין ממוקד המרות עדיין צריך פיקסל או דיווח משרת לשרת.
האם אפשר לשנות את אירוע ההמרה אחרי שהקמפיין עלה?
לא. אירוע ההמרה נבחר פעם אחת בהקמת הקמפיין וננעל, בדיוק כמו מטרת הקמפיין ומודל החיוב. יש אירוע המרה אחד לקמפיין, ואירועי המרה מותאמים אישית אינם נתמכים כרגע. מי שרוצה למדוד אירוע אחר פותח קמפיין חדש. לכן שווה להחליט מה נחשב המרה לפני ההקמה, ולא תוך כדי.
האם משלמים לפי המרה בקמפיין ממוקד המרות?
לא. בקמפיין ממוקד המרות החיוב הוא לפי קליק תקף או לפי אלף חשיפות, בהתאם למודל שנבחר בהקמה. ההמרה היא היעד שהמערכת מתכווננת אליו, לא יחידת החיוב. זו נקודה שמפתיעה הרבה מפרסמים שמגיעים מציפייה לשלם רק כשנכנס ליד, וכדאי להיערך אליה בתקציב מראש.
האם כל ההמרות שמדווחות באמת נמדדו?
לא בהכרח. חלק מההמרות המדווחות מוערכות סטטיסטית ולא נמדדות ישירות, מנגנון שנקרא modeled measurement. כשהמערכת לא מצליחה לראות המרה מסוימת, למשל בגלל תנאי דפדפן או הסכמה, היא עשויה להשלים אותה בהערכה. זו לא המצאה ולא שגיאה, אבל זו סיבה טובה לא להתייחס למספר בממשק כאל ספירה מדויקת של חשבוניות, ולהצליב אותו מדי פעם מול המערכת שבה העסקאות באמת נסגרות.
למה ההוצאה בקמפיין מוצגת כאפס?
כי דיווח ההוצאה מתעכב. חשיפות, קליקים ו-CTR מופיעים תוך דקות, אבל ההוצאה מתעדכנת מאוחר יותר. קמפיין שמציג אפס בשעות הראשונות אינו בהכרח קמפיין שלא הוציא כלום, ואין סיבה לכבות אותו, להעלות תקציב או להסיק מסקנות על סמך המספר הזה. כדאי לתת לדיווח להתייצב לפני שמחליטים משהו.
מדדו נכון כל המרה שמגיעה מ-ChatGPT
לשיחת ייעוץ ללא עלות השאירו פרטים
