שאלות ראיון לתפקיד אנליסט נתונים

גישה: סינון ← JOIN ← קיבוץ ← מיון ← הגבלה

נניח שיש לנו את הטבלאות customers(customer_id, name) ו-orders(order_id, customer_id, order_date, status, revenue). קודם כול אבהיר אם ההכנסות צריכות לכלול הזמנות שבוטלו או שקיבלו החזר כספי. בדרך כלל כדאי לכלול רק הזמנות שהושלמו. השאילתה מסננת הזמנות מ-30 הימים האחרונים, משאירה רק הזמנות בסטטוס הושלמה, מקבצת לפי לקוח, סוכמת את ההכנסות, ממיינת בסדר יורד ומגבילה ל-5 תוצאות. בגרסה נקייה אשתמש ב-CTE להזמנות הרלוונטיות אם הלוגיקה תהיה מורכבת יותר. פרטים חשובים: להשתמש בעמודת התאריך הנכונה, להימנע מ-JOIN לטבלאות ברמת פריט אלא אם בוצעה אגרגציה מקדימה, ולהחליט איך לטפל בתוצאות שוויון. אם מסד הנתונים תומך בכך, אשתמש בפונקציית חלון לדירוג כשצריך לכלול גם תוצאות שוויון, במקום LIMIT 5 פשוט. תשובה חזקה גם מאמתת את התוצאה באמצעות בדיקת סך ההכנסות הרלוונטיות, מספר השורות והאם אצל אחד הלקוחות המובילים יש שורות הזמנה כפולות באופן חשוד.

גישה: הגדרת קוהורט ← הגדרת אירוע חזרה ← LEFT JOIN ← אגרגציה

קודם כול צריך להגדיר שימור במדויק. אגדיר את משתמשי קוהורט ינואר כמשתמשים שתאריך ההרשמה שלהם הוא בין 1 בינואר ל-1 בפברואר. משתמש נחשב כמשתמש שנשמר (retained) ל-7 ימים אם יש לו לפחות אירוע פעילות רלוונטי אחד ביום השביעי אחרי ההרשמה, או בימים ⁦1-7⁩ אם החברה מגדירה שימור כחזרה בתוך 7 ימים. את זה צריך להבהיר לפני כתיבת השאילתה. לשימור מדויק ביום 7, אצור CTE של הקוהורט עם user_id ו-signup_date. לאחר מכן אבצע LEFT JOIN לטבלת האירועים לפי user_id, בתנאי ש-event_date שווה ל-signup_date + interval 7 days ו-event_name הוא אירוע פעילות משמעותי. המכנה הוא מספר משתמשי הקוהורט הייחודיים, והמונה הוא מספר המשתמשים הייחודיים שיש להם אירוע תואם. המפתח הוא לשמור משתמשים ללא פעילות באמצעות LEFT JOIN. שימוש ב-INNER JOIN מסיר את המשתמשים שלא נשמרו ומנפח את שיעור השימור. בנוסף, ספירת user_id ייחודיים מונעת מצב שבו כמה אירועים משכפלים משתמשים שנשמרו. המדד הסופי: retained_users / cohort_users. אם תהיה בקשה לאבחון, אפלח לפי ערוץ גיוס, פלטפורמה, אזור גיאוגרפי או שבוע הרשמה.

גישה: דירוג הרכישות של כל משתמש

אשתמש בפונקציית חלון כדי לדרג את הרכישות שהושלמו של כל משתמש לפי חותמת הזמן של הרכישה. קודם אסנן רק רכישות שהושלמו, ואז אפעיל row_number() over partition by user_id order by purchase_at. הרכישה השנייה היא השורה שבה row_number = 2. סדר הסינון חשוב. אם רכישות שבוטלו או שקיבלו החזר כספי לא אמורות להיספר, צריך להסיר אותן לפני הדירוג. אם לכמה רכישות יש אותה חותמת זמן, אוסיף שובר שוויון דטרמיניסטי כמו order_id. הפלט יכול לכלול user_id ו-second_purchase_at. אם הבקשה היא למשתמשים שביצעו לפחות שתי רכישות, אחזיר רק שורות עם דירוג 2. אם הבקשה היא לכל המשתמשים, עם NULL למי שאין לו רכישה שנייה, אבצע LEFT JOIN של התוצאה חזרה לטבלת המשתמשים. את סיבוכיות הזמן מנהל מסד הנתונים, אבל בפועל בטבלאות גדולות כדאי שיהיו אינדקסים על user_id ועל חותמת הזמן של הרכישה.

גישה: שורה אחת לכל משתמש עם חותמות זמן לכל שלב

אצור שורה אחת לכל משתמש עם חותמת הזמן המוקדמת ביותר של כל שלב במשפך. כך נמנעת ספירה כפולה של משתמשים שמפעילים את אותו אירוע כמה פעמים. אשתמש באגרגציה מותנית על טבלת האירועים: min(case when event_name = signup then event_at end), min(case when event_name = email_verified then event_at end) וכן הלאה. אחר כך, אם נדרש, אאכוף את סדר השלבים. לדוגמה, אימות המייל צריך להתרחש אחרי ההרשמה, האונבורדינג אחרי האימות, והרכישה הראשונה אחרי האונבורדינג. אם העסק מעוניין בהמרה גמישה ללא תלות בסדר, אציין את ההנחה הזו במפורש. מדדי ההמרה: מהרשמה לאימות, מאימות לאונבורדינג, מאונבורדינג לרכישה, וההמרה הכוללת מהרשמה לרכישה. המונה הוא מספר המשתמשים הייחודיים בכל שלב, והמכנה הוא השלב הקודם. אפלח לפי פלטפורמה, ערוץ גיוס, מכשיר, אזור גיאוגרפי ותאריך קוהורט כדי לזהות היכן הנשירה מרוכזת. מקרי קצה חשובים: אירועים כפולים, משתמשים שמדלגים על שלבים, גבולות של אזורי זמן, חשבונות של בוטים ושל בדיקות, ונתוני אירועים שמגיעים באיחור.

גישה: אימות ← פילוח ← משפך ← גורמים חיצוניים ← המלצה

קודם כול אוודא שהירידה אמיתית. אבדוק שינויים במדידה (instrumentation), עיכובים ב-pipeline של הנתונים, בעיות של אזורי זמן, סינון בוטים, שינויים שהגיעו עם גרסת אפליקציה חדשה, והאם הירידה מופיעה בכמה דשבורדים או בטבלאות הגולמיות. לאחר מכן אפלח את הירידה: פלטפורמה, גרסת אפליקציה, אזור גיאוגרפי, ערוץ גיוס, ותק המשתמש, משתמשים משלמים לעומת חינמיים, סוג מכשיר ומקור תנועה. ירידה גורפת מרמזת על בעיית מעקב, תשתית או בעיה רחבה במוצר. ירידה ממוקדת מצביעה על פלטפורמה, גרסה, שוק או ערוץ מסוימים. בשלב הבא אבחן את מסע המשתמש. האם ירדו פתיחות האפליקציה, האם ירדה הצלחת ההתחברות, האם טעינות דף הבית נכשלו, האם ירדה התגובה להתראות, או שהפעולות המרכזיות ירדו אחרי שהמשתמשים כבר הגיעו? אם פתיחות האפליקציה יציבות אבל הפעילות המרכזית ירדה, הבעיה נמצאת בתוך המוצר. אם פתיחות האפליקציה ירדו, צריך לבדוק התראות, גיוס משתמשים, עונתיות, תקלות שירות או אירועים חיצוניים. לבסוף, אמליץ על פעולה לפי שורש הבעיה. אם ה-DAU ב-iOS ירד אחרי גרסה חדשה ושיעור הקריסות עלה, צריך לבצע rollback או hotfix. אם הירידה היא רק במשתמשים שהגיעו מקמפיינים ממומנים, אבדוק את תקציב הקמפיינים ואת השיוך (attribution). אם הנתונים מתעכבים, אעדכן על המגבלה לפני שתיווצר תחושת דחיפות מיותרת.

גישה: מטרה ← מדד ראשי ← מדדי קלט ← מדדי הגנה ← פילוחים

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

גישה: פירוק ההכנסות לתנועה, המרה, AOV, תמהיל, מחיר ושימור

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

גישה: קהל ← החלטות ← מדדים ← חתכים ← התראות

קודם כול אגדיר את הקהל ואת ההחלטות. ההנהלה צריכה תמונה ברמה גבוהה של צמיחה, שימור, מונטיזציה וסיכונים. היא לא צריכה כל פרט תפעולי במסך הראשון. מדדים ברמה העליונה: הכנסה חודשית חוזרת (MRR), שימור הכנסות נטו, שימור הכנסות ברוטו, MRR חדש, MRR מהרחבה, MRR מצמצום, MRR שאבד בנטישה, לקוחות פעילים, המרה מתקופת ניסיון למינוי בתשלום, ARPU, תקופת החזר CAC אם זמינה, ותחזית מול יעד. חתכים שימושיים: פלח לקוחות, ערוץ גיוס, תוכנית, אזור גיאוגרפי, גודל חברה, חודש קוהורט, ומכירה בליווי צוות מכירות לעומת שירות עצמי. הוויזואליזציות צריכות לכלול קווי מגמה, שימור לפי קוהורט, גשר MRR, סיבות נטישה וסטייה מהיעד. עקרונות עיצוב: להציג הגדרות, חותמת זמן של עדכניות הנתונים, מסננים, בעלים וספי התראה. להימנע ממדדי יוהרה (vanity metrics) ומערבוב ספירת משתמשים עם מדדי הכנסות בלי תוויות ברורות. הדשבורד צריך לענות על השאלות: האם אנחנו צומחים, למה, איפה הסיכון ומה ההנהלה צריכה לבדוק בהמשך?

גישה: הבהרת ההחלטה ← הסבר הסיכון ← הצעת תצוגה טובה יותר

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

גישה: מיפוי הנתונים ← סטנדרטיזציה ← אימות ← תיעוד

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

גישה: חקירה לעומת חישוב מבוקר

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

גישה: השערה ← רנדומיזציה ← מדדים ← מדדי הגנה ← החלטה

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

גישה: בדיקת עוצמה סטטיסטית ← בחינת הכיוון ← הערכת עלות ← החלטה

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

גישה: הגדרות ← מקורות ← מסננים ← רמת פירוט ← תזמון ← התאמה

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

גישה: מדידת היקף החוסרים ← אבחון הסיבה ← בחירת טיפול ← שקיפות

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

גישה: החלטה ← ניתוח ← תובנה ← המלצה ← השפעה

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

גישה: הבהרת הדחיפות ← הערכה כיוונית ← הצגת מגבלות ← תכנון המשך

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

גישה: השפעה ← דחיפות ← מאמץ ← תלויות ← תיאום עם בעלי עניין

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