מעקב המרות בווקומרס: GA4, גוגל אדס ומטא

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

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

התשובה הקצרה

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

ארבע מערכות, ארבעה תפקידים

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

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

למה המספרים אף פעם לא זהים

שלוש סיבות לגיטימיות:

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

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

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

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

ההגדרה הבסיסית: מה חייב להיות מחובר

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

בגוגל אדס

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

בווקומרס

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

במטא

פיקסל ו-Conversions API, עם מזהה אירוע משותף.

ואיך יודעים שזה עובד? מבצעים רכישת בדיקה, ובודקים בשלושה מקומות במקביל:

Tag Assistant של גוגל, שתג ההמרה של גוגל אדס נורה בדף התודה, פעם אחת, עם הסכום הנכון.
DebugView ב-GA4, שאירוע purchase הגיע עם מספר ההזמנה והערך.
Test Events ב-Events Manager של מטא, שאירוע Purchase הגיע גם מהפיקסל וגם מהשרת, ושמטא סימן אותם ככפולים של אותו אירוע.

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

הכלל הראשון: אירוע רכישה אחד, מקור אחד

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

בחנויות ווקומרס זה נשבר בשתי צורות:

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

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

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

גוגל אדס: פעולת המרה ראשית אחת

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

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

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

מטא: פיקסל, Conversions API ומניעת כפילויות

הפיקסל של מטא רץ בדפדפן, ולכן הוא מאבד רכישות לחוסמים ולמגבלות פרטיות. Conversions API שולח את אותן רכישות מהשרת. ההמלצה של מטא היא להפעיל את שניהם יחד, אבל אז חייבים מזהה אירוע משותף (event_id), כדי שמטא ידע שזו אותה רכישה ולא שתיים.

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

מעקב בצד השרת: מתי הוא כדאי

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

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

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

החלק הישראלי: שערי סליקה ודף התודה

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

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

השער לא מעדכן את החנות. ה-שער גובה את הכסף, אבל ההודעה לחנות לא מגיעה, וההזמנה נשארת ב-pending. בבטא, מתוך 4 חנויות שבהן הזמנות לא נרשמו כראוי בווקומרס, 3 עבדו דרך טרנזילה או PayPlus.

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

UTM: הערוצים שנעלמים

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

זה לא מקרה שולי. ב-5 מתוך 13 חנויות בבטא, אימייל או SMS היה הערוץ עם שיעור ההמרה הגבוה ביותר, 7% עד 21%, לעומת 1% עד 3% בתנועה ממומנת מגוגל. בחנות שבה הקישורים לא מתויגים, המספרים האלה פשוט לא היו מופיעים.

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

בדיקת תקינות חודשית, 20 דקות

פעם בחודש, חמש בדיקות:

רכישות מול הזמנות. בחרו יום אחד והשוו את מספר הרכישות ב-GA4 למספר ההזמנות המשולמות בווקומרס. רשמו את הפער באחוזים. אם הוא קפץ מהחודש הקודם, משהו השתנה.
כפילויות. ב-GA4, דוח Explore לפי Transaction ID. מזהה שמופיע פעמיים = טריגר כפול.
פעולות המרה בגוגל אדס. פעולת רכישה אחת שמוגדרת כהמרה ראשית, לא יותר.
Events Manager של מטא. אירועי Purchase מגיעים עם ערך ומטבע ILS, ואין אזהרות על כפילויות.
ספק הסליקה. עסקאות מאושרות בשער מול הזמנות משולמות בחנות, לאותו יום.

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

מדריכים מפורטים

שאלות נפוצות

איזה מספר להציג בדוח למנהלים?

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

האם אפשר לסמוך על ה-ROAS שגוגל אדס או מטא מדווחים?

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

כל כמה זמן לבדוק שהמעקב תקין?

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

צריך GTM או שאפשר בלי?

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

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