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

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

מה זה אומר ולמה זה חשוב.

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

הנה דוגמא-  Sony Ericsson מעלים קמפיין אדוורדס לטאץ' סקרין החדש שלהם.
מנהל הקמפיין בחר כמה מילות מפתח שאיתם הוא מתחרה (בביד) על ההופעה של המודעה שלו.

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

נחזור אלי, המשתמש.

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

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

יש פתרון.

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

להלן הפתרון:

1. צור פרופיל חדש בכדי לא לפגוע בסדירות הפרופיל הראשי.

2. צור פילטר ראשון שנראה כך:

3. שייך את הפילטר לפרופיל שזה עתה יצרת (יש משמעות לסדר הפילטרים. זה צריך להיות הראשון)

4. צור את הפילטר השני שנראה כך:

5. שמור.

את האינפורמציה תוכלו לראות בכל דו"ח שמסגמנט לפי Keywords

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

גוגל אנאליטיקס היא שירות אינטרנטי במודל שנקרא SAAS

(Software As a Service)

תחשבו רגע על Google Docs והנה לכם אותו עקרון – מהדפדפן שלכם אתם ניגשים לאפליקציה שמורצת
מהשרתים של גוגל ומאפשרת לכם להשתמש בה (בחינם) וזאת בניגוד להתקנה "פיזית" של אפליקציית  Word שמורצת מהמחשב שלכם. (ובעקון אמורה לעלות כסף : )

בגוגל אנאליטיקס המודל של גישה מרחוק ללא התקנה "פיזית" מתאפשר בזכות שיטת ניטור חדשה יחסית
(חדשה מבחינת הדומיננטיות שלה) שהיא שיטה אחת מתוך שתיים עיקריות – Log files V.S Page tagging

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

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

2. Log Files - זו השיטה הוותיקה יותר, בשיטה זו האינפורמציה מגיעה אך ורק לשרת שמתפעל את האתר שלכם. בכל פעם שאתם גולשים לאתר, הדפדפן שלכם מייצר בקשה לדף מהשרת שעליו יושב האתר (יש יוצאי דופן – עניין לפוסט אחר) ברגע שהשרת מקבל בקשה לדף הוא רושם אותה והרישום הזה נקרא Log. אם על השרת שלכם מותקנת תוכנת ניתוח לוגים היא תעבד את האינפורמציה ותאפשר בנייה והצגה של דוחו"ת (דוגמא לאפליקציית ווב אנאליטיקס עם גרסאת חינם נפוצה לשיטה הזו- Web Trends)

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

——————-

Log Files

1.  דפדפן מבצע בקשה לעמוד מהשרת שמארח את האתר שלכם

1.1 השרת בודק אם יש קוקיז בדפדפן (בכדי לייצר גרסא אישית של העמוד) ואז שולח את הקוד
שמרכיב את הדף חזרה לדפדפן

2. במקביל ליצירת הדף, השרת רושם Log עם פרטים המיוחסים לדפדפן (סוג דפדפן, מערכת הפעלה,
זמן הבקשה, מספר IP וכו') ופרטים המיוחסים לעמוד שאותו הדפדפן ביקש  (URL של העמוד, Referrer  וכו')

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

4. את המאמץ מסעיף 3 אתם רואים בדוחו"ת דרך אינטרפייס גרפי.

—————-

Page Tagging (השיטה של  גוגל אנאליטיקס)

1. דפדפן מבצע בקשה לעמוד מהשרת שמארח את האתר שלכם

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

3. הדפדפן בונה את הדף כשהוא מבקש חלק מהאובייקטים הנדרשים לבניית הדף משרתים אחרים,
אובייקט אחד הוא קובץ של גוגל אנאליטיקס – urchin.js
(אובייקט אחר יכול להיות נגן של Youtube או תמונה שנמצאת על הפליקר שלכם ואשר הוטמעו בעמוד)

3.1 השרת של גוגל שולח לדפדפן את הקובץ שנקרא urchin.js

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

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

6.  נרשם Log בשרת של גוגל אנאליטיקס המבוסס על האינפורמציה שהגיעה עם הקוקיז הייעודיים של אנאליטיקס

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

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

———————————————————————————–

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

]]> http://1bit.co.il/archives/9/feed 1