רוב האנשים פותחים דאטה חדש כמו דביבון שפותח פח אשפה: מהר, ברעש ובלי שום תוכנית חוץ מלמצוא משהו נוצץ.
רואים את זה בכל סבב גיוס. המועמד מקבל את הקישור, העיניים שלו מצטעפות מהתרגשות, רגע קצר של Analysis Paralysis — היי לכם! — והוא מיד מתחיל לכתוב קוד.
הוא רוצה להשוויץ.
הוא רוצה למצוא את המתאם המתוק־מתוק הזה.
הוא רוצה להיות הגיבור שמוצא את ה״סוד״ במספרים.
אבל הדחף התזזיתי הזה הוא בדיוק הסיבה שכל כך הרבה מטלות בית קורסות עוד לפני שה־JOIN הראשון מתבצע. אפשר לפלס בכוח דרך לגרף, אבל אם היסודות שלכם רופפים, המסקנה תהיה רק פנטזיה שהתחפשה לתובנה.

כשאתם מקבלים בריף, הצעד הראשון שלכם צריך להיות שקט מוחלט.
באמת, זה מה שאני עושה. תמיד.
שלבו ידיים מאחורי הראש וקראו את השאלה פעמיים.
אל תסרקו אותה סתם — חקרו אותה.
הקיפו את המשפטים, או צבעו אותם, אתם יודעים, מה שעובד עם הטכנולוגיה שלכם, שמתארים את ההחלטה העסקית שצריך לקבל בפועל.
שאלו את עצמכם: ״אם אספק את התשובה המושלמת, מה ישתנה מחר?״ האם תקציב יזוז? האם פיצ׳ר יבוטל? האם האסטרטגיה תשתנה? אם אתם לא יכולים לענות על זה בבירור, אתם פשוט עדיין לא מוכנים לכתוב שאילתה, וזה בסדר גמור.
רק אחרי הבהירות הפנימית הזאת שרטטו על נייר שלושה דברים:
- איך נראית הצלחה.
- מה עלול להשתבש באופן סביר.
- אילו הנחות אתם כבר מניחים.
זה הקו שמפריד בין מי שלוחץ על כפתורים לבין איש דאטה מקצועי.
כשאתם סוף־סוף פותחים את הדאטה, השאילתות הראשונות שלכם צריכות להיות ״משעממות״ בכוונה: טווחי תאריכים, ערכים חסרים, כפילויות והתפלגויות בסיסיות.
חשבו על זה כמו להסתכל לשני הצדדים לפני שחוצים את הכביש. זה לא יזכה אתכם בפרסים, אבל זה משאיר אתכם בחיים מבחינה אנליטית.
כשאני בונה משימות למשתמשים של XP Lab, אני דואג שהמטלות שלנו יענישו בכוונה מהירות שאין מאחוריה חשיבה.
חשיבה איטית אינה עצלנות. היא היגיינה מקצועית.
וזה בדיוק מה שאני רוצה בשבילכם.
.
רשימת בדיקה למסגור בעיה שאפשר להשתמש בה כבר מחר
לפני שפותחים את הדאטה, כתבו בריף קצר שעונה על השאלות האלה:
- באיזו החלטה האנליזה הזאת תתמוך? ״להבין המרה״ הוא נושא. ״להחליט אם לעצור את הקמפיין למובייל בשבוע הבא״ היא החלטה.
- מי יפעל על סמך התשובה? זהו את האדם שיכול לשנות את התקציב, המוצר או התהליך. שאלו מה הוא צריך לדעת לפני שיפעל.
- מה אנחנו משווים? הגדירו את האוכלוסייה, התקופה, יחידת הניתוח והמכנה. ״לקוחות״ יכולים להיות חשבונות, אנשים, רוכשים או ביקורים. אלה אנליזות שונות.
- מה יגרום לנו לשנות את דעתנו? ציינו איזו תצפית תתמוך בפעולה אחרת. אם כל תוצאה אפשרית מובילה לאותה המלצה, בחנו מחדש את מטרת האנליזה.
- מה חייב להיות נכון כדי שהדאטה יענה על השאלה? רשמו את ההנחות לגבי כיסוי האירועים, ההגדרות, החיבורים והתזמון שיכולות לשנות את המסקנה.
- מה אנחנו יכולים לספק באחריות? הסכימו על היקף ועל מועד, והפרידו בין מה שאפשר לענות עליו עכשיו לבין מה שדורש מקור נוסף או יותר זמן.
הבריף לא צריך להיות יפה. הוא צריך לחשוף את הבחירות שאחרת נעלמות בתוך השאילתה הראשונה שלכם.
דוגמה מלאה: ״ההמרה במובייל ירדה״
הנה תרחיש להמחשה. מנהל שיווק מבקש מכם להסביר ירידה בהמרה במובייל וממליץ לקצץ בהוצאות. התגובה האינסטינקטיבית היא לפצל את הגרף לפי קמפיין עד שמופיע עמוד אדום.
קודם שאלו איזו פעולה נשקלת. האם המנהל מחליט אם לעצור קמפיין, לשנות דף נחיתה או לבדוק את מערכת המעקב? ההחלטות האלה דורשות ראיות שונות.
אחר כך הגדירו המרה: הזמנות שהושלמו חלקי סשנים שעומדים בתנאי ההכללה, עבור קבוצת מכשירים מוגדרת וחלון זמן בר־השוואה. בדקו שההגדרות של ההזמנות ושל הסשנים תואמות, ושהתקופה הנוכחית שלמה.
עכשיו יש לכם סיבה לשאילתות המשעממות. בדקו את ספירת האירועים סביב שחרורי גרסאות, את הכיסוי לפי פלטפורמה ותאריך, מזהי הזמנות כפולים ואת הדרך שבה מחברים סשנים לרכישות. השוו את סך הרכישות למקור תפעולי עצמאי, אם יש כזה. סשנים חסרים ופחות רכישות הם בעיות שונות.
התוצר הראשון שלכם יכול להיות: ״אנחנו עדיין לא יכולים להבחין בין שינוי בהתנהגות הלקוחות לבין שינוי במדידה. אלה בדיקות הכיסוי שצריך לבצע לפני שמחליטים על התקציב.״ זאת תשובה מועילה כשהחלופה היא המלצה בטוחה בעצמה שנשענת על הנחה שלא נבדקה.
לבעיית הכיסוי, המשיכו לקרוא על שלמות נתונים. לסטנדרטים שהתשובה הסופית צריכה לעמוד בהם, קראו על המאפיינים של אנליזה עסקית טובה. כדי לתרגל את הגישה, הכירו את תהליך העבודה האנליטי של XP Lab.




