ייבוא תוצאות עסקיות מאפשר לחבר בין פנייה מקמפיין לבין שלב שאושר לאחר מכן, כגון ליד כשיר או עסקה. לפני חיבור מגדירים אירועים, שדות, הרשאות ומניעת כפילויות. זהו תכנון מדידה עסקי, לא הוראה לשלוח נתוני לקוחות ללא בסיס והרשאה.
מגדירים מה חוזר ממערכת המכירות
טופס שנקלט, פנייה מתאימה ועסקה הם שלבים שונים. לכל שלב קובעים הגדרה, אחראי ומועד שבו התוצאה מאושרת. אם המוכר והמשווק משתמשים באותו שם לשתי תוצאות שונות, ההעלאה לא תפתור את הפער.
מתחילים מהשלב שהעסק באמת מסוגל לתעד. אין להעלות סטטוס אוטומטי כליד כשיר אם אף אחד לא בדק התאמה. ביטול או תיקון תוצאה צריכים להיות חלק מתהליך העבודה ולא להישאר הערה שאינה מגיעה לבקרה.
מפת שדות לפני בחירת חיבור
ממפים מזהה פנימי יציב, מקור שיוך זמין, זמן התוצאה ואירוע המרה מוגדר. שדות אישיים, אם נדרשים במסלול שנבחר, נבדקים לפי דרישות הפלטפורמה וההרשאות של העסק; אין להעתיק רשימות לקוחות לכלי בדיקה ציבורי.
שומרים רק את מה שנחוץ לתהליך ומגבילים גישה בהתאם. גיבוב נתון אינו מבטל כשלעצמו את הצורך בבדיקת זכויות שימוש, הודעה והסכמה לפי המקרה. בנושאי פרטיות נעזרים בגורם מתאים לפני חיבור חי.
בודקים את נתיב ההעלאה העדכני
לפי התיעוד הרשמי שנבדק ב־30.10.2026, Google מעבירה העלאות של המרות אופליין ו־enhanced conversions for leads ל־Data Manager API החל מ־15.6.2026. אין להסתמך על מדריך ישן שמניח שהעלאה ישירה ב־Google Ads API היא המסלול הנכון לכל חשבון.
הבחירה בין חיבור נתמך, Data Manager ומימוש טכני תלויה במערכת ובחשבון. בודקים את התיעוד וההרשאות לפני פיתוח, ומפרידים את בחירת המסלול מהאישור להעברת נתונים בפועל.
תרחישי בדיקה בלי לנפח תוצאות
משתמשים בנתוני בדיקה מסומנים ובסביבה מתאימה. בודקים פנייה חדשה, שליחה חוזרת, שינוי סטטוס ותוצאה חסרה. מזהה עקבי צריך לאפשר לזהות שניסיון חוזר שייך לאותה תוצאה ולא לעסקה חדשה.
מנסחים גם ציפייה לכשל: אם חסר שדה חובה, ההעלאה צריכה להופיע ככשל לטיפול, לא כהצלחה. הודעת קבלה טכנית אינה תמיד אישור שהאירוע יוחס למודעה, והדוחות עשויים להתעדכן בעיכוב.
מתי החיבור עדיין לא מוכן
אם אין מקור אמין לזמן האירוע, אם שדות אינם עקביים או אם לא נקבע מי רשאי לשנות תוצאה, יש להשלים את המודל לפני חיבור לחשבון פרסום. תיעוד ידני מוגבל ועדכני עדיף על העלאה אוטומטית של סטטוסים שגויים.
לאחר ההטמעה בוחנים שיעור כשלים, התאמה למערכת המקור ומדיניות ניסיונות חוזרים. ההשוואה היא מול אותה קבוצת פניות ובאותה הגדרת זמן, ולא מול סך כל ההמרות מכל המקורות.
מגדירים מראש גם טיפול בתקלה: מי מקבל התרעה, היכן נשמר סטטוס שלא הועלה ואיך נמנע שליחה נוספת אחרי אישור. זמן יצירת הפנייה וזמן התוצאה העסקית נשמרים כשדות נפרדים, כדי שניסיון חוזר לא ישנה את ההיסטוריה. בודקים מקרה שבו חלק מהרשומות התקבלו וחלק נכשלו, ולא שולחים שוב אוטומטית את כולן כמקשה אחת. תיעוד הכשל צריך להספיק לתיקון בלי לחשוף את תוכן הפנייה לאדם שאינו צריך גישה אליו.
| שדה | מטרתו | בדיקת בקרה |
|---|---|---|
| מזהה תוצאה | זיהוי יציב של השלב העסקי | ניסיון חוזר אינו תוצאה נוספת |
| שם אירוע | ליד כשיר או עסקה לפי הגדרה | תואם להגדרה בחשבון |
| זמן תוצאה | מועד האישור העסקי | אזור זמן וסדר שלבים תקינים |
| סטטוס העלאה | הצלחה או כשל מפורט | אפשר לאתר ולתקן כשל |
שאלות ותשובות
האם כל פנייה צריכה להפוך להמרה כשירה?
לא. יש להגדיר תנאי התאמה ולשלוח את השלב שאושר בפועל.
האם אפשר להתחבר בלי להעביר נתונים אישיים?
הדבר תלוי במסלול השיוך ובדרישות החיבור. ממפים מראש את הנתונים הנחוצים ולא מניחים שכל שדה נדרש.
מה קורה בהעלאה חוזרת?
צריך לזהות שזו אותה תוצאה לפי מנגנון המזהים והכללים של החיבור, ולבדוק שלא נוצרת כפילות.
האם המדריך מחבר את ה־CRM לחשבון שלי?
לא. הוא מסביר הכנה ובקרה; חיבור חי דורש בחירת מסלול, הרשאות ובדיקת נתונים ייעודית.
