מה זה ייבוא המרות אופליין ולמה צריך אותו?
בעסק שמוכר דרך לידים, ההמרה שהתג באתר רואה היא שליחת טופס. המכירה עצמה קורית ימים או שבועות אחר כך, בטלפון או בפגישה, כך שהיא נרשמת רק ב-CRM. בלי ייבוא, Google Ads מודד ומבצע אופטימיזציה לפי כמות הטפסים ולא לפי מה שקרה איתם.
ייבוא המרות אופליין סוגר את הפער. כשליד משנה סטטוס ב-CRM, שולחים ל-Google Ads שורה שמתארת את ההמרה ומזהה שמאפשר לשייך אותה לקליק על המודעה. Google ממליצה ליצור פעולת המרה נפרדת לכל שלב במשפך ולהשתמש ביעדים Qualified lead או Converted lead. אותו רעיון בצד של מטא פירטנו במדריך Meta CAPI ללידים מה-CRM.
מה ההבדל בין ייבוא לפי gclid ל-Enhanced Conversions for Leads?
לפי התיעוד של Google, Enhanced Conversions for Leads היא גרסה משודרגת של ייבוא המרות אופליין ולא מוצר נפרד שעוברים אליו: היא מוסיפה לייבוא הקיים נתונים מגובבים שהגולש מסר, לצד ה-gclid שכבר שולחים.
| נושא | ייבוא לפי gclid בלבד | Enhanced Conversions for Leads |
|---|---|---|
| המזהה שמחבר לקליק | gclid שנשמר עם הליד | אימייל או טלפון מגובבים, רצוי יחד עם gclid |
| מה צריך באתר | קוד שתופס את ה-gclid ושומר אותו בטופס | תג שאוסף את הנתון המגובב בשליחת הטופס |
| עד מתי אפשר להעלות | עד 90 יום אחרי הקליק האחרון | עד 63 יום אחרי הקליק האחרון |
| מה מקבלים בנוסף | שיוך לקליק מסוים | לפי התיעוד: דיווח מדויק יותר, המרות engaged-view והמרות חוצות מכשירים |
| ההמלצה של Google | לשדרג ל-Enhanced Conversions for Leads | הדרך המומלצת, גם למי שמתחיל היום |
שני כללים מהתיעוד שכדאי לזכור. הראשון: gclid הוא חובה כשאין באתר תג שאוסף נתוני גולש. השני: גם כשיש תג כזה, Google ממליצה להמשיך לייבא את ה-gclid בכל פעם שהוא קיים, כדי שההמרה תשויך לקליק מסוים. את הגיבוב עצמו ואת כללי הנרמול הסברנו במדריך Enhanced Conversions ל-Google Ads באתר.
מהקליק ועד העסקה
איך המרה מה-CRM חוזרת ל-Google Ads
איך תופסים את ה-gclid ושומרים אותו ב-CRM?
לפי התיעוד יש שלושה תנאים מקדימים: auto-tagging מופעל בחשבון, אפשרות לשנות קוד בכל עמודי האתר ויכולת לשמור את ה-gclid יחד עם פרטי הליד במערכת ניהול הלידים.
- מוסיפים שדה נסתר לכל טופס. השדה יקבל את ערך ה-gclid ויישלח עם שאר פרטי הליד.
- מוסיפים סקריפט שתופס את ה-gclid. הסקריפט שבתיעוד קורא את הפרמטר gclid מהכתובת, שומר אותו בעוגייה או ב-local storage עם תוקף של 90 יום וממלא את השדה הנסתר בטעינת העמוד.
- מטמיעים את הסקריפט בכל העמודים. לא רק בעמודי נחיתה, כי גולש שנחת בעמוד אחד ומילא טופס בעמוד אחר עדיין צריך להגיע לטופס עם הערך.
- שומרים את הערך ב-CRM. מוסיפים לרשומת הליד שדה ייעודי. לפי התיעוד ה-gclid רגיש לאותיות גדולות וקטנות, לכן אסור שמערכת בדרך תשנה אותו.
כך נראה השדה הנסתר בדוגמה של התיעוד:
<input type="hidden" id="gclid_field" name="gclid_field" value="">
אם לכל הטפסים באתר יש אותו שם שדה, התיעוד מציע להטמיע את הסקריפט דרך Google Tag Manager עם טריגר של כל העמודים. בשיטת Enhanced Conversions for Leads נוסף לזה תג מסוג Google Ads User-Provided Data Event שנורה בשליחת הטופס ואוסף את האימייל או הטלפון.
מה צריך להיות בכל שורה שמייבאים מה-CRM?
הטבלה הבאה מבוססת על דרישות השדות בתיעוד של Google Ads Data Manager.
| השדה | ייבוא לפי gclid | Enhanced Conversions for Leads |
|---|---|---|
| GCLID | חובה | חובה כשאין תג שאוסף נתוני גולש, רשות כשיש |
| אימייל או טלפון | לא רלוונטי | חובה למפות לפחות אחד מהם |
| תאריך ושעת ההמרה | חובה | חובה |
| ערך ההמרה | רשות | רשות |
| Order ID | רשות | רשות |
| GBRAID או WBRAID | רשות | רשות |
שלושה פרטים שמכשילים ייבוא בפועל. תאריך ושעה: לפי התיעוד, שורה בלי אזור זמן לא תיובא אם לא הוגדר אזור זמן חלופי בחיבור. התיעוד גם מזהיר מתאריך דו משמעי: 02/01/2026 עלול להתפרש כ-1 בפברואר, כי הפורמט MM/DD/YYYY נתמך. אם המערכת מזהה ולו שורה אחת בפורמט DD/MM/YYYY, המקובל בישראל, הייבוא נכשל. הפורמט הבטוח הוא תאריך מלא עם היסט, לדוגמה 2026-11-10T14:30:00+02:00.
טלפון: חייב להיות בפורמט E.164, כלומר 11 עד 15 ספרות כולל סימן פלוס וקידומת מדינה, בלי מקפים, סוגריים או רווחים. גיבוב: לפי התיעוד Data Manager מגבב את הנתונים האישיים ב-SHA256 בעצמו, כך שלא חייבים לגבב מראש. שדות גיאוגרפיים כמו מדינה ומיקוד לא מגבבים.
השדה שמזהה את הליד צריך להיות אותו שדה בשני הצדדים: מה שהתג אסף בטופס ומה שיוצא מה-CRM. התיעוד ממליץ על אימייל, כי מערכות CRM כמעט לא משנות את הפורמט שלו. טלפון עובד רק עם קידומת מדינה.
אילו מגבלות זמן חייבים להכיר?
| המגבלה | מה קובע התיעוד |
|---|---|
| גיל הקליק בייבוא לפי gclid | המרה שהועלתה יותר מ-90 יום אחרי הקליק האחרון לא תיובא |
| גיל הקליק ב-Enhanced Conversions for Leads | המרה שהועלתה יותר מ-63 יום אחרי הקליק האחרון לא תיובא |
| קליק טרי מדי | קליק מלפני פחות מ-6 שעות מחזיר שגיאה. מנסים שוב אחרי 6 שעות |
| פעולת המרה חדשה | ממתינים 4 עד 6 שעות מיצירת הפעולה לפני ההעלאה הראשונה |
| תיקון של המרה שכבר הועלתה | אפשר לעדכן עד 55 יום מהרישום הראשון של ההמרה |
המשמעות העסקית: מחזור מכירה שארוך מ-90 יום לא ייכנס כולו. במקרה כזה מייבאים שלב מוקדם יותר במשפך, כמו ליד איכותי, שקורה בתוך החלון. זאת גם ההמלצה שמופיעה בתיעוד לשגיאת קליק ישן מדי.
דרך מה מעלים את הנתונים ל-Google Ads?
לפי התיעוד אפשר להעלות דרך Google Ads Data Manager, שהיא הדרך ש-Google ממליצה עליה, דרך API, דרך Zapier או בהעלאה של קובץ. לא חייבים CRM: התיעוד מציין שכל מערכת ששומרת את פרטי הלידים מתאימה, כולל גיליון.
ב-Data Manager מחברים מקור נתונים, ממפים את השדות של המקור לשדות היעד ואפשר להוסיף טרנספורמציות. חלון הייבוא תלוי בסוג המקור. במקורות כמו Google Sheets ו-SFTP כל ריצה מייבאת המרות מ-90 הימים האחרונים. ב-Salesforce וב-HubSpot הריצה הראשונה מייבאת 14 יום אחורה והבאות רק את השינויים מאז. במקורות כמו BigQuery ו-MySQL כל ריצה מייבאת את 14 הימים האחרונים.
מי שמעלה בקוד צריך להכיר שינוי אחד. לפי הודעה שמופיעה בראש דפי העזרה של Google, החל מ-15 ביוני 2026 העלאות של המרות אופליין ושל Enhanced Conversions for Leads עוברות ל-Data Manager API ונחסמות ב-Google Ads API. לפי אותה הודעה, developer token שלא שלח בקשות בין ינואר ליוני 2026 לא נכלל ברשימת הגישה הישנה. נכון ל-10.11.2026 ההודעה עדיין מופיעה בדפים באותו ניסוח. לכן אינטגרציה חדשה כותבים מול Data Manager API. אינטגרציה ישנה שנכתבה מול Google Ads API היא הדבר הראשון שבודקים כשהייבוא מפסיק לעבוד.
באיזה סדר מקימים את התהליך?
- מגדירים את שלבי המשפך. פעולת המרה נפרדת לכל אירוע אופליין. רשימת הבדיקה של Google ממליצה לסמן פעולה חדשה כ-secondary בשבועיים עד שלושה הראשונים.
- מפעילים Enhanced Conversions ומאשרים את תנאי נתוני הלקוחות. בלי האישור הנתונים לא מעובדים. לפי עמוד העדכונים של Google, מיוני 2026 זה מתג אחד שמשותף לגרסת האתר ולגרסת הלידים.
- מטמיעים את האיסוף באתר. שדה נסתר ל-gclid ותג שאוסף את האימייל או הטלפון בשליחת הטופס.
- מוודאים שהנתונים מגיעים ל-CRM. שולחים ליד בדיקה מקליק אמיתי על מודעה ובודקים שהרשומה מכילה gclid ואימייל.
- מחברים את מקור הנתונים וממפים שדות. כולל אזור זמן חלופי לתאריכים.
- מעלים כל יום. רשימת הבדיקה מגדירה העלאה יומית כמומלצת מאוד. היא גם דורשת להעלות את כל ההמרות של האירוע, כולל כאלה שלא הגיעו מ-Google Ads.
- מעבירים ל-primary אחרי אימות. רק כשהמספרים בדוחות תואמים למה שיש ב-CRM.
איך בודקים שהייבוא עובד ומה השגיאות הנפוצות?
את התג בודקים ב-Chrome DevTools: אחרי שליחת טופס מחפשים בלשונית Network בקשה ל-google.com/pagead/form-data/ עם פרמטר em שמכיל את הנתון המגובב. את הייבוא עצמו בודקים בדוחות הקמפיינים בעמודה All conv. (by conv. time), שמדווחת לפי תאריך ההמרה. התיעוד מזהיר במפורש לא להשוות המרות לפי תאריך ההעלאה לדיווח ב-Google Ads.
ארבע שגיאות שחוזרות. המרה שקדמה לקליק: לפי התיעוד זה בדרך כלל אזור זמן שגוי. Unknown clicks: ההמרה לא שויכה ל-Google Ads. לפי התיעוד, ב-Enhanced Conversions for Leads זה צפוי באופן כללי, למשל כשמעלים גם לידים שלא הגיעו ממודעות. חוקרים רק אם כל השורות מחזירות את השגיאה או שמספר ההמרות המשויכות נמוך בהרבה מהצפוי. ספירה במצב One: רק המרה אחת לכל אינטראקציה עם מודעה מדווחת והשאר נזרקות. כפילויות: אותה המרה לא תיובא פעמיים. כדי לרשום שתי המרות מאותו סוג לאותו קליק צריך זמני המרה שונים וספירה במצב Every.
שאלות נפוצות
מה זה gclid ולמה צריך לשמור אותו?
gclid הוא מזהה הקליק ש-Google Ads מוסיף לכתובת כש-auto-tagging מופעל. בייבוא המרות אופליין הוא מה שמחבר בין עסקה שנרשמה ב-CRM לבין הקליק על המודעה. לפי התיעוד של Google צריך לשמור אותו יחד עם פרטי הליד. הוא רגיש לאותיות גדולות וקטנות, לכן אסור לשנות אותו בדרך.
עד כמה זמן אחרי הקליק אפשר לייבא המרה ל-Google Ads?
לפי התיעוד של Google, המרה לפי gclid שהועלתה יותר מ-90 יום אחרי הקליק האחרון לא תיובא. ב-Enhanced Conversions for Leads המגבלה היא 63 יום. יש גם גבול תחתון: קליק מלפני פחות מ-6 שעות מחזיר שגיאה וצריך לנסות שוב אחרי 6 שעות.
מה ההבדל בין ייבוא המרות אופליין ל-Enhanced Conversions for Leads?
ייבוא המרות אופליין רגיל מחבר את ההמרה לקליק לפי gclid בלבד. Enhanced Conversions for Leads היא גרסה משודרגת שלו: היא מוסיפה נתון מגובב שהגולש מסר, כמו אימייל או טלפון, שנאסף בתג בשליחת הטופס ונשלח שוב מה-CRM בייבוא. Google ממליצה לשדרג ייבוא שמבוסס על gclid בלבד. למי שמתחיל היום היא ממליצה להתחיל ישר בגרסה המשודרגת.
האם חייבים CRM כדי לייבא המרות אופליין?
לא. לפי התיעוד של Google כל מערכת ששומרת את פרטי הלידים מתאימה, כולל גיליון. מה שחייב להיות בכל שורה הוא מזהה, כלומר gclid או אימייל או טלפון, יחד עם תאריך ושעת ההמרה. את ההעלאה עצמה אפשר לעשות דרך Google Ads Data Manager, דרך API, דרך Zapier או בקובץ.
כל כמה זמן צריך להעלות המרות אופליין?
רשימת הבדיקה של Google ל-Enhanced Conversions for Leads מגדירה העלאה יומית כמומלצת מאוד. לפי עמוד השאלות הנפוצות, לצורכי Smart Bidding מעלים לפחות פעם ביום או בלוח זמנים עקבי. העלאה נדירה מסכנת גם את חלון הזמן: המרה שמגיעה אחרי 90 יום מהקליק לא מיובאת.
למה המרות שהעליתי לא מופיעות בדוחות של Google Ads?
הסיבות שהתיעוד של Google מונה: בודקים לפי תאריך ההעלאה במקום בעמודה All conv. (by conv. time) שמדווחת לפי תאריך ההמרה, פעולת ההמרה מוגדרת לספירה במצב One כך שהמרות חוזרות נזרקות, הקליק ישן מ-90 יום או שההמרה לא שויכה לקליק של Google Ads. התיעוד ממליץ גם להמתין כמה ימים לפני שמסיקים שחסרים נתונים.
מה השורה התחתונה?
ייבוא המרות אופליין הוא לא פרויקט של Google Ads אלא פרויקט של שרשרת: המזהה צריך לעבור מהכתובת לטופס, מהטופס ל-CRM ומה-CRM חזרה ל-Google Ads בתוך חלון הזמן. רוב התקלות הן בחוליה אחת: טופס שלא שומר gclid, תאריך בלי אזור זמן או העלאה שנעשית פעם בחודש. מי שמקים היום מתחיל ישר ב-Enhanced Conversions for Leads דרך Data Manager וממשיך לשמור gclid לצד האימייל. אנחנו מקימים את השרשרת הזאת מקצה לקצה כחלק משירות מדידה מתקדמת, כולל המיפוי מול ה-CRM ובדיקת ההתאמה מול הדוחות. אם Google Ads אצלכם עדיין מודד טפסים ולא עסקאות, כתבו לנו.
מקורות
Google Ads Help: About enhanced conversions for leads, Google Ads Help: Set up offline conversions using Google Click ID (GCLID), Google Ads Help: Guidelines for importing offline conversions, Google Ads Help: Offline conversion imports FAQs, Google Ads Data Manager Help: Prepare your data for import, Google Ads Help: Fix discrepancies and errors in offline conversion imports
