Yapay zekayı kullanarak Power BI ile çalışan herkesin mutlaka en az bir kez duvara tosladığı anlar vardır: Her şeyin kitabına uygun göründüğü bir kümülatif toplam DAX formülü yazarsınız ama grafikte kümülatif (birikimli) bir artış görmek yerine, aylara göre inip çıkan anlamsız bir zikzakla karşılaşırsınız.

Geçtiğimiz aylarda tam olarak bu problemi yaşadım. İşin en sinir bozucu yanı, sorunu çözmek için yapay zekaya danıştığımda da aylarca aynı kısır döngüye girmemdi. “Bak, bu bir kümülatif toplam olmalı, dikkat et” diyerek defalarca sormama rağmen yapay zeka bana her seferinde teorik olarak kusursuz görünen ama raporumda bir türlü çalışmayan o klasik ezber formülleri verip durdu.

Ta ki yeni bir denemede yapay zekanın sütun adının sonuna eklediği o küçücük .[Date] detayını fark edene kadar. Meğer aylardır beni ve yapay zekayı ters köşe yapan bu kördüğümün çözümü sadece 7 karakterde gizliymiş.

Gelin, bu “görünmez tuzak” neymiş ve nasıl çözülüyormuş adım adım inceleyelim.

Sorun Neydi? (Kâğıt Üzerinde Kusursuz, Grafikte Zikzak)

Elimde şirket kayıtlarının tutulduğu standart bir tablo vardı ve amacım kayıt tarihine göre kümülatif toplam şirket sayısını hesaplamaktı. İlk etapta yazdığım ve yapay zekanın da “Daha iyisi ve doğrusu bu” diyerek bana aylarca önerdiği klasik formül şuydu:

// Teoride doğru görünen ama grafikte zikzak çizen klasik yaklaşım:
Kumulatif Sirket Sayisi = 
VAR _MaxTarih = MAX('SirketKayitlari'[KayitTarihi])
RETURN
CALCULATE(
    COUNT('SirketKayitlari'[Id]),
    'SirketKayitlari'[KayitTarihi] <= _MaxTarih,
    NOT ISBLANK('SirketKayitlari'[SirketAdi]),
    REMOVEFILTERS('SirketKayitlari'[KayitTarihi])
)

Yazım (syntax) olarak tek bir hatası bile yoktu. Ancak formülü çizgi grafiğe attığımda kümülatif bir yükseliş yerine, her ayın sadece kendi içindeki sayıyı gösteren zikzaklı bir grafikle karşılaşıyordum.

Sorunu çözen ise formülün mantığını değiştirmek değil, tarih sütununa sadece .[Date] ekleyerek şu yapıya geçmek oldu:

// Sorunu çözen ve grafiği pürüzsüzleştiren nihai formül:
Kumulatif Sirket Sayisi = 
VAR _MevcutDonemSayisi = 
    CALCULATE(
        COUNT('SirketKayitlari'[Id]),
        NOT ISBLANK('SirketKayitlari'[SirketAdi])
    )
VAR _MaxTarih = MAX('SirketKayitlari'[KayitTarihi].[Date])
RETURN
IF(
    NOT ISBLANK(_MevcutDonemSayisi),
    CALCULATE(
        COUNT('SirketKayitlari'[Id]),
        NOT ISBLANK('SirketKayitlari'[SirketAdi]),
        FILTER(
            ALLSELECTED('SirketKayitlari'[KayitTarihi].[Date]),
            'SirketKayitlari'[KayitTarihi].[Date] <= _MaxTarih
        )
    )
)

Peki ama ne değişti de aylardır çalışmayan formül bir anda kusursuz bir kümülatif eğriye dönüştü? Cevap 3 kritik detayda gizli.

1. İki Katmanlı Filtre Tuzağı: KayitTarihi vs KayitTarihi.[Date]

Eğer projenizde Auto Date/Time (Otomatik Tarih/Saat) ayarını kapatmadıysanız ve ayrı bir Takvim (Date) tablosu oluşturmadıysanız, Power BI modelinizdeki her bir tarih sütunu için arka planda sizin görmediğiniz gizli bir takvim tablosu (LocalDateTable_...) üretir.

Siz KayitTarihi sütununu grafiğin X eksenine sürüklediğinizde, Power BI aslında sizin tablonuzdaki o sütunu değil, arka planda ürettiği bu gizli tablonun Yıl > Çeyrek > Ay > Gün hiyerarşisini kullanır.

• Neden zikzak çıkıyordu? Formülde REMOVEFILTERS('SirketKayitlari'[KayitTarihi]) veya ALL('SirketKayitlari'[KayitTarihi]) yazdığınızda, yalnızca ana tablodaki sütunun filtresini kaldırıyorsunuz. Oysa grafik eksenindeki Ay veya Yıl filtresi, arka plandaki o gizli takvim tablosundan gelmeye devam ediyor. Filtre kırılmadığı için Power BI her ay sadece kendi içindeki sayıyı hesaplıyor.
• Nasıl çözüldü? Sütunun sonuna .[Date] ekleyerek Power BI'a şu net komutu vermiş olduk: "Ana tablodaki sütuna değil, arka planda oluşturduğun o gizli takvim tablosunun filtresine müdahale et."

2. Neden ALL Yerine ALLSELECTED Kullanmalıyız?

Çözümdeki bir diğer hayati dokunuş ise ALL yerine ALLSELECTED fonksiyonunu tercih etmek:

• Eğer ALL('SirketKayitlari'[KayitTarihi].[Date]) kullanırsanız, sayfadaki Tarih Slicer (dilimleyici) seçimini de ezersiniz. Örneğin kullanıcı ekrandan sadece 2024 yılını seçse bile, grafik en baştan (örneğin 2020'den) itibaren kümülatif toplamı hesaplamaya devam eder.
• ALLSELECTED(...) ise Power BI'a şunu söyler: "Kullanıcının slicer'dan seçtiği tarih aralığını ve diğer filtreleri (örneğin sadece İstanbul'u) koru; yalnızca seçili aralıktaki tarih kırılımını kendi içinde kümülatif olarak biriktir."

(Küçük bir bonus ipucu: Formülün başındaki IF(NOT ISBLANK(_MevcutDonemSayisi), ...) kontrolü ise henüz yaşanmamış gelecek aylarda çizginin dümdüz sağa doğru uzamasını engelleyip grafiği veri olan son ayda keser.)

3. Büyük Ders: Otomatik Takvim mi, Özel Takvim Tablosu mu?

Bu süreç bana Power BI’ın arka plandaki zaman zekâsının nasıl çalıştığını bilmenin ne kadar kritik olduğunu gösterdi. İki yaklaşımın davranış farkını bilmek, yazacağınız DAX formüllerinin kaderini doğrudan belirliyor:

• Otomatik Tarih/Saat (Auto Date/Time) Kullanıyorsanız: Power BI her tarih sütunu için arka planda kendi gizli hiyerarşisini kurar. Bu yapıda standart tarih sütununu doğrudan çağırmak yeterli olmaz; gizli takvim tablosuna ulaşmak için formüllerinizde mutlaka .[Date] uzantısını belirtmeniz gerekir.
• Kendi Özel Takvim Tablonuzu (Calendar Table) Oluşturuyorsanız: Modelinize özel bir takvim tablosu ekleyip ayarlardan Auto Date/Time özelliğini kapattığınızda, arka planda gizli tablolar üretilmez. İlişkiyi doğrudan kendi tablonuz üzerinden kurduğunuz için .[Date] yazmanıza gerek kalmadan, yapay zekanın da ilk anda önerdiği o standart ve temiz kümülatif formüller sorunsuz çalışır.

Sonuç

Yapay zeka harika bir yardımcı; ancak modelin arka planında Power BI’ın hangi gizli ayarlarının açık olduğunu göremiyor. Veri setinin mimarisini, veri modelini, neleri barındırdığını ve sınırlarını da bilmiyor — ve siz bunları yapay zekaya söylemediğiniz takdirde asla bilmeyecek.

Bazen aylarca uğraştıran veri analitiği problemlerinin çözümü yalnızca doğru kodu yazmaktan değil; veriyi tanımaktan, veri modelinin mimarisine hâkim olmaktan ve kullandığımız aracın arka plan ayarlarını bilmekten geçiyor.

Gerçek kâbus; işi baştan yanlış yaptığının farkında olmayıp buna rağmen terminalin yemyeşil olduğu ve modelin başarıyla canlıya alındığı an başlar.

Diyelim ki bir e-ticaret şirketinde kullanıcıların gelecek ayki harcama tutarlarını tahmin eden bir regresyon modeli kuruyoruz. Elimizde 100.000 satırlık bir veri seti var ve modelin başarı metrikleri (RMSE, R²) gayet makul görünüyor.

Veri ön işleme aşamasında iade_edilen_urun_tutari kolonunda yaklaşık %34 oranında eksik veri (NaN) olduğunu fark ediyoruz ve şu masum satırı yazıyoruz:

# İade tutarı boş olanlar belli ki ürün iade etmemiş, o zaman 0 yazalım!
df['iade_edilen_urun_tutari'] = df['iade_edilen_urun_tutari'].fillna(0)

Dışarıdan bakıldığında “mantıklı bir iş kuralı” gibi duran bu satır, gerçekte modeli nasıl felç etti?

SQL’in Sessiz Mirası: Tablolar Nasıl Birleşti?

Gerçek projelerde veri kimsenin önüne tertemiz bir CSV olarak gelmez. İster bir BI geliştiricisi olun ister veri bilimci, o veriyi üretim veritabanından veya veri ambarından (DWH) SQL sorgularıyla bizzat çekersiniz. Asıl kopukluk da tam burada yaşanır: SQL tarafında veriyi birleştirirken kurduğumuz mimari mantığı, Python tarafında modellemeye geçtiğimiz an unuturuz.

Muhtemelen bu tablo veritabanından şöyle bir sorguyla çekilmişti:

SELECT 
    u.kullanici_id,
    u.toplam_siparis_sayisi,
    i.iade_edilen_urun_tutari
FROM kullanicilar u
LEFT JOIN iadeler i ON u.kullanici_id = i.kullanici_id;

LEFT JOIN atıldığında sağ taraftaki iadeler tablosunda eşleşmeyen her kayıt için SQL NULL basar, Python ise bunu NaN olarak karşılar.

Gizli Tuzak: İki Farklı Dünyayı Aynı Çuvala Koymak

Veriyi doğrudan 0 ile doldurduğumuzda aslında birbirinin tamamen zıttı iki müşteri profilini modelin gözünde ikiz kardeş haline getiririz:

• Müşteri A (Sadık / Risksiz): 15 adet sipariş vermiş, ürünleri beğenmiş ve bugüne kadar 1 lira bile iade yapmamış. Gelecek ay harcama yapma potansiyeli oldukça yüksek.
• Müşteri B (İnaktif / Yeni Kayıt): Siteye aylar önce kaydolmuş ama tek bir sipariş bile vermemiş (toplam_siparis_sayisi = 0). Doğal olarak iade edecek bir ürünü de olmamış.

.fillna(0) yazdığımız an, Müşteri A ile Müşteri B'nin iade tutarı eşitlenir (0 TL). Model; sipariş geçmişi olmayan pasif bir kullanıcı ile sadık bir müşteriyi ayırt edemez ve tahminleri sistematik olarak sapar.

İş tarafında bunun faturası ağırdır: Model, hiç alışveriş yapmamış pasif kitleye yanlışlıkla yüksek harcama potansiyeli biçerek pazarlama ve kampanya bütçesinin yanlış hedef kitleye akmasına yol açar.

Eksiklik Bir Hata Değil, Bir Davranıştır

Bazı veri setlerinde eksiklik bir sistem hatası değil, doğrudan bir kullanıcı davranışının sonucudur. Örneğimizde iade verisinin eksik olması, veri setindeki başka bir gözlemlenebilir değişkene — yani kullanıcının sipariş geçmişine — doğrudan bağıntılıdır.

İstatistik dünyasında bir değişkendeki eksikliğin veri setindeki başka bir sütuna bağlı olması durumu MAR (Missing at Random — Rastgele Eksiklik) olarak adlandırılır. Yani bir hücrenin boş kalması tesadüf değildir; kullanıcının henüz o aksiyonu almadığını gösteren güçlü bir ipucudur. Siz o boşluğu varsayımsal bir sıfırla doldurduğunuz an, sistemi uyaran bu değerli ipucunu silip gerçek verilerin arasına karıştırmış olursunuz.

Peki Doğrusu Ne Olmalıydı?

1. Koşullu Doldurma (Conditional Imputation) Tüm kolona körü körüne 0 basmak yerine iş kuralını filtreleyerek uygulayın. Siparişi olanlara 0 atarken, siparişi olmayanları NaN olarak bırakın ki model bu iki grubu birbirinden ayırabilsin:

# Sadece siparişi olup iadesi olmayanlara 0 ver, siparişi olmayanlar NaN kalsın
has_orders = df['toplam_siparis_sayisi'] > 0
df.loc[has_orders & df['iade_edilen_urun_tutari'].isna(), 'iade_edilen_urun_tutari'] = 0

2. Kayıp Bilgisini Özelliğe Çevirmek (Indicator Flags) Eksikliği modelin doğrudan okuyabileceği yeni bir değişkene dönüştürün. Örneğin hic_siparis_verdi_mi (0/1) veya iade_verisi_eksik_mi gibi ikili (flag) kolonlar türeterek modele sinyali açıkça verin.

3. Ağaç Tabanlı Modellerin Gücünü Kullanmak XGBoost, LightGBM veya CatBoost gibi modern algoritmalar NaN değerlerini varsayılan olarak yerel şekilde yönetebilir. Boşlukları zorla ezmek yerine ağacın o eksikliği kendi karar kuralı (split) olarak öğrenmesine izin verin.

Sonuç

Veri setinde kayıp gözlemlerle karşılaştığımızda bunun otomatik bir doldurma işlemi değil, verilmesi gereken stratejik bir karar olduğunu unutmamalıyız. Bir sonraki adıma geçmeden önce kendimize şu kritik soruyu sormalıyız:

“Bu bilgi gerçekten bilinmediği veya sistemde kaybolduğu için mi eksik, yoksa iş kuralı gereği zaten boş mu olması gerekiyor?”

“Müşterilerin toplam harcamasına bak, 10 bin TL’nin üzerindekilere VIP, altındakilere Standart yaz.”

Geliştirici koltuğuna oturan pek çok kişinin ilk hamlesi bellidir: Koşulu yapıştır ve geç. Rapor çalışıyor mu? Çalışıyor, olay bitmiştir.

Peki, karar verirken kendimize şu soruyu soruyor muyuz? Elimizde bulunan veri seti için kategorize etmek amacıyla kurgulanacak mantığın nasıl yazılması gerektiğini gerçekten biliyor muyuz?

Mesele DAX fonksiyonunu veya formülü yazabilme becerisi değil; esas mesele, kategorilendirme yaparken verinin doğasını bilmektir.

Eğer yapacağınız kategorilendirme; raporda seçilen yıla, seçilen tarih aralığına veya uygulanan diğer filtrelere bağlı olarak değişiyorsa ya da zamanla verinin kendisi güncellendiği için farklı sonuçlar veriyorsa başka bir yol izlemelisiniz. Aksi bir durum söz konusu ise, yani mantık tamamen sabitse, hareket tarzınız bambaşka olmalıdır.

Kısacası, klavyeye basmadan önce vereceğiniz ilk ve en kritik karar şudur: Yazacağımız bu mantık statik mi olmalı, yoksa dinamik mi?

İşte Power BI modellemesinde işler tam burada çatallaşır. Mimari başarının sırrı şu iki net kuralda yatar:

“Statikse Power Query, dinamikse DAX Ölçüsü!”

1. Statik Durumlar: “Veri güncellenince bu etiket değişiyor, o zaman dinamik değil mi?” Tuzağı

Geliştirici olarak hemen şöyle düşünebilirsin:

“Müşterinin geçen ayki toplam harcaması 5 bin TL’ydi ve Standart’tı. Bu ay yeni siparişler girdi, yaşam boyu harcaması (LTV) 10 bin TL’yi geçti ve etiket VIP oldu. Veri yenilendikçe bu etiket değişiyor, demek ki bu dinamik!”

İşte en büyük zihinsel tuzak burasıdır.

Veri kaynağının her gece güncellenmesi (Scheduled Refresh) veya “Ödendi / Ödenmedi” gibi durumların zamanla değişmesi, o kuralı dinamik yapmaz. Kural buz gibi sabittir: Müşterinin tüm zamanlardaki harcaması > 10.000 TL ise VIP yaz.

Veri yenilendikçe Power Query bu sabit kuralı yeni satırlara bir kez basar ve geçer. Bu işlem, verinin o anki fotoğrafıdır. Madem etiket sabit bir kurala dayanıyor, bunu raporda kullanıcı her tıkla etkileşime girdiğinde anlık hesaplatıp CPU’yu ve hafızayı yormanın alemi yok. İşlem Power Query (M Kodu) katmanında çözülüp modele öyle yüklenmelidir. Bu yaklaşım, Power BI’ın sıkıştırma motorundan (VertiPaq) maksimum performans almanızı sağlar ve rapor açılış hızını uçurur.

2. Dinamik Durumlar: “Kuralın Kendisi Kullanıcının Elindeyse”

Peki olay ne zaman DAX Ölçüsü (Measure) olmak zorundadır?

Diyelim ki rapora bir tarih dilimleyicisi (Slicer) koydunuz. Kullanıcı rapordan “Sadece 2026 yılı” veya “Son 3 Ay” seçimini yaptı. Amacınız da müşterinin seçilen bu spesifik tarih aralığındaki harcamasına göre VIP olup olmadığını bulmak.

Ya da patron rapora geldi ve slicer’dan:

“Bakalım müşteriler son 3 ayda mı pasifleşmiş, yoksa son 6 aya vites büyütürsek tablo nasıl değişiyor?” diye sordu.

Kullanıcı ekrandaki filtreleri değiştirdiği veya o çubuğu 3 aydan 6 aya çektiği an, riskli müşteri tanımı da VIP müşteri listesi de anlık olarak değişmek zorundadır. Bunu gidip veri yüklenirken Power Query’de tablonun içine sabit bir sütun olarak yazamazsınız; çünkü Power Query kullanıcının ekranda neyi seçeceğini (Filter Context) önceden bilemez.

Karar Rehberi: Klavyeye Basmadan Önce Kendine Sor

• Müşterinin tüm zamanlardaki (LTV) 10k üzeri harcaması: Kullanıcı ekran filtresinden bağımsız sabit bir veri kuralıdır. → Statik (Power Query)
• “Ödendi / Ödenmedi” bilgisi: Veri yenilendikçe durumu değişse de mantık kuralı sabittir. → Statik (Power Query)
• Takvimdeki “Son 3 Ay” etiketi: Çıpan sabittir (TODAY()), kullanıcı slicer’ına göre şekil değiştirmez. → Statik (Power Query / Tarih Tablosu)
• Seçilen tarih aralığına göre 10k üzeri harcayan müşteri: Kullanıcı slicer’dan tarihi değiştirdikçe etiket anlık değişmelidir. → Dinamik (DAX Ölçüsü)
• Kullanıcının değiştirdiği eşiklere göre (örn. 3 ay vs 6 ay pasiflik) değişen risk analizi: Kullanıcı ekranda parametreyle oynadıkça anlık yeniden hesaplanır. → Dinamik (DAX Ölçüsü)
• Tarih Dilimleyicisi (Slicer) ile esnek zaman analizleri: Kullanıcının serbest seçimlerine dayalı kıyaslamalar (SAMEPERIODLASTYEAR vb.). → Dinamik (DAX Ölçüsü)

Sonuç olarak; harika bir Power BI mimarisi, sadece karmaşık DAX formülleri yazmakla değil; doğru hesabı doğru katmanda yapma disipliniyle inşa edilir.

Bir dahaki sefere modele yeni bir mantık eklemeden önce durun, klavyeden elinizi çekin ve kendinize şu kritik soruyu sorun:

“Ben şu an verinin anlık bir fotoğrafını mı çekiyorum (Statik / Power Query), yoksa kullanıcının her hareketine göre akan bir video mu kaydediyorum (Dinamik / DAX Ölçüsü)?”

Bu soruya vereceğiniz yanıt, sadece raporunuzun performansını değil, mimarinizin kaderini belirleyecek.

Veri temizleme ve keşifsel veri analizi yaparken hepimizin beklediği o klasik mutlu an vardır: df.isnull().sum() çalıştırırsınız ve karşınıza tertemiz bir tablo çıkar: 0 eksik veri! İçiniz rahatlar, her şeyin yolunda olduğunu düşünürsünüz.

Oysa veri dünyasında asıl tehlike, sistemin çığlık attığı hatalar değil; sessizce işleyen hatalardır. Ve o sinsi sıfırlarla ilk kez yüzleştiğinizde anlarsınız ki: Her 0 bir sayı değildir.

Örnek vermek gerekirse bazı veri setlerinde yaş değişkeni mevcuttur ve Python programlama ile df.describe() kodu yazıldığında değişkenlerin sahip oldukları değer aralıklarını incelerken yaş değişkeninin minimum değerinin 0 olduğunu görürüz. Bazen veride yaş değişkeninin içerisinde 0 yer almasının normal olduğunu varsayarız; peki ya varsayımlarımız bizi tehlikeye götürüyorsa? Gerçekten elimizdeki veriden yola çıkarak yaş değişkeninin içerisinde 0 olabilme ihtimali söz konusu mudur? Hangi kitleden yola çıkarak örneklem topladığımızın bilincinde miyiz?

Gelin, veride yer alabilecek o 4 farklı “Sıfır” türüne bakalım.

1. Yalancı Sıfır

En tehlikeli tür tam olarak budur. Kullanıcı bir web formunda yaşını, aylık gelirini veya harcama tutarını boş bıraktığında; arka taraftaki yazılım hata fırlatmasın diye ilgili kişiler bu alanı veritabanına 0 olarak kaydeder.

Siz Python’da df.isnull().sum() çalıştırırsınız. Çıktı tertemizdir: 0 eksik veri!

Ancak bir müşteri grubunun ortalama gelirini hesaplamaya kalktığınızda, geliri bilinmeyen binlerce kişi 0 TL kazanıyormuş gibi hesaba katılır. Sonuç? Ortalama yerle bir olur, makine öğrenmesi modeliniz yanlış ağırlıklar öğrenir ve şirket tamamen yanlış bir stratejiye saplanır.

2. Gerçek Sıfır

Bu, hepimizin sevdiği ve aradığı masum sıfırdır.

• Müşterinin hesabındaki bakiye gerçekten 0 TL'dir.
• Bugün mağazadan 0 adet ürün satılmıştır.

Gerçek bir ölçümdür, nicel bir değer taşır ve istatistiksel hesaplamalara (ortalama, standart sapma vb.) gönül rahatlığıyla dahil edilebilir.

3. Yapısal Sıfır

Bu sıfır, bir olayın gerçekleşmediğini değil; gerçekleşmesinin mantıken imkansız olduğunu söyler.

Örneğin, bir sağlık verisetinde erkek bir hastaya “Geçirilen Hamilelik Sayısı” sorulduğunda cevabın 0 olması gibi. Bu kişi "0 hamilelik geçirdi" demek doğru değildir; bu soru bu hasta için kavramsal olarak geçersizdir. Bu sıfırları, normal sayısal sıfırlarla aynı çuvala atmak modeli tamamen mantık dışı kararlara sürükler.

4. Mantıksal / Kategori Sıfırı

Bir durumun varlığını veya yokluğunu gösteren sıfırdır.

• Sözleşmeyi kabul etti mi? 1 (Evet) / 0 (Hayır).
• Premium üye mi? 1 / 0.

Bu sıfır bir “sayı” değildir, bir etikettir. Ancak analiz yaparken bu sütunu yanlışlıkla sayısal bir değişken sanıp esasında kategorik bir değişken olduğunu fark etmezseniz, veriye tamamen yanlış bir açıdan bakmış olursunuz.

Şimdi Kontrol Sırası Sizde

Bu yazıyı okumayı bitirdikten sonra yapacağınız ilk iş ne olmalı biliyor musunuz? Şu an üzerinde çalıştığınız projeyi veya çalıştığınız firmanın sahip olduğu veri setlerini açın, veri setinizdeki sıfırları value_counts() ile önünüze dizin ve kendinize şu soruyu sorun:

“Bu sıfır gerçekten matematiksel olarak gerçekten olması gereken bir sıfır mıdır, yoksa anlık bir karar ile gözden kaçma ihtimali olabilecek bir varsayım yanılsaması mı?”

Çünkü veriyi sadece keşfetmek ve temizlemek yetmez; verinin kalitesinin ve doğru veri ile çalışıldığının teyit edilmesi gerekir; ayrıca verinin arkasındaki hikayeyi ve niyeti anlamak gerekir.