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

GA4 Connection email

firebase-measurement@system.gserviceaccount.com

Search Console connection email

search-console-data-export@system.gserviceaccount.com

בהצלחה!

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

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

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

וככה נראה הסוף (תמונה חלקית):

לצוות ב"כאן" יש את האפשרות לבחור נתוני "אתמול" או טווח תאריכים אחר, לבחור אם רוצים נתוני VOD/AOD או שידורים חיים, או בכלל באילו כתבות תוכן צפו.

תחת ה VOD אפשר לבחור תוכנית/עונה/פרק/שעה ולראות יוניקים צפו, כמה לחצו על play, כמה צפו בדקה או יותר ומה חישוב זמן הצפייה הכולל.  מעבר לזה יש עוד גרפים, trendlines למיניהם, pie charts צבעוניים ועוד חישגוזים שקצרה היריעה מלהציגם.

קביעת יעדים

ב"כאן" רצו שכל הפלטפורמות ידברו בשפה אחת. על פניו זה נשמע קל אבל אתרי ה Web משתמשים בנגן הוידאו של Kaltura, אפליקצית המובייל רצה על מנוע של Applicaster שאורזת למעשה את הגרסה הוובית, ואפליקציית הטלוויזיה (Kan Box) רצה על מנוע של חברת 24i ההולנדית. בין לבין יש גם את נגן האודיו של Omny שמטפל בפודקאסטים וקטעי האודיו השונים. ומאחורי הכל יש את מערכת ניהול התוכן של "כאן" שמחזיקה את כל המידע ומתוחזקת בין היתר ע"י חברה חיצונית. חתיכת סלט.

מערך המדידה היה צריך לתמוך בסוגי התכנים הבאים:

• תכני טקסט (כתבות) – כולל שם הכתבה, שם הכתב, קטגוריות, מילות מפתח וכו'.
• תכני VOD – שם תוכנית ("קופה ראשית"), שם פרק ("כוכבה משדרגת ל GA4"), מספר פרק ומספר עונה.
• תכני AOD – תוכנית ("חיות כיס"), עונה (אם יש), שם פרק ("שאול מגלה את עולם הלק ג'ל") וכו'.
• תכני Live – האזנה לערוצי רדיו וצפייה בשידורים חיים.

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

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

תוכנית עבודה

אז איך מתחילים פרוייקט כזה? הנה המתודלוגיה לפניכם.

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

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

הפלטפורמות הטכנולוגיות המשתתפות במשחק

כל אחת מהחברות שציינתי מקודם – אפליקסטר, קלטורה, 24i  – מחזיקות את התוכן ואחראיות להצגה שלו (אם הוא תוכן טקסטואלי), או לניגון שלו (אם זה VOD/AOD או שידור חי), אבל השליטה שלנו על האופן בו הדאטה נשלח מוגבלת. לכל חברה יש קריטריונים שונים מה זה Play, איך קוראים לאוונט בדיוק, מתי הוא נשלח וכיו"ב, וללקוח (כלומר ל"כאן") לא תמיד יש say בעניין. חברות טכנולוגיה מספקות את צרכי המדידה באופן גנרי לכמה שיותר לקוחות, ומשתדלות ככל האפשר להמנע מקסטומיזציות ייעודיות ללקוח. (בהזדמנות אני אכתוב איך זה להרים כלי מדידה לתוכנות שישרתו את כלל הלקוחות. זו הרפתקאה מרתקת בפני עצמה.)

קחו דוגמא: החבר'ה ב 24i שאחראים על אפליקציית ה Box לטלוויזיה החליטו ליישר קו עם הסטנדרט של GA4 ולשלוח אוונטים של מעקב אחרי וידאו בדיוק לפי התיעוד הרשמי וזה עובד באמצעות Measurement protocol.

קלטורה הציעו להשתמש בספריית ה open source שמדווחת אירועים ל Google Tag Manager במקום להשתמש במדידה במובנית בתוך הנגן, ואפליקסטר הציעו סט ענק של אוונטים עם שמות משלהם שנשלחים ישירות ל GA4 באמצעות כלי "מתורגמן" שיושב במערכת הניהול שלהם והדאטה בכלל נשלח ל Firebase. כשמציירים את זה, זה מתחיל לקבל צורה:

מה רואים בתרשים?

חלק א' (למעלה) – אפשר לראות שאפליקציות המובייל (iOS/Android) מנוהלות על ידי Applicaster, שואבות נתונים מה CMS של "כאן" (שמכיל את המידע המאד חשוב של מספר פרק, עונה, ומאפיינים נוספים) עם נגן הוידאו של קלטורה ונגן האודיו של Omny.

המערכת של Applicaster אורזת את הכל כאפליקציה עם ה SDK של Firebase ושם נוצרים כל האוונטים. לשמחתי Applicaster נותנים ל"כאן" ממשק שמאפשר להם לשלוט בחלק מהאוונטים ולהעשיר את המידע שנשלח. כלומר, כשצופה לוחץ על PLAY נדע לא רק את הפעולה עצמה, אלא גם את שם הפרק, העונה וכו'. מידע שמגיע מה CMS בכלל ושאפליקסטר דואגים שיתגלגל הלאה.

חלק ב' – האתר עצמו, מכיל את הנגן של קלטורה ופה הייתה צריכה להתבצע עבודת הטמעה "ידנית" עם Google Tag Manager, אבל מאיפה הוא יקבל את המידע? הנגן של קלטורה צריך לשלוח לו מידע על התוכן שנטען ועל הפעולות של היוזר. לשמחתנו Kaltura שחררו ל GitHub ספרייה עשירה מאד של פקודות שהם יכולים לירות ל dataLayer. בנוסף לזה, ה CMS של "כאן" יודע להגיד כל פעם שנטען דף עם פרק כלשהו, איזה פרק זה, עונה וכו'. כנסו לאתר של כאן, בחרו פרק ב VOD ונגנו אותו. אם יש לכם analytics debugger, אתם תראו את כל המידע שעובר הלאה ל GTM על כל הפעולות שמתרחשות בנגן. רוב האוונטים האלה נורים על ידי Kaltura באמצעות הספרייה המיוחדת שלהם:

וככה זה נראה כשזה יוצא ל GA4 אחרי שמועשר על ידי המידע מה CMS:

אפשר לראות את כל ה Custom dimensions שמכילים את שם הפרק, התוכנית, מספר עונה וכו'. בהמשך, אפשר לקחת את המידע הזה ו"להדביק" אותו לפעולות של הנגן. אם מישהו לחץ על Play אפשר לדעת איזה פרק זה היה וכו'.

חלק ג' – אפליקציית BOX, שואבת את הנתונים מ ה CMS אבל שולחת את הדאטה ישירות ל GA4 באמצעות ה Measurement protocol. אין Firebase ואין שום דרך להתערב באמצע. מה שיש זה מה שיש. 

יצירת Custom dimensions והטמעות

כדי לתמוך בכל המטא-דאטה (שם פרק, עונה וכו'), נתתי ל Firebase לקבוע את הטרמינולוגיה של כל ה custom dimensions ולאחר מכן האתרים שלחו את הדאטה לאותן שדות.  עם זאת, אפליקציית הטלוויזיה, בגלל מבנה הנתונים המיוחד שלה, שולחת דאטה לחשבון נפרד עם שדות שונים. את "התרגום" וההתאמה בין שני העולמות האלו, ביצעתי בשאילתות עצמן ב BigQuery.

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

אורזים את הכל

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

1. עבור כל פלטפורמה (אפליקציה, אתר, BOX), יש שאילתה שרצה על נתוני האתמול, מעבדת את הנתונים ו"מתרגמת" אותם לשפה חדשה, המשותפת לכל מקורות המידע. את הנתונים הסופיים,  מעבירים לטבלה שטוחה ופשוטה לניתוח שמכילה עבור כל "פרק" את כל הפעולות שבוצעו עליו. למשל בטבלה יש שורה אחת של קופה ראשית, עונה 5, פרק 2, שעה 5 בבוקר, ושם פלטפורמה (אתר, אפליקציה..) עבור השורה הזו יש נתוני צפייה מצטברים – כמה התחילו צפייה, מה זמן הצפייה המצטבר וכו'. השאילתות דרשו fine-tuning בכמה וכמה סבבים עד שהתוצאות היו טובות. זה לא פגע במכה הראשונה והיה צורך לבדוק כל הזמן מול ה Raw data ולעשות חישובי סנדלרים ואקסלים כדי לוודא שמה שהשאילתה מוציאה אכן make sense. זה השלב הכי קשה בפרוייקטים כאלה. להוכיח שהשאילתה "צודקת", וככל שיש יותר עיניים על התהליך – יותר טוב.
2. נתוני realtime  ב BigQuery. שימו לב, שכשעוברים מליון אוונטים ביום, הסנכרון היומי (Daily) של GA4 עם BigQuery מפסיק לעבוד (מקבלים התראה). עם זאת, אם הפעלתם את הסנכרון גם של ה Realtime – הדאטה ממשיך להגיע לטבלאות realtime. אני ממילא תשאלתי רק את נתוני אתמול, אז לא דאגתי יותר מדי.
3. לא הטמעתי את כל האתרים במכה אחת. עברתי אתר אתר, פלטפורמה פלטפורמה. התוכנית לטווח הארוך כבר הייתה כתובה, אבל כדי לאפשר לי סביבה סטרילית ככל האפשר לדיבוגים, העדפתי לשדרג פלטפורמה אחת, לראות שהדאטה תקין, לכתוב את השאילתות, לחכות לנתונים, להעלות אותם על הדשבורד, לראות שהמספרים make sense, ואז לצרף את האתר הבא. בתצורה הזו גם "כאן" קיבלו תוצרים חלקיים מצטברים. במקום להמם אותם בבלוק של נתונים מכל הפלטפורמות עם קושי בדיבוג, החלוקה לשלבים הייתה במובן מסויים בריאה יותר לתהליך. הנה נתוני האתר בלבד, ננתח אותם כמה זמן ועוד שבוע נצרף גם את נתוני ה Box וכן הלאה. אנשי הפיתוח שביניכם מכירים את זה כ Iterative development או סוג של  Continues integration. מעבר לזה, יש עוד בונוס חשוב – זה מראה ללקוח על התקדמות הפרוייקט.
4. חישוב זמני הצפייה היה מסובך כי ל Applicaster יש נתונים בתצורה אחת שמצריכים חישוב מסוג אחד, ל 24i שיטה אחרת לגמרי וב Kaltura צריך לחשב לבד, כדי להגיע לזמן הכי מדוייק שניתן, ברמת האייטם הספציפי. מעבר לזה, חלק מהפלטפורמות שולחות נתונים בשניות וחלק בדקות. אז יש פה הרבה נוסחאות וטריקים חמודים אבל בסוף צריך להציג מספר אחד.
5. טיוב נתונים – כשהנתונים התחילו לזרום ל BQ ובהמשך לדשבורד, התחילו לצוץ כל מיני אנומליות מוזרות. מספרים שקפצו לשמיים או התאפסו, תווים מוזרים שהגיעו וכל מיני. זה כמעט שלב מנדטורי בפרוייקטים כאלה. שלב טיוב המידע. קשה מאד לראות את הנתונים החריגים האלה מבעוד מועד, ודווקא ההשפעה שלהם בתוצאה הסופית ישר מצביעה על האשמים. פעם זה משך פרק שהוזן ל CMS בשניות במקום בדקות (או ההיפך), פעם זה זמן שחסר או מספר עונה שלא מופיע וכו', והרבה NULL-ים יתומים שקופצים מדי פעם. לאט לאט לאחר טיוב הנתונים הבנו מאיפה הפערים יכולים להיווצר ועכשיו צריך לדאוג שהמקרים האלה לא יחזרו שוב.
6. תיעוד תיעוד תיעוד – התיעוד תמיד חשוב אבל הפעם במיוחד. אנליטיקס במערכות מורכבות הוא טריקי ומסובך. התיעוד מאפשר לאנשים חדשים להרים מכסה מנוע ולהבין מיד איך המנגנון עובד. זה אומר איך קוראים לשאילתות, מה הלוגיקות מאחורי הקלעים, איך הדאטה נשלח ונשמר וכו'. אגב, התיעוד חשוב גם לי, לא רק ללקוח. לא תמיד מתאפשר לכם לעבוד על פרוייקט ברצף. כדי לחזור לעניינים, פשוט חוזרים למסמך התיעוד ונזכרים מה עשיתים לפני חודש. במיוחד אם יש פתאום באג. 
7. ונקודה אחרונה וחשובה מאד! הפרוייקט לקח המון זמן. לא שעות עבודה, אלא זמן קלנדרי. כל שינוי, טיוב, בדיקה, זה עוד יום ועוד שבוע שעבר בהמתנה לנתונים או תיקונים בקוד, או בכלל העלאת תיקון לאפליקציה וסתם לחכות לספרינט הבא. עם זאת, היינו נחושים והצוות ב"כאן" היה סבלני עד כמה שאפשר (תודה לכם!), ועקב בצד אגודל הגענו לסיום המיוחל. ארוך אבל סופר מתגמל. איך כוכבה אומרת:

שחקן חדש – גוגל אנליטיקס!

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

איך גוגל אנליטיקס עושה אטריביושן

זוכרים את התמונה בחלק א' של המאמר? זו שמראה איך חלונות ההמרה של כל הפלטפורמות "חופפים"? אז לגוגל אין ממש "חלון המרה". מה שגוגל אנליטיקס רואה זה רק את הביקורים של היוזרים באתר על פי מקורות ההגעה שלהם (זה בהנחה שהכל מתויג פיקס עם UTM). מסע לקוח שכולל 5 ביקורים לפני ההמרה נראה בעיני גוגל אנליטיקס כאוסף של נקודות, או Touch points:

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

כל הדוחות בגוגל אנליטיקס מיישרים קו לפי אותו עקרון . למשל, אם תלכו לדוח המרות לפי מדינה, המדינה שהייתה בביקור האחרון תקבל את הקרדיט. אם טיילתי בעולם עם הלפטופ שלי, ונכנסתי לאתר שלכם בכל פעם ממדינה אחרת, אז בביקור החמישי משבדיה, שעשיתי דרך טאבולה וגם המרתי – ההמרה תשויך לשבדיה. כנ"ל דוח המרות לפי שעות. גם אם בכל הביקורים ההיסטוריים נכנסתי בשמונה בבוקר, אבל ב14/11 נכנסתי בשש בערב, אז גוגל יגיד ששש בערב זו שעת ההמרה. אבל זה לא הספיק לגוגל ובטח שלא למשתמשים ולאנליסטים. אז במקום לפרק ולבנות מחדש את כל המערכת, הם פיתחו סט דוחות שנקרא Multi Channel Attribution. 

Multi Channel Attribution

תחת דוחות ה Conversion תמצאו סט דוחות תחת הכותרת Multi Channel Attribution. שם תמצאו דוח חמוד בשם Top Conversion Paths שמציג את כל ה Touch points של היוזרים שהמירו. הדוח נראה ככה:

למעלה, תחת Conversion, בחרתי את ההמרה שמעניינת אותי, נניח Subscription, או PDF Download או Purchase. אגב, הדבר הכי גרוע לעשות זה להשאיר את ברירת המחדל שזה "All Conversions".

לאחר מכן, ב Path Length בחרתי "One or more" שזה אומר: "תראה לי המרות שכללו Touch point אחד לפחות." תוכלו לראות שגם פה אפשר לבחור Lookback window. כלומר, גוגל מסתכל על כל ההמרות שבוצעו בטווח התאריכים שבחרתם למעלה בצד ימין, ועבור כל אחת מההמרות, גוגל "הולך אחורה בזמן" לפי החלון שהגדרתם, כדי לאסוף מידע על היסטוריית הביקורים של היוזר. כמה אחורה? מה שתקבעו ב Lookback Window. ברירת המחדל היא 30 יום. 

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

אם תקליקו על הכפתור Conversion Segments למעלה, תוכלו לייצר פילטר חכם שיעזור לכם להתפקס על צ'אנל אחד ספציפי שאתם רוצים לתחקר. נניח Facebook CPC, ולראות איך הוא משתלב בהמרות:

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

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

למשל האופציה הרביעית, First Interaction, תתן את הקרדיט למי שהביא את היוזר ראשון. האופציה האחרונה Position Based, תתן חצי המרה לערוץ האחרון וחצי לערוץ ראשון, כך שכל הערוצים שהיו באמצע – לא יקבלו קרדיט.

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

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

איך GA4 עושה אטריביושן

בגרסה 4, גוגל החליטו שברירת המחדל תהיה Cross-Channel Data-Driven Model שזה אומר קודם כל, שהקרידט מתחלק בין כל הערוצים שהיו שותפים להמרה (חוץ מ Direct שלא יקבל כלום בדר"כ), שזה כבר אומר ש GA4 יושב תחת Multi Touch Attribution. אז ברגע שגוגל החליט מי הצ'אנלים שהיו מעורבים בהמרה, הוא צריך להחליט כמה קרדיט לתת לכל אחד מהם. האם זה מחולק שווה בשווה? אם הייתה המרה שהייתה כרוכה בארבעה Touch Points ממומנים, תתחלק שווה בשווה ביניהם וכל אחד יקבל רבע המרה? אז לא. גוגל החליטו לחלק את ההמרה על פי כל מיני מודלים מסתוריים מאחורי הקלעים. זה העתיד אגב, ולשם כולם הולכים.
אם יש לכם כמה המרות מוגדרות ב GA4, אז ה Data-Driven הזה יהיה שונה לכל אחד מהם. זה לא שיש עקרון אחד מנחה לכל החשבון.

גם ב GA4, תוכלו להכנס לדוחות האטריביושן ולבחור מודלים אחרים, משוכללים יותר ממה שיש ביוניברסל וכמובן שיש גם מודלים מסוג Single Touch. 

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

אתגרים באטריביושן

אתגר 1: אטריביושן בעידן של Cross-Device

היוזר שלנו לא חי סביב Device אחד. יש לו סמארטפון בכיס, לפחות מחשב אחד בבית ואולי אפילו טאבלט. רוב רשתות הפרסום יודעות לא רע שאתם בנייד שלכם והרגע עברתם לדסקטופ. כל אחת עם שיטות משלה יודעת לאגד את המכשירים שלכם תחת הזהות שלכם. בפייסבוק, זה יחסית קל. הרי אם אתם גולשים בפייסבוק, זה אומר שאתם בלוגאין, אם בנייד או בדסקטופ, ולכן פייסבוק יכולים לעשות את ניתוחי ה Cross-Device. אצל Google Ads זה עובד אחרת כי אין לה רשת חברתית, אבל יש לה Gmail ו Android ועוד כלים שיכולים לחבר את הנקודות ולספר על עולם ה Cross-Device של כל יוזר. ספציפית גוגל אנליטיקס לא ממש מקבל את המידע הזה (כן, גם GA4 שטוען שהוא מצליח להתמודד עם זה) ולכן הסשנים "שבורים" יותר ולמעשה לא ממש מצליחים לזהות שזה שנכנס ממובייל וזה שנכנס מדסקטופ הם אותו אדם. הם מנסים, אבל זה רחוק מלהיות טוב (ויש גם ענייני Privacy וכל זה.)

אתגר 2: In-App browser ו Apple

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

אתגר 3: אטריביושן של ערוצי אופליין ופעילות ברנדינג

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

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

אתגר 4: ערוצים שלא בשליטתנו

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

אתגר 5: איכות המידע

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

נסכם את הקשיים:

1. ריבוי ערוצי אונליין שלכל אחד חלונות המרה שונים ואלגוריתמים שונים לספירת המרות.
2. אלגורתמים שונים במערכות האנליטיקס.
3. יוזרים שמוחקים קוקיז או שלא נותנים הסכמה למעקב אחריהם (GDPR+User Consent).
4. זמני המרה ארוכים. לקוח נתקל בכם בפעם הראשונה היום ויכול לקחת לו חודשים עד שימיר.
5. ערוצי אופליין שיכולים להשפיע. לעניין הזה יש מה שנקרא אטריביושן עקיף – Implied attribution. שבו בודקים את ההשפעה של ערוצי האופליין על כניסות דיירקט או אורגני, גידול בחיפושי מותג וכו'. למשל קמפיין רדיו שעולה/יורד, כנס שנוכחתם בו שגורם לגידול זמני בכניסות לאתר שאפשר לייחס אותם לכנס וכו'. זה עובד באופן חלקי ולפעמים לפעילות שהיא בעיקר ברנדינג אין השפעה בטווח המיידי.
6. לא בטוח שיש ערוצים שצריך בכלל לשקלל (אונליין או אופליין).
7. לא יודעים איזה מודל לבחור.
8. ערוצים שלא בשליטתנו במיוחד, אבל עלולים לייצר השפעה על מפת האטריביושן.
9. פעילות ברנד משמעותית שכן בשליטתנו, אבל המדידה שלה כמעט בלתי אפשרית.
10. Cross Device.
11. ומעבר לזה – בעיות טכניות, כשלים במדידה, מדידה לא תקנית וכיו"ב.

הנחות יסוד לבחירת המודל

1. שום מודל אינו מושלם.
2. אין באמת בנצ'מארק. כל חברה פועלת אחרת. מכיר לא מעט שהולכים אוטומטית למודל של 40-20-40 כלומר 40% לצ'אנל הראשון, 40% לצ'אנל האחרון, וכל ה"באמצע" יסתפקו ב 20% ביחד (נקרא גם U-shape Model). אבל פופולריות של מודל לא אומרת שהוא מתאים לכם.
3. לכולם יש דעה בנושא אטריביושן. גם לחתול שלי. אל תקשיבו לאף אחד, גם לא לי. תעשו את הטסטים בעצמכם. אל תאמינו לכל בנצ'מארק שקראתם עליו. זה שמודל מסויים עבד טוב בחברה א', לא אומר שהוא יעבוד בחברה ב'.
4. גם אם מגיע משיח מהעתיד ומראה לכם את המודל המושלם ביקום, עדיין המודל הזה מתייחס לנתונים שהצלחתם לאסוף באופן תקין. יש המון רעש, המון דאטה שנופל בין החריצים ובעיקר חוסר דאטה שמשפיע. סוג של לחפש את המטבע מתחת לפנס.
5. אם היה פתרון קסם, כולם היו משתמשים בו. כל החברות הגדולות מנסות להתמודד עם הדבר הזה. אתם לא לבד.

איך בוחרים את מודל האטריביושן המתאים לכם

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

אני ממליץ כמובן להגדיר בנוסף להמרות "קשות" (קבלת ליד, מכירה וכו'), גם המרות רכות יותר (Micro Conversions) כמו add to cart ,צפייה בדף מוצר, הורדת eBook וכיו"ב.

שאלות שצריך לשאול

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

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

אבל מה קורה כשמסע הלקוח אורך כמה חודשים ועובר דרך שלל צ'אנלים?

עוד דוגמא: פיתחתם מערכת SaaS חדשה המיועדת ל DevOps. התחלתם להרים וובינרים מקצועיים לתעשייה ואתם מפרסמים אותם באופן שוטף בקבוצות מקצועיות בפייסבוק ולינקדאין. במקביל, פעילות תוכן ענפה מתחילה לתת גז על מנת להגדיל את הטראפיק האורגני ואפילו הצלחתם להרים שני פרופילים שמתחילים לענות על שאלות ב Stack Exchange ולקבל קצת תשומת לב. לא רק זה, שני אנשי ה Sales שלכם מתחילים ליצור קשר עם לקוחות פוטנציאלים בלינקדאין באמצעות הודעות פרטיות ועוד כמה חודשים אתם בכנס מציגים את המערכת. כל זה, בשאיפה שאחרי 3-4 חודשים שמישהו "מתחכך" בכם בכל מיני צ'אנלים, סוף סוף יחתום על חוזה. במקרה הזה מקובל להשתמש במודל Multi Touch, או מודל U כמו שתארתי מקודם (40-20-40) או אפילו Time Decay שנותן קרדיט לכל הערוצים אבל ככל שהערוץ קרוב יותר לסוף הוא מקבל יותר קרדיט (שימושי כשהסייקל קצר יחסית.)

הפקטורים

מה שמשותף לדוגמאות שנתתי למעלה, הוא שאני מתייחס לשלושה פקטורים:

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

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

ככל שמסע הלקוח ארוך יותר => הנטייה ללכת למודלים של Multi Touch.

ככל שמסע הלקוח קצר יותר => הנטייה ללכת למודלים של Single Touch.

מסע לקוח קצר עם מספר צ'אנלים מרובה=> הנטייה ללכת למודל Time decay שנותן משקל שהולך ועולה ככל שהצ'אנל קרוב לרגע ההמרה. 

מסע לקוח ארוך עם מספר צ'אנלים מרובה=> הנטייה ללכת למודל Position Based שנותן משקל משמעותי לצ'אנל הראשון והאחרון, ומשאיר קצת  לכל אלו שבאמצע (כמו 40-20-40.)

ככל שמספר הצ'אנלים קטן יותר => הנטייה ללכת למודל של Single Touch. אם אין עדיין פעילות Branding, הייתי מתחיל עם Last Click כדי לבחון איזה צ'אנל באמת מצליח להביא למכירה, ובמקביל גם First Click כדי לראות איזה צ'אנל מצליח להביא לי יוזרים טובים לתחילת הפאנל.

מותג חזק עם פעילות מרובת ערוצים => עובד במודל של Multi-Touch. תתחילו ממודל Position Based כלשהו (40-20-40 נניח) ואם טכנית זה אפשרי, אז Data Driven. ממליץ גם להשוות את התוצרים של שני המודלים האלה לראות אולי הם נותנים תוצאות זהות.

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

כך או כך, מדובר בתהליך ארוך שכולל עבודת תשתית משמעותית ולאחר מכן, היכולת לקבל החלטות והכי חשוב – ליישם את מה שלמדתם. וכן, להחליט לחתוך תקציב בחצי באיזה ערוץ יכול להיות בשורות קשות להרבה אנשים.

בונוס: MMM – Marketing Mix Modeling

מודל אטריביושן בשם MMM הוא סוג של מקבילה וותיקה ל Data Driven Attribution, עם כמה הבדלים קטנים. בעוד המנגנונים של DDA הם בדר"כ דינמיים, מבוססי משין לרנינג, בבעלות הפלטפורמות ונמצאות מאחורי הקלעים ולא חשופים לנו, מודל MMM בבסיסו סטטיסטי, כולל בעיקר הרבה רגרסיות, ומבוסס על דאטה מצטבר של כמה שנים אחורה. בנוסף, אפשר לערבב שם גם ביצועי מדיה אופליין (טלוייזיה למשל). את המודל מריצים פעם אחת בגדול על הדאטה ההיסטורי וניתן לרענן אותו מדי פעם.

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

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

בהצלחה לכולם(:

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

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

1. מערכת לניהול קמפיינים – יצירת קמפיינים, בניית מודעות וכו'. זו המערכת שמנהלי הקמפיינים עושים cv את העבודה השחורה, עושים טסטים, מעלים קריאייטיבים שונים, מוצאים מילות מפתח וכל השבנג.
2. מערכת אנליטיקס קטנה ומוגבלת שכוללת כלי להגדרת אוונטים/המרות. גם אם אין לכם קמפיינים בכלל – המודול הזה עובד כמעט stand -alone.
3. מנגנון נסתר שמחבר את שני הסעיפים הקודמים. כלומר, לקחת אוונט שהתרחש, ולהגיד שהוא נגרם בזכות קמפיין מסויים. לפעולה הזו של שיוך אירוע לקמפיין מסוים קוראים Attribution.

איך אטריביושן עובד

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

1. רבקה רואה מודעה כלשהי בפייסבוק. ברגע ההקלקה על המודעה, עוד לפני שהיא מועברת הלאה, פייסבוק כבר יודעים מי היא, מכיוון שהפעולה בוצעה בתוך פייסבוק. אז פייסבוק רושמים בצד – "רבקה, מספר מזהה 100100, קליק אחד על מודעת אינסטגרם של קמפיין בלאק פריידי של חשבון פרסום מספר 999".
2. פייסבוק ממציאים "תעודת זהות" נורא נורא ארוכה וייחודית שתזהה את ההקלקה שלה. זה נקרא Facebook click ID או בקיצור fbclid. אמור להיות רק אחד כזה בעולם. מה שלא כולם יודעים, זה שה fbclid הזה מונפק בכל קליק שמתרחש בתוך פייסבוק שמוציא משתמשים החוצה. גם אם זה ממודעות וגם אם מתוכן אורגני רגיל. פייסבוק יודעת להגיד אם ה fbclid הזה הוא אורגני, מתוך הפיד, אינסטגרם, מהרילס, מהצד, ואולי זה בכלל הגיע מקמפיין מסויים. כלומר, פייסבוק אומרים: "בהנתן fbclid אנחנו יודעים להנדס אותו לאחור ולזהות את כל המידע על המקור שלו."
3. רבקה מועברת לאתר שלכם. כשהיא נוחתת באתר, ה fbclid מופיע בתוך כתובת האתר שהיא נמצאת בו כרגע. כלומר domain.com/page/?fbclid=1234567.
4. באתר שלכם כידוע, מותקן סקריפט קטן שאתם שמתם באתר. זה הסקריפט של הפיקסל של פייסבוק. הסקריפט הזה עושה כמה דברים. דבר ראשון, הוא מייצר (או מעדכן) כמה קבצי קוקיז (עוגיות) ומאחסן מידע נוסף בדפדפן שלכם. בין היתר, המידע הזה שומר את ה fbclid הזה.
5. כאשר הדף נטען, מתרחש עוד דבר – הסקריפט ששמתם באתר "יורה" מידע לשרתים של פייסבוק ואומר להם "תקשיבו חבר'ה, התרחש עכשיו Pageview".  הירייה הזה היא בעצם פיקסל מעקב מיוחד וקטנטן שכאשר הוא יורה את המידע הזה לפייסבוק, הוא אוסף על הדרך מידע מתוך הקוקיז שנוצרו במחשב של רבקה, בין היתר, את ה fbclid. אז עכשיו פייסבוק יודעים ש "רבקה צפתה בדף הבית, של אתר domain.com וה fbclid שלה היה שווה ל 1234567."
6. אחרי כמה דקות רבקה ממלאה טופס ליד ושולחת אותו לאתר. שוב, כל המנגנון הזה שתיארתי עובד והפעם נשלח אוונט מסוג Lead לפייסבוק, עם ה fbclid.
7. פייסבוק סופרים במערכת האנליטיקס שלהם שבוצע Pageview או Lead וזה מה שאתם רואים במסך ה Events manager. בתמונה שלפניכם, פייסבוק כותב שהוא קיבל 459,000 קריאות של Pageviews וגם 11,000 לידים. ממש מערכת אנליטיקס קטנה.
   
   
8. שימו לב שה events Manager סופר את כל האירועים, גם אם לא הגיעו בזכות טראפיק של פייסבוק. כלומר, המספרים האלו אמורים להיות תואמים בערך למספרים שיש לכם בגוגל אנליטיקס או כל מערכת אנליטיקס אחרת.
9. במקביל, פייסבוק מפענחת את ה fbclid שהיא קיבלה עכשיו בחזרה, ואומרת לעצמה "אה, אני יודעת מה זה הקליק הזה. זה קליק של רבקה שנוצר ממודעה של בלאק פריידי של לקוח X".
10. עכשיו, כשפייסבוק יודעת מה האירוע שהתרחש ("Lead") ולאיזה Click ID הוא שייך, ומכיוון שהיא יודעת לאיזה קמפיין שייך ה Click ID הזה, פייסבוק לוקחת את האוונט של ה Lead מהאנליטיקס שלה, ו"מדביקה" אותו לתוך הממשק של ה Campaign Manager, אל המודעה ולקמפיין הרלוונטיים. ואז מנהלי הקמפיין יכולים לראות אם המודעה המירה או לא. הפעולה הזו של הדבקת האוונט לקמפיין/מודעה ספציפיים – נקראת אטריביושן, שיוך. אני קורא לזה אטריביושן מקומי כי הוא מתעלם מכל הגורמים החיצוניים לפייסבוק והוא מתייחס לאיך שפייסבוק לוקחת קרדיט בתוך הקמפיינים של עצמה.

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

האטריביושן אגוצנטרי

נחזור לרבקה.

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

ביום שני, רבקה פותחת את המחשב ובאופן מופלא רואה איזה באנר נחמד של גוגל שמספר לה שעוד יומיים נגמר המבצע. רבקה לוחצת על המודעה ומגיעה לאתר. הפעם, כל התהליך שתיארתי מקודם, קורה שוב, רק מי שעושה את כל המעקב ואת כל ה ClickID, זה גוגל. הם אגב, קוראים ל ClickID שלהם בשם GCLID שזה ראשי תיבות של Google Click ID.

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

אבל לרבקה לא מתחשק לקנות כלום עכשיו. אז היא סוגרת את המחשב ושוכחת מזה.

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

אבל כאן מתחילה הבעיה.

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

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

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

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

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

חלון המרה – Attribution Window

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

1. הגדרנו המרה כלשהי בממשק של Google Ads. נניח Add to cart. בתהליך ההגדרה נתבקש למלא את הערכים האלה שמופיעים בתמונה למטה.
2. Count – לדוגמא, אם מדובר בפעולה transaction כדאי לבחור every, כלומר גוגל יספור המרה על כל עסקה. אם תבחרו One, ההמרה תפעל פעם אחת בלבד עבור אותו יוזר (ניח טופס Leads)
3. בחלק הבא מגדירים Click Through Conversion Window. גוגל אומר לכם: "כמה זמן צריך לעבור מהקליק עצמו עד שההמרה מתרחשת, כדי שאוכל לקחת קרדיט? יום? שבועיים?"
   שימו לב שאפשר לבחור גם 90 יום, כלומר אם מישהו הקליק בראשון לינואר, והמיר רק בסוף מרץ, גוגל יקח על זה קרדיט.
4. בחלק הבא, במידה ואתם מריצים קמפיין ביוטיוב, תוכלו לקבוע כמה זמן עובר בין צפייה של יוזר במודעת וידאו עד לרגע ההמרה עצמה כדי שגוגל יקח קרדיט. לדוגמא, היוזר צופה בסרטון "איך קושרים עניבה" ביוטיוב, ולפני הסרטון הופיעה מודעה מסוג In-Stream. היוזר צפה בה נניח יותר מ 10 שניות ואחרי כמה ימים, בלי שהוא הקליק על שום מודעה, נכנס לאתר והמיר. כאן תוכלו לקבוע את חלון ההמרה של זה.
   
   
5. בהמשך ניתן לקבוע View-Through-Conversion. כאן, ברגע שמישהו רק ראה(!) מודעה שלכם ולא הקליק, אם הוא המיר בהמשך, גם כאן גוגל יקחו קרדיט. אתם יכולים לקבוע את גודל החלון הזה.
6. ההגדרה האחרונה והמאד חשובה, מיועדת למי שעושה כמה סוגי קמפיינים בגוגל. נניח, רימרקטינג, שופינג, חיפוש, יוטיוב וכו'. כולם "תוקפים" את הלקוח מכל מיני כיוונים, וייתכן שהיו לו כמה Touch points. צפה בפרסומת ביוטיוב, הקליק על מודעת שופינג, ואחרי יומיים הקליק בכלל על מודעת Brand. מי מהקמפיינים יקבל את הקרדיט? פה תוכלו לבחור את מודל האטריביושן בתוך גוגל. Last click למשל, ישייך את ההמרה לקמפיין האחרון שהביא אותו. Linear אומר למשל, שכל הערוצים שהיו שותפים להבאת היוזר, מתחלקים בקרדיט. כלומר, אם הייתה עסקה אחת, ויש לכם חמישה קמפיינים שכולם היו מעורבים בתהליך, כל קמפיין יקבל 0.2 המרות. האופציה של Data-Driven אומרת בעצם לגוגל, "שמע גוגל, אין לי מושג מה לבחור, תחליט אתה". עם זאת, צריך לזכור. כל מה שכתבתי בסעיף הזה, מתייחס אך ורק לקמפיינים של גוגל בתוך החשבון והיחסים ביניהם.

איפה הקאצ'?

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

ככה זה נראה בפועל:

ב 1/11 יש קליק ב Snap שהוביל לאתר, לאחר כמה ימים, ב 3/11 אותו יוזר מקליק על מודעה בפייסבוק, ויום אחרי, ב 4/11 הוא מקליק על מודעה בטיקטוק. האורך של ה Bar עצמו מציין את חלון ההמרות של כל פלטפורמה כמו שהגדרתם בסעיף הקודם.

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

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

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

אבל מה יעשו אתרי B2B, שלפעמים מהרגע שהלקוח נחשף לחומרים באתר או לאיזה וובינר, ועד הרגע שהוא קונה משהו, יכולים לעבור 4-5 חודשים? מסובך, אני מסכים. אבל זה עוד כלום, רק התחלתי. 

רוצים להמשיך? ==> כל מה שרצית לדעת על Attribution חלק 2. 

Funnels – תזכורת קצרה

בזמנו, כתבתי מאמר בשם "מפצחים את הפאנל" (שווה לכם לקרוא בכל זאת), שמתאר פרקטיקה חלופית לבניית פאנלים בגוגל אנליטיקס. פאנל במובן Funnel ולא Panel, כן?

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

ככה זה נראה באנליטיקס:

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

הכירו את Trended Funnels בגוגל אנליטיקס 4

אז עכשיו, לא צריך את כל הקומבינות שתארתי במאמר ההוא, ואפשר לבנות את זה באופן מובנה ופשוט.

(1) כנסו ל Explore על מנת לבנות דוח מותאם אישית

(2) תנו שם לדוח

(3) בחרו טווח תאריכים, נניח חצי שנה אחורה

(4) תחת Technique בחרו Funnel

(5) תחת Visualization  בחרו Trended Funnel

(6) בחרו Show elapsed Time כדי שגוגל יגיד לכם גם כמה זמן בשניות עובר בין השלבים (מומלץ).

מגדירים את שלבי  Funnel

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

(1) הזינו את שם ה Step.

(2) בחרו את התנאי, נניח שהצעד הראשון יהיה אוונט בשם add_to_cart.

(3) ב Step2 שאתם מוסיפים, ניתן לקבוע אם אתם רוצים להתייחס למקרים בהם Step2 התרחש מיד אחרי Step1, או שמא אין לכם בעיה שיכולים להיות עוד כמה שלבים ביניהם.

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

ולסיום, הדוח שלכם יראה בערך כך:

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

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

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

מה זה Audience Conversions

בדומה ליוניברסל אנליטיקס, גם בגוגל אנליטיקס 4 ניתן ליצור קהלים, עם הבדל אחד. עכשיו תוכלו לדעת כשיוזר עונה על הקריטריונים של להיות חלק מקהל, ולשלוח Event כשזה קורה. לא רק זה, לא רק שיש לכם אוונט, תוכלו להגדיר אותו כ Conversion! 

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

שלב 1 – בניית קהל

נתחיל בשלב הראשון, יצירת הקהל. את זה עושים דרך תפריט
Configure->Audience->New Audience->Create a Custom Audience 
ולייצר קהל חדש לפי הקריטריונים שבא לכם. שימו לב לתמונה ולמספרים:

1. כאן מזינים את שם הקהל החדש
2. כאן בונים את סט הפעולות שמזהה את הקהל. אפשר לייצר יוזרים שעשו פעולות מסויימות, הגיעו מקמפיינים מסויימים, מדינות וכו'.
3. אפשר לייצר רצף של פעולות. נניח פעולה ראשונה תהיה יוזרים שצפו בדף מסוים, ולאחר מכן התרחש event מסויים.
4. אם יוזר צפה בדף מוצר ביום ראשון, וביום שני, בביקור אחר שלו, ביצע add to cart הרי שאלו שני אוונטים שונים, שבוצעו על ידי אותו היוזר, בשני מועדים שונים. לחלופין, יוזר אחר, יכול לבצע את שתי הפעולות באותו הסשן. כך או כך, הדרופדאון הזה מאפשר לכם לבחור איזה סנריו מתאים לכם. האם רק יוזרים שעוברים את כל התהליך באותו הסשן ייכסנו לקהל, או שזה בסדר אם הפעולות מתפרשות על פני כמה סשנים.
5. כאן אתם קובעים את אורך חיי היוזר בקהל. נניח, מהרגע שהיוזר עונה על הקריטריונים, הוא "צבוע" למשך 30 יום, ואז "נמחק" מהקהל.
6. פה תראו את סימולטור שמציג לכם על סמך 30 הימים האחרונים – כמה יוזרים בעצם עונים על הקריטריונים שלכם ומה גדול הקהל.

שלב 2 – יצירת אוונט

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

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

בנוסף, במסך הזה לא רק שתוכלו לקבוע את שם ה Event, יש אופציה נוספת (Log an additional…). אם תסמנו את הצ'קבוקס הזה, זה אומר שאם אותו היוזר, עונה על התנאי של הקהל כמה פעמים, האם תרצו לשלוח אוונטים נוספים או שמספיקה פעם אחת. 

שלב 3 – יצירת המרה מבוססת על האוונט

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

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

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

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

מה הבעיות כרגע עם גרסה 4

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

בגדול, מהי תוכנית ההסבה לגגוגל אנליטיקס גרסה 4

• לפתוח חשבון בגרסה החדשה.
• להסב את כל האוונטים, ההמרות, הטרנזקציות, וכל המדידות שיש לכם כיום (הזדמנות טובה לעשות דיאטה ולהעיף דברים שאף אחד לא עושה בהם שימוש)
• להכין סט של דוחות קבועים שהתרגלתם כבר לעבוד לפיהם\לבנות דוחות מתאימים ב Data Studio.
• לחברות גדולות יותר – ללמוד את העבודה מול BigQuery ולהריץ של שאילתות.
• והכי חשוב: להמשיך בינתיים לעבוד במקביל בשתי המערכות כי גרסה 4 עדיין לא הכי יציבה.
• לקראת סוף מרץ 2023, להפסיק לגמרי לעבוד עם היוניברסל ונקווה שעד אז יהיו הכרזות חדשות מטעם גוגל.

צריכים סיוע? אני פה לשירותכם, מוזמנים ליצור איתי קשר (או להתקשר ל 03-5104335) ואבצע את כל ההסבה עבורכם.

אחד מהאלמנטים הויזואלים היפים וה Straight-to-the-point שיש, זה ה Gauge. אותו שעון מפורסם עם מחוג כמו שיש על בלוני גז שמודדים לחץ. באנגלית אגב, יש לבטא גייג' (מתחרז עם Age) ולא גאוג' שזו טעות נפוצה. המילה העברית המקבילה היא מד (כמו מד-חום, מד-לחץ.)
השעון החמוד הזה מורכב משני מרכיבים עיקריים. מחוג קטן שמציג את הערך הנוכחי של המדד שאתם רוצים לעקוב אחריו (מכירות, לידים, וואטאבר) ורקע בעל שלושה צבעים המשמשים כאזהרה. כמובן שתוכלו לקבוע את סדר הצבעים. נניח בשעון שמציג יעדי המרות, ככל שהערך עולה הצבע משתנה מאדום->צהוב->ירוק (השעון השמאלי בתמונה למטה.)
בשעון שמציג נניח Bounce rate או כל מדד שיש לכם שאתם בכלל שואפים לערך נמוך ככל האפשר (נניח אוונט של נטישות סל), סדר הצבעים יהיה הפוך. מתחילים מירוק וככל שהערך עולה, הצבע הופך לצהוב ואדום (השעון הימני בתמונה למטה.)

איך בונים Gauge שנראה מליון דולר

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

1. לפני שאנחנו רצים לבנייה בפועל, צריך לזכור שיעדים חייבים להיות תחומים בזמן. יכול להיות שיש לנו יעד מכירות יומי, שבועי, חודשי, שנתי. כל אחד מאלה צריך להיות מיוצג על ידי שעון אחר. במידה ויש לנו יעד חודשי, יש להגדיר את השעון כך שיכיל נתונים של This Month. במקרה הזה, בראשון לחודש הבא, השעון יתאפס והמחוג ירד לנקודת ההתחלה.
2. האובייקט של ה Gauge של דאטה סטודיו הוא קצת פרימיטיבי ולא חכם במיוחד אז ההגדררה שלו קצת טריקית אבל אני בטוח שתסתדרו אם תצמדו להוראות.

כנסו לדשבורד שלכם, וליד הכפתור של Add a chart, יש כפתור נוסף קטנצ'יק שיפתח לכם את המסך הבא ובחרו כמובן ב Gauge:

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

שלב 1 – בחרו את ה Data Source.
שלב 2 – בחרו את המדד, נניח Revenue במקרה הזה.
שלב 3 – בחרו את טווח התאריכים על פי היעד שלכם. אם זה יעד חודשי, בחרו This Month וסמנו גם Including Today.
שלב 4 – לא חובה כמובן אבל אפשר להוסיף פילטרים בשביל שהיעד יציג נתונים רק עבור נניח מוצרים שונים או חלקים שונים של האתר או של הקמפיינים שלכם (נניח רק מכירות מתנועה אורגנית).

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

עיצוב ה Gauge

בחרו את ה Gauge ועברו לטאב של Style על מנת שתוכלו לעצב אותו כמו שצריך, אבל יש פה בעיה שאתם חייבים להיות מודעים אליה.

1. בשדה הראשון, Minimal Range Value נהוג לכתוב אפס, אבל אם למשל זה יעד מכירות חודשיות באתר שבו כבר אחרי יומיים אתם בחצי מליון שקל מכירות, אתם יכולים להתחיל את הטווח במספר גבוה יותר כמובן.
2. בשדה Maximum, לכאורה צריך לשים את היעד שלכם, אבל שימו ערך מקסימלי שאפשר להגיע אליו גם אם עברתם את היעד. כלומר, אם היעד שלי זה מכירות ב60000 בחודש, אתם יכולים לכתוב כאן 60000, אבל אם הצטיינתם, ועברתם את היעד הזה, זה לא יוצג ב Gauge, אז אני ממליץ להגדיר ערך גדול מהיעד, נניח 70000. הגדרה של שני השדות האלה תזיז את המחוג בהתאם למיקום שלו בטווח שקבעתם.
3. השדה Major tick label משמש לכתיבת ערכים בתוך השעון שזה מאד מומלץ. בתמונה כאן אפשר לראות שהגדרתי חמישה ערכים. אממה, יש פה טריק קטן. אתם צריכים קודם כל לקבוע לכמה מקטעים הסקאלה תתחלק, שוב, אני לא מתכוון לצבעים, אלא לשנתות הראשיות. נניח רציתי לחלק לחמישה איזורים, אז אני צריך בראש לקחת את הטווח שבחרתי (0-70000 בדוגמה), לחלק בחמש, וזה יוצא שכל שנתה היא בגודל של 17500. עכשיו אני כותב בשדה הזה את המיקומים של השנתות 0,17500,35000,52500,70000. שימו לב שה Gauge לא יודע לעשות את זה בעצמו. אם אני הייתי המפתח של הווידג'ט הזה, הייתי פשוט שואל לכמה חלקים לחלק את השטח והאם להציג ערכים ודואג לחישוב בעצמי. כאן זה עוד קצת פרימיטיבי ואתם צריכים לעשות את שתי הפעולות בעצמכם. אם טעיתם, זה יראה עקום והמערכת לא תנסה לתקן אתכם. נסו לשחק עם כל מיני ערכים מוזרים או חלוקה לא לינארית, תראו איך העיצוב מתחרפן, שוב, בשלב הזה תתעלמו מהצבעים או מכל אלמנט אחר ותתרכזו רק בשנתות הראשיות ובערכים שלהם. עוד נקודה קטנה, במידה והערכים שלכם הם אחוזים, נניח יחס המרה, אתם צריכים לכתוב כאן שברים עשרוניים בין אפס לאחד. לא לכתוב 50% אלא 0.5.
4. השדה של Number of minor sections מאפשר לכם לקבוע כמה שנתות משניות יופיעו. אותם קווים קטנים שאתם רואים בין המספרים. ככל שיש לכם יותר ערכים ששמתם בסעיף הקודם, כך אתם פחות צריכים את השדה הזה. אם התקמצנתם מקודם, ושמתם רק התחלה אמצע וסוף, מומלץ לפנק בשנתות קטנות.

ועכשיו החלק הכי כיפי!

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

בערך Range start מזינים את הערך המינימלי בו הצבע יתחיל. ב Range end מזינים את הערך בו הצבע מסתיים. לא חייבים שכל הצבעים יהיו "צמודים אחד לשני", ואפילו לא חייבים שהצבע הצהוב יסתיים ב 19,999 והירוק יתחיל ב 20,000. תרשמו 20,0000 בשני המקומות וזה מספיק טוב.

אם תגללו עוד קצת תמצאו צ'קבוקס של Hide Label שמאפשר לכם להעלים את השם של המדד שבחרתם מה Gauge. בשלב הזה, הדשבורד כבר די מוכן, אפשר לזרוק אותו על איזה מסך, להתקין את התוסף של Data Studio Auto Refresh שיטפל לכם ברענונים באופן אוטומטי ואתם על הסוס. אבל חכו, זה עוד לא הכל.

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

אתם חייבים חייבים חייבים (אי אפשר להדגיש את זה יותר), שכל ה Gauge-ים יראו בדיוק אותו דבר. מה זאת אומרת? זה אומר שלכולם יש את אותם הצבעים, ואפילו החלוקה בין הצבעים מבחינה ויזואלית זהה.
זה למשל, דשבורד מחורבן:

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

יאללה בהצלחה!

לפני שמתחילים:

1. זה לא משנה עם איזו מערכת איקומרס אתם עובדים, מג'נטו, Shopify, Woocommerce או מערכת שפיתחתם בעצמכם. לשם פשטות הכתיבה אני פשוט אכתוב back-end. 
2. המצב תמיד לרעת גוגל אנליטיקס. כלומר, לא ייתכן שעסקה תירשם בגוגל אנליטיקס אבל לא תופיע לכם ב back-end. אם זה המצב, אז המפתח על סמים.
3. "אני עובד עם (פלאגין מוכן/שופיפיי/מערכת סגורה כלשהי) אין צורך לבדוק" – אחלה. בכל זאת, עשו את הבדיקה ויפה שעה אחת קודם.

שלב א' – בדיקת עסקאות קיימות

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

נכנסים לגוגל אנליטיקס 4 ל Explore ובונים דוח לפי האפיון הבא:

1. ברשימת הדיימנשנס, לבחור את Transaction ID
2. ברשימת המטריקות לבחור tax amount, shipping amount, purchase revenue, ecommerce quantity 
3. מוסיפים פילטר של transaction id לא שווה ל not set. 
4. מוודאים שבחרתם שיוצגו 50-100 שורות או כמה עסקאות שאשתם מצפים שיופיעו בדוח בטווח תאריכים מסויים.
5. בצד ימין הדוח יציג את רשימת העסקאות עם פירוט ההכנסות לכל עסקה.
6. בוחרים בטווח התאריכים תאריך של יום אחד ספציפי. איזה שבא לכם, רצוי מהתקופה האחרונה.
7. הקליקו על הכותרת של Transaction ID על מנת לראות את העסקאות ממוינות לפי מספר העסקה.

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

מה השגנו עד עכשיו? הבנה של כמה עסקאות "נפלו" לנו.

עכשיו מסתכלים על כמה עסקאות אקראיות מתוך הדוח הזה ומשווים את הנתונים המספריים שמוצגים לנו עם המספרים שיש לכם ב Backend, ובעיקר להשוות את ה Revenue (שווי העסקה), Shipping ו Quantity המייצג את מספר המוצרים בעסקה. במידה ויש חוסר התאמה עם המספרים ב Back-end, סביר להניח שהיא תהיה גורפת לכל העסקאות ולא רק לאחת.  ובמידה ויש בעיה כזו, הגורם הוא בדר"כ הטמעה לא טובה של ה E-commerce ויש לפנות למפתח. אבל לפני שאנחנו פונים אל המפתח, כדאי להיות קצת יותר מבושלים עם הבעיה.

מה השגנו עד עכשיו? בדיקת תקינות נתונים ברמת העסקה.

צוללים פנימה לעסקה ספציפית

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

1. בחרו את הדיימנשנס transaction id, item id, item name
2. בחרו את המטריקות item revenue, item quantity
3. הוסיפו פילטר של transaction id=12345 או כל מספר אחר של עסקה שאתם רוצים לתחקר.
4. הדוח יציג לכם את כל רשימת המוצרים בתוך עסקה מסויימת.

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

1. מוצרים מסויימים נשלחים עם מחיר אפס
2. לא משנה מה הלקוח קנה וכמה, תמיד הכמות של כל מוצר היא 1.
3. כל המחירים של המוצרים זהים.
4. לא משנה כמה מוצרים המשתמש קנה, בפועל תמיד מופיעים עד X מוצרים ולא יותר.
5. המשלוח מופיע כ"מוצר" עם עלות מה שמנפח לכם את מספר המוצרים בכל עסקה. אם היו 100 עסקאות היום, זה נראה בדוחות כאילו נמכרו מאה נמורצים יותר מהמציאות. זה "לא בסדר" או "כן בסדר". פשוט תצטרכו להחליט אם זה מתאים לכם או לא.

כך או כך, ממליץ גם לבדוק את ה SKU של המוצרים והשמות שלהם ולוודא שיש התאמה ל Backend.

מה השגנו עד עכשיו? בדיקת נתוני מוצרים בתוך עסקה ספציפית, ובדיקה ששם המוצר וה SKU תקינים.

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

שלב ב' – בדיקת שעון

זה החלק הכי נחמד שנסתר מעיני הרבה אנשים.

1. בחרו יום ספציפי ב Backend ויצאו את רשימת העסקאות לאקסל.
2. לכו לגוגל אנליטיקס, לאותו היום ולאותו הדוח שהוצאנו בשלב א' והסתכלו ברשימת העסקאות.
3. כל עסקה שמופיעה ב Back-end ולא מופיעה באנליטיקס, צבעו אותה באקסל.
4. חזרו לאנליטיקס, אבל הפעם שנו את טווח התאריכים ל 5 ימים כאשר היום הבעייתי ממוקם באמצע. כלומר, אם החלטנו לתחקר את ה 10 ליולי, הדוח באנליטיקס צריך להתייחס לתאריכים 8-12 ליולי.
5. חפשו שוב את העסקאות ה"חסרות".

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

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

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

שלב ג'- איתור עסקאות חסרות

עכשיו הגענו ל Money Time ולשאלה הכי חשובה – למה לעזאזל יש עסקאות שלא מופיעות בגוגל אנליטיקס?

האם הפיקסלים אשמים או האתר אשם?

הבדיקה הראשונה שהייתי עושה, זה לבדוק מה הכתובת של דף התודה. היא יכולה להיות נניח domain.com/transactionSuccess. הולך לדוח של Pages and screen ומסתכל כמה צפיות יש ב URL של דף התודה. נניח שיש 1000 View, זה אומר בגדול שיש כ 1000 עסקאות. אבל אם בדוחות האיקומרס יש לנו 700 עסקאות זה אומר שייתכן ומשהו מתפקשש בקוד ששולח את נתוני האיקומרס ואז אפשר להמשיך במאמר לשאר הפתרונות, ולדלג על הפסקה הבאה.

אבל(!), יצא כבר שגיליתי שדף התודה בעצמו מופיע מעט פעמים ביחס לכמות הטרנזקציות. כלומר, הדף נטען 500 פעמים בגלל בעיות ביצועים או השד יודע למה, ויש לי בבקאנד 600 עסקאות שנספרו. זה אומר ש 100 עסקאות פוספסו, לא כי הקוד לא תקין, אלא כי הדף לא נטען בכלל כמו שצריך! אז אם חסרים לי Pageviews ברור שגם כל מה שנגזר מזה יתפספס – כל המידע של העסקאות לא ישלח וכמובן כל הפיקסלים למיניהם של רשתות הפרסום. אז מה בודקים? קודם כל זמני טעינה של הדף, עומס של קוד, צמצום הקונטיינר של GTM וכו'. כך או כך, זו שיחה שאתם צריכים לנהל מול המפתח.
טיפ קטן: קחו בחשבון שייתכן שהבקאנד סופר עסקאות שבוצעו באופן אחר (נניח באמצעות הטלפון, או דרך דפים אחרים, שותפים וכו'), אז וודאו שאתם משווים עגבניות לעגבניות.

ממשיכים…

אז בהנחה וכמות ה Pageviews זהה לכמות העסקאות ב Backend, ועדיין חסרות עסקאות בדוחות האיקומרס, נחזור לאקסל.

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

1. כל העסקאות החסרות הן של PayPal או סולק ספציפי אחר, או כרטיס אשראי ספציפי.
2. לכל העסקאות יש הטבה שהופעלה,  כגון קוד קופון.
3. בכל העסקאות שנפלו יש משלוח בתשלום/בחינם.
4. כל העסקאות כוללות את אותו מוצר ספציפי (כמו מתנה שמתווספת בקופה), או סוג מוצר (נניח באנדלים, שזה אומר קבוצה של מוצרים שנמכרים כיחידה אחת כמו חבילת שי)
5. כל העסקאות שנפלו התרחשו באותן שעות (נניח בלילה, או בין 8-9 בבוקר או וואטאבר)
6. כל העסקאות שנפלו כוללות מעל X מוצרים (בעיה מאד מוכרת)
7. כל העסקאות שנפלו בעלות הכנסות מעל סכום X.

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

עסקאות הכוללת מעל X מוצרים

לגוגל אנליטיקס יש מגבלה של נפח המידע שנשלח  ב event אחד. הבעייה מחמירה באתרי סופרמרקט למיניהם ששם עסקה יכולה להכיל עשרות אם לא מאות מוצרים, ועל כל מוצר יש כל מיני Custom dimensions שהוספתם. איך יודעים? כל המידע שנשלח לגוגל אנליטיקס בקריאה אחת לא יכול לעבור משקל של 8kb שזה בערך 8200 תווים. זה אמור להספיק לכמה עשרות מוצרים ברמה בסיסית. במידה וזה המקרה וחרגתם מהמקסימום, אתם תראו בלשונית של ה Console ב DevTools בדפדפן, את ההודעה "Payload Size is too large" וגם יצויין המשקל הנוכחי של הקריאה ותדעו כמה צריך לצמצם. יש כמה דרכים לצמצם את הקריאה אבל זה רחוק מלהיות טריוויאלי או שאוכל לכסות את זה כאן. אחד הפתרונות אגב, זה לפצל את הטרנזציה לכמה טרנקזציות קטנות יותר או כל מיני תכמונים ותרגילים אחרים.

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

תרחישים נוספים ללא מידע

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

יש לכם שתי אופציות לחקור  את זה:

1. לעשות טסטים עם VPN, או ממכשירים שונים  או דפדפנים שונים שוב ושוב ושוב ולנסות לזהות מכנה משותף בין כל העסקאות שנפלו אם בכלל.
2. לשכלל את מערכת ה Backend שלכם כך שתאסוף עבור כל טרנזציה גם מידע טכני כמו דפדפן, כתובת IP, סוג Device, רזולוציית מסך וכו'. מסובך, מגעיל, לא פתרון אסתטי – אבל זה מה שיש.

ועוד קצת..

עוד כמה סיבות אפשריות לפספוס עסקאות באיקומרס:

1. לקוח סיפר שכמות המוצרים שאנליטיקס דיווח גדולה מכמות המוצרים שנמכרה בפועל. מה שגיליתי זה שהמשלוח נשלח כמוצר נפרד. כלומר, עסקה שכללה מוצר אחד, נשלחה כעסקה עם שני מוצרים (מוצר+משלוח) שזה כמובן שגוי. משלוח אינו מוצר.
2. המשתמש חוסם את גוגל אנליטיקס – או שהוא חוסם קוקיז. כל הטרנזקציות שלו נרשמות כמובן ב Back-end אבל לא בגוגל. ישנן כמה שיטות למדוד האם למשתמש יש או אין חוסם קוקיז/פרסומות וכיו"ב. אפשר גם להעביר את המדידה לServer side במקום client-side.
3. אספתם יותר מדי מידע על כל משתמש וזה חרג מכמות המידע שניתן לאסוף על משתמש בסשן אחד (500 היטים). זה קורה שאתם משתמשים בגוגל אנליטיקס לאיסוף של מידע זבל על המשתמש כמו תנועות עכבר, מעקב אחרי גלילה וכו'. יש כלים אחרים בשביל זה.
4. אתם שולחים את המידע על הטרנזקציה תוך כדי Redirect לדף התודה. וייתכנו מקרים שזה פשוט "נופל" בדרך. זה רחוק מלהיות מומלץ, ואני מעדיף כי את כל הפרטים תשלחו לגוגל בדף התודה עצמו ולא בדרך אליו.
5. בעיות ביצועים בדף התודה – יותר מדי סקריפטים רצים בדף התודה, וגוגל אנליטיקס איכשהו מתועדף נמוך, כך שהמשתמש מספיק לצאת מדף התודה לפני שהסקריפט רץ. זה אומר שאתם צריכים לנקות את הדף התודה מזבל, לנתח את הביצועים ובעזרת Google Tag Manager לסדר את הסקריפטים לפי עדיפות. 
6. האתר שלכם מבקש מהמשתמש לאשר או לא לאשר שמירת קוקיז. המשתמש מחליט להתעלם מההודעה או לדחות קוקיז – שום דבר לא יעבוד.

פתרון נפוץ לבעיות שצוינו לעיל, הוא לא לשלוח את העסקה מהדף תודה, אלא מהשרת באמצעות Measurement Protocol או בכלל מעבר ל Server -side tagging. אמנם תקבלו מידע מדוייק אבל יש לזה יותר חסרונות מיתרונות ולכן אני מתייחס לזה כאל פתרון בעדיפות הכי נמוכה.

עסקאות כפולות

בתגובות למטה מישהי ציינה בעייה של ספירה כפולה. יש פה כמה תרחישים:

1. בדוח העסקות, כל עסקה מופיעה פעמיים או יותר. זה אומר שבדוח של ה Transaction, תראו 100 שורות במקום נניח 50. אז בהנחה וכל עסקה מדוייקת כשלעצמה, הבעיה היא ככל הנראה טריגרים שלא מוגדרים נכון ב GTM. בנוסף, יש מקרים בהם היוזר יכול לחזור לדף התודה ואז כל הפיקסלים והמידע ייטען שוב. זו תקלה והיא לא אמורה לקרות. ברגע שיוזר עוזב או סוגר את דף התודה, אסור לאפשר טעינה שלו מחדש, ואם זה קורה זו תקלת פיתוח חמורה שצריך לטפל בה. לדפי תודה בעסקאות איקומרס, חייב להיות זמן "תוקף" שבדר"כ נקבע סביב כמה שניות.
2. רשימת העסקאות תקינה, אבל בתוך כל עסקה, כל מוצר מופיע פעמיים – זו תקלה בקוד שאתם שולחים לגוגל אנליטיקס או ב GTM. קל לתקן יחסית.
3. רשימת העסקאות תקינה, בתוך כל עסקה מספר מוצרים תקין, אבל הסכומים כפולים – במקום שפריט יעלה 10 שח, כתוב שהוא עולה 20 שח. גם כאן, תקלה בקוד שאפשר לתקן יחסית בקלות.

תוספים ומערכות איקומרס סגורות

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

אם Pixel Your Site מפספס הרבה עסקאות באתר ה WooCommerce שלכם, סביר להניח שזו לא בעיית קונפיגורציה אלא שהתוסף פשוט לא מתאים לאתר שלכם. זה קורה כי עשיתם שינויים רבים בטמפלטים ושינויים בקוד. ברמה האישית, אני חושב ש Pixel Your Site הוא מוצר בינוני לגמרי שלא יכול להתמודד עם כל השינויים ב WP וב WOO ולא מתוחזק ברמה הראויה. אני ממליץ לא להשתמש בו ולפנות לאיש פיתוח שיעשה לכם את זה.

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

ו..אני חושב שזהו. עכשיו שימו את המאמר הזה ב Bookmarks ושלפו אותו כשיגיע הצורך.

למי זה מתאים

לעיתים האתר שלכם כולל כתובות נורא יפות כמו domain.com/page ולפעמים מערכת ניהול התוכן משרשרת לכתובת הדף ערימות של פרמטרים שמייצרים משהו שיכול להיראות ככה:

domain.com/page/?apd=123&DS=2544&PartnerID=664

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

אז איפה הבעיה

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

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

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

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

הדרך הקלה והבעייתית להתמודד עם זה

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

אחלה. אבל…

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

הפתרון – לשפוך את את התינוק עם המים ולשלוף אותו בחזרה.

 מכיוון שאנחנו לא יודעים אילו פרמטרים הולכים להגיע אלינו למערכת, החלטתי שבאמצעות Google Tag Manager אני אמחק את כל הפרמטרים באופן גורף. כן, כן. את כולם. גם את הטובים וגם את הרעים, ואשאיר URL נקי וטהור מפרמטרים, אבל, שנייה לפני שאשלח אותו לגוגל אנליטיקס, אוסיף לו בחזרה את הפרמטרים שהלקוח רצה שיישארו.

איך עושים את זה עם Google Tag Manager

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

עבור כל פרמטר כזה, אנחנו מייצרים Variable שכל התפקיד שלו, זה לשאוב את הערך מה URL. כלומר, גולש נכנס לאתר, לדף הבית, ו GTM לפני שהוא שולח את הדף לגוגל אנליטיקס, שולף את הערכים מהפרמטרים החשובים ו"שומר אותם" בצד. אז אם יש לנו עשרה פרמטרים חשובים, אנחנו צריכים לייצר עשרה Variables. הנה דוגמא לאחד ששולף את הערך של הפרמטר CampaignD למשל:

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

כדי לעשות את זה, נייצר Variable חדש מסוג JavaScript, נקרא לו נניח Clean Path ונזין בו את הקוד הבא:

function() {
var final = {{url path}}; 
 final +='?';
   if(
     ({{language}})
   )
   {
   final +='&lang={{language}}';
   }
if(
     ({{mediaID}})
   )
   {
   final +='&mediaID={{mediaID}}';
   }
if(
     ({{campaignId}})
   )
   {
   final +='&campaignId={{campaignId}}';
   }
return final;
}

הסבר לקוד:

1. אני מייצר משתנה בשם Final והוא בהתחלה מכיל את ה URL Path המכיל את כתובת האתר ללא שום פרמטר. זה משתנה פנימי של GTM ואין צורך להגדיר אותו.
2. אחר כך אני מצמיד לכתובת את סימן השאלה ? (לא חובה..)
3. בשלב הבא, אני שואל את המערכת האם קיים ערך במשתנים שיצרתי מקודם. נניח CampiagnID. אם יש, הוא מצמיד אותו לכתובת האתר. אם לא, הוא ממשיך לפרמטר הבא. וכך, הפונקציה הזו מדביקה פרמטר אחר פרמטר. רק את הפרמטרים שאנו רוצים ורק את אלו עם ערכים. כמו שאמרתי – שואפים למינימום.
4. השורה האחרונה פולטת החוצה את הכתובת הסופית.

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

תחת More Settings, הקליקו על Fields to Set ואז בעמודת Field Name הזינו Page. בעמודה השנייה הזינו את השם של ה Variable שיצרנו זה עתה – Clean Path.

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

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