# ווקומרס לא תואם לגוגל אנליטיקס? איך יודעים מי צודק
מאת בוריס קימלמן · 22 בספטמבר 2026

פותחים בבוקר את ווקומרס ורואים שמונה הזמנות מאתמול. פותחים את GA4 ורואים אפס רכישות. הסוכנות שולחת דוח שמבוסס על GA4, ה-ROAS נראה נורא, ומישהו כבר מציע להוריד תקציב.

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

## התשובה הקצרה

- **להכנסות ולמספר ההזמנות, ווקומרס הוא מקור האמת.** שם הכסף.
- **להתנהגות, GA4 הוא מקור האמת.** מאיפה הגיעו המבקרים, מה ראו ואיפה נטשו.
- פער קטן ויציב ביניהם, של 5% עד 10% לכל היותר, הוא תקין. פער גדול מדי, או פער שהופיע פתאום, מעיד על תקלה.
- לפני שמחפשים את התקלה, בודקים **לאיזה כיוון** הפער. כל כיוון מצביע על קבוצה אחרת של בעיות.

## זו לא בעיה נדירה

בבדיקה של 13 חנויות בבטא של ג'ימי, בין 7 ל-17 בספטמבר 2026, ב-10 מהן נמצא פער בין [GA4](/glossary/kpi/google-analytics-ga4) לווקומרס במספר הרכישות או בהכנסה.

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

ההנחה המקובלת היא ש-GA4 תמיד מראה פחות מהחנות. לרוב היא נכונה, אבל דווקא החריגים מסוכנים: במקרים האלה מקבלים החלטות לפי מכירות שלא קרו.

## פער קטן הוא נורמלי

הנתונים ב-GA4 אף פעם לא יתאימו לנתונים בווקומרס אחד לאחד. יש לכך סיבות לגיטימיות:

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

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

## הצעד הראשון: לאיזה כיוון הפער

| מה רואים | מה זה בדרך כלל אומר |
|---|---|
| GA4 מראה **פחות** רכישות מווקומרס | אירוע הרכישה לא נשלח, או לא מגיע |
| GA4 מראה **יותר** רכישות מווקומרס | אירוע רכישה נשלח בלי הזמנה אמיתית מאחוריו |
| ווקומרס מראה **אפס**, GA4 מראה מכירות | ההזמנות לא נרשמות בחנות, לרוב בגלל בעיה בעמוד התודה |

## כיוון 1: GA4 מראה פחות

בתרחיש הנפוץ הזה יש ארבעה חשודים. בדקו אותם לפי הסדר:

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

כדי לבדוק, השוו את מספר הצפיות בדף התודה ב-GA4 למספר ההזמנות בווקומרס. כתובת ה-URL של דף התודה בדרך כלל מכילה confirm. אם גם הצפיות חסרות, הבעיה בדף. אם הצפיות קיימות והרכישות לא, הבעיה בתג.

**כמה כלים שולחים ל-GA4 במקביל.** Site Kit של גוגל, תוסף [GTM](/glossary/kpi/google-tag-manager-gtm) ותוסף אנליטיקס ייעודי לווקומרס יכולים כל אחד לטעון GA4. כשיותר מאחד פעיל, הם מתנגשים.

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

הכלל: **כלי אחד שולח את אירועי האיקומרס.** רק אחד.

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

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

## כיוון 2: GA4 מראה יותר רכישות = רכישות רפאים

הסכנה בתרחיש הזה היא שהוא נראה כמו חדשות טובות.

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

החשודים:

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

כדי לבדוק, בנו ב-GA4 דוח Explore עם הממד Transaction ID. מזהה שמופיע פעמיים מצביע על טריגר כפול. מזהה שלא קיים בווקומרס בכלל מצביע על אירוע רפאים, בלי רכישה אמיתית מאחוריו.

## כיוון 3: ווקומרס מראה אפס כשהבעיה בספק הסליקה

על התרחיש הזה כמעט לא כותבים, והוא ישראלי במיוחד.

רוב החנויות בישראל עובדות עם [ספקי סליקה](/glossary/kpi/payment-gateway) חיצוניים כמו טרנזילה, PayPlus, קארדקום ודומיהם. הלקוח משלם בעמוד של הספק, והספק מודיע לחנות שהתשלום עבר. כשההודעה הזו לא מגיעה, ההזמנה נשארת בסטטוס pending או לא נרשמת כמשולמת, למרות שהכסף נגבה.

בבטא, מתוך 4 חנויות שבהן הזמנות לא נרשמו כראוי בווקומרס, 3 עבדו דרך טרנזילה או PayPlus. אלה הדפוסים שחזרו:

- webhook מהספק שלא עדכן את סטטוס ההזמנה בחנות
- שגיאות טרנזילה 900 (כשל באימות [3D Secure](/glossary/kpi/3d-secure)) ו-901 (שגיאה לא ידועה), שהשאירו הזמנות ב-pending
- הפניה מדף התשלום חזרה לסל, כך שהרכישה לא הושלמה בכלל

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

את התקלה הזו צריכים לתקן המפתח או התמיכה של ספק הסליקה, לא סוכנות הפרסום.

## מה בכלל נחשב מכירה

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

| סטטוס | מה זה אומר |
|---|---|
| processing, completed | שולם |
| pending | ממתין לתשלום, לרוב לא מכירה |
| on-hold | תלוי בחנות. בחלק מהחנויות הישראליות הסטטוס מציין עגלה שלא שולמה, ולא הזמנה שממתינה לאישור |
| failed | התשלום נכשל |

אם הדוח שלכם סופר pending או on-hold כמכירה, המספר גבוה מהמציאות עוד לפני שנגעתם ב-GA4.

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

## בדיקה של 15 דקות

1. בחרו יום אחד מהשבוע האחרון.
2. ייצאו מווקומרס את רשימת ההזמנות המשולמות של אותו יום, עם מספר הזמנה וסכום.
3. ב-GA4 פתחו Explore, הוסיפו את הממד Transaction ID ואת המדד Purchase revenue, וסננו לאותו יום.
4. השוו את שתי הרשימות לפי מספר הזמנה.
5. סמנו שלוש קבוצות: הזמנות שחסרות ב-GA4, מזהים שמופיעים ב-GA4 ולא בחנות, ומזהים כפולים.
6. בכל קבוצה חפשו מכנה משותף, למשל אמצעי התשלום, המכשיר או השעה.

הקבוצה הגדולה ביותר מצביעה על הכיוון שבו כדאי לחפש.

## למי להאמין בינתיים

עד שתתקנו את הפער:

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

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

להסבר המלא על הדרך שבה GA4, גוגל אדס ומטא אמורים לעבוד יחד בחנות, ראו את [המדריך למעקב המרות בווקומרס](/blog/woocommerce-conversion-tracking).

## שאלות נפוצות

### כמה פער נחשב נורמלי?

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

### האם מעקב בצד השרת פותר את זה?

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

### GA4 מראה אפס רכישות, אבל צפיות בדפים עובדות. מה הסיבה הסבירה?

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

### למה הסוכנות מראה ROAS שונה ממה שאני רואה בחנות?

גם בלי שום תקלה, גוגל אדס ומטא [מייחסים המרות](/glossary/kpi/attribution) לפי מודל משלהם, ולכן הנתונים שלהם שונים ממה שנרשם בחנות.

---

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