Monthly Archives: מרץ 2015

28מרץ

UserId בגוגל אנליטיקס לניתוח משתמשים

גוגל אנליטיקס ובעיית המשתמשים הסטטיסטים

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

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

Universal Analytics וה-User ID

עם השקת ה-Universal Analytics בשנה שעברה גוגל ניסו לשפר את המצב ואת נתוני אותם דוחות משתמשים ולשם כך השיקו את הפיצ׳ר של User ID. התוספת הזו מאפשרת לנו, כבעלי אתר או אפליקציה, לתת יותר אינפורמציה לגוגל אנליטיקס על המשתמשים שלנו. גוגל אולי לא בהכרח יודעת ששני גולשים משני מכשירים שונים הם אותו אדם, אבל אנחנו כבעלי אתר יכולים לפעמים לדעת את זה כאשר המשתמש נרשם ומזדהה (מבצע לוגין). ישנם אתרים שמחייבים הרשמה (כמו פייסבוק), ישנם כאלה שלא, אבל בגוגל אנליטיקס בגרסת היוניברסל (ואם עדיין לא לא המרתם אתרים ישנים שלכם מהקוד הישן של אנליטיקס לזה של יוניברסל, עכשיו זה הזמן), מאפשרים לנו להעביר מידע מזהה לקוח לתוך דוחות האנליטיקס דרך הפרמטר user id.

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

גוגל היא חברה ששומרת על פרטיות, או בעיקר לא רוצה לקחת אחריות על נושאי פרטיות ולכן תנאי השימוש בגוגל אנליטיקס אוסרים על העברת מידע מזהה לקוח בצורה מובהקת. זאת אומרת שהערך של ה-user id שאתם מעבירים לגוגל אנליטיקס לא יכול להיות ערך שממנו הם יכולים להבין מי הגולש – לא אימייל, טלפון, שמות וכו׳. לכן הערך של הפרמטר חייב להיות משהו שרק אתם יכולים לקשר לפרטים האמיתיים של לקוח. למשל, אם יש לכם דטהבייס בו רשומים כל המשתמשים שנרשמו לאתר שלכם, תהיה באותה טבלה בדטהבייס עמודת מפתח ייחודית לכל משתמש (זה יכול להיות מספר רץ, או ערכים ייחודים יותר כמו guid). אותו ערך ייחודי יהיה הערך שתוכלו להעביר לאנליטיקס כדי לסמן בצורה טובה יותר את המשתמשים.

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

ga('create', 'UA-XXXX-Y', { 'userId': 'USER_ID' });
ga('send', 'pageview');

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

במידה והטמעתם גוגל אנליטיקס באתר בעזרת Google Tag Manager, העברת הפרמטר תעשה בתוך הטאג של יוניברסל אנליטיקס שיצרתם ב-Tag Manager תחת Fields to Set ועם שם השדה uid&:

userid-in-tag-manager

דוחות מבוססי User ID

לאחר שהטעמתם את הקוד הרלוונטי עדיין יש שני דברים שצריך לבצע כדי לצפות בדוחות המשתמשים המזוהים. דבר ראשון, תחת הגדרת ה-Property של הנכס שלכם, תכנסו ל-Tracking Info < User-Id

user-id-settings

בשלב הראשון הסכימו לתנאי השימוש והעבירו את מצב ה-User-Id ל-ON. עברו לשלב השני ושם תוכלו לסמן אם אתם מעוניינים ב-Session Unification .Session Unification מטפל במצב בו גולש נכנס לאתר, עדיין לא הזדהה (בין אם לא ביצע לוגין או כלל לא הספיק להרשם), ורק לאחר זמן מסוים, או ביקור בכמה עמודים, מבצע את פעולת הלוגין. במידה ונרצה שכל הביקור ישוייך לאותו משתמש, ולא רק החלקים שאחרי הלוגין, נסמן את Session Unification כ-ON.

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

creating a new view for user id

creating a new view for user id

לאחר שיצרתם את ה-View החדש יתחילו להצטבר בו נתונים על כל הטרפיק שמזוהה עם user id. עכשיו גם תוכלו לראות שתחת audience מופיע סט חדש של דוחות – ה-Cross Device. בזכות ה-user id גוגל אנליטיקס עכשיו יכול לחבר יחד נתונים על משתמשים מזוהים, ללא קשר אם עברו מכשירים או דפדפנים (כל עוד היו מזוהים – ביצעו לוגין – בכל אחת מהפלטפורמות).

דוח ה-Device Overlap מציג לנו בצורה גרפית את החפיפה בין סוגי המכשירים השונים – Desktop, Mobile, Tablet

דוח ה-Device Path מציג לנו את כל המכשירים שעברו משתמשים בסדר שעברו אותם:

device-path

למשל בדוח הזה אנחנו רואים ש-1286 משתמשים הגיעו אלינו רק דרך המחשב. 403 נכנסו דרך המובייל, אחר כך דרך המחשב ואז שוב דרך המובייל.

הדוח השלישי, Acquisition Device מציג באיזה סוג מכשיר הגולש המזוהה השתמש כאשר ביקר לראשונה באתר:

acquisition-device

User-ID Coverage

את הדוחות שפירטתי למעלה ניתן כאמור לראות רק ב-View ייעודי שנוצר למעקב אחר ביקורים עם User-ID, זאת אומרת כאשר המשתמש מזוהה. עם זאת אם תסתכלו על ה-View הרגיל של האתר/אפליקציה, זה שמציג את כל נתוני הטרפיק, ללא קשר ל-User-Id, תמצאו דוח חדש תחת Audience>Behavior>User-ID Coverage. דוח זה יציג לכם כמה מהטרפיק שלכם מסומן עם User-ID (וזה מה שמופיע בעצם ב-View שיצרתם קודם), וכמה לא:

user-id-coverage

סיכום

שימו לב שבכל הדוחות שהצגנו עדיין לא ניתן לראות נתונים על משתמשים ספציפיים. זאת לא המטרה של גוגל אנליטיקס, גם בתוספת ה-User-ID. המטרה היא לאפשר לנו להבחין בין משתמשים ״יוניקים״ כפי שמוגדרים בתצורה הרגילה של אנליטיקס (כדפדפן מתוך מחשב/מכשיר ספציפי), לעומת מעקב טוב יותר אחר משתמשים שמגיעים אלינו מכמה מכשירים שונים, שעם כמות המכשירים המחוברים לאינטרנט, התופעה הזו רק תלך ותגדל (אגב, למרות שדוחות ה-User-Id עדיין לא מציגים מכשירי טלוויזיה חכמים כ-Device שנכנסים ממנו, בדוחות מסויימים באנליטיקס תוכלו לאתר גם טרפיק כזה).

השימוש ב-User-ID אינו חובה כמובן, הוא רק כאן כדי לתת לכם מידע נוסף ונכון יותר אודות המשתמשים. זו דרך טובה למשל להבין שהתנהגות רצויה באתר (כמו המרה לקניה) לא בהכרח נובעת רק ממובייל או רק מדסקטופ – יתכן מאוד ותגלו בעזרת ה-User-Id שאנשים גולשים לאתר שלכם דרך הסלולרי, בודקים את המוצרים שמעניינים אותם ובסוף לשם הנוחות ניגשים למחשב ומבצעים שם את הקניה. כמו עם כל נתון חדש, מגוון התובנות שתוכלו להוציא רחב, רק צריך לקרוא נכון את הנתונים.

תגובות או שאלות? תשאירו למטה.

22מרץ

מדידה משותפת לאפליקציה ואתר

גוגל אנליטיקס במובייל

גוגל אנליטיקס מאפשר לנו למדוד את כל המתרחש באתרים שלנו, ובאותה מידה גם באפליקציות. אם הקמתם כבר View לאחד הנכסים שלכם ודאי ראיתם שניתן להגדיר אם מדובר באתר או באפליקציה. הטמעת אנליטיקס לאפליקציה שונה מזאת של הטמעה באתר. בעוד באתר נדרש לשתול קוד בכל עמוד ועמוד, להטמעה באפליקציה נדרש להוסיף לאפליקציה SDK ייעודי לאנדרואיד או ל-iOS (מערכות הפעלה אחרות למובייל נתמכות בצורה שונה). ניתן לקרוא על צורת ההטמעה באתר של גוגל אנליטיקס, שימו לב שהמדריכים מיועדים למפתחי אפליקציות – https://developers.google.com/analytics/solutions/mobile

יצירת View לאתר או אפליקציה

הבחירה של סוג ה-view משפיעה על הדוחות המוצגים לאחר מכן בחשבון האנליטיקס. ההבדלים לא מאוד גדולים אך הסמנטיקה קריטית – במקום דפים יש מסכים. דוחות מיוחדים קיימים על פי גרסת האפליקציה או מערכת ההפעלה, ועוד הבדלים נוספים, אך בסופו של דבר העקרון דומה – אנחנו מקבלים סט של דוחות על הקהל המשתמש באפליקציה, מאיפה הוא הגיע, ואופי השימוש של אותו הקהל באפליקציה. גם כאן, כמו בדוחות של אתרים, ניתן להגדיר אירועים (Events) או מטרות (Goals).

חשבון משותף או מפוצל למדידת אתרים ואפליקציות

בדרך כלל תלמדו שעל כל נכס שונה שלכם יש להקים Property שונה (תחת אותו חשבון אם תרצו) בגוגל אנליטיקס. כל נכס כזה מקבל קוד ייחודי לו, ונמדד באופן עצמאי מנכסים אחרים. הבעיה היא שאין שיתוף במידע שבין הנכסים השונים, וכך משתמש שנכנס לשני אתרים שונים, שלכל אחד מהם מוגדר Property משלו, לא יזוהה כאותו משתמש. אך מה קורה אם לחברה שלכם קיים גם אתר וגם אפליקציה ואתם רוצים לחבר את הנתונים יחד? אם תגדירו Property אחד לאתר ואחד לאפליקציה כל אחד מהנכסים כאמור ימדד באופן עצמאי. עם זאת, אם תשתמשו באותו קוד נכס (property id) לאתר והאפליקציה, המידע כולו ישמר תחת אותו נכס. גם אם תמדדו את שני הנכסים כאחד, עדיין תרצו להפריד בין הדוחות, כי כאמור לאפליקציה סט דוחות שונה מאלה של אתר. אז איך עושים את זה?

Filtered Views לאתר ולאפליקציה

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

לשם כך נכנס ל-Admin תחת טור ה-View ונבחר ב-Filters

Admin_views

וניצור פילטר חדש עם ההגדרות האלו:

פילטר אפליקציה

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

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

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

 User-Id

כדי לפתור את האתגר שציינתי למעלה – אותו cross platform – כאשר משתמש עובד עם מספר ממשקים שונים על אותו הנכס, גוגל אנליטיקס השיקו יחד עם היוניברסל אנליטיקס את הקונספט של user-id. מדובר בזיהוי ייחודי לכל משתמש שאתם כבעלי הנכס צריכים להזין לכל מדידה של אנליטיקס בדף, או במסך באפליקציה. במקרים בהם המשתמש אנונימי (לא מחובר), לא תשמרו user-id, אבל לאחר שהמשתמש מתחבר תוכלו לשמור יחד עם הביקור שלו פרמטר שמזהה אותו באופן ייחודי. מדיניות השימוש של גוגל אנליטקס אוסרת על שימוש במידע מזהה על המשתמש כערך לאותו user-id, לכן לא תוכלו למשל להשתמש במייל שלו, או מספר הטלפון. לעומת זאת, בהנחה שכל המשתמשים שלכם שמורים באיזשהו דטהבייס, תוכלו לייצר להם id ייחודי שאותו תוכלו להעביר לאנליטיקס. כל עוד שמרתם את אותו user-id לאותו משתמש, בלי קשר לממשק אליו התחבר (אתר או אפליקציה), תוכלו לקבל נתונים אחידים על המשתמש ולהוציא דוחות שמציגים את התנהגות המשתמש על פני כלל הערוצים. שימו לב שעדיין, כדי לקבל מידע אחיד על משתמש על פני ממשקים שונים, חשוב שכולם יוגדרו תחת אותו ה-property.

device overlap

איזורי החפיפה בתמונה מציגים לנו משתמשים שביקרו ביותר מממשק אחד – למשל, משתמש שגם ביקר באתר וגם פתח את האפליקציה של אותה החברה

על הגדרת ה-user-id והדוחות שניתן לראות שמבוססים על המשתמש ניתן לקרוא בפוסט הזה.

© Copyright 2015, All Rights Reserved