נתוני דיירקט לא הגיוניים בגוגל אנליטיקס

עם המייל הזה פתחתי את הבוקר שלי לפני כמה ימים:

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

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

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

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

אבל קודם כל אני חייב להבהיר משהו חשוב:

תנועת דיירקט בגוגל אנליטיקס **אינה** נובעת (רק) מגולשים שהקלידו את כתובת האתר בדפדפן

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

כדי שתבינו למה זה קשור לדיירקט אני רוצה להסביר בקצרה מה זה HTTP Referrer ואיך המערכת של גוגל אנליטיקס “יודעת” מאיזה מקור תנועה הגולש הגיע.

HTTP Referrer על קצה המזלג

בכל פעם שגולש עובר מכתובת URL אחת לשניה, הכתובת הראשונה שולחת לעמוד היעד אינפורמציה אודות הגולש, והמידע הזה כולל בין היתר גם את ה-URL שממנו הגולש מגיע (HTTP Referrer).

הבעיה מתחילה כאשר ה-URL ממנו הגולש מגיע יושב על פרוטוקול מסוג HTTPS, כלומר פרוטוקול מאובטח, והוא מפנה לעמוד שיושב על HTTP רגיל, כלומר פרוטוקול לא מאובטח.

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

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

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

אותו דבר קורה במעבר בין אפליקציית מובייל (בהנחה שהיא native) לאתר וובי רגיל – האפליקציה היא לא דפדפן ולכן אין לה אפשרות לשלוח HTTP Referrer גם אם היא רוצה, וכאשר הגולש מגיע מהאפליקציה לעמוד HTML כלשהוא – הוא מגיע ללא מידע על ה-referrer ששלח אותו.

איך גוגל אנליטיקס יודעת לזהות את מקור התנועה?

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

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

(כדי לפשט את התהליך אני אתאר רק את השלבים העיקריים של הבדיקה אבל כדאי לעיין בתרשים הבא כדי לראות את התהליך במלואו).

1. האם הגולש הגיע לאתר עם פרמטר =gclid? ב-URL?

אם כן – זה גולש שהגיע מאדוורדס ולכן מקור התנועה יהיה google / cpc. אם לא – המערכת ממשיכה בבדיקה.

2. האם הגולש הגיע עם פרמטר UTM כלשהוא?

אם כן – מייחסת לו את נתוני ה-UTM. אם לא – ממשיכה לבדוק.

3. האם אני יודעת לזהות את ה-HTTP referrer בתור מנוע חיפוש אורגני שאני מכירה?

אם כן – זה גולש שהגיע מאורגני ולכן מקור התנועה יהיה google / organic (או בינג, יאהו או כל אחד ממקורות התנועה המוכרים ע”י גוגל ומופיעים בלינק הזה). אם לא – ממשיכה לבדוק.

4. האם הגולש הגיע עם HTTP Referrer כלשהוא?

אם כן – מקור התנועה יהיה site.com / referrer (בהתאם לאתר ממנו הגולש הגיע).

ואם לא…

אתם יכולים לשים לב שאת רוב הבדיקות האנליטיקס עושה על ה-URL (פרמטרים איתם הגולש נוחת באתר), או HTTP Referrer עליו דברנו קודם, ולכן במידה והגולש לא הגיע עם פרמטרים וגם לא הגיע עם מידע כלשהוא ב-HTTP Referrer – גוגל אנליטיקס תכריז על הגולש הזה כ-direct / (none).

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

עכשיו בואו נחבר את שני הדברים האלו ביחד

המונח direct traffic נולד איפשהוא לפני 15 שנה, כאשר הסיטואציה היחידה שבה גולשים היו יכולים להגיע לאתר ללא referrer היתה במידה והם הקלידו את כתובת האתר ישירות בדפדפן או נכנסו אליו מ-bookmark.

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

אז מאיפה הדיירקט באמת מגיע?

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

כדי לעזור לכם בתהליך הכנתי רשימה של שאלות שיכולות לכוון אתכם:

1. האם אתם מריצים קמפיין בפייסבוק/לינקדאין/טוויטר או כל רשת חברתית אחרת?

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

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

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

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

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

כדי להיות בטוחים שהמידע על מקור התנועה עובר כמו שצריך מבלי שנהיה תלויים ב-linkshim כזה או אחר, אנחנו צריכים לתייג את ה-URLים שלנו עם פרמטרים שנקראים UTM, והם בעצם “יספרו” לגוגל אנליטיקס מאיפה הגולש הגיע.

אפשר לכתוב פוסט שלם על UTM אבל בגדול אתם פשוט צריכים לשרשר ערכים מסויימים (בהתאם למקום ממנו שלחתם את הטראפיק) לאחד או יותר מהפרמטרים הבאים:

utm_source

utm_medium

utm_campaign

utm_content

utm_term

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

לדוגמא,אם אתם מריצים את אותו קמפיין/קריאייטיב בלינקדאין ופייסבוק, אז utm_source יכיל את השם של הפלטפורמה (linkedin/facebook), ב-utm_medium אתם יכולים לשלוח את סוג המודעה, כמו News Feed, Right Ad או כל סוג אחר, ב-utm_campaign תשרשרו את השם של הקמפיין וב-utm_content את השם או הקוד של הקריאייטיב.

כאשר הגולש מגיע לאתר עם הפרמטרים הללו, הקוד של גוגל אנליטיקס קורא אותם מתוך ה-URL ומסווג את הטראפיק לפי הערכים ששרשרתם לפרמטרים:

2. האם אתם מוציאים ניוזלטר ללקוחות?

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

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

אפליקציית המייל ואאוטלוק בכלל לא ישלחו HTTP Referrer כי הם לא דפדפנים ואמרנו שרק דפדפנים שולחים את זה, וגם האתר של ג’ימייל/יאהו וכו’ לא ישלח HTTP Referrer בגלל שהוא יושב על פרוטוקול מאובטח HTTPS.

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

גם פה יש כמה דעות מה לשלוח בכל פרמטר UTM, ומה שאני עושה זה שולח utm_source=email, ב-utm_medium אני שולח את השם של הרשימה (יש לי כמה רשימות תפוצה), ב-utm_campaign את שם הקמפיין, וב-utm_content את המזהה של הלינק (במידה ויש לי באותו מייל כמה לינקים לאותו עמוד).

3. האם יש לכם חתימה אוטומטית במייל עם לינק לאתר?

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

4. האם יש לכם אפליקציה?

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

את הגרסא הוובית אתם יכולים לפתוח ב-native browser של המכשיר (כרום, ספארי וכו’) או ב-in-app version כמו שפייסבוק והרבה אפליקציות אחרות עושות.

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

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

5. האם אתר שלכם מאוזכר באתר חדשות כלשהוא?

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

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

דפדפן ה-in app לא שולח HTTP Referrer כמו דפדפן רגיל, ולכן אתם לא תדעו שהגולש הגיע מאתר החדשות אלא מדיירקט.

בנוסף, גם גולשים שיקראו את הכתבה באפליקצייה של אתר החדשות ייספרו בתור דיירקט, בגלל שאפליקציות לא שולחות HTTP Referrer.

מה לעשות? אין יותר מדי אפשרויות, כי רוב אתרי החדשות שאני מכיר לא יסכימו לשים לכם UTM על הלינקים…

6. האם יש ברשת איבוקים שמכילים לינקים לאתר שלכם?

ebooks הם בסה”כ קובץ PDF גם אם אתם פותחים אותם בתוך הדפדפן. הם לא יודעים לשלוח HTTP Referrer ולכן אם אתם מפרסמים איבוקים ושמים לינקים לאתר שלכם – תדאגו לתייג אותם עם UTM כמו ש-Hubspot עושים:

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

https://offers.hubspot.com/demo?
utm_campaign=Ecommerce-Demo&
utm_source=Conversion-Mistakes-Ebook-CTA

7. האם אתם עובדים עם תוכנה כלשהיא שפועלת על הדסקטופ?

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

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

מה שכן, כדאי מאוד להקפיד על שימוש בשירות קיצור כתובות כמו bit.ly או goo.gl, כי בד”כ אנשים נרתעים מפרמטרים ארוכים ב-URL וכשאתם משתפים משהו כדאי שהוא יראה אותנטי ולא ממוסחר יותר מדי.

סיכום + רעיונות שיכולים לתת לכם כיוון לחקירת מקור הדיירקט

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

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

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

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

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

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

הרבה פעמים אתם תגלו ISP שנראה תקין ואפילו מביא רכישות ביחס המרה גבוה במיוחד, אבל אם תוסיפו Secondary Dimension של Screen Resolution אתם תראו (not set), כלומר יש פה איזה בוט שאחראי לביקורים הללו וזה בדיוק הזמן לבדוק מול מחלקת ה-IT מה קרה באותו תאריך.

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