איך GA4 מזהה משתמש?
ספירת משתמשים היא תמיד ספירה של מזהים ולא של בני אדם. השאלה היא איזה מזהה. לפי התיעוד של Google יש שלושה מרחבי זהות, שכל אחד מהם פותר בעיה אחרת.
| מרחב הזהות | מאיפה הוא מגיע | מה הוא יודע לחבר |
|---|---|---|
| User-ID | מזהה קבוע שאתם יוצרים ושולחים למשתמשים מחוברים | סשנים, מכשירים ופלטפורמות של אותו משתמש |
| Device ID | באתר ה-client ID, באפליקציה ה-app-instance ID | ביקורים חוזרים מאותו דפדפן או מאותה התקנה |
| Modeling | מידול לפי התנהגות של גולשים דומים שאישרו עוגיות באותו נכס | פערים של גולשים שסירבו לעוגיות |
התיעוד מגדיר את User-ID כמרחב הזהות המדויק ביותר, כי הוא נשען על נתונים שאתם אוספים בעצמכם. מזהה המכשיר חלש ממנו מטבעו. באתר הוא נשמר בעוגיית צד ראשון בשם _ga, שתוקף ברירת המחדל שלה שנתיים. לפי התיעוד, הדפדפנים מגבילים בעצמם את אורך החיים של עוגיות צד ראשון כשהגולש לא חוזר לאתר: עד 400 ימים ב-Chrome ועד 7 ימים ב-Safari. גולש שחוזר אחרי שהעוגייה פגה, או מדפדפן אחר, הוא מבחינת מזהה המכשיר משתמש חדש.
מה זה User-ID ומה הכללים שלו?
User-ID מאפשר לשייך מזהה משלכם למשתמש, כך שאפשר לחבר את ההתנהגות שלו בין סשנים, מכשירים ופלטפורמות. Analytics מתייחס לכל user ID כאל משתמש נפרד. אלה הכללים שהתיעוד מפרט:
| הכלל | מה הוא אומר בפועל |
|---|---|
| אורך | כל user ID באורך של 256 תווים או פחות |
| בלי מידע מזהה | המזהה לא מכיל מידע שצד שלישי יכול לזהות לפיו את האדם. כתובת מייל גלויה אינה user ID, משתמשים במזהה פנימי ממערכת הלקוחות |
| ייחודי ועקבי | מזהה אחד לכל משתמש, שמוקצה באופן עקבי, בדרך כלל בהתחברות. מזהה שמשותף לכמה משתמשים מעוות את הנתונים |
| null בהתנתקות | אחרי התנתקות שולחים null ולא מחרוזת ריקה או ערך דמה. התיעוד מזהיר שמזהי דמה חוזרים עלולים לגרום לנתונים שגויים |
| אין רטרואקטיביות | נתונים שנאספו לפני ההטמעה לא מעובדים מחדש ולא משויכים ל-user ID |
| נכס אחד | נתוני User-ID לא משותפים בין נכסים |
כלל נוסף שהתיעוד למפתחים מדגיש: user_id הוא פרמטר מערכת שמור. לא מגדירים אותו כ-user property, לא שולחים אותו כפרמטר אירוע ולא רושמים אותו כמימד מותאם. מימד מותאם על מזהה משתמש יוצר מימד עם מספר עצום של ערכים ייחודיים, פוגע בביצועי הדוחות ודוחף נתונים לשורת (other). על המגבלות האלה כתבנו במדריך על מימדים ומדדים מותאמים ב-GA4.
איך שולחים User-ID דרך Google Tag Manager?
- דוחפים את המזהה ל-dataLayer. כשהמשתמש מחובר, האתר דוחף את user_id. לפי התיעוד הדחיפה חייבת לקרות לפני קוד הקונטיינר של Google Tag Manager. אחרת הערך לא יהיה זמין כשהתגים נורים בטעינת העמוד.
- יוצרים משתנה. ב-Variables יוצרים משתנה מסוג Data Layer Variable שקורא את user_id.
- מעדכנים את ה-Google tag. ב-Configuration settings של התג מוסיפים שורה עם הפרמטר user_id ובוחרים בה את המשתנה.
- שומרים ומפרסמים. אחרי בדיקה ב-Preview מפרסמים את הגרסה.
// before the GTM snippet
dataLayer.push({ 'user_id': 'USER_ID' });התיעוד מגדיר שלושה מצבים: למשתמש שמעולם לא התחבר לא שולחים את הפרמטר בכלל, למשתמש מחובר שולחים את המזהה שלו ולמשתמש שהתנתק שולחים null. יש מלכודת שכדאי להעביר למפתחים: לפי התיעוד המחרוזות "null" או "undefined" במירכאות נחשבות מזהה אמיתי. אם הקוד שולח אותן, כל הגולשים הלא מחוברים יאוחדו למשתמש אחד ענק. מי שמטמיע בלי Google Tag Manager מוסיף את הפרמטר user_id לפקודת ה-config של gtag.js בכל עמוד.
מה קורה לאירועים שלפני ההתחברות ואחרי ההתנתקות?
לפי התיעוד, אירועים שהופעלו לפני שה-User-ID נקבע משויכים למזהה ברגע שהוא נקבע. הדוגמה שבתיעוד מתרחשת בתוך סשן אחד: גולש מפעיל כמה אירועים ורק אחר כך מתחבר. האירועים שלפני ההתחברות משויכים למזהה שלו.
בכיוון ההפוך זה לא עובד: אירועים שנשלחים בלי User-ID אחרי התנתקות לא משויכים למזהה. אם המשתמש מתחבר שוב באותו סשן עם אותו מזהה, האירועים הבאים חוזרים להיות משויכים אליו.
מה ההבדל בין Blended, Observed ו-Device based?
זהות הדיווח היא ההגדרה שקובעת באילו מרחבי זהות הדוחות משתמשים. לפי התיעוד, Analytics משתמש בה בכל הדוחות כדי למנוע ספירה כפולה של משתמשים ולבנות מסע משתמש אחיד.
| האפשרות | סדר השימוש במזהים | מתי היא מתאימה |
|---|---|---|
| Blended | User-ID, אחריו מזהה מכשיר, אחריו מידול | כשרוצים את התמונה המלאה, כולל הערכה של גולשים בלי הסכמה |
| Observed | User-ID, אחריו מזהה מכשיר | כשרוצים רק נתונים שנצפו בפועל, בלי מידול |
| Device based | מזהה מכשיר בלבד, בהתעלמות מכל מזהה אחר שנאסף | כשמשווים לכלי שסופר לפי מכשיר או דפדפן |
זהות הדיווח Blended
באיזה סדר GA4 בוחר מזהה למשתמש
משנים את ההגדרה ב-Admin, תחת Data display, בלחיצה על Reporting identity. בוחרים אפשרות ולוחצים על Save. צריך הרשאת Editor ומעלה. הנקודה החשובה: לפי התיעוד הבחירה לא משפיעה על איסוף הנתונים או על העיבוד שלהם, כך שאפשר לעבור בין האפשרויות בכל רגע בלי השפעה קבועה על הנתונים. לכן זאת גם דרך אבחון טובה: כשמספר המשתמשים נראה מוזר, עוברים זמנית בין האפשרויות ורואים איזה מרחב זהות אחראי לפער. על המידול ועל הקשר שלו ל-Consent Mode הרחבנו במדריך על מה ש-Consent Mode v2 משנה בדוחות.
מה התפקיד של Google signals?
Google signals הוא לא אחד ממרחבי הזהות שלמעלה ובעמוד התיעוד העדכני על זהות הדיווח הוא לא מופיע בכלל. לפי התיעוד, Google signals עוסק בטיפול בנתונים ש-Google אספה על משתמשי Google. הדיווח המועשר חל על משתמשים שהתחברו לחשבון Google שלהם והפעילו Ads Personalization. הפעלה שלו עשויה לשפר את דוחות הדמוגרפיה ותחומי העניין.
מפעילים אותו ב-Admin, תחת Data collection and modification, בלחיצה על Data Collection, במתג Enable Google signals data collection. אפשר לבחור באילו אזורים האיסוף פעיל. לפי התיעוד, נתוני משתמשים מחוברים של Google פגים כברירת מחדל אחרי 26 חודשים. אם הגדרת שמירת הנתונים בנכס קצרה יותר, התקופה הקצרה היא שקובעת.
שני פרטים שמשפיעים על העבודה היומיומית. לפי התיעוד, ל-BigQuery מיוצאים נתוני אירועים שמשויכים לעוגיות פסאודונימיות. לכן אותו משתמש עלול להיספר שם כמה פעמים במכשירים שונים ומספר האירועים למשתמש יכול להיות שונה בין הממשק של Analytics ל-BigQuery.
הפרט השני הוא שינוי בחלוקת השליטה. עד 15 ביוני 2026 האיסוף של עוגיות ומזהים של Google Ads דרך התג של Analytics נשלט גם בהגדרת Google signals וגם בהגדרות הפרסום של Consent Mode. לפי מרכז העזרה של Analytics, מאותו תאריך Consent Mode הוא הבקרה היחידה על הנתונים האלה. בהודעת העדכון שלה Google כתבה שמאותו תאריך ההגדרה של Google signals שולטת רק בשיוך של נתוני Analytics למידע על משתמשים מחוברים, לצורך דיווח התנהגותי. נכון ליום הבדיקה עמוד ההודעה עצמו עדיין מנוסח בלשון עתיד, אבל עמוד העזרה על המרות ואירועי מפתח כבר מתאר את המעבר ל-Consent Mode בלשון עבר.
מה הקשר בין זיהוי משתמשים לספי נתונים?
ספי נתונים (data thresholds) מסתירים נתונים בדוחות כדי שלא יהיה אפשר לזהות משתמש בודד. התיעוד על זהות הדיווח קושר אותם ישירות לנושא: כדי ליהנות מ-Blended ומ-Observed צריך לאסוף user IDs, לצד מספיק פעילות של משתמשים מחוברים כדי שזהות של אדם בודד לא תיחשף. כתוצאה מכך, לפי התיעוד, הדוחות כפופים לספי נתונים. את הנושא כולו, כולל מה אפשר לעשות כששורות נעלמות, פירטנו במדריך על ספי נתונים, דגימה ושורת (other).
איך בודקים שה-User-ID עובד?
התיעוד מציע שלוש בדיקות. הראשונה היא המימד Signed in with user ID: בונים איתו השוואה (comparison) בדוחות או ב-exploration כדי לראות משתמשים מחוברים מול לא מחוברים. אם כל התנועה מופיעה כלא מחוברת, המזהה לא מגיע.
השנייה היא User Explorer. מזהי המשתמש הגולמיים לא מופיעים כמימד בדוחות הרגילים. אפשר לראות אותם ב-User Explorer תחת Effective user ID, בתנאי שזהות הדיווח היא Blended או Observed.
השלישית היא BigQuery. לניתוח של מזהים גולמיים התיעוד ממליץ על הייצוא ל-BigQuery, שבו השדה user_id זמין. לפי התיעוד, מזהי המשתמש שנאספו מיוצאים ל-BigQuery בלי קשר לסטטוס ההסכמה של המשתמש. את זה צריך להביא בחשבון מול היועץ המשפטי. איך זהות המשתמש מתחברת בין אתר לאפליקציה באותו נכס מוסבר במדריך על אפליקציה ואתר באותו נכס GA4.
שאלות נפוצות
איך GA4 מזהה משתמש?
לפי התיעוד של Google יש שלושה מרחבי זהות. User-ID הוא מזהה קבוע שאתם שולחים למשתמשים מחוברים. Device ID הוא ה-client ID באתר או ה-app-instance ID באפליקציה. Modeling משלים פערים של גולשים שסירבו לעוגיות לפי התנהגות של גולשים דומים באותו נכס. זהות הדיווח קובעת באילו מהם הדוחות משתמשים.
מה ההבדל בין Blended, Observed ו-Device based?
Blended משתמש ב-User-ID אם נאסף, אחרת במזהה המכשיר, אחרת במידול. Observed משתמש ב-User-ID אם נאסף, אחרת במזהה המכשיר, בלי מידול. Device based משתמש במזהה המכשיר בלבד ומתעלם מכל מזהה אחר שנאסף. משנים את הבחירה ב-Admin, תחת Data display, בלחיצה על Reporting identity.
האם שינוי זהות הדיווח משנה את הנתונים שנאספו?
לא. לפי התיעוד של Google הבחירה בזהות הדיווח לא משפיעה על איסוף הנתונים או על העיבוד שלהם. אפשר לעבור בין Blended, Observed ו-Device based בכל רגע בלי השפעה קבועה על הנתונים. השינוי משפיע רק על האופן שבו הדוחות סופרים משתמשים ומחברים את המסע שלהם.
מה האורך המקסימלי של User-ID ומה אסור לשלוח בו?
לפי התיעוד של Google כל user ID חייב להיות באורך של 256 תווים או פחות. אסור שיכיל מידע שצד שלישי יכול להשתמש בו כדי לזהות את האדם, כמו כתובת מייל. אחרי התנתקות שולחים את הערך null. מחרוזת ריקה, ערך דמה או המחרוזת null במירכאות אינם תקינים.
האם אירועים שלפני ההתחברות משויכים ל-User-ID?
כן. לפי התיעוד של Google, אירועים שהופעלו לפני שה-User-ID נקבע משויכים למזהה ברגע שהוא נקבע. הדוגמה בתיעוד היא גולש שמפעיל אירועים ורק אחר כך מתחבר באותו סשן. אירועים שנשלחים בלי User-ID אחרי התנתקות לא משויכים למזהה. נתונים שנאספו לפני הטמעת User-ID לא מעובדים מחדש.
מה זה Google signals ב-GA4?
לפי התיעוד, Google signals עוסק בנתונים ש-Google אספה על משתמשי Google שהתחברו לחשבון שלהם והפעילו Ads Personalization. הפעלה שלו עשויה לשפר את דוחות הדמוגרפיה ותחומי העניין. מפעילים אותו ב-Admin תחת Data Collection. Google signals אינו אחד ממרחבי הזהות של זהות הדיווח. מאז 15 ביוני 2026 האיסוף של עוגיות ומזהים של Google Ads נשלט ב-Consent Mode ולא בהגדרה הזאת.
מה השורה התחתונה?
מספר המשתמשים ב-GA4 תלוי בשתי החלטות. הראשונה היא האם אתם שולחים User-ID, כי בלעדיו כל דפדפן וכל מכשיר הוא משתמש נפרד. השנייה היא זהות הדיווח, שקובעת אם הדוחות משתמשים גם ב-User-ID וגם במידול או רק במזהה המכשיר. את השנייה אפשר לשנות בכל רגע בלי נזק, אבל את הראשונה צריך להטמיע נכון מההתחלה: מזהה פנימי בלי מידע אישי, null בהתנתקות ובלי לרשום אותו כמימד מותאם. Google signals הוא שכבה נפרדת שמעשירה דמוגרפיה ולא תחליף לאף אחת מהן. אנחנו מטמיעים ובודקים User-ID וזהות דיווח כחלק משירות הטמעת ובדיקת GA4. אם מספר המשתמשים אצלכם לא מסתדר עם מספר הלקוחות האמיתי, כתבו לנו.
מקורות
Analytics Help: Reporting identity, Analytics Help: Measure activity across platforms with User-ID, Google for Developers: Send user IDs, Analytics Help: Activate Google signals for Google Analytics properties, Analytics Help: Updates to Google Analytics Data Controls, Analytics Help: Conversions vs. key events in Google Analytics, Analytics Help: [GA4] Cookie usage on websites
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי