מקור הגיוס הראשון של משתמש, מקור ביקור והקרדיט לאירוע מפתח הם מבטים שונים. דוח שימושי מבהיר אותם לפני השוואת ערוצים.
לקבוע בסיס משותף
יש להגדיר תקופה, אזור זמן, מטבע, המרה וחלון ייחוס. ברכישות, מתאימים אירועים להזמנות, בודקים כפילויות ומבהירים את הטיפול בהחזרים. הכנסה מיוחסת אינה שיעור רווח ואינה רווח תוספתי.
לקרוא ממדי GA4 לפי היקף
הטבלה מבדילה בין שלושת היקפי מקורות התנועה. שינוי מודל הייחוס לדוחות אינו משנה ממדי משתמש וביקור. התעלמות מהבדל זה עלולה ליצור סתירה לכאורה.
| היקף | שאלה | השפעת בחירת המודל |
|---|---|---|
| משתמש | מקור הגיוס הראשון | ממדים בהיקף זה אינם משתנים |
| ביקור | מקור כל ביקור | ממדים בהיקף זה אינם משתנים |
| אירוע | קרדיט לאירוע מפתח | תלוי במודל הייחוס לדוחות שנבחר |
לתעד הבדלים לפני פעולה
יש לציין שינויים בתיוג, בהסכמה, בכיסוי ובעיכובי המרות. שומרים הגדרות ותאריכי חילוץ עם הדוח. פער בין פלטפורמות מחייב התאמת היקפים, ולא חלוקה מחדש אוטומטית של תקציב.
מקורות ואימות
- Google Analytics — Scopes of traffic-source dimensions
- Google Analytics — Minimize duplicate key events with transaction IDs
- Google Analytics — Get started with attribution
דוחות רב-ערוציים זקוקים לספירה סמכותית.
מספר ערוצים יכולים לתרום למסע אחד. יש להגדיר הקצאת קרדיטים בכל דוח ואת המקור שסופר תוצאות ייחודיות. יש לבחון חלונות, מעקב מופרע ומבקרים החוזרים ללא פרמטרים של קמפיין; ישיר לא בהכרח אומר שאין תרומה מוקדמת יותר.
- יש לתעד מודל ייחוס וחלון.
- יש ליישב תוצאות ייחודיות עם קרדיטים לערוצים.
- יש לחשוף מגבלות של מסעות שלא עוקבים.
האם יש לחבר יחד מכירות המיוחסות לפלטפורמה?
לא כספירה של הזמנות ייחודיות. כל דוח יכול לזכות את אותה מכירה; יש להציג התאמה וחפיפות.
מקור ראשוני: Google Analytics — Campaign URL data. שיטה קשורה: קריאת המדריך המעשי.
אזורי זמן ואירועים מאוחרים
תקופת דוח תלויה בזמן האירוע ובכללי הסגירה.
- שמרו בנפרד זמן אירוע, זמן קליטה ואזור זמן עסקי. בדוגמה בדיונית, 23:30 UTC הוא 01:30 ביום הבא בהיסט קבוע UTC+02:00. חותמת הזמן עם אזור זמן של PostgreSQL אינה שומרת את שם האזור המקורי.
- כללו את ההתחלה והחריגו את הסיום. חשבו את הגבולות באזור העסקי לפני המרה ל־UTC. בדקו שינוי שעון עונתי, מעבר חודש ותאריך בלי שעה; יום מקומי אינו תמיד 24 שעות.
- הגדירו איחור מותר ומועד סגירת הדוח. חזרו על אותו מזהה כדי להבחין בין אירוע חדש לכפילות. שמרו גרסה שפורסמה ותעדו את השפעת התיקון; סימן מים מעריך הגעה ואינו מבטיח שלמות.
מקרה קבלה שניתן לשחזר
דוגמה בדיונית: הנתונים אינם מתארים לקוח או תוצאה שנצפתה.
הצגת נתוני המקרה
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}החלטה צפויה
באזור הזמן שצוין האירוע שייך ל־9 באוקטובר. שמרו גם את רגע UTC.
נוהל בדיקה
- הגדירו אזור זמן ורגע ייחוס.
- שחזרו אירוע סמוך לחצות.
- שמרו UTC, תאריך מקומי וכלל סגירה. הוסיפו שעה מקומית דו־משמעית בעת שינוי השעון; שמרו היסט ואזור זמן במקום להסיק רגע מסוים.
האם יום הקליטה יכול לשמש כיום האירוע?
רק אם הגדרת הדוח דורשת זאת. שמרו את שני הזמנים והסבירו טיפול באירועים מאוחרים.
מקור ראשוני: PostgreSQL — Date/time types. שיטה קשורה: קריאת המדריך המעשי.