Veri analisti mülakat rehberi

Çerçeve: Filtrele → join et → grupla → sırala → sınırla

customers(customer_id, name) ve orders(order_id, customer_id, order_date, status, revenue) tablolarımız olduğunu varsayıyorum. Önce gelire iptal edilen veya iade edilen siparişlerin dahil edilip edilmeyeceğini netleştiririm. Genellikle yalnızca tamamlanmış siparişleri dahil etmek gerekir. Sorgu, siparişleri son 30 günle ve tamamlanmış durumla filtreler, müşteriye göre gruplar, geliri toplar, azalan sırada sıralar ve sonucu 5 satırla sınırlar. Mantık karmaşıklaşırsa uygun siparişler için bir CTE kullanmak sorguyu daha temiz hâle getirir. Önemli ayrıntılar: doğru tarih kolonunu kullanmak, ön toplulaştırma yapılmadıkça ürün kalemi seviyesindeki tablolara join yapmamak ve eşitliklerin nasıl ele alınacağına karar vermek. Eşit değerlerin de sonuca dahil edilmesi gerekiyorsa ve veritabanı destekliyorsa, basit bir LIMIT 5 yerine sıralama yapan bir window function kullanırım. Son olarak sonucu da doğrularım: Uygun siparişlerden gelen toplam geliri, satır sayısını ve listenin üst sıralarındaki herhangi bir müşteride şüpheli şekilde mükerrer sipariş satırı olup olmadığını kontrol ederim.

Çerçeve: Kohortu tanımla → geri dönüş event'ini tanımla → left join → toplulaştır

Önce retention'ı net bir şekilde tanımlarım. Ocak kohortunu, kayıt tarihi 1 Ocak ile 1 Şubat arasında olan kullanıcılar olarak tanımlarım. Bir kullanıcı, kayıt olduktan sonraki 7. günde en az bir geçerli aktivite event'i gerçekleştirmişse 7 günlük retention kapsamında sayılır; şirket retention'ı 7 gün içinde geri dönmek olarak tanımlıyorsa bu aralık 1-7. günler olur. Sorguya geçmeden önce bunu netleştiririm. Tam olarak 7. gün retention'ı için user_id ve signup_date içeren bir kohort CTE'si oluştururum. Ardından event'leri user_id üzerinden left join ile bağlarım; koşul olarak event_date değerinin signup_date + interval 7 days değerine eşit olmasını ve event_name değerinin anlamlı bir aktiflik event'i olmasını ararım. Payda olarak kohorttaki tekil kullanıcıları, pay olarak da eşleşen event'i olan tekil kullanıcıları sayarım. Kritik nokta, left join kullanarak hiç aktivitesi olmayan kullanıcıları korumaktır. Inner join kullanırsanız geri dönmeyen kullanıcıları elemiş olur ve retention'ı olduğundan yüksek gösterirsiniz. Ayrıca user_id üzerinden tekil sayım yaparak birden fazla event'in aynı kullanıcıyı mükerrer saymasını önlerim. Nihai metrik: retained_users / cohort_users. Mülakatçı teşhis isterse sonucu edinim kanalı, platform, coğrafya veya kayıt haftasına göre segmentlere ayırırım.

Çerçeve: Satın almaları kullanıcı bazında sırala

Her kullanıcının tamamlanmış satın almalarını satın alma zaman damgasına göre sıralamak için bir window function kullanırım. Önce tamamlanmış satın almaları filtreler, ardından row_number() over partition by user_id order by purchase_at uygularım. İkinci satın alma, row_number = 2 olan satırdır. Filtreleme sırası önemlidir. İptal edilen veya iade edilen satın almalar sayılmayacaksa sıralamadan önce bunları çıkarırım. Birden fazla satın alma aynı zaman damgasına sahipse order_id gibi deterministik bir eşitlik bozucu eklerim. Çıktıda user_id ve second_purchase_at yer alabilir. Mülakatçı en az iki satın alma yapan kullanıcıları isterse yalnızca sırası 2 olan satırları döndürürüm. Tüm kullanıcıları isteyip ikinci satın alması olmayanlar için null görmek isterse sonucu users tablosuna left join ile geri bağlarım. Zaman karmaşıklığını veritabanı yönetir; ancak pratikte büyük tablolarda user_id ve satın alma zaman damgası üzerindeki indeksler bu sorgunun performansına ciddi katkı sağlar.

Çerçeve: Kullanıcı başına bir satır, her adım için zaman damgası

Her kullanıcı için tek satır oluşturur ve her huni adımının en erken zaman damgasını bu satıra yazarım. Bu sayede aynı event'i birden çok kez tetikleyen kullanıcılar iki kez sayılmaz. Events tablosu üzerinde koşullu toplulaştırma kullanırım: min(case when event_name = signup then event_at end), min(case when event_name = email_verified then event_at end) vb. Gerekiyorsa ardından adımların sırasını zorunlu kılarım. Örneğin e-posta doğrulaması kayıttan, onboarding doğrulamadan, ilk satın alma da onboarding'den sonra gerçekleşmelidir. İş birimi sıradan bağımsız, esnek bir dönüşüm istiyorsa bu varsayımı açıkça belirtirim. Dönüşüm metrikleri: kayıttan doğrulamaya, doğrulamadan onboarding'e, onboarding'den satın almaya ve uçtan uca kayıttan satın almaya dönüşüm. Her adımda pay olarak o adımdaki tekil kullanıcıları, payda olarak da bir önceki adımı kullanırım. Kaybın nerede yoğunlaştığını görmek için platform, edinim kanalı, cihaz, coğrafya ve kohort tarihine göre segmentlere ayırırım. Önemli uç durumlar: mükerrer event'ler, adım atlayan kullanıcılar, saat dilimi sınırları, bot/test hesapları ve geç gelen event verileri.

Çerçeve: Doğrula → segmentlere ayır → huni → dış etkenler → öneri

Önce düşüşün gerçek olup olmadığını doğrularım. Event takibindeki (instrumentation) değişiklikleri, veri pipeline'ındaki gecikmeleri, saat dilimi sorunlarını, bot filtrelemeyi, uygulama sürümündeki değişiklikleri ve düşüşün birden fazla dashboard'da ya da ham tablolarda da görünüp görünmediğini kontrol ederim. Ardından düşüşü segmentlere ayırırım: platform, uygulama sürümü, coğrafya, edinim kanalı, kullanıcı kıdemi, ücretli ve ücretsiz kullanıcılar, cihaz türü ve trafik kaynağı. Genel bir düşüş tracking, altyapı ya da ürünün genelini etkileyen bir soruna işaret eder. Dar bir alandaki düşüş ise belirli bir platformu, sürümü, pazarı veya kanalı gösterir. Sonra kullanıcı yolculuğunu incelerim. Uygulama açılışları mı düştü, başarılı giriş oranı mı azaldı, ana sayfa yüklenemiyor mu, bildirimler mi azaldı, yoksa kullanıcılar geldikten sonra temel aksiyonlar mı geriledi? Uygulama açılışları sabitken temel aktivite düşmüşse sorun ürünün içindedir. Uygulama açılışları düşmüşse bildirimlere, edinime, mevsimselliğe, kesintilere veya dış etkenlere bakarım. Son olarak kök nedene göre aksiyon öneririm. iOS'taki DAU bir sürümden sonra düştüyse ve çökme oranı arttıysa sürümü geri alır ya da hotfix çıkarırız. Yalnızca ücretli edinimle gelen kullanıcılarda düşüş varsa kampanya harcamasını ve attribution'ı kontrol ederim. Veri gecikmeliyse gereksiz bir alarm havası yaratmadan önce bu kısıtı paydaşlara iletirim.

Çerçeve: Hedef → birincil metrik → girdi metrikleri → koruyucu metrikler → segmentler

Hedefle başlarım. Bir öneri özelliği keşfi, etkileşimi, dönüşümü, retention'ı veya sipariş tutarını artırmayı amaçlayabilir. Birincil metrik yalnızca tıklamaları değil, kullanıcıya sağlanması hedeflenen değeri yansıtmalıdır. Örneğin bir e-ticaret öneri sisteminde aktif kullanıcı başına önerilen ürünlerden gelen satın alma veya sepete ekleme sayısı güçlü bir metrik olabilir. Girdi metrikleri arasında öneri gösterimleri, tıklama oranı, sepete ekleme oranı, dönüşüm oranı, oturum başına gelir, kapsama ve çeşitlilik yer alır. Koruyucu metrikler ise ürün iadeleri, para iadeleri, düşük kaliteli tıklamalar, sayfa gecikmesi, kullanıcı şikâyetleri ve organik keşif üzerindeki kanibalizasyondur. Yeni ve geri dönen kullanıcılar, kategori, cihaz, trafik kaynağı ve önerinin gösterildiği alana göre segmentlere ayırırım. Bir model ortalama performansı iyileştirirken yeni kullanıcılara veya uzun kuyruktaki ürünlerin keşfine zarar verebilir. Mümkünse özelliği bir A/B testiyle değerlendirir, ardından uzun vadeli retention'ı ve tekrar satın alma davranışını izlerim. Kullanıcılar alakasız veya memnuniyeti düşük ürünlere yönlendiriliyorsa kısa vadeli tıklama artışı tek başına yeterli değildir.

Çerçeve: Geliri trafik, dönüşüm, AOV, ürün karması, fiyat ve retention bileşenlerine ayır

Gelir genellikle trafik × dönüşüm oranı × ortalama sipariş tutarı (AOV) olarak ifade edilir; buna ürün karması, fiyatlandırma, tekrar satın alma ve iadelerin etkileri eklenir. Dönüşüm düşerken gelir arttıysa birkaç olası açıklama vardır. Trafik hacmi, düşen dönüşümü telafi edecek kadar artmış olabilir. Ortalama sipariş tutarı fiyat değişiklikleri, paket teklifler, kurumsal müşteriler, daha büyük sepetler veya ürün karmasının pahalı ürünlere kayması nedeniyle yükselmiş olabilir. Şirket satın alma niyeti düşük trafiği azaltmış olabilir; bu da oran bazında daha az dönüşüm ama daha değerli satın almalar anlamına gelir. Gelir ya da dönüşüm ölçümünü etkileyen tracking değişiklikleri de söz konusu olabilir. Kanal, ürün, coğrafya, yeni ve geri dönen kullanıcılar, müşteri segmenti ve cihaza göre segmentlere ayırırım. Ardından geliri oturumlar, dönüşüm, AOV, iade oranı ve tekrar satın almalar olarak bileşenlerine ayırırım. Dönüşümün oturum, kullanıcı veya ziyaretçi seviyesinde mi ölçüldüğünü de kontrol ederim; çünkü paydadaki değişiklikler yanıltıcı trendler yaratabilir. Öneri, büyümenin kalitesine bağlıdır. Gelir artışı daha sağlıklı, yüksek değerli müşterilerden geliyorsa daha düşük dönüşüm kabul edilebilir. Yeni müşteri dönüşümü zayıflarken artış tek seferlik bir fiyat artışından geliyorsa bu, gelecekteki büyüme için bir risk olabilir.

Çerçeve: Kitle → kararlar → metrikler → kırılımlar → uyarılar

Önce kitleyi ve alınacak kararları tanımlarım. Üst yöneticilerin büyüme, retention, monetizasyon ve riske dair üst düzey bir görünüme ihtiyacı vardır. İlk ekranda her operasyonel ayrıntıyı görmeleri gerekmez. Üst düzey metrikler: aylık yinelenen gelir (MRR), net gelir retention'ı, brüt gelir retention'ı, yeni MRR, genişleme MRR'ı, daralma MRR'ı, churn nedeniyle kaybedilen MRR, aktif müşteriler, denemeden ücretliye dönüşüm, ARPU, varsa CAC geri ödeme süresi ve hedefe karşı tahmin. Faydalı kırılımlar: müşteri segmenti, edinim kanalı, plan, coğrafya, şirket büyüklüğü, kohort ayı ve satış ekibi destekli ile self-servis karşılaştırması. Görseller arasında trend çizgileri, kohort retention'ı, MRR köprüsü, churn nedenleri ve hedeften sapma yer almalıdır. Tasarım ilkeleri: Tanımları, verinin güncellik zaman damgasını, filtreleri, dashboard sahibini ve uyarı eşiklerini gösteririm. Gösteriş metriklerinden ve kullanıcı sayılarını net etiketler olmadan gelir metrikleriyle karıştırmaktan kaçınırım. Dashboard şu sorulara yanıt vermelidir: Büyüyor muyuz, neden büyüyoruz, risk nerede ve yönetim bir sonraki adımda neyi incelemeli?

Çerçeve: Kararı netleştir → riski açıkla → daha iyi bir görünüm öner

Önce hangi kararı almaya çalıştığını netleştiririm. Bazen paydaşlar kafalarında hazır bir hikâye olduğu için belirli bir grafik ister; oysa asıl ihtiyaç, bir iş sorusunun yanıtıdır. Ardından riski net ve savunmacı olmayan bir dille açıklarım. Örneğin kümülatif gelir grafiği her zaman yukarı gider ve son dönemdeki yavaşlamayı gizleyebilir. Çok fazla kategori içeren bir pasta grafik farkları belirsizleştirebilir. Güven aralığı olmayan bir grafik, hassasiyeti olduğundan fazla gösterebilir. Trafik karması verilmeden sunulan bir dönüşüm oranı yanıltıcı olabilir. Aynı soruyu daha doğru yanıtlayan bir alternatif öneririm: trend çizgisi, kohort grafiği, huni, dağılım grafiği, segmentlere ayrılmış sütun grafik veya metrik ayrıştırması. Orijinal grafiğe yine de ihtiyaç duyarlarsa uyarı notlarıyla birlikte ekleyebilirim, ancak yanıltıcı bir analizi kendi önerim olarak sunmam. Amaç güveni korumaktır. Analistler yardımcı olmalı, ama analitik dürüstlüğün sorumluluğu da onlardadır.

Çerçeve: Profil çıkar → standartlaştır → doğrula → belgele

Önce verinin profilini çıkarırım: satır sayısı, kolon adları, eksik değerler, mükerrer kayıtlar, veri tipleri, imkânsız değerler, tarih formatları ve aykırı değerler. Herhangi bir dönüşüm yapmadan önce ham verinin bir kopyasını saklarım. Ardından alanları standartlaştırırım: baştaki ve sondaki boşlukları temizler, büyük/küçük harf kullanımını tek tipe getirir, tarihleri ayrıştırır, para birimlerini veya ölçü birimlerini dönüştürür, gerekirse birleşik alanları böler ve tutarsız kategorileri kontrollü bir listeyle eşleştiririm. Mükerrer kayıtlarda herhangi bir şeyi silmeden önce iş anahtarını tanımlarım. Sonra toplamları güvenilir bir kaynakla karşılaştırarak doğrularım. Örneğin toplam gelir finans ekibinin dışa aktarımlarıyla mutabık olmalı, sipariş sayıları kaynak sistemlerle eşleşmeli ve tarih aralıkları eksiksiz olmalıdır. Null oranları, tekil sayımlar ve kategori değerleri için kontroller oluştururum. Son olarak dönüşümleri belgelerim. Karar almada kullanılan bir elektronik tablo varsayımları görünür kılmalı, ham veriyi temizlenmiş veriden ayırmalı ve denetlenemeyen gizli manuel düzenlemelerden arınmış olmalıdır.

Çerçeve: Keşif mi, kontrollü hesaplama mı?

Pivot tablolar veriyi hızlıca keşfetmek, gruplamak, farklı boyutlarda dilimlemek ve özetlemek için mükemmeldir. Soru kategoriye göre toplamlar, sayımlar, ortalamalar veya trendlerle ilgiliyse ve paydaşlar etkileşimli filtreleme istiyorsa çok işe yarar. Mantık özel, çok adımlı ya da denetlenebilir olmak zorundaysa veya hassas kontrol gerektiriyorsa formül tabanlı analiz daha iyidir. Kohort hesaplamaları, şelale modelleri, ağırlıklı puanlama, istisna işaretleri, mutabakat kontrolleri veya bir tahmini besleyen girdiler buna örnektir. Pratikte genellikle ikisini birlikte kullanırım: Örüntüleri hızlıca keşfetmek için pivot tabloları, nihai yanıtı üretmek için de formülleri ya da daha temiz bir modeli. Düzenli raporlamada kırılgan, manuel bir elektronik tablo yerine yeniden üretilebilir bir sorgu veya BI pipeline'ını tercih ederim.

Çerçeve: Hipotez → randomizasyon → metrikler → koruyucu metrikler → karar

Hipotez: Yeniden tasarlanan ödeme sayfası sürtünmeyi azaltır ve sonraki adımlarda olumsuz etki yaratmadan tamamlanan satın almaları artırır. Önce deney kurulumunu teyit ederim: randomizasyon birimi, örneklem büyüklüğü, süre, maruz kalma (exposure) loglaması, uygunluk kriterleri ve kullanıcıların oturumlar arasında aynı varyantta kalıp kalmadığı. Randomizasyonu kullanıcı yerine oturum bazında yapmak, kullanıcılar geri döndüğünde sonuçları kirletebilir. Birincil metrik: ödemeye başlamadan tamamlanmış satın almaya kadar olan ödeme dönüşüm oranı. İkincil metrikler: ödeme başarısızlık oranı, ödemeyi tamamlama süresi, ortalama sipariş tutarı, ek ürün ekleme oranı ve tekrar ziyaretler. Koruyucu metrikler: iadeler, ters ibrazlar (chargeback), destek talepleri, gecikme, hata oranı ve müşteri şikâyetleri. Analiz hem istatistiksel hem de pratik anlamlılığı kapsamalıdır. Çok küçük bir artış, getireceği mühendislik karmaşıklığına değmeyebilir. Segment analizi mobilde iyileşme olurken masaüstünde düşüş yaşandığını ortaya çıkarabilir; ancak gürültülü alt gruplara aşırı tepki vermekten kaçınırım. Öneri: Birincil metrik anlamlı ölçüde iyileşiyorsa, koruyucu metrikler sağlıklıysa, ölçüm altyapısı güvenilirse ve etki test süresinin tamamı boyunca sürüyorsa değişikliği yayına alırım.

Çerçeve: Gücü kontrol et → yönü incele → maliyeti değerlendir → karar ver

İstatistiksel olarak anlamlı olmayan bir sonuç, özelliğin hiçbir etkisi olmadığı anlamına otomatik olarak gelmez. Önce testin anlamlı bir etkiyi yakalayacak istatistiksel güce sahip olup olmadığını kontrol ederim. Örneklem büyüklüğü çok küçükse veya metrik gürültülüyse sonuç kesin olmayabilir. Ardından etki büyüklüğünü ve güven aralığını incelerim. Aralık hem anlamlı bir yukarı yönlü potansiyeli hem de anlamlı bir aşağı yönlü riski kapsıyorsa test belirsizdir. Aralık sıfırın çevresinde dar bir şekilde toplanıyorsa özelliğin o metrik üzerindeki etkisi büyük olasılıkla azdır. Sonra maliyeti ve stratejiyi değerlendiririm. Özelliğin bakımı pahalıysa ve ölçülebilir bir fayda göstermiyorsa yayına almam ya da geri alırım. Stratejik açıdan önemliyse, riski düşükse veya kullanıcı deneyimini niteliksel olarak iyileştiriyorsa üzerinde iterasyon yapmayı ya da daha iyi bir metrikle ölçmeyi düşünürüm. Sonucu şöyle özetlerim: Neyi test ettik, ne gözlemledik, ne kadar eminiz, hangi kısıtlar var ve hangi kararı öneriyorum.

Çerçeve: Tanımlar → kaynaklar → filtreler → granülarite → zamanlama → mutabakat

Önce tanımları karşılaştırırım. Dashboard'lardan biri brüt geliri, diğeri iadeler, indirimler, vergiler veya ters ibrazlar düşüldükten sonraki net geliri gösteriyor olabilir. Gelirin kayda alınma zamanlaması da farklı olabilir: sipariş tarihi, ödeme tarihi, sevkiyat tarihi veya fatura tarihi. Ardından veri kaynaklarını, filtreleri ve granülariteyi karşılaştırırım. Bir dashboard test hesaplarını, iptal edilen siparişleri, şirket içi kullanıcıları, kurumsal faturaları veya belirli coğrafyaları hariç tutuyor olabilir. Diğeri sipariş kalemlerini hatalı şekilde join edip geliri mükerrer sayıyor olabilir. Saat dilimini ve verinin güncelliğini de kontrol ederim. Güvenilir bir kaynaktan yola çıkarak bir köprü kurar ve mutabakat yaparım: A dashboard'undaki gelirle başlar, farkları adım adım ekleyip çıkararak B dashboard'undaki rakama ulaşırım. Her farkın adı konmuş bir nedeni olmalıdır. Nihai çıktı yalnızca “A dashboard'u yanlış” demek olmamalıdır. Düzeltilmiş bir tanım, bir sahip, tek bir doğruluk kaynağı (source of truth) ve gelecekte benzer karışıklıkları önleyecek bir plan ortaya koymalıdır.

Çerçeve: Eksikliği ölç → nedenini teşhis et → yöntemi seç → açıkça belirt

Önce eksikliği sayısallaştırırım: Hangi alanlar, kaç satır, yüzde kaç ve eksiklik segmente, zamana, kaynağa veya platforma göre değişiyor mu? Eksik veri her zaman rastgele değildir. Ardından neden eksik olduğunu teşhis ederim. İsteğe bağlı bir kullanıcı girdisi, tracking hatası, geç gelen veri, entegrasyon sorunları, gizlilik kısıtlamaları veya geçerli bir “uygulanamaz” değeri olabilir. Hangi yöntemi seçeceğim nedene bağlıdır. Seçenekler arasında satırları hariç tutmak, değer ataması (imputation) yapmak, “bilinmiyor” kategorisi oluşturmak, başka bir kaynaktan geriye dönük doldurmak veya analizin kapsamını değiştirmek var. Eksik değerleri körü körüne sıfırla doldurmaktan kaçınırım, çünkü sıfır ile bilinmeyen farklı anlamlara gelir. Son olarak etkisini açıkça belirtirim. Eksik verinin güven düzeyini nasıl etkilediğini ve makul varsayımlar altında önerinin değişip değişmediğini ifade ederim.

Çerçeve: Karar → analiz → içgörü → öneri → etki

Analizin bir kararı açıkça etkilediği bir hikâye seçin. Söz konusu iş kararıyla başlayın: lansman, fiyatlandırma, pazarlama harcaması, ürün değişikliği, operasyonlar veya önceliklendirme. Ardından analizi sade bir dille anlatın. Hangi verileri kullandınız, hangi metrik önemliydi, hangi segmentleri incelediniz ve sizi ne şaşırttı? Yanıtın tamamını araçlardan bahsederek geçirmeyin. Mülakatçı, çalışmanızın düşünce biçimini nasıl değiştirdiğini öğrenmek ister. Sonra önerinizi ve etkisini belirtin. Örneğin analiziniz bir kampanyanın genel olarak kârlı göründüğünü ama bir kanalda zarar ettiğini ortaya koydu; ekip de bütçeyi kaydırarak ROI'yi iyileştirdi. Ya da bir ürün özelliği tıklamaları artırırken retention'ı düşürdü ve ekip özelliği geri aldı. Güçlü bir yanıt, kısıtları ve paydaş iletişimini de içerir. Belirsizliği nasıl yönettiğinizi ve öneriyi nasıl anlaşılır kıldığınızı açıklayın.

Çerçeve: Aciliyeti netleştir → yön gösteren bir okuma sun → kısıtları belirt → takip planı yap

Önce kararı ve son tarihi netleştiririm. Karar düşük riskliyse yön gösteren bir yanıt kabul edilebilir. Geliri, müşterileri, mevzuata uyumu veya stratejiyi etkiliyorsa kalite çıtası daha yüksek olmalıdır. Ardından şu anda neyin yanıtlanabileceğini, neyin yanıtlanamayacağını açıklarım. Net uyarılarla birlikte ön bir değerlendirme sunabilirim: “Şu an elimizdeki verilere göre trend olumsuz görünüyor, ancak Android kullanıcıları için tracking eksik; bu yüzden henüz nihai bir lansman kararı vermezdim.” Anlık yanıtı takip planından ayırırım. Anlık: mevcut en iyi tahmin ve güven düzeyi. Takip: veri temizleme adımları, doğrulama kontrolleri, doğruluk kaynağıyla mutabakat ve daha sağlam bir yanıtın ne zaman hazır olacağı. Bu yaklaşım, analitik dürüstlüğü korurken paydaşın ilerlemesini sağlar. En kötü yanıt, hızlı ama yanlış olan ve kendinden emin bir şekilde sunulan bir rakamdır.

Çerçeve: Etki → aciliyet → efor → bağımlılık → paydaş uyumu

Önceliklendirmeyi iş etkisine, aciliyete, efora, bağımlılıklara ve analizin geri dönüşü olmayan ya da yüksek riskli bir karara destek olup olmadığına göre yaparım. Yarınki bir lansman kararına bağlı bir talep, genellikle “olsa iyi olur” denecek bir dashboard iyileştirmesinin önüne geçer. Her talebin hangi karara destek olduğunu da netleştiririm. Net bir kararı veya sahibi olmayan bir talebin, analize başlamadan önce olgunlaştırılması gerekebilir. Tekrarlayan taleplerde ekibin manuel raporlamaya hapsolmaması için otomasyon fırsatları ararım. Öncelikler çatıştığında ödünleşimleri açıkça iletirim: “Bugün churn analizini ya da dashboard güncellemesini tamamlayabilirim, ama ikisini birden yetiştiremem. Churn analizi bu haftaki retention planını etkilediği için önce onu yapmayı öneriyorum.” Güçlü analistler her talebi geliş sırasına göre kabul etmekle yetinmez. Kurumun analitik zamanını kararları değiştirdiği yerlere harcamasına yardımcı olurlar.