מה זה Enhanced Conversions ואיך זה עובד?
לפי התיעוד של Google, Enhanced Conversions לא מחליפה את תג ההמרה אלא משלימה אותו. כשגולש משלים רכישה או הרשמה, לאתר יש בדרך כלל נתון שהגולש מסר בעצמו: אימייל, שם, כתובת או טלפון. התג אוסף את הנתון, מגבב אותו באלגוריתם חד כיווני בשם SHA256 ושולח ל-Google רק את הגרסה המגובבת.
בצד של Google הנתונים מנורמלים ומותאמים, בתוך סביבת confidential computing, לחשבונות Google שהיו מחוברים כשהגולש היה במגע עם אחת המודעות שלכם. Google מציגה את התכונה כדרך לשפר את דיוק מדידת ההמרות ולתת לבידינג אות טוב יותר.
יש שתי גרסאות. Enhanced conversions for web מיועדת להמרות שקורות באתר עצמו, בעוד ש-Enhanced conversions for leads מיועדת למכירות שנסגרות מחוץ לאתר ומתחילות בליד מהאתר. המדריך הזה עוסק בגרסת האתר. את הגרסה ללידים פירטנו במדריך ייבוא המרות אופליין ל-Google Ads.
Enhanced Conversions לאתר
מה קורה לנתון מרגע ההמרה ועד השיוך
אילו נתונים שולחים ובאיזה פורמט?
לפי התיעוד צריך לספק לפחות אחד מהשניים: אימייל, שהוא הנתון המועדף, או שם מלא עם כתובת. כששולחים כתובת, ארבעה שדות הם חובה, שם פרטי, שם משפחה, מיקוד ומדינה, בעוד שרחוב, עיר ואזור הם רשות. את הטלפון Google ממליצה לשלוח יחד עם אימייל.
| הנתון | שם המפתח | כללים |
|---|---|---|
| אימייל | הנתון המועדף | |
| טלפון | phone_number | פורמט E.164, עם קידומת מדינה |
| שם פרטי | first_name | חובה בכתובת |
| שם משפחה | last_name | חובה בכתובת |
| מיקוד | postal_code | חובה בכתובת |
| מדינה | country | חובה בכתובת, קוד של שתי אותיות |
| רחוב, עיר, אזור | street, city, region | רשות |
שלושה פרטים משלימים לטבלה. שדות השם והכתובת יושבים בתוך אובייקט בשם address, כך שהמפתח המלא הוא למשל address.first_name. טלפון בפורמט E.164 הוא 11 עד 15 ספרות כולל סימן פלוס וקידומת מדינה, בלי מקפים, סוגריים או רווחים. קוד המדינה הוא לפי ISO 3166-1 alpha-2. לערכים שגובבו מראש התיעוד מגדיר מפתחות נפרדים: sha256_email_address, sha256_phone_number, address.sha256_first_name ו-address.sha256_last_name.
אפשר לשלוח את הנתונים לא מגובבים, כך שהתג מנרמל ומגבב אותם בעצמו, או לגבב מראש בצד שלכם. מי שמגבב בעצמו חייב לנרמל קודם לפי הכללים של התיעוד: להסיר רווחים בתחילת הערך ובסופו, להפוך לאותיות קטנות, לכתוב טלפון ב-E.164, להסיר נקודות שלפני שם הדומיין בכתובות gmail.com ו-googlemail.com. הגיבוב עצמו הוא hex SHA256.
עוד שלושה כללים מהתיעוד שחוסכים דיבוג. כל הערכים חייבים להיות מסוג String. שדה שהאתר לא אוסף מסירים מהאובייקט לגמרי במקום להשאיר אותו ריק. מי שאוסף יותר מערך אחד יכול לשלוח במערך עד 3 ערכים לאימייל ולטלפון ועד 2 אובייקטים של כתובת, כדי להגדיל את הסיכוי להתאמה.
אילו דרכי הטמעה יש ומה ההבדל ביניהן?
| השיטה | איך היא עובדת | מתי היא מתאימה |
|---|---|---|
| Automatically detect user-provided data | התג סורק את העמוד ומחפש מחרוזות שמתאימות לסוגי הנתונים. אפשר להחריג אזורים עם Add exclusions | התחלה מהירה בלי פיתוח |
| Specify CSS selectors or Javascript variables | מצביעים ידנית על האלמנט או על המשתנה שמכיל כל נתון | הנתון מוצג בעמוד ההמרה במקום קבוע |
| Add a code snippet to your website | האתר מעביר את הנתונים בקוד, בפרמטר user_data | שליטה מלאה בפורמט ובגיבוב |
| API | השרת שולח את הנתונים המגובבים אחרי שההמרה נרשמה בתג | הנתון נמצא ב-CRM או במסד הנתונים ולא בעמוד |
לפי התיעוד אפשר לשלב שיטות, למשל זיהוי אוטומטי לכל ההמרות וקטע קוד לאירועים מסוימים, כשנתונים שמגיעים מקטע קוד מקבלים תמיד עדיפות. דוח האבחון של Google עצמו מציג התראה למי שמשתמש בשיטה האוטומטית, שלפיה הטמעה ידנית עם קוד בעמוד עשויה לתת תוצאות טובות יותר. לכן סדר העבודה המומלץ הוא להתחיל באוטומטי כדי לראות נתונים ולעבור לקוד כשיש מפתח זמין.
כך נראה קטע הקוד בהטמעה ישירה של Google tag, לפי הדוגמה בתיעוד:
gtag('set', 'user_data', {
"email": userEmail,
"phone_number": userPhone
});בשליחה דרך API התיעוד מדגיש שני תנאים. התג באתר חייב לשלוח transaction ID, כדי ש-Google יתאים בין ההמרה מהתג לנתונים מה-API. בנוסף, את הנתונים המגובבים שולחים עד 24 שעות אחרי ההמרה. היתרון הוא שהנתון לא חייב להיות זמין בעמוד ברגע ההמרה ואפשר להביא אותו מה-CRM או ממסד הנתונים.
איך מגדירים Enhanced Conversions ב-Google Tag Manager?
- מאשרים את התנאים ומפעילים ב-Google Ads. לפי התיעוד האיסוף לא מתחיל לפני שמאשרים את תנאי השימוש בנתוני לקוחות. בלי האישור Google לא אוסף ולא מעבד את הנתונים גם אם התג כבר שולח אותם. איפה נמצא המתג בחשבון מפורט בהמשך, בסעיף על השינויים של 2026.
- מאפשרים איסוף בתג. ב-Google tag שבקונטיינר לוחצים Manage, בוחרים Allow user provided data capabilities ומסמנים את שיטת האיסוף.
- יוצרים משתנה User-Provided Data. למשתנה שלושה מצבים: איסוף אוטומטי, Manual configuration או Code. במצב הידני יוצרים לכל שדה משתנה מסוג DOM Element, בוחרים CSS Selector כ-Selection Method ומשאירים את Attribute name ריק. התיעוד ממליץ להצביע על אלמנט לפי ה-id שלו, כי id יציב יותר משם של class.
- מוסיפים את הפרמטר user_data. בתג שמשרת את פעולת ההמרה פותחים את Event Parameters, מוסיפים פרמטר בשם user_data ובוחרים כערך את המשתנה שיצרתם.
- מטפלים במקרה שהנתון נמצא בעמוד קודם. אם האימייל הוזן בטופס אבל לא מוצג בעמוד התודה, יוצרים תג מסוג Google Ads User-Provided Data Event עם ה-Conversion Tracking ID וטריגר Form Submission. לפי התיעוד Google משתמש בעוגיית פרסום כדי לחבר את הנתון המגובב להמרה שתקרה באותו סשן. נתון שלא חובר להמרה נמחק.
- בודקים ומפרסמים. מריצים המרת בדיקה במצב Preview, מוודאים שהפרמטר נשלח ורק אז מפרסמים את הקונטיינר.
את תג ההמרה עצמו ואת Conversion Linker לא נפרט כאן, כי הם מוסברים במדריך תג המרה של Google Ads ו-Conversion Linker ב-GTM. מי שעובד עם קונטיינר שרת צריך להכיר פרט אחד ממרכז העזרה: כשהסקריפטים נטענים דרך קונטיינר השרת או דרך Google tag gateway, נתוני הגולש נשלחים מהדפדפן לקונטיינר השרת, שם תג Google Ads מצפין אותם לפני השליחה ל-Google. את הקמת הקונטיינר פירטנו במדריך הקמת Server-Side GTM.
מה השתנה בהגדרות של Enhanced Conversions ב-2026?
Google פרסמה עמוד עדכונים עם לוח זמנים בשני שלבים. החל מאפריל 2026 החשבון מקבל נתונים שהגולש מסר מכמה מקורות במקביל: תגים באתר, Data Manager וחיבורי API. החל מיוני 2026 שתי הגרסאות, לאתר וללידים, מאוחדות לתכונה אחת עם מתג הפעלה יחיד, כך שהחשבון כבר לא אמור להציג בחירה של שיטת הטמעה כמו Google tag, Google Tag Manager או API. שיטות האיסוף בתג עצמו, כלומר זיהוי אוטומטי, selectors או קוד, נשארות כפי שתיארנו למעלה.
מה זה אומר בפועל: לפי העמוד, מי שכבר אישר את תנאי נתוני הלקוחות מועבר אוטומטית ולא נדרש לפעולה. חשבון חדש מפעיל את התכונה ב-Settings שבתפריט Goals, בפאנל Customer data use, בתיבה Turn on enhanced conversions. עדיין אפשר לכבות אותה לפעולת המרה בודדת.
נכון לבדיקה שלנו ב-10.11.2026, התיעוד עצמו עוד לא התיישר עם השינוי. עמוד העדכונים מנוסח עדיין בלשון עתיד. דפי ההקמה של Google ל-Tag Manager ול-API ממשיכים לתאר את המסך הקודם, כולל בחירת השיטה ואזהרה שנתונים שנשלחים בשיטה שונה מזו שנבחרה עלולים לא להיות מעובדים. אם המסך אצלכם נראה אחרת מדף עזרה או מצילום במדריך ישן, זאת הסיבה. במקרה כזה סומכים על מה שמופיע בחשבון ועל דוח האבחון.
מה הקשר בין Enhanced Conversions להסכמת הגולש?
התיעוד של Google קושר את האיסוף גם למצב ההסכמה: היכן שנדרש, פרמטרי ההסכמה צריכים להיות granted. הפרמטר הרלוונטי הוא ad_user_data. לפי תיעוד Consent Mode, כשהוא denied איסוף נתונים אישיים לצורכי פרסום מושבת, כולל Enhanced Conversions שמבוססות על נתוני צד ראשון מגובבים.
יש כאן עוד פרט שקל לפספס. בשיטה האוטומטית ובשיטת ה-selectors התג משתמש כברירת מחדל בעוגיית פרסום כדי לחבר נתון מגובב להמרה באותו סשן. לפי התיעוד העוגייה הזאת מצייתת למצב של ad_storage כשמוטמע Consent Mode. מה כל אחד מהפרמטרים שולט בו הסברנו במדריך ארבעת הפרמטרים של Consent Mode v2.
איך בודקים ש-Enhanced Conversions עובד?
הבדיקה המיידית היא ב-Chrome DevTools. פותחים את עמוד ההמרה, עוברים ללשונית Network ומחפשים google. מאתרים את הבקשה ל-googleadservices.com/pagead/conversion/ או, בחלק מהדפדפנים, ל-google.com/pagead/1p-conversion/. בלשונית Payload מחפשים את הפרמטר em. לפי התיעוד ערך תקין מתחיל ב-tv.1~em ואחריו מחרוזת מגובבת ארוכה. אם מופיע רק tv.1~em בלי המשך, הפרמטר נשלח ריק. בדרך כלל זה אומר שהנתון לא היה זמין ברגע שההמרה נורתה.
הבדיקה השנייה היא דוח האבחון ב-Google Ads, בלשונית Diagnostics של פעולת ההמרה. הדוח מציג ארבעה סטטוסים, Excellent, Good, Needs attention ו-No recent data, לצד שני מדדים: שיעור הכיסוי (כמה מאירועי ההמרה הגיעו עם נתוני גולש מספיקים) ושיעור ההתאמה מול חשבונות Google. לפי התיעוד התראות לא מוצגות כשיש פחות מ-20 המרות בשבעת הימים האחרונים, כי הנפח קטן מדי. את ההשפעה על הדיווח אפשר לראות אחרי כ-30 יום.
אילו טעויות חוזרות בהטמעה?
הראשונה: עמוד תודה שלא מכיל את הנתון. האימייל הוזן בטופס, הגולש הועבר לעמוד אחר והתג לא מוצא שם כלום. הפתרון הוא תג User-Provided Data Event על שליחת הטופס או העברת הנתון בקוד לעמוד ההמרה.
השנייה: הנחה שכל סוג המרה נתמך. לפי התיעוד המרות שמיובאות מ-Google Analytics לא נתמכות, בעוד שהמרה שהוגדרה לפי כתובת URL מוגבלת לשיטה האוטומטית או ל-selectors ולמשתני JavaScript.
השלישית: פורמט. שדה ריק שנשאר באובייקט, טלפון בלי קידומת מדינה, כתובת בלי אחד מארבעת שדות החובה. דוח האבחון מתריע על בעיות כאלה, לכן כדאי לעבור עליו שבוע אחרי העלייה לאוויר ולא להסתפק בבדיקת ה-Network. אם אחרי התיקון עדיין יש פער מול GA4, הסיבות האחרות לכך מפורטות במדריך למה מספר ההמרות ב-GA4 שונה מ-Google Ads.
שאלות נפוצות
מה זה Enhanced Conversions ב-Google Ads?
Enhanced Conversions היא תוספת למעקב ההמרות הקיים. לפי התיעוד של Google, יחד עם ההמרה נשלחים נתוני צד ראשון שהגולש מסר, כמו אימייל, טלפון, שם וכתובת, אחרי גיבוב ב-SHA256. Google מתאים את הנתונים המגובבים לחשבונות Google שהיו מחוברים בזמן המגע עם המודעה ומשפר כך את דיוק מדידת ההמרות.
האם Google מקבל את האימייל של הלקוחות כמו שהוא?
לא. לפי התיעוד הנתון מגובב באלגוריתם חד כיווני בשם SHA256 לפני שהוא נשלח. ל-Google מגיעה רק הגרסה המגובבת. אפשר לתת לתג לנרמל ולגבב בעצמו או לגבב מראש בצד שלכם ב-hex SHA256 אחרי נרמול: אותיות קטנות, בלי רווחים בקצוות, טלפון בפורמט E.164.
אילו נתונים חובה לשלוח ב-Enhanced Conversions?
לפי התיעוד צריך לספק לפחות אחד מהשניים: אימייל, שהוא הנתון המועדף, או שם מלא עם כתובת. בכתובת ארבעה שדות הם חובה: שם פרטי, שם משפחה, מיקוד ומדינה. רחוב, עיר ואזור הם רשות. את הטלפון Google ממליצה לשלוח יחד עם אימייל, בפורמט E.164.
מה ההבדל בין Enhanced Conversions for web ל-Enhanced Conversions for leads?
הגרסה לאתר מיועדת להמרות שקורות באתר עצמו, כמו רכישה או הרשמה. הנתון המגובב נשלח מהתג ברגע ההמרה. הגרסה ללידים מיועדת למכירות שנסגרות מחוץ לאתר: התג שולח את הנתון המגובב כשהליד נוצר. כשהליד הופך ללקוח מייבאים את ההמרה מה-CRM עם אותו נתון. לפי עמוד העדכונים של Google, החל מיוני 2026 שתי הגרסאות מאוחדות בחשבון למתג הפעלה אחד.
איך בודקים ש-Enhanced Conversions עובד?
ב-Chrome DevTools, בלשונית Network, מאתרים את הבקשה ל-googleadservices.com/pagead/conversion ובודקים ב-Payload את הפרמטר em. לפי התיעוד ערך תקין מתחיל ב-tv.1~em ואחריו מחרוזת מגובבת ארוכה. אם מופיע רק tv.1~em הפרמטר נשלח ריק. בנוסף בודקים את דוח האבחון ב-Google Ads, שמציג כיסוי, שיעור התאמה והתראות.
מה קורה ל-Enhanced Conversions כשהגולש לא נתן הסכמה?
לפי תיעוד Consent Mode של Google, כשהפרמטר ad_user_data במצב denied איסוף נתונים אישיים לצורכי פרסום מושבת, כולל Enhanced Conversions שמבוססות על נתוני צד ראשון מגובבים. בנוסף, האיסוף לא מתחיל בכלל לפני שמאשרים בחשבון את תנאי השימוש בנתוני לקוחות.
מה השורה התחתונה?
Enhanced Conversions לאתר היא אחת ההטמעות עם היחס הטוב ביותר בין מאמץ לתועלת במדידת Google Ads, בתנאי שהנתון באמת מגיע לתג. רוב ההטמעות שאני בודק נופלות לא על ההגדרה ב-Google Ads אלא על עמוד תודה בלי אימייל, על פורמט לא מנורמל או על הסכמה שלא עוברת. סדר העבודה הנכון: מוודאים שהנתון זמין ברגע ההמרה, בוחרים שיטת איסוף, בודקים את הפרמטר em בבקשה ועוברים על דוח האבחון. אנחנו מטמיעים ובודקים את זה כחלק משירות מדידה מתקדמת, כולל Consent Mode ומדידה בצד שרת. אם ההמרות ב-Google Ads נראות חסרות או שדוח האבחון מציג התראות, כתבו לנו.
מקורות
Google Ads Help: About enhanced conversions, Google Ads Help: Set up enhanced conversions for web using Google Tag Manager, Google Ads Help: Set up enhanced conversions for web using the Google tag, Google Ads Help: Updates to your enhanced conversions settings, Google Ads Help: About the enhanced conversions for web tag diagnostics report, Google Ads Help: About enhanced conversions for web in the Google Ads API
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי