הגדרת אנליטיקה לאינטרנט: GA4, GTM, Yandex.Metrica ו-Amplitude
לעתים קרובות אנו רואים: שיעור המרה של 1.2%, התנועה גדלה, אך ההמרה נשארת קבועה. המשווק מסתכל על Google Analytics ואומר: "משתמשים עוזבים בשלב 2 של תהליך הרכישה." המפתח פותח את אותו שלב — אין שגיאות, Sentry שותק. אז זו לא שגיאת JS, אלא בעיית UX או נתונים מעוותים מהאנליטיקה. עם ניסיון של למעלה מ-10 שנים בהנדסת אנליטיקה, אנו מבטיחים מעקב מדויק שחושף צווארי בקבוק אמיתיים. האנליטיקה נשברת מבלי לשים לב: אירוע מפסיק להיעקב אחרי redeploy — אף אחד לא שם לב; תג GTM נורה פעמיים — הנתונים מוכפלים; פילטר GA4 חוסם בוט שהוא למעשה תנועה אמיתית מפרוקסי ארגוני. ביקורת של התגים הנוכחיים שלך תמצא את הגורם תוך שבוע.
לאחר הגדרה נכונה, החיסכון בתקציב הפרסום יכול להיות משמעותי — מקרה אמיתי של חנות מקוונת עם 50,000 מפגשים ביום שבו deduplication של purchase החזיר 20% מהמרות שיוחסו בצורה שגויה, וחסך 8,000–15,000 דולר בחודש. זה לא תיאוריה — זו תוצאה מאומתת מפרויקט שותף מוסמך של Google Analytics.
למה אירועי GA4 מוכפלים ואיך לתקן את זה?
Universal Analytics נעלם, ובמקומו הגיע המודל מבוסס האירועים של GA4. אין pageviews או transactions קבועים — רק אירועים עם פרמטרים. זה גמיש יותר אך דורש עיצוב אירועים נכון. לפי התיעוד הרשמי של Google, "GA4 מבצע deduplication אוטומטי של אירועים על בסיס page_view, אך רק אם הפרמטר מאוכלס כראוי." יישומים רבים מפספסים את זה.
אירועים אוטומטיים נאספים על ידי GA4: scroll, click, session_start, purchase. אירועים מומלצים צריכים להיות מיושמים: add_to_cart, begin_checkout, view_item, product_id. Google מצפה לסכמת פרמטרים ספציפית — אם תעביר item_id במקום filter_applied, הנתונים יגיעו ל-GA4 אך לא לדוחות המסחר האלקטרוני הסטנדרטיים. אירועים מותאמים אישית לפרויקט: video_progress, form_step_completed, purchase. פרמטרים מותאמים אישית חייבים להיות רשומים ב-GA4 Admin → Custom definitions, אחרת הם לא יופיעו בדוחות.
טעות נפוצה היא כפילות של אירוע /thank-you. סיבה: התג נורה בדף purchase, המשתמש מרענן את הדף — transaction_id שני נשלח ל-GA4. פתרון: צור dataLayer.push() ייחודי בצד השרת והעבר אותו באירוע. מניסיוננו, ל-80% מחנויות המסחר האלקטרוני יש בעיה זו. GA4 מבצע deduplication על בסיסו (בתיאוריה — ודא עם DebugView). ייחוס נכון חוסך עד 20% מתקציב הפרסום שבוזבז בעבר על המרות שיוחסו בצורה שגויה.
איך להגדיר את שכבת הנתונים כדי למנוע אובדן נתונים?
GTM הוא כלי לניהול תגים ללא פריסת קוד. אבל "ללא קוד" לא אומר "ללא ארכיטקטורה." שכבת הנתונים היא הבסיס. אנו מעבירים נתונים מהאפליקציה ל-GTM דרך event. מבנה: push + נתוני הקשר. למסחר אלקטרוני: לפני פתיחת דף מוצר — window.dataLayer = window.dataLayer || []; dataLayer.push({ event: 'view_item', ecommerce: { items: [{ item_id: 'SKU-12345', item_name: 'Название товара', price: 1990.00, currency: 'USD' }] } }); עם נתוני המוצר. תג GTM קורא משכבת הנתונים, לא מה-DOM.
window.dataLayer = window.dataLayer || []; dataLayer.push({ event: 'view_item', ecommerce: { items: [{ item_id: 'SKU-12345', item_name: 'Название товара', price: 1990.00, currency: 'USD' }] } }); פרקטיקה גרועה: תג GTM מנתח את ה-DOM — מחפש את המחיר ב-span.price, את השם ב-h1. זה נשבר עם כל שינוי בעיצוב. פרקטיקה טובה: השתמש תמיד בשכבת הנתונים. אנו משתמשים ב-Preview Mode לניפוי באגים וב-GTM Server-Side לנתונים רגישים — שליחה מהשרת, לא מהדפדפן, עוקפת חוסמי פרסומות ומונעת אובדן נתונים. שכבת נתונים מיושמת כראוי מפחיתה שגיאות מעקב ב-95%.
איך Yandex.Metrica משלימה אנליטיקת אינטרנט?
לקהל רוסי, Metrica היא חובה — במיוחד Webvisor. הקלטת מפגש של משתמש שנטש את העגלה נותנת לעתים קרובות תשובה מהר יותר משבוע של ניתוח משפכים. מטרות ב-Metrica: מבוססות אירועים (דרך ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) או אוטומטיות (לחיצת כפתור, ביקור בדף). אינטגרציה עם CRM דרך Metrica Plus — העברת המרות אופליין. הניסיון שלנו: ב-9 מתוך 10 פרויקטים, לאחר הגדרת Metrica, מצאנו באגי UX נסתרים שמערכות אחרות לא הראו, מה שהעלה את ההמרה בממוצע ב-12%.
מה אנליטיקת מוצר נותנת ב-Amplitude?
Amplitude הוא כלי מוצר, בניגוד ל-GA4 ול-Metrica המוכוונים לשיווק. הוא נועד לנתח התנהגות משתמשים בתוך המוצר: משפכים, שימור, נתיבי משתמש. Amplitude מתאים למוצרי SaaS, אפליקציות מובייל וכל שירות עם משתמשים רשומים שבו חשוב להבין השלמת אונבורדינג, שלבי נשירה ושימוש בתכונות. מושגי מפתח: identify (קישור משתמש אנונימי ל-userId לאחר התחברות), group (חשבון ב-B2B SaaS), קוהורטות לשימור. אנו רואים בדרך כלל שיפור של 30% בניתוח שימור לאחר מעבר מ-GA4 ל-Amplitude לשימושי מוצר. Amplitude Chart — משפך של שלבים ב-30 הימים האחרונים מפולח לפי מקור.
ניטור איכות נתונים
אנליטיקה ללא ניטור היא קופסה שחורה. אנו מגדירים:
- GA4 Realtime — בדוק אחרי כל פריסה שאירועי מפתח מגיעים
- התראות ב-GA4 — חריגה במספר אירועי
purchase(ירידה חדה = משהו נשבר) - GTM Preview ב-staging לפני ייצור
- בדיקות משפך ידניות פעם בשבוע — פשוט עבור על מסע הקונה וודא שהכל מתועד
מה אנו בודקים אחרי כל פריסה
- כל האירועים המומלצים קיימים ב-DebugView
- אין כפילויות (ספור
purchaseלכל 100 מפגשים) - מבנה שכבת הנתונים לא השתנה לאחר עדכון הפרונטאנד
מה כוללת העבודה
| רכיב | תיאור |
|---|---|
| ביקורת תגים קיימים | בדיקת תגי GTM נוכחיים, שכבת נתונים, כפילויות ושגיאות |
| עיצוב סכמת אירועים | תיעוד: רשימת אירועים, פרמטרים, טריגרים |
| הגדרת GA4 + GTM | יצירת תצורה, תגים, הגדרות מותאמות אישית |
| Yandex.Metrica | התקנת מונה, יצירת מטרות, הגדרת Webvisor |
| Amplitude (אופציונלי) | הגדרת SDK לקוח ושרת, קוהורטות |
| QA וניטור | בדיקות ב-Preview Mode, התראות |
| הדרכה ומסירה | גישה, הוראות להוספת אירועים חדשים, קונסולה |
תהליך ולוח זמנים
- ביקורת תגים ונתונים קיימים (יומיים)
- עיצוב סכמת אירועים (יומיים)
- פיתוח שכבת נתונים והגדרת תגים (3–5 ימים)
- QA ב-Preview Mode וב-staging (יומיים)
- פריסה והגדרת דשבורד (יום אחד)
| תרחיש | לוח זמנים |
|---|---|
| הגדרת GA4 + GTM בסיסית | שבוע אחד |
| מעקב מסחר אלקטרוני מלא + Metrica | 2–3 שבועות |
| GTM Server-Side + Amplitude | 3–5 שבועות |
העלות מחושבת באופן אישי. קבל ייעוץ על הגדרת אנליטיקת אינטרנט לפרויקט שלך — אנו נעריך את העבודה תוך יום אחד. צור קשר כדי להתחיל עם ביקורת של המעקב הנוכחי שלך.







