ייחוס Shopify ו-Google Ads: למה המספרים לא מתאימים ואיך מחברים נכון

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

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

מה כל מערכת סופרת, בדיוק

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

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

שתי שורות מסבירות לבד את רוב הפער: תאריך הקליק מול תאריך ההזמנה, והטיפול בביטולים.

חמש סיבות שהמספרים לא מתאימים

1. תאריך הקליק מול תאריך ההזמנה

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

2. חלון הייחוס

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

3. ייחוס מבוסס נתונים מול מקור אחרון

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

4. מה נכלל בערך ההמרה

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

5. ביטולים, החזרות והזמנות כפולות

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

איך מחברים נכון: ארבעה שלבים

שלב 1: מעקב המרות עם ערך אמיתי

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

שלב 2: Enhanced Conversions

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

שלב 3: פרמטרי UTM על כל קישור יוצא

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

שלב 4: מקור אמת אחד להחלטות כספיות

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

חמש תקלות שמחזירות מספר שגוי בלי להודיע

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

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

איזה פער סביר ואיזה פער הוא תקלה

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

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

מה SFB Insights עושה כאן, ומה לא

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

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