Problem
Finans ve kampanya verileri çoğu zaman ayrı analitik hatlarda tutulur; bu durum reklam harcaması sonrası kârlılığı tek bir raporlama ekranında görmeyi zorlaştırır.
Teknik vaka çalışması
Greenweez Finance & Campaign Analytics
E-ticaret finans raporlaması ve ücretli kampanya performansını birleştiren dbt analitik mühendisliği çalışması. BigQuery ve her PR'de test edilen DuckDB eşleniği kullanılır.
Teknik açıklamalar Türkçeye çevrilmiştir. Sonuç metriklerinin ölçüm koşulları, başarısız denemeler ve kaynak bağlantıları özgün proje kanıtlarıyla aynı kapsamda korunur.
Hızlı teknik inceleme
Teknik vaka çalışması: dört temel nokta.
Mimari
dbt; staging, intermediate ve mart mantığını ayırır. Aynı kod farklı adaptör makrolarıyla BigQuery ve DuckDB üzerinde çalışır. source_system değişkeni, ham veri girişini özgün reklam platformu tabloları ile Google Sheets dışa aktarımı arasında seçer.
Sonuçlar
Reklam harcaması sonrası kârlılığı gösteren ads_margin dâhil birleşik finans ve pazarlama raporlama martları oluşturur.
Sınırlamalar ve kapsam
Ham veri ambarı kümesi boş olduğundan varsayılan mod sentetik seed verisinde doğrulanmıştır. Gelir belirli reklam kaynağına atfedilmediği için ROAS yalnızca birleşik düzeyde bulunur. Sheet dışa aktarımında anlamı doğrulanmamış iade sütunu ayrı…
Tam açıklamayı oku
Ham veri ambarı kümesi boş olduğundan varsayılan mod sentetik seed verisinde doğrulanmıştır. Gelir belirli reklam kaynağına atfedilmediği için ROAS yalnızca birleşik düzeyde bulunur. Sheet dışa aktarımında anlamı doğrulanmamış iade sütunu ayrı raporlanır; gelir veya marjdan düşülmez. Gösterge paneli bir BI ürünü değil, demodur.
Kaynaklarda yayımlanmış teknik kanıtlar kullanılmıştır. Ölçüm koşulları için tam vaka çalışmasını inceleyin.
Kanıta dayalı görsel inceleme
Projenin gerçek çıktılarını inceleyin.
Tasarım kapağı, kaynak ekran görüntüleri ve proje figürleri birbirinden ayrılmıştır.
Portföy illüstrasyonu
Portföy için hazırlanmış kavramsal görseldir; canlı uygulama arayüzü veya ölçülmüş performans kanıtı değildir.
Proje kanıtları
Doğrulanabilir dış kaynaklar
Son doğrulama 2026-10-06
Problem ve yaklaşım
Problem
Finans ve kampanya verileri çoğu zaman ayrı analitik hatlarda tutulur; bu durum reklam harcaması sonrası kârlılığı tek bir raporlama ekranında görmeyi zorlaştırır.
Mimari
dbt; staging, intermediate ve mart mantığını ayırır. Aynı kod farklı adaptör makrolarıyla BigQuery ve DuckDB üzerinde çalışır. source_system değişkeni, ham veri girişini özgün reklam platformu tabloları ile Google Sheets dışa aktarımı arasında seçer.
İş mantığı
Finans raporlamasına kampanya maliyeti ve performansı eklenir: reklam sonrası kârlılık için ads_margin, birleşik ROAS ve kaynak bazında CPC/CTR. Bütün oranlar günlük oranların ortalaması değil, toplamların oranıdır; sıfır paydada NULL döndürülür.
Doğrulama
CI, her iki kaynak modunda DuckDB ile dbt seed ve dbt build çalıştırır (şema, uzlaştırma ve birim testleri) ve grafik arayüzsüz panel smoke testi uygular. BigQuery çalıştırması salt okunur sorguydu ve DuckDB ile aynı sonuçları verdi.
İddia edilmeyen noktalar
Ham veri ambarı kümesi boş olduğundan varsayılan mod sentetik seed verisinde doğrulanmıştır. Gelir belirli reklam kaynağına atfedilmediği için ROAS yalnızca birleşik düzeyde bulunur. Sheet dışa aktarımında anlamı doğrulanmamış iade sütunu ayrı raporlanır; gelir veya marjdan düşülmez. Gösterge paneli bir BI ürünü değil, demodur.
Neden önemli?
Proje analitik mühendisliği kontrollerini görünür bırakır: yapılandırılmış martlar, yeniden kullanılabilir iş mantığı, gerçekten çalışan testler ve verinin neyi destekleyip neyi desteklemediğine ilişkin açık açıklamalar.
Mimari ve analiz
- Finans ve pazarlama verilerini ayrı geçici SQL analizleri yerine tek modüler dbt mimarisinde birleştirir.
- Gelir, maliyet, operasyonel marj ve reklam harcamasını ROAS/CPC/CTR martlarıyla bağlayan günlük ve aylık raporlama modelleri kurar.
- Sadece proje ayrıştırmasıyla yetinmez; her pull request’te iki kaynak modunda DuckDB dbt build, lint ve panel smoke testi çalıştırır.
- Özgün modellerde sessiz kalan üç hatayı bulup düzeltti: kargo satırı olmayan siparişler marj hesabından düşüyordu, siparişsiz günlerde reklam harcaması kayboluyordu ve aylık sepet değeri günlük ortalamaların ortalamasıyla hesaplanıyordu.
Test ve doğrulama
- Satış, ürün, kargo, dört reklam platformu ve Google Sheets dışa aktarımı için staging modelleri
- int_orders_operational ve int_campaigns_day gibi intermediate modeller
- finance_days, finance_campaigns_month, marketing_performance_month ve finance_refunds_month raporlama modelleri
- Veri soy ağacı grafiğinde görülebilmesi için dbt exposure olarak tanımlanmış Streamlit paneli
Operasyonel değer
- Reklam harcaması sonrası kârlılığı gösteren ads_margin dâhil birleşik finans ve pazarlama raporlama martları oluşturur.
- Toplamların oranı yöntemiyle birleşik ROAS, marj ROAS ve kaynak bazında CPC/CTR ekler.
- Gerçek Google Sheets aktarımında (13,362 sipariş) gelir 967,261, reklam sonrası marj 144,727 ve birleşik ROAS 14.69 düzeyindedir; bağımsız BigQuery toplamlarıyla kontrol edilmiştir.
- İade sütunu gerçek iade gibi davranmadığından (her siparişte değer; toplam gelirin 3.8 katı) net gelir ve marjdan düşülmez.
Nasıl incelenir
- SQL dosyalarından önce mart adlarını ve README mimari görünümünü inceleyin.
- Verilerin neleri destekleyip desteklemediğini görmek için README içindeki kaynak sistem ve iade bölümlerini okuyun.
- Projeyi veri ambarı öncelikli kanıt olarak inceleyin; panel martlar üzerinde basit bir demodur.