Merkezi Raporlama Ne Çözer (Ve Ne Çözmez)\n\nMerkezi raporlama, zaten kullandığınız araçlardan (CRM, faturalama, pazarlama, destek, ürün analitiği) verileri alıp herkesin aynı sayıları—aynı şekilde tanımlanmış—görebileceği tek bir yere çekmek demektir; panolar bir takvime göre güncellenir.\n\nUygulamada, “hesap tablosu bayrak yarışını” paylaşılan bir sistemle değiştirir: bağlayıcılar veriyi alır, bir model onu standartlaştırır ve panolar her hafta birinin raporu yeniden kurmak zorunda kalmadan tekrarlayan soruları yanıtlar.\n\n### Çözdüğü sorunlar\n\nÇoğu ekip aynı nedenlerle bir raporlama uygulaması inşa eder:\n\n- Manuel dışa aktarımlar ve kopyala/yapıştır iş akışları. CSV indirmeler, VLOOKUP'lar ve “o raporu tekrar gönderir misin?” talepleri zaman kaybettirir.\n- Tutarsız metrikler. İki pano farklı “MRR” gösterir çünkü her kişi farklı hesaplamıştır (veya zaman aralıklarını farklı filtrelemiştir).\n- Silo halinde erişim. Pazarlama gelir sonuçlarını göremez, Satış destek eğilimlerini göremez ve liderler çoklu ekipten sormadan uçtan uca görünüm elde edemez.\n- Yavaş yanıtlar. Basit sorular günler alır çünkü veriler farklı sistemlerde dağılmıştır, farklı kişiler tarafından sahiplenilmiş ve hiçbir yerde birleştirilmemiştir.\n\nMerkezileştirme ayrıca hesap verebilirliği artırır: metrik tanımları tek bir yerde yaşadığında, bir sayının ne zaman ve neden değiştiğini görmek daha kolay olur.\n\n### Liderlerin Gerçekten Sorduğu Araçlar Arası Sorular\n\nKaynakları birleştirebildiğinizde, tek araç panolarının yanıtlayamadığı soruları cevaplayabilirsiniz, örneğin:\n\n- “Pipeline büyümesi reklam harcamalarıyla uyumlu mu ve hangi kampanyalar gerçekten kapanan anlaşmalar üretiyor?”\n- “Destek ticket'ları ve ilk yanıt süresi, takip eden ay churn veya düşüşle ilişkilendiriliyor mu?”\n- “Hangi müşteri segmentleri en yüksek ürün kullanımına sahip ama en düşük yenileme oranına sahip ve CRM'de Satış ne görüyor?”\n- “Kullanım arttığında SLA'larımızı karşılıyor muyuz ve bu NPS veya iadeleri etkiliyor mu?”\n\n### Çözmediği şeyler\n\nMerkezi raporlama, yukarı kaynaklı problemleri tek başına düzeltemez:\n\n- Kötü kaynak verisi. CRM'de çoğaltılmış hesaplar veya eksik kapanış tarihleri varsa, temizlenene kadar uygulamanız bunu yansıtır.\n- Eksik izleme. Önemli ürün olaylarını takip etmiyorsanız, hiçbir pano bunları sonradan türetemez.\n- Belirsiz sahiplik. “Aktif kullanıcı” veya “nitelikli lead” gibi tanımlara kimse sahip değilse, merkezileştirme anlaşmazlığı görünür kılacaktır ama ortadan kaldırmaz.\n\nAmaç, birinci günde kusursuz veri değil. Amaç, zaman içinde raporlamayı tutarlı, tekrarlanabilir şekilde geliştirmek ve cevap almaya dair günlük sürtünmeyi azaltmaktır.\n\n## Kullanıcıları, Soruları ve Başarı Metriklerini Tanımlayın\n\nMerkezi raporlama, gerçek kararlar etrafında inşa edildiğinde işe yarar. Bağlayıcı yazmadan veya araç seçmeden önce uygulamanın kimin için olduğunu, ne öğrenmeye çalıştıklarını ve projenin başarılı sayılacağını açıkça belirleyin.\n\n### Birincil kullanıcıları belirleyin\n\nÇoğu raporlama uygulaması birden çok kitleye hizmet eder. Onları açıkça adlandırın ve her grubun verilerle ne yapması gerektiğini yazın:\n\n- Liderlik: şirket sağlığını takip etme, riskleri görme, performans eğilimlerini inceleme.\n- Operasyon: throughput'u izleme, SLA uyumu, süreç darboğazları.\n- Finans: gelir/maliyet uzlaştırma, tahmin, sayıların doğrulanması.\n- Satış: pipeline görünürlüğü, dönüşüm oranları, temsilci performansı.\n- Destek: ticket hacmi, çözüm süresi, müşteri duyarlılığı.\n- Analistler: esnek keşif, dışa aktarımlar, tutarlı metrik mantığı.\n\nHer grup için bir panoyu bir cümlede açıklayamıyorsanız, onu oluşturmaya hazır değilsiniz demektir.\n\n### En önemli raporlama sorularını yakalayın\n\nİnsanların tekrar tekrar sordukları “en iyi 10” soruyu toplayın ve her birini bir kararla ilişkilendirin. Örnekler:\n\n- “Geçen hafta gelir neden düştü?” → fiyatlandırma, harcama veya outreach'i ayarlama kararı.\n- “Hangi kanallar en kaliteli leadleri getiriyor?” → bütçe yeniden tahsisi.\n- “SLA'mızı karşılıyor muyuz?” → personel ve yükseltme kararları.\n\nBu liste sizin backlog'unuz olur. Bir kararla bağlantısı olmayan her şey ertelenmeye adaydır.\n\n### Başarı metriklerini tanımlayın (raporlama uygulaması için)\n\nÖlçülebilir sonuçlar seçin:\n\n- İçgörü süresi: sorudan cevaba geçen süre (dakika)\n- Benimseme: rol bazlı haftalık aktif kullanıcılar\n- Veri tazeliği: panoların ne kadar güncel olduğu (ör. saatlik, günlük)\n- Doğruluk: tanımlanmış bir gerçek kaynağa uyum (ve daha az “sayı tartışması”)\n\n### Kapsam sınırları belirleyin\n\nHangi araçların, hangi ekiplerin ve hangi zaman aralığının (ör. son 24 ay) destekleneceğini yazın. Bu, “raporlama uygulaması”nın sonsuz bir entegrasyon projesine dönüşmesini engeller.\n\nPlanlama notu: nihai inşa planı, yaklaşık 3.000 kelimelik bir uygulama rehberini destekleyecek kadar detaylı ama odaklı kalacak kadar kısa olmalıdır.\n\n## Veri Kaynaklarını ve Erişim Yöntemlerini Envanterleyin\n\nBoruları veya panoları tasarlamadan önce, gerçekte hangi verilere sahip olduğunuzu ve bunları ne kadar güvenilir çekebileceğinizi netleştirin. Bu, iki yaygın hatayı önler: yanlış “gerçek kaynak” üzerine raporlar inşa etmek ve önemli bir sistemin yalnızca aylık CSV dışa aktarabildiğini geç fark etmek.\n\n### Etki alanına göre gerçek kaynağı belirleyin\n\nHer iş alanını, sayılar uyuştuğunda hangi aracın “kazandığını” gösterecek şekilde eşleyin.\n\n- Gelir: faturalama sistemi (ör. Stripe), fatura aracı veya ERP—birini birincil olarak seçin.\n- Pazarlama: reklam platformları mi yoksa attribution aracı mı yoksa analitik mi—dönüşüm sayılacak şeyi tanımlayın.\n- Destek: yardım masası (ticket) mı yoksa CRM (hesaplar) mı—durum ve sahipliğin nerede olduğunu kararlaştırın.\n\nBunu açıkça yazın. Paydaşlar metrikleri yan yana gördüğünde saatler süren tartışmayı önler.\n\n### Dışa aktarma ve alma yöntemlerini belgeleyin\n\nHer araç için veriyi çekmenin gerçekçi yollarını kaydedin:\n\n- REST API'leri (endpoint'ler, kimlik doğrulama türü)\n- Webhook'lar (olay tipleri, yeniden denemeler, imza doğrulama)\n- Zamanlanmış CSV dışa aktarımları (teslim yeri, dosya adlandırma, şema kayması)\n- Doğrudan veritabanı erişimi (okuma replika, view'lar, ağ/VPN gereksinimleri)\n\n### Raporlamayı etkileyen kısıtları yakalayın\n\nKısıtlar yenileme sıklığını, backfill stratejisini ve hangi metriklerin mümkün olduğunu belirler.\n\n- Hız sınırları (dakika/gün), patlama davranışı dahil\n- Sayfalandırma stili ve maksimum sayfa boyutları\n- Tarihsel backfill: ne kadar geriye çekebilirsiniz ve ne kadar sürecek?\n- Veri saklama: eski kayıtlar siliniyor veya anonimleşiyor mu?\n\n### Erişim ve gizli bilgilerin yönetimini planlayın\n\nGüvenli bağlantı için gerekenleri listeleyin:\n\n- Servis hesapları vs. kullanıcı tabanlı OAuth uygulamaları\n- Token ömürleri ve yenileme tokenleri\n- Gerekli kapsamlar/izinler\n\nKimlik bilgilerini bir sır yöneticisinde saklayın (kodda veya pano ayarlarında değil).\n\n### Pratik bir kaynak matrisi oluşturun\n\nBasit bir tablo yapın: kaynak → varlıklar → gerekli alanlar → yenileme sıklığı. Örneğin: “Zendesk → tickets → created_at, status, assignee_id → her 15 dakikada bir.” Bu matris, inşa kontrol listeniz ve istekler genişlediğinde kapsam kontrolünüz olur.\n\n## Bir Mimari Seçin: ETL, ELT veya Canlı Sorgular\n\nBu seçim, sayılarınızın ne kadar “gerçek” hissettirdiğini, panoların ne sıklıkla bozulduğunu ve altyapı ve API kullanım maliyetinizi belirler. Çoğu raporlama uygulaması karışık bir kullanım sunar, ama yine de açık bir varsayılan seçmeniz gerekir.\n\n### Kullanabileceğiniz üç yaklaşım\n\n1) Canlı sorgular (talep üzerine çekme)\n\nUygulamanız her kullanıcı bir pano yüklediğinde her aracı API ile sorgular.\n\n- Tazelik: En iyi (saniye/dakika)\n- Maliyet: Aynı veriyi tekrar tekrar çekerseniz yüksek olabilir\n- Güvenilirlik: En düşük—her pano birden çok dış sistemin çalışır olmasına bağlı\n- Karmaşıklık: Orta (boru hattı yok), ama önbellekleme ve yeniden denemeler karmaşıklaşır\n- API limitleri: Riskli—panolar patlamalara neden olup hız limitlerine takılabilir\n\n2) Zamanlanmış borular (ETL/ELT ile depolamaya kopyalama)\n\nVeriyi bir takvime göre kopyalarsınız (ör. saatlik/gecelik), sonra panolar kendi veritabanınız/veri ambarınızdan sorgular.\n\n- Tazelik: Çoğu ekip için yeterli (15 dk–24 saat)\n- Maliyet: Öngörülebilir; hesaplama takviminizde gerçekleşir\n- Güvenilirlik: Yüksek—harici bir API yavaş olduğunda panolar başarısız olmaz\n- Karmaşıklık: Başlangıçta daha yüksek (bağlayıcılar, backfill'ler, şema değişiklikleri)\n- API limitleri: Artımlı senkron ve kota ile daha kolay yönetilir\n\nETL vs ELT uyumu:\n\n- ETL (yükleme öncesi dönüştürme): Depolamaya yazmadan önce temizleme/özetleme yapar. Küçük depolama faturası ve sıkı, küratörlü veri istendiğinde faydalıdır.\n- ELT (önce yükle sonra dönüştür): Ham veriyi önce bırakır, sonra ambar içinde dönüştürür. Tekrar işleme ve denetim için genellikle daha hızlı iterasyon sağlar.\n\n3) Hibrit (zamanlanmış + seçici canlı/yarın-gerçek-zamanlı)\n\nÇekirdek veri setleri zamanlanmış, ama birkaç “sıcak” widget (ör. bugünün harcaması, aktif olaylar) canlı sorgu veya daha sık senkron kullanır.\n\n- Tazelik: Önemli yerlerde çok iyi\n- Maliyet: Dengeli—yakın-gerçek zamanlıyı isteğe bağlı kılarsınız\n- Güvenilirlik: Canlı başarısız olduğunda son eşitleme değeri gösterilirse yüksek olur\n- Karmaşıklık: En yüksek—iki yolun bakımını yapmak gerekir\n- API limitleri: Yüzey alanı küçük tutulursa yönetilebilir\n\n### Pratikte önemli takaslar\n\nTazelik ücretsiz değildir: gerçek zamana ne kadar yakınsanız, API çağraları, önbellekleme ve hata yönetiminde o kadar ödersiniz. Zamanlanmış alma, kullanıcıların panoların her zaman hızlı yüklenmesini beklediği bir ürün için genellikle en sağlam temeldir.\n\n### Önerilen varsayılan\n\nÇoğu ekip için: zamanlanmış ELT ile başlayın (ham veriyi yükleyin + hafif normalizasyon, sonra metrikler için dönüştürün) ve yakın-gerçek zamanlıyı yalnızca birkaç yüksek değerli metrik için ekleyin.\n\n### Karar kontrol listesi\n\nCanlı sorguları seçin eğer:\n\n- Veri dakika dakika değişiyor ve kullanıcılar anında harekete geçiyor\n- API hız limitleri cömert veya güçlü önbellekleme yapabiliyorsanız\n- Kısmi pano durumlarına ara sıra katlanabilirsiniz\n\nZamanlanmış ETL/ELT seçin eğer:\n\n- Doğruluk, tutarlılık ve hızlı panolar dakika seviyesinden daha önemliyse\n- Tarihsel analiz, backfill ve yeniden üretilebilir sayılar gerekiyorsa\n- Tutarsız API'lere sahip birçok araç entegre ediliyorsa\n\nHibrit seçin eğer:\n\n- Çoğu raporlama gecikebilir, ama birkaç metrik taze olmalıysa\n- Canlı bileşenler için son eşitleme + zaman damgası gibi geri dönüşler uygulayabiliyorsanız\n- İki veri yolunu karıştırmadan sürdürecek kapasiteniz varsa\n\n## Veri Modelini ve Metrik Tanımlarını Tasarlayın\n\nMerkezi raporlama iki şeye bağlı olarak başarır veya başarısız olur: insanların anlayabileceği bir veri modeli ve her yerde aynı anlama gelen metrikler. Panoları kurmadan önce “iş isimlerini” ve KPI'ların tam matematiğini tanımlayın.\n\n### Temel varlıkları tanımlayın\n\nBasit, paylaşılan bir sözlükle başlayın. Yaygın varlıklar şunlardır:\n\n- Hesaplar/Şirketler (müşteri organizasyonu)\n- Kullanıcılar/Kişiler (hesaptaki kişiler)\n- Anlaşmalar/Fırsatlar (satış pipeline'ı)\n- Faturalar/Abonelikler/Ödemeler (faturalama gerçeği)\n- Ticket'lar/Konuşmalar (destek iş yükü ve sonuçları)\n- Kampanyalar/Reklamlar (pazarlama harcaması ve atıf girdileri)\n\nHangi sistemin her varlık için gerçek kaynak olduğunu (ör. faturalar için faturalama) kararlaştırın. Modeliniz bu sahipliği yansıtmalı.\n\n### Sistemler arası join'lerin nasıl yapılacağını planlayın\n\nAraçlar arası raporlama güvenilir anahtarlar gerektirir. Tercih edilen join sırası:\n\n1. Açık stabil ID'ler (external_id gibi)\n2. Kontrolünüzdeki eşleme tabloları (ör. crm_account_id ↔ billing_customer_id)\n3. E-posta/domain'ler (yararlı ama değişiklik ve çoğaltma riski taşır)\n\nEşleme tablolarına erken yatırım yapın—bunlar “dağınık ama çalışır” durumunu “tekrarlanabilir ve denetlenebilir” hale getirir.\n\n### Metrikleri bir kez tanımlayın (ve bir sahibi atayın)\n\nMetrik tanımlarını ürün gereksinimi gibi yazın: isim, formül, filtreler, granülerlik ve kenar durumlar. Örnekler:\n\n- MRR: vergiler dahil mi/dışlanacak mı? indirimler? duraklatılmış abonelikler?\n- CAC: hangi harcama kaynakları sayılır ve hangi zaman penceresi?\n- Churn: logo vs. gelir churn; düşüşler nasıl ele alınır?\n\nBir metrik sahibi atayın (finans, revops, analiz) ve değişiklikleri o onaylasın.\n\n### Zaman, para birimi ve takvimleri standardize edin\n\nVarsayılanları seçin ve sorgu katmanında uygulayın:\n\n- Saat dilimi: zaman damgalarını UTC'de saklayın; raporları seçilen iş saat diliminde gösterin\n- Para birimi: bir temel para birimi ve döviz kuru kuralları (günlük/aylık) seçin\n- Mali takvim: mali ayları/çeyrekleri tanımlayın ve tutarlılığı koruyun\n\n### Metrik mantığını versiyonlayın ve değişiklikleri belgeleyin\n\nMetrik mantığını kod gibi ele alın: versiyonlayın, yürürlük tarihlerini ekleyin ve kısa bir değişiklik günlüğü tutun (“MRR v2, tek seferlik ücretleri 2025-01-01'den itibaren dışlar”). Bu, “panodaki sayı değişti” kafa karışıklığını engeller ve denetimleri kolaylaştırır.\n\n## Veri Boruları İnşa Edin: Çıkarma, Normalize Etme, Zamanlama\n\nMerkezi raporlama uygulaması, borularının güvenilirliği kadar güvenilirdir. Her bağlayıcıyı küçük bir ürün gibi düşünün: veriyi tutarlı çekmeli, öngörülebilir bir formata şekillendirmeli ve her seferinde güvenli şekilde yüklemelidir.\n\n### Bağlayıcı sorumlulukları (çek → doğrula → normalleştir → yükle)\n\nÇekme, ne istediğini (endpoint'ler, alanlar, zaman aralıkları) ve nasıl kimlik doğrulaması yaptığını açıkça belirtmelidir. Veriyi çektikten hemen sonra temel varsayımları doğrulayın (gerekli ID'ler mevcut mu, zaman damgaları ayrışıyor mu, diziler beklenmedik şekilde boş mu).\n\nNormalize etme, veriyi araçlar arasında kullanılabilir hale getirdiğiniz yerdir. Standartlaştırın:\n\n- Tarihler ve saat dilimleri (UTC saklayın; orijinal zaman damgalarını gerekli yerde tutun)\n- Durumlar/enums ("won/closed/success" gibi değerleri paylaşılan sete eşleyin)\n- İsimlendirme kuralları (snake_case vs. camelCase; account_id gibi tutarlı alan adları)\n\nSon olarak, raporlamayı hızlı destekleyecek ve güvenli yeniden çalıştırmalara izin verecek şekilde yükleyin.\n\n### Zamanlama: saatlik/günlük işler, artımlı senkronlar ve backfill'ler\n\nÇoğu ekip kritik bağlayıcıları saatlik, uzun kuyruk kaynakları günlük olarak çalıştırır. İşleri hızlı tutmak için artımlı senkronları tercih edin (ör. updated_since veya bir cursor), ama eşleme kuralları değiştiğinde veya sağlayıcı API'si kapalıyken backfill tasarlayın.\n\nPratik bir desen:\n\n- Artımlı: güncellenme zamanına veya değişim token'ına göre çek\n- Backfill: tarih veya ID ile sınırlı aralıklarla ve hız sınırlamasıyla çalıştır\n\n### Gerçek API sorunlarıyla başa çıkma\n\nSayfalandırma, hız sınırları ve ara sıra kısmi hatalar bekleyin. Üstel geri denemeler kullanın, ama aynı zamanda çalışmaları idempotent yapın: aynı payload iki kez işlendiğinde çoğaltma yaratmamalıdır. Stabil dış ID'lerle upsert genelde iyi çalışır.\n\n### Temizin yanında hamı saklayın\n\nNormalize edilmiş tabloların yanında ham cevapları (veya ham tabloları) saklayın. Bir pano sayısı yanlış görünürse, ham veri API'nin ne döndürdüğünü ve hangi dönüşümün değiştirdiğini izlemenizi sağlar.\n\n## Depolama Seçimi: Veritabanı mı, Ambar mı, Göl mü\n\nDepolama, merkezi raporlamanın başarılı olup olmayacağını belirler. “Doğru” seçim araçlardan daha çok insanların nasıl sorgulayacağına bağlıdır: sık pano okumaları, ağır agregasyonlar, uzun geçmiş ve aynı anda kaç kullanıcının sisteme erişeceği.\n\n### Seçenek 1: İlişkisel veritabanı (Postgres/MySQL)\n\nVeritabanı, uygulamanız genç ve veri setiniz orta büyüklükteyse iyi bir varsayılandır. Güçlü tutarlılık, anlaşılır modelleme ve filtreli sorgular için öngörülebilir performans sunar.\n\nKullanılmalıysa:\n\n- Birçok küçük sorgu bekleniyorsa (takımlar/organizasyonlar bazında)\n- Orta düzeyde agregasyon ihtiyacı varsa\n- Düşük eşzamanlılık (onlarca kullanıcı, yüzler değil) varsa\n\nTipik raporlama desenleri için planlayın: (org_id, date) ile indeksleyin ve team_id veya source_system gibi yüksek seçicilikli filtreleri düşünün. Event-benzeri kayıtlar saklıyorsanız, indeksleri küçük tutmak ve bakım yönetimini kolaylaştırmak için aylık partition'lar düşünün.\n\n### Seçenek 2: Veri ambarı (BigQuery/Snowflake/Redshift)\n\nAmbarlar analitik iş yükleri için inşa edilmiştir: büyük taramalar, geniş joinler ve birçok kullanıcının panoları yenilemesi. Uygulamanız çok yıllık geçmiş, karmaşık metrikler veya dilimleme-keşif gerektiriyorsa, ambar genelde karşılığını verir.\n\nModelleme ipucu: ekleme-odaklı bir fact tablosu (ör. usage_events) ve dimension tabloları (orgs, teams, tools) tutun ve metrik tanımlarını standartlaştırın ki panolar aynı mantığı yeniden yazmasın.\n\nTarihe göre partition'layın ve sık filtrelediğiniz alanlara göre cluster/sort yapın—bu tarama maliyetini düşürür ve sık kullanılan sorguları hızlandırır.\n\n### Seçenek 3: Nesne depolama / veri gölü (S3/GCS/Azure Blob)\n\nGöl, ham ve tarihsel verinin ucuz, dayanıklı saklanması için iyidir; birçok kaynağı alıyor veya dönüşümleri yeniden oynatmanız gerekiyorsa kullanışlıdır.\n\nTek başına göl raporlama için hazır değildir. Genelde panolar için bir sorgu motoru veya ambar katmanı ile eşleştirilir.\n\n### Maliyet ve saklama: faturayı ne belirler\n\nMaliyeti genelde depolamadan çok hesaplama belirler (panoların ne sıklıkta yenilendiği, her sorgunun ne kadar veri taradığı). Tam tarihçeli sorgular pahalıdır; panoları hızlı tutmak için özetler (günlük/haftalık rollup) tasarlayın.\n\nErken saklama kurallarını belirleyin: küratörlü metrik tablolarını sıcak tutun (ör. 12–24 ay) ve daha eski ham dışa aktarımları backfill ve uyumluluk için göle arşivleyin. Daha derin planlama için /blog/data-retention-strategies metnine bakabilirsiniz.\n\n## Backend'i Uygulayın: Kimlik Doğrulama, Sorgu Katmanı ve Metrik Mantığı\n\nBackend, dağınık ve değişen veri kaynakları ile insanların güvendiği raporlar arasındaki sözleşmedir. Tutarlı ve öngörülebilirse, UI basit kalabilir.\n\n### Dahil edilmesi gereken temel servisler\n\nBaşlangıçta küçük bir “her zaman gerek” hizmet seti ile başlayın:\n\n- Kimlik doğrulama & oturumlar: SSO (Google/Microsoft), gerekiyorsa parola girişi, ve API erişimi için servis tokenleri.\n- Organizasyon/çalışma alanı yönetimi: orglar, çalışma alanları/projeler, üyelik, davetler ve roller.\n- Bir sorgu API'si: panolar, dışa aktarımlar ve otomasyonların hepsinin kullanabileceği tek tarz bir endpoint (ör. /api/query, /api/metrics).\n\nSorgu katmanını kısıtlayıcı yapın: sınırlı filtre seti (tarih aralığı, boyutlar, segmentler) kabul edin ve keyfi SQL çalıştırılmasına dönüşebilecek her şeyi reddedin.\n\n### Semantik (metrik) katmanı ekleyin\n\nMerkezi raporlama, “Gelir” veya “Aktif Kullanıcı”nın her panoda farklı hesaplanmasıyla başarısız olur.\n\nBir semantik/metrik katman uygulayın; bunun içinde:\n\n- metrik formülleri (örn. net gelir = brüt − iadeler)\n- izin verilen boyutlar (kanal, kampanya, bölge)\n- zaman mantığı (saat dilimi, hafta Pazartesi mi Pazar mı başlar)
\nBu tanımları versiyonlanmış konfigürasyonda (veritabanı tablosu veya git'teki dosyalar) saklayın ki değişiklikler denetlenebilir ve geri alınabilir olsun.\n\n### Gerçek pano davranışına uygun önbellekleme\n\nPanolar aynı sorguları tekrarlar. Erken önbellekleme planlayın:\n\n- workspace + tarih aralığı + filtre hash'ine göre ortak aggregate'leri önbellekle\n- “bugün” için daha kısa TTL'ler, tarihsel aralıklar için daha uzun TTL'ler kullan\n- mümkünse pahalı rollup'ları zamanlanmış olarak önceden hesapla\n\nBu, UI'ı hızlı tutar ve veri tazeliğini gizlemez.\n\n### Çok kiracılılık: veriyi güvenli izole et\n\nAralarında seçim yapın:\n\n- (güçlü izolasyon, daha fazla operasyonel iş), veya\n- tenant ID ile (çalıştırması daha kolay, katı erişim kontrolleri gerektirir).\n\nHangisini seçerseniz seçin, tenant kapsamını frontend'de değil, sorgu katmanında zorunlu kılın.\n\n### Dışa aktarma ve paylaşma\n\nBackend desteği raporlamayı eyleme dönüştürür:\n\n- Her kaydedilmiş rapor için CSV dışa aktarımı\n- Zamanlanmış e-postalar (günlük/haftalık anlık görüntüler)\n- Aşağı akış araçları için API erişimi, kapsamlı tokenler ve hız sınırlarıyla\n\nBu özellikleri birinci sınıf API yetenekleri olarak tasarlayın ki raporlar her yerde çalışsın.\n\n### Hızlı çalışan bir dahili prototip yolu\n\nHızla çalışan bir iç raporlama uygulaması göndermek istiyorsanız, önce UI ve API şekillerini üzerinde prototiplemeyi düşünün. Bu, sohbet tabanlı bir spesifikasyondan React frontend ve Go backend + PostgreSQL oluşturabilen bir vibe-coding platformudur; planlama modu, anlık görüntüler ve geri alma destekler—şemalar ve metrik mantığında yineleme yaparken kullanışlıdır. Daha sonra prototipi aştığınızda kaynak kodunu dışa aktarabilir ve kendi boru hattınızda geliştirmeye devam edebilirsiniz.
