Proje vitrini hazırlanıyorPreparing project showcaseПодготавливаем витрину проекта

Raporlama & Analitik

Raporu düz dille sormak: SQL bilmeden veri çekmek

Bir cümlelik soru nasıl rapora dönüşüyor, hangi sorular düz dille yanıtlanır ve ekrana gelen sayının doğruluğunu toplantı öncesi üç adımda nasıl denetlersiniz?

Rocketly · 2026-09-05

Salı sabahı 09.12. Yönetim toplantısına on sekiz dakika var ve pazarlama sorumlusu tek bir sayıya ihtiyaç duyuyor: geçen çeyrek hangi kaynaktan gelen lead'ler kaç liralık kazanılmış fırsata dönüştü. Sayı veritabanında duruyor, kimse saklamıyor; ama ona ulaşmanın bilinen iki yolu var. Ya bir analistten rica edeceksiniz, cevap öğleden sonra gelir; ya üç ayrı raporu dışa aktarıp elektronik tabloda yan yana koyacaksınız, o da kırk dakika sürer. Sorumlu üçüncü yolu deniyor: kutuya “bu çeyrek kaynağa göre kazanılan tutar” yazıyor ve birkaç saniye sonra ekranda kaynak başına bir sütun grafik beliriyor. Buradaki süreler ve rakamlar örnektir. Asıl soru şu: o birkaç saniyede tam olarak ne oldu, gelen cevaba toplantıda hangi ölçüde güvenilebilir?

Bu yazı düz dille rapor sormanın nasıl çalıştığını, hangi sorularda gerçekten işe yaradığını ve hangi noktada elle kurulmuş bir rapora ya da veri ambarına devretmek gerektiğini anlatıyor. Önce bir cümlenin sorguya çevrilme adımlarını ele alacağız, sonra aynı sorunun neden birden fazla doğru cevabı olabildiğini. Ardından iyi bir sorunun dört parçasını, gelen yanıtı doğrulama yöntemlerini, veri modelinizin soru kapasitenizi nasıl sınırladığını ve tekrar eden soruların kalıcı görünüme nasıl dönüştüğünü göreceğiz. Sonda yetki sınırları, ekibe yerleştirme ve sık sorulan sorular var.

Bir soru cümlesi rapora dönüşürken arada ne oluyor?

Düz dille sorma özelliği sihir yapmıyor; iyi tanımlanmış bir çeviri işi yapıyor. Yazdığınız cümle önce parçalarına ayrılıyor: hangi büyüklük ölçülecek, hangi kayıt kümesi üzerinde, hangi tarih alanına göre, hangi alana göre gruplanacak. Bu dört parça belirlendikten sonra sistem sizin adınıza yapısal bir sorgu kuruyor ve sonucu grafikle döndürüyor. Rocketly'de Düz Dille Sor alanı tam olarak bu adımı yapar: “bu çeyrek kaynağa göre kazanılan tutar” cümlesini metrik, dönem ve kırılım olarak çözer, sorguyu üretir, sonucu görselleştirir.

Aradaki farkı görmek önemli. Bir arama kutusu size eşleşen kayıtları listeler; düz dil sorgusu ise kayıtları toplar, gruplar ve bir büyüklük üretir. “Ahmet Yılmaz” yazdığınızda kişi kartı gelir; “temsilciye göre bu ay kapanan anlaşma sayısı” yazdığınızda ortada tek bir kayıt yoktur, hesaplanmış bir tablo vardır. İkincisi bir raporlama işidir ve arka planda bir sorgu çalışır. CRM verisine doğal dilde soru sormanın mekaniğini ayrı bir yazıda daha ayrıntılı ele aldık; buradaki odağımız bu mekaniğin rapor üretirken nerede tökezlediği.

Çeviri katmanının en kırılgan yeri belirsizliktir. “Geçen ay” ifadesi takvim ayı mı, son otuz gün mü? “Satış” kesilen fatura mı, kazanılan fırsat mı? Bu belirsizlikler cümlede çözülmezse sistem bir varsayım yapar ve size o varsayımın cevabını verir. Cevap teknik olarak doğrudur ama sorduğunuz soru değildir. Bu yüzden düz dille sormayı öğrenmek, aslında kendi metrik tanımlarınızı netleştirmeyi öğrenmektir.

Neden “geçen ay ne sattık?” sorusunun tek bir doğru cevabı yok?

Aynı ekipte üç kişiye bu soruyu sorun, üç farklı sayı gelir. Satış müdürü kazanılan fırsatların toplam tutarını söyler. Ön muhasebe kesilen fatura toplamını verir. Finans yalnızca tahsil edileni sayar. Üçü de dürüsttür; farklı olay tanımlarını ölçüyorlardır. Fırsat kazanıldığı gün, fatura kesildiği gün ve para hesaba geçtiği gün genellikle aynı ay içinde bile olmaz.

Tarih alanı seçimi de aynı biçimde ayrıştırıcıdır. Bir fırsatı oluşturulma tarihine göre saydığınızda pazarlamanın o ayki üretimini ölçersiniz; kapanış tarihine göre saydığınızda satışın o ayki hasadını. İki grafiğin şekli birbirini tutmaz ve tutmaması gerekir. Satış raporunun hangi KPI etrafında kurulacağına karar vermeden düz dille soru sormak, cevabı hızlandırır ama tartışmayı bitirmez.

Pratik çözüm, ekip içinde üç dört temel metriği yazılı olarak tanımlamaktır: kazanılan tutar, dönüşüm oranı, ortalama anlaşma büyüklüğü ve satış döngüsü süresi. Her birinin hangi kayıt kümesinden, hangi tarih alanıyla hesaplandığı bir kez kararlaştırılır. Bundan sonra düz dille sorulan sorular aynı tanıma oturur ve iki kişinin ekranındaki sayı ayrışmaz. Tanım yoksa hız, yanlış anlaşmanın da hızı olur.

İyi bir soruyu oluşturan dört parça nedir?

Cevabı isabetli gelen sorular hemen her zaman dört bileşeni açıkça taşır. Birincisi metrik: tutar mı, adet mi, oran mı, ortalama mı. “Satışlar” bir metrik değildir; “kazanılan fırsat tutarı” metriktir. İkincisi dönem: bu çeyrek, son otuz gün, ocak ayı. Dönem yazılmazsa sistem bir varsayılan uygular ve genellikle bu varsayılan sizin aklınızdakinden geniş olur.

Üçüncüsü kırılım, yani sonucun neye göre gruplanacağı: kaynağa göre, temsilciye göre, ürüne göre, aşamaya göre. Kırılım yazmazsanız tek bir sayı alırsınız; bu bazen istediğiniz şeydir ama çoğu zaman karar için yetmez. Dördüncüsü süzgeç: yalnızca kurumsal segment, yalnızca İstanbul, yalnızca belirli bir kampanyadan gelenler. Süzgeç sonucu daraltır ve kıyaslanabilir hale getirir.

Bu dördünü tek cümlede toplamak alışkanlık meselesidir. “Kurumsal segmentte, bu çeyrek, kaynağa göre kazanılan fırsat tutarı” cümlesi dördünü de taşır ve tek seferde doğru yanıtlanır. Aynı ihtiyacı “kurumsalda işler nasıl gidiyor” diye sorduğunuzda, sistemin verdiği cevabın sizin sorunuz olma ihtimali düşüktür. Sorunun kalitesi, cevabın kalitesini doğrudan belirler.

Hangi sorular düz dille iyi yanıtlanır, hangileri yanıtlanmaz?

Düz dil arayüzünün gerçek bir kapsamı vardır ve bu kapsamı bilmek zaman kazandırır. Genel kural şudur: toplama, sayma ve tek boyutlu gruplama iyi çalışır; çok adımlı türetmeler, kohort hesapları ve nedensellik soruları çalışmaz. Aşağıdaki tablo, bir soruyu yazmadan önce hangi kulvarda olduğunuzu kestirmenize yarar.

Soru tipiÖrnek cümleBeklenen sonuç
Tek metrik, tek dönem“Bu ay kazanılan fırsat tutarı”Doğrudan yanıtlanır, tek sayı döner
Metrik + tek kırılım“Bu çeyrek kaynağa göre kazanılan tutar”Doğrudan yanıtlanır, grafikle döner
İki kırılımlı çapraz“Temsilci ve kaynak kırılımında dönüşüm”Kısmen; ikinci kırılımı süzgece çevirin
Kohort veya süre hesabı“İlk temastan ilk satışa geçen ortalama gün”Hazır rapor ya da özel rapor oluşturucu daha isabetli
Neden sorusu“Satışlar neden düştü?”Sayıyı getirir, nedeni siz kayıtlardan okursunuz
Sistem dışı veri“Reklam harcamasına göre geri dönüş”Harcama verisi CRM'de yoksa yanıt boş döner

Tablonun son iki satırı özellikle önemli. Düz dil arayüzü olmayan veriyi üretemez; yalnızca sizin sisteminizde duran kayıtları toplar. Reklam maliyeti, üretim gideri veya kargo verisi CRM'e akmıyorsa, o soruyu nasıl yazarsanız yazın cevap gelmez. Bu bir eksiklik değil, sınırın doğru yerde olmasıdır.

Gelen cevabın doğru olduğunu nasıl anlarsınız?

Hızlı cevabın en büyük riski, kontrol edilmeden slayta girmesidir. Bu yüzden düz dille alınan her sayının üç kontrolden geçmesi gerekir: tanım, tazelik ve kayıt. Tanım kontrolü, sayının hangi kayıtlardan hesaplandığını okumaktır. Metodoloji Paneli her metriğin yanında bu bilgiyi yazar: hangi kaynak, hangi süzgeç, hangi tarih alanı. Toplantıda “bu gelir neyi kapsıyor” sorusu geldiğinde cevap tahminle değil ekrandan verilir.

Tazelik kontrolü ikinci adımdır. Veri Tazeliği Göstergesi her kartın verisinin en son ne zaman güncellendiğini söyler; canlı pano sekme açıkken düzenli aralıklarla kendini tazeler ve yenile düğmesi önbelleği atlayıp veriyi yeniden çeker. Önbellekten gelen eski bir sayıyı taze sanmak, yanlış sayı kadar zararlıdır. Üçüncü adım kayıt kontrolüdür: Derin Analiz ile grafikteki bir dilime tıklayıp arkasındaki kayıtların sayfalanmış listesine inersiniz. Yirmi saniyelik bu bakış, sayının makul olup olmadığını çoğu zaman anında gösterir.

Bir de sunum katmanı var. Doğru hesaplanmış bir sayı, yanlış ölçekli bir eksende veya kırpılmış bir sütun grafikte olduğundan büyük görünebilir. Grafiği yalan söyletmeden kurmanın ilkeleri düz dille üretilen çıktılar için de geçerlidir; hızlı gelen bir grafik, denetlenmemiş bir grafik demek değildir.

Veri modeliniz sorabileceğiniz soruları nasıl sınırlıyor?

Düz dil arayüzünün tavanını dil değil, veri yapısı belirler. “Sektöre göre ortalama anlaşma büyüklüğü” sorusunun cevabı, firma kayıtlarında sektör alanı doluysa vardır; boşsa yoktur. Kayıtlar arasındaki ilişkiler de aynı ölçüde belirleyicidir: fırsatın hangi firmaya, firmanın hangi kişiye bağlandığı net değilse, kırılımlı sorular yarım döner. Kişi, firma ve fırsat arasındaki ilişkileri düzgün kurmuş bir sistemde sorabileceğiniz soru sayısı katlanarak artar.

İkinci sınır veri kalitesidir. Aynı kaynağın “Google”, “google ads” ve “Google Ads” olarak üç ayrı değerle kaydedilmesi, kaynak kırılımlı her grafiği üçe böler ve sonucu sessizce bozar. Bu tür bozulmalar hata vermez; sadece yanlış bir tablo üretir. Temiz ve doğrulanmış müşteri verisi için seçim listesi kullanmak, serbest metin alanlarını azaltmak ve giriş anında doğrulama koymak, düz dille sorulan her sorunun isabetini doğrudan yükseltir.

Üçüncü sınır kapsamdır. Müşterilerinizin bir kısmı hala elektronik tabloda, bir kısmı eski bir listede duruyorsa, sorduğunuz her soru yalnızca sistemdeki kesiti yanıtlar. Müşteri veri tabanını tek yerde toplamak, raporlamanın önkoşuludur; dağınık veriyle çalışan bir sorgu motoru en fazla dağınıklığı hızlıca gösterir.

Aynı soruyu her hafta yeniden sormak yerine ne yapmalı?

Düz dille sorma, keşif için mükemmel; rutin için israftır. Bir soruyu ikinci kez soruyorsanız o artık bir soru değil, bir rapordur. Doğru hamle onu kalıcılaştırmaktır. Kaydedilmiş Rapor Görünümleri süzgeç, tarih aralığı, gruplama ve sütun düzeninden oluşan kombinasyonu tek bir görünüm olarak saklar ve ekiple paylaşır. Aynı kesiti her pazartesi yeniden tarif etmek yerine kaydettiğiniz görünümü açarsınız.

Bir adım ötesi gönderimdir. Zamanlanmış Rapor ile günlük, haftalık veya aylık bir saat belirlersiniz; rapor PDF ya da Excel olarak alıcı listesine e-postayla düşer. Bu, raporu isteyen kişinin sisteme girme zorunluluğunu ortadan kaldırır ve “bana şu sayıyı atar mısın” trafiğini bitirir. Eşik takibi için Rapor Alarm Kuralları vardır: hangi metrik, hangi eşik, hangi dönem ve bildirimin kime gideceği sizin tanımınıza göre çalışır.

Bazı ekipler sonucu kendi çalışma dosyalarında görmek ister. Böyle durumlarda raporu PDF, Excel ya da CSV olarak indirmek yerine CRM ile elektronik tablo arasında düzenli bir senkronizasyon kurmak daha sürdürülebilirdir; elle indirilen her dosya, indirildiği andan itibaren eskimeye başlar.

Düz dil ne zaman yetmez, ne zaman rapor oluşturucuya geçilir?

Üç işaret gelir. Birincisi, aynı soruyu düz dille üç kez sorup üç kez farklı sonuç almanız; bu, sorunun tarifinin cümleye sığmadığını gösterir. İkincisi, cevabı aldıktan sonra düzenli olarak dışa aktarıp elle düzeltmeniz. Üçüncüsü, sorunun içinde “ve ayrıca”, “hariç”, “şu koşulda” gibi birden fazla kural bulunması. Bu üç durumda Özel Rapor Oluşturucu daha doğru araçtır: lead, müşteri, fırsat, teklif, görev ve randevu kaynaklarından alan, süzgeç, gruplama ve toplama seçerek raporu bir kez kurarsınız ve tanım artık cümlede değil yapıdadır.

Sorunuz CRM dışındaki sistemleri de kapsıyorsa sınır büsbütün değişir. Reklam maliyetini, ürün maliyetini veya web analitiğini satış verisiyle aynı grafikte görmek istiyorsanız, bu bir raporlama değil bir birleştirme işidir. CRM verisini bir veri ambarına ve BI aracına taşımak bu noktada devreye girer; düz dil arayüzünü zorlamak yerine veriyi doğru katmanda buluşturursunuz.

Pazarlama tarafında birden fazla kanaldaki müşteri davranışını tek profilde birleştirme ihtiyacı varsa, tartışma bambaşka bir araç sınıfına kayar. Müşteri veri platformunun CRM'den farkı tam da burada belirginleşir: biri ilişkiyi ve satışı yönetir, diğeri davranış verisini birleştirir. Her ikisini de tek bir soru kutusundan beklemek gerçekçi değildir.

Herkes her sayıyı sorabilmeli mi?

Soru kutusunu açmak, veriyi herkese açmak anlamına gelmez. Yetkiye Göre Kapsam ilkesi burada işler: rapor, onu çalıştıran kişinin görebildiği satırları gösterir. Ekip kapsamlı bir kullanıcı yalnızca kendi ekibinin verisini alır; düz dille sorduğunda da aynı sınır geçerlidir. Yani arayüz değişse de kapsam değişmez, bu da düz dil arayüzünü kurumsal ortamda güvenli kılan asıl unsurdur.

İkinci konu paylaşımdır. Paylaşılan Rapor Linki ile bir raporu giriş gerektirmeyen bir bağlantıyla dışarı verebilirsiniz; parola, son kullanma tarihi ve görüntüleme limiti koyarak istediğiniz an kapatırsınız. Bu esneklik, paylaşılan bağlantının kimde durduğunu takip etme sorumluluğunu da getirir; süresiz link, süresiz erişim demektir.

Üçüncüsü verinin nerede işlendiği sorusudur. Sorgu motoru, cevabı üretirken kayıtları bir yerde işler; bu yerin hangi ülkede olduğu birçok sektörde sözleşmesel bir konudur. Verilerin fiziksel olarak nerede durduğu, düz dil arayüzü kadar temel bir soru olarak masada kalır ve satın alma sürecinde sorulur.

Bu alışkanlık ekibe nasıl yerleşir?

En hızlı yol, ilk haftada herkesin kendi işine ait üç soruyu yazmasıdır. Satış temsilcisi kendi hattındaki fırsatları, pazarlama kanal performansını, yönetici ekip toplamını sorar. Bu üç soru kaydedilmiş görünüme dönüştüğünde alışkanlık kendiliğinden yerleşir; kimse eğitim dokümanı okumaz, çalışan bir örneği kopyalar.

İkinci adım, ortak bir soru sözlüğü tutmaktır: işe yarayan cümleleri olduğu gibi bir yerde biriktirin. “Bu çeyrek kaynağa göre kazanılan tutar” cümlesi bir kez doğru cevap verdiğinde, aynı kalıp ürün, temsilci ve bölge için de çalışır. Sözlük büyüdükçe ekibin soru kalitesi yükselir ve destek talebi düşer. Hazır rapor kütüphanesi de bu sözlüğü besler: kütüphanedeki bir raporun tarifini okumak, aynı sorunun nasıl kurulduğunu öğretir.

Üçüncü adım ölçmektir. Ay sonunda kaç sorunun kaydedilmiş görünüme, kaçının zamanlanmış rapora dönüştüğüne bakın; bu iki sayı, ekibin veriye ulaşma biçiminin gerçekten değişip değişmediğini gösterir. Kendi verinizle denemek isterseniz Rocketly hesabınızı ücretsiz açıp ilk sorunuzu kendi kayıtlarınız üzerinde sorabilirsiniz.

Sıkça sorulan sorular

Düz dille sormak için SQL veya rapor bilgisi gerekiyor mu?

Hayır. Gereken tek şey metriği, dönemi ve kırılımı cümlede söylemektir. “Bu çeyrek kaynağa göre kazanılan tutar” gibi bir cümle yeterlidir; sorguyu sistem kurar. Ancak metriğin ne anlama geldiğine ekibin karar vermiş olması gerekir.

Gelen cevabın yanlış olduğunu nasıl fark ederim?

Metodoloji panelinden sayının hangi kayıt kümesi ve tarih alanıyla hesaplandığını okuyun, veri tazeliği göstergesinden güncelliğini kontrol edin, sonra grafikteki bir dilime tıklayıp arkasındaki kayıtlara inin. Üç kontrol birkaç dakika sürer ve yanlış sayıların çoğunu burada yakalarsınız.

Sorduğum soru boş dönerse ne yapmalıyım?

Önce dönemi genişletin, sonra süzgeci kaldırın, en son kırılımı sadeleştirin. Hala boşsa aradığınız veri sistemde tutulmuyor olabilir; reklam maliyeti gibi dış veriler bunun tipik örneğidir.

Aynı raporu her hafta almak için ne yapmalıyım?

Soruyu bir kez sorup sonucu kaydedilmiş görünüm olarak saklayın, ardından zamanlanmış rapor kurun. Rapor belirlediğiniz gün ve saatte PDF ya da Excel olarak alıcı listesine e-postayla gider; kimsenin sisteme girmesi gerekmez.