למה החודש הראשון לא מתחיל בדשבורד?
הבקשה הראשונה שאנליסט חיצוני מקבל היא כמעט תמיד דשבורד. הבעיה היא שדשבורד שנבנה לפני האודיט מציג מספרים שאף אחד עוד לא בדק. דשבורד שנבנה לפני השיחות עם מקבלי ההחלטות עונה על שאלות שאף אחד לא שאל. בפרויקטים שלנו, הדשבורד של השבוע הראשון הוא בדרך כלל הדשבורד שנבנה מחדש בשבוע השלישי. לכן הסדר קבוע: להבין, לאמת, לבנות, להחליט.
לאנליסט חיצוני יש יתרון על עובד חדש: אין לו היסטוריה בארגון ויש תאריך ברור שבו תקופת הלמידה נגמרת. יש לו גם חיסרון: אין לו גישות, הקשר או אמון. לכן כל שבוע מסתיים בתוצר שמישהו בארגון מקבל לידיים, לא בסטטוס. "החלטה" במדריך הזה היא בחירה בין חלופות שמזיזה כסף, אנשים או סדר עדיפויות: תקציב שעובר מערוץ לערוץ, עמוד נחיתה שמשתנה, קמפיין שנעצר. דוח הוא קלט. החלטה היא תוצאה. את החודש הראשון מודדים על תוצאות.
איך נראית תוכנית ארבעת השבועות?
התוכנית מחולקת לארבעה שבועות עם אבן דרך אחת בסוף כל שבוע. הדיאגרמה מראה את ציר הזמן, שזורם מימין לשמאל כמו הטקסט:
ציר זמן
30 הימים הראשונים: מהיכרות עם ההחלטות ועד החלטה ראשונה שנמדדה
למעלה במה האנליסט עסוק, בכתום אבן הדרך שהארגון מקבל לידיים בסוף כל שבוע.
הטבלה מפרטת את ארבעת השבועות. כשהחודש הראשון מתארך לחודשיים, הסיבה נמצאת בדרך כלל בעמודה "מה הארגון מספק":
| שבוע | מה האנליסט עושה | מה הארגון מספק | התוצר |
|---|---|---|---|
| שבוע 1 להבין ולבדוק |
שיחות של 30 דקות עם שלושה עד חמישה מקבלי החלטות, עם שאלה אחת: מה החלטת בחודש האחרון ועל סמך איזה מספר. מיפוי המערכות והדשבורדים הקיימים. אודיט של כל מספר שהוזכר בשיחות. דירוג הממצאים. | גישות ביום הראשון: GA4 ברמת Analyst לפחות, Tag Manager ברמת Edit, קריאה בפלטפורמות המדיה, עריכה בדשבורדים הקיימים, ייצוא מה-CRM. חצי שעה של כל מקבל החלטה. איש קשר טכני אחד. | טבלת ממצאי אודיט מדורגת לפי השפעה על החלטות, עם הבחנה בין ממצא שמשנה החלטה לממצא קוסמטי ותאריך תיקון לכל שורה. |
| שבוע 2 לתקן מה שחוסם |
תיקון הממצאים שמשנים החלטה, בסדר הדירוג. מה שאפשר, האנליסט מתקן בעצמו ב-GTM וב-GA4. מה שדורש קוד, הוא כותב כמסמך הטמעה קצר למפתח. סימון אירועי מפתח. בדיקת קבלה לכל תיקון ואימות מול מקור אמת. | הרשאת Editor ב-GA4 ואישור לפרסום ב-Tag Manager. מפתח זמין בזמן תגובה של ימים, לא שבועות. גישה למקור האמת. בעלים לכל KPI. | מדידה אמינה לשלושה עד חמישה KPI, מתועדת: מה נספר, מה לא נספר, מה הפער המקובל מול מקור האמת. |
| שבוע 3 לבנות תמונה אחת |
הגדרה כתובה של שורה אחת לכל KPI, שהשיווק והמכירות מסכימים עליה. דשבורד של עמוד אחד ב-Looker Studio עם ההגדרות לידו. פגישת קריאה עם ההנהלה. | 45 דקות של ההנהלה. אדם אחד שמכריע במחלוקת על הגדרה. נתונים שאין ב-GA4: תקציבים, יעדים, מחירי מכירה. | דשבורד של עמוד אחד שההנהלה קראה והבינה בלי שהאנליסט הסביר אותו. |
| שבוע 4 להחליט ולמדוד |
ניתוח של שאלה אחת משבוע 1 שהנתונים המתוקנים יכולים לענות עליה. המלצה אחת עם מספר ועם החלופה. הגדרת ההחלטה כניסוי מדיד. תוכנית 90 יום. | מקבל החלטה שמוכן להחליט בתוך שבוע. משאב קטן ליישום. מועד קבוע לפגישת נתונים חודשית ביומן של ההנהלה. | החלטה אחת שהתקבלה על בסיס הנתונים, עם מדד, ערך פתיחה, תאריך בדיקה ובעלים. תוכנית 90 יום. |
על הגישות כדאי להרחיב, כי שם נשרף הזמן. לפי התיעוד של Google, תפקיד Viewer ב-GA4 רואה הגדרות ונתונים, Analyst יכול בנוסף לשתף Explorations, Marketer יכול ליצור ולערוך קהלים, אירועים ואירועי מפתח, Editor שולט בכל ההגדרות ברמת הנכס ו-Administrator מנהל גם משתמשים. לאודיט מספיק Analyst. לסימון אירוע קיים כאירוע מפתח צריך Editor ומעלה. יש גם שתי הגבלות נתונים, No Cost Metrics ו-No Revenue Metrics. אנליסט שהן חלות עליו לא יכול לחשב עלות לליד או החזר על הוצאת מדיה. את ההחלטה הזו מקבלים ביום הראשון, לא מגלים בשבוע השלישי.
שבוע 1: איך מדרגים ממצאי אודיט לפי השפעה על החלטות?
האודיט עובר על הגדרות הנכס ב-GA4, על התגיות והטריגרים ב-GTM, על אירועי המפתח וההמרות בפלטפורמות המדיה, על ה-UTM, על סינון טראפיק פנימי ועל הדשבורדים הקיימים. אבל הכיסוי הוא לא העיקר. אודיט שמסתיים בארבעים ממצאים בלי דירוג גורם לכל ממצא להיראות דחוף באותה מידה. התוצאה: לא מתקנים כלום.
הדירוג שאנחנו עובדים איתו מבוסס על שאלה אחת לכל ממצא: אם נתקן את זה מחר, מי בארגון יחליט אחרת ועל מה? אם יש תשובה, הממצא משנה החלטה. אם אין, הממצא קוסמטי. ממצא קוסמטי יכול להיות מכוער מבחינה טכנית, למשל 14 אירועי קליק עם שמות לא אחידים שאף אחד לא מחליט שום דבר על פיהם. ממצא שנראה קטן, כמו אירוע שנורה על לחיצה במקום על הצלחה, יכול להפוך את ההחלטה על חלוקת התקציב. הדירוג הוא לפי גודל ההחלטה, לא לפי גודל התיקון.
דוגמת תוצר: טבלת ממצאי האודיט של שבוע 1 (נתוני דמו)
כך נראה התוצר של שבוע 1 באתר לידים עם קמפיינים ממומנים. כל הממצאים והמספרים הם נתוני דמו של סוגי ממצאים שחוזרים בפרויקטים, לא ארגון מסוים:
| דירוג | הממצא (מה ראינו ואיפה) | על איזו החלטה זה משפיע | סוג | מה עושים ומתי |
|---|---|---|---|---|
| 1 | generate_lead נורה על לחיצת כפתור "שליחה" ולא על תגובת הצלחה מהשרת. ב-Preview של GTM, טופס עם שדה חובה ריק ירה את האירוע. בדמו: 38% מה"לידים" ב-GA4 לא קיימים במערכת הטפסים. | חלוקת התקציב בין ערוצים לפי עלות לליד. הערוץ שמייצר הכי הרבה "לידים" הוא הערוץ שמייצר הכי הרבה שגיאות טופס. גם הבידינג של Google Ads מקבל את האירוע הזה. | משנה החלטה | שבוע 2, יום ראשון. העברת ה-push לתגובת ההצלחה, בדיקת קבלה של "שגיאה אינה ליד", אימות מול מערכת הטפסים. |
| 2 | המרת "ליד" ב-Google Ads נספרת פעמיים: מתג המרה ישן על עמוד התודה ומייבוא אירוע המפתח מ-GA4. שתי ההמרות מסומנות Primary. | ה-CPA המדווח נמוך בחצי מהאמיתי. על בסיסו הוחלט להעלות תקציב בשני קמפיינים. האלגוריתם מבצע אופטימיזציה על מספר כפול. | משנה החלטה | שבוע 2. מקור אחד נשאר Primary, השני עובר ל-Secondary. תיעוד תאריך השינוי כדי להסביר את "הירידה" במספרים. |
| 3 | בדשבורד הקיים המדד "המרות" סוכם את כל אירועי המפתח, כולל scroll ו-file_download. בדמו: ההנהלה רואה שיעור המרה של 11%, שיעור הלידים בפועל הוא 1.4%. | יעד שיעור ההמרה בתוכנית השנתית נקבע על בסיס המספר השגוי. גם ההחלטה אם הבעיה באתר או במדיה מתבססת עליו. | משנה החלטה | שבוע 2: הסרת scroll ו-file_download מאירועי המפתח. שבוע 3: הדשבורד החדש מציג "לידים" ולא "המרות". |
| 4 | הגדרת Internal traffic ב-GA4 לא פעילה. כתובות ה-IP של המשרד ושל סוכנות המדיה נספרות. בדמו: 9% מהסשנים, בעיקר בעמודי נחיתה שבבדיקה. | שיעור ההמרה של עמודי נחיתה חדשים נראה נמוך ממה שהוא, כי הסוכנות פותחת אותם עשרות פעמים ביום. על בסיס זה נפסלו שני עמודים. | משנה החלטה | שבוע 2. הגדרת Internal traffic וסינון, בלי לגעת בנתונים ההיסטוריים. השוואה חוזרת של העמודים שנפסלו. |
| 5 | utm_source בקמפיינים של Meta מופיע בשלוש גרסאות כתיב: facebook, Facebook, fb. כולן מתקבצות ל-Paid Social בקיבוץ הערוצים של GA4. | אף החלטה. חלוקת התקציב נעשית ברמת הערוץ, שם המספר נכון. רק טבלת source / medium מתפצלת לשלוש שורות. | קוסמטי | שבוע 3, במסגרת תקנון UTM כתוב. בלי לשנות קמפיינים פעילים באמצע. |
| 6 | 14 אירועי קליק עם שמות לא אחידים (click_button_1, btn_click, cta) ושלושה נכסי GA4 ישנים וריקים, שניים מהם עם שם דומה לנכס הפעיל. | אף החלטה. אף אחד מהאירועים לא מופיע בדוח שמישהו קורא. הנכסים הריקים מבלבלים משתמש חדש, לא משנים מספר. | קוסמטי | תוכנית 90 יום. איחוד שמות בהדרגה, שינוי שם לנכסים הישנים. |
שלוש הערות על הטבלה. ראשית, הממצאים 5 ו-6 נראים לא פחות "לא מסודרים" מהממצאים 1 ו-2 ובכל זאת הם בתחתית. ההבדל הוא בעמודה השלישית: בשורות 1 עד 4 יש החלטה שמישהו קיבל או עומד לקבל על בסיס מספר שגוי, בשורות 5 ו-6 אין. שנית, גם ממצא קוסמטי נרשם ומקבל תאריך. הוא רק לא נדחף לפני דברים שמשנים כסף. שלישית, הטבלה היא עמוד אחד שנשלח לפני פגישת הסיכום של שבוע 1, לא מסמך של ארבעים עמודים שנשלח אחריה. העמודה "על איזו החלטה זה משפיע" היא הסיבה שמנהל שיווק קורא טבלה טכנית עד הסוף.
שבוע 2: מה מתקנים קודם ואיך יודעים שתוקן?
בשבוע השני מתקנים לפי סדר הטבלה ורק את מה שסומן כמשנה החלטה. לכל תיקון יש בדיקת קבלה שנכתבת לפני התיקון: מה צריך לקרות ב-Preview של GTM וב-DebugView של GA4 כדי שנגיד שזה עובד. אחרי התיקון משווים את המספר למקור אמת חיצוני לאורך כמה ימים: מערכת הטפסים, ה-CRM, פלטפורמת המדיה. פער קטן וקבוע הוא תקין ומתעדים אותו כפער מקובל. פער משתנה הוא בעיה שעוד לא נפתרה.
שני פרטים מהתיעוד של Google משפיעים על התזמון. סימון אירוע כאירוע מפתח לא רטרואקטיבי: הוא משפיע על הדוחות מרגע הסימון ולא משנה נתונים היסטוריים. בדוחות הסטנדרטיים הוא מופיע בתוך עד 24 שעות. לכן מסמנים ביום התיקון ולא בסוף השבוע. בנוסף, נכס GA4 רגיל מוגבל ל-30 אירועי מפתח, כך שהסרת scroll ו-file_download בדמו היא גם שחרור מקום לאירועים שבאמת צריכים אותו. כשהתיקון דורש קוד והמפתח לא זמין, הדשבורד של שבוע 3 מציג את ה-KPI הזה עם סימון שהמספר עדיין לא אמין.
שבוע 3: איך בונים תמונת מצב אחת שההנהלה קוראת?
לפני שפותחים את Looker Studio כותבים הגדרה של שורה אחת לכל KPI: מה נספר, מה לא נספר, מה המכנה ומה חלון הזמן. ההגדרה נכתבת במילים של מנהל המכירות ומנהל השיווק, לא של אנליסט. ברוב הארגונים השלב הזה חושף שהשיווק והמכירות סופרים "ליד" אחרת. זו מחלוקת ארגונית, לא בעיית מדידה. תפקיד הארגון הוא לקבוע מי מכריע בה.
הדשבורד עצמו הוא עמוד אחד: שלושה עד חמישה KPI, השוואה לתקופה קודמת וליעד, שורת התאמה למקור האמת וההגדרות לידו. לפי התיעוד של Google, Looker Studio עובד עם מטמון שנקרא data freshness: הדוח שומר תוצאות של שאילתות ומגיש אותן מחדש בתוך חלון הרעננות, שלמקור נתונים של Google Analytics עומד כברירת מחדל על 12 שעות. עורכי הדוח יכולים לרענן ידנית, צופים רק אם העורך הפעיל את האפשרות Viewer data refresh. יחד עם העובדה שאירועי מפתח מגיעים לדוחות הסטנדרטיים של GA4 בתוך עד 24 שעות, המסקנה פשוטה: הדשבורד מציג נתונים עד אתמול. כותבים את זה בראש העמוד.
פגישת הקריאה היא 45 דקות שבהן האנליסט לא מציג. ההנהלה קוראת את העמוד ושואלת. כל שאלה שהעמוד לא עונה עליה בעצמו היא הערה לתיקון הדשבורד או סעיף בתוכנית 90 הימים. התוצר של השבוע הוא לא "דשבורד נבנה" אלא "דשבורד נקרא והובן".
שבוע 4: איך מלווים החלטה ראשונה ומודדים אותה?
בשבוע הרביעי בוחרים שאלה אחת מהשיחות של שבוע 1, שהנתונים המתוקנים יכולים עכשיו לענות עליה. בדמו שלנו: אחרי תיקון generate_lead והספירה הכפולה ב-Google Ads, עלות הליד המתאים בערוץ א' היא 410 שקלים ובערוץ ב' 190 שקלים, במקום 150 ו-180 שהוצגו קודם. ההמלצה היא אחת, עם מספר ועם החלופה: להעביר חלק מהתקציב לערוץ ב', או להשאיר את החלוקה ולבדוק קודם את עמוד הנחיתה של ערוץ א'.
החלק החשוב הוא מה שקורה אחרי שההחלטה מתקבלת. מגדירים אותה כניסוי מדיד: מה משתנה, מה המדד (עלות לליד מתאים, לא עלות לליד), מה ערך הפתיחה, מתי בודקים ומי הבעלים. אנחנו נזהרים משני דברים. האחד, הכרזה על הצלחה לפני שיש מספיק לידים כדי שההבדל לא יהיה רעש. השני, התייחסות לייחוס של GA4 כאמת מוחלטת: הייחוס הוא מודל, מקור האמת הוא ה-CRM. בסוף השבוע מסדרים גם את תוכנית 90 הימים: הממצאים הקוסמטיים, השאלות שלא נענו בפגישת הקריאה, הדשבורדים הנוספים שבאמת צריך.
איך יודעים אחרי 30 יום אם זה עובד?
לא לפי מספר הדוחות שנוצרו או האירועים שהוטמעו. אלה תפוקות. בודקים תוצאות: החלטות שהתקבלו ונמדדו. בסוף יום 30 אנחנו עוברים עם מקבל ההחלטות הראשי על חמש בדיקות:
- יש לפחות החלטה אחת שהתקבלה אחרת בגלל הנתונים. אם אין תשובה לשאלה "מה היינו מחליטים בלי זה", הנתונים לא השתתפו בהחלטה.
- לכל החלטה כזו יש מדד, ערך פתיחה, תאריך בדיקה ובעלים. החלטה בלי תאריך בדיקה היא כוונה, לא ניסוי.
- מקבלי ההחלטות יודעים את המספר של החודש בלי לפתוח את הדשבורד. שואלים אותם. מי שיודע, משתמש.
- המספרים בדשבורד מתיישבים עם מקור האמת בפער קבוע ומתועד: לידים ב-GA4 מול ה-CRM, הוצאה מול החשבונית.
- פגישת הנתונים הבאה קבועה ביומן של ההנהלה עם תאריך ושעה. אם היא "תיקבע כשיהיה משהו להראות", היא לא תיקבע.
יש גם סימנים הפוכים. אם האנליסט הוא היחיד שפותח את GA4 ואם השאלות עדיין מגיעות בצורת "תוציא לי מספר", החודש הראשון הפיק תפוקות ולא תוצאות. במקרה כזה חוזרים לשיחות של שבוע 1.
מהן הטעויות הנפוצות בחודש הראשון?
הטעות הראשונה היא להתחיל מהדשבורד, כולל הגרסה העדינה שלה: תיקון "מהיר" של הדשבורד הקיים בלי אודיט. מתקנים את הצורה של מספר שאף אחד עוד לא בדק. הטעות השנייה היא אודיט בלי דירוג. רשימה של ארבעים ממצאים בחומרה אחידה נקראת פעם אחת ונשכחת. הטעות השלישית קשורה אליה: לתקן קודם את מה שקל. איחוד שמות של אירועים הוא עבודה נעימה שנראית טוב ולא משנה אף החלטה. ממצא 1 בטבלה שלנו קשה יותר לתיקון מממצא 6 ושווה פי כמה.
הטעות הרביעית היא לא לסגור את הגישות ביום הראשון. אנליסט בלי Editor ב-GA4 ובלי פרסום ב-GTM מבלה את שבוע 2 בכתיבת הוראות למישהו אחר. בחודש של 30 יום, שבוע של המתנה הוא רבע מהזמן. הטעות החמישית היא לדבר רק עם השיווק. השיווק הוא בדרך כלל מי שהזמין את האנליסט, אבל ההחלטות מתקבלות גם במכירות, במוצר ובהנהלה.
הטעות השישית היא למדוד את החודש לפי תפוקות. "הטמענו 22 אירועים ובנינו 3 דשבורדים" הוא סיכום של עבודה, לא של ערך. הסיכום הנכון הוא "התקבלה החלטה אחת על חלוקת תקציב ונקבע מתי ולפי איזה מדד היא תיבדק".
איך ממשיכים מכאן?
החודש הראשון של אנליסט חיצוני הוא לא תקופת היכרות אלא פרויקט קצר עם ארבע אבני דרך ותוצאה אחת: החלטה שהתקבלה ונמדדה. אם יש לכם נתונים ואין לכם החלטות שמתבססות עליהם, כך אנחנו עובדים בפרויקטי הליווי האנליטי שלנו. את האודיט של שבוע 1 אנחנו מבצעים גם כפרויקט נפרד במסגרת המדידה המתקדמת ואת הדשבורד של שבוע 3 בונים בדשבורדים הניהוליים. אפשר לפנות אלינו דרך טופס הקשר.
עוד מדריכים בנושא ליווי אנליטי
מקורות
Analytics Help - Mark events as key events, Analytics Help - Access and data-restriction management, Looker Studio Help - Manage data freshness
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי