Google Cloud'da Birleşik Pazarlama Zekâsı

Problem

Google Cloud üzerinde çalışan bir e-ticaret perakendecisinin birbiriyle konuşmayan beş veri kaynağı var. Bunlar GA4 akışı, günlük rakip dosyaları, sosyal medya ve reklam API’leri, arama verisi ve kurumsal veri ambarı. Pazarlama ekibi CSV dışa aktarımlarını elle uzlaştırıyor. “Dünkü dönüşüm düşüşünü bizim fiyatımız mı, rakibin fiyatı mı yaptı?” gibi bir soru iki gün sürüyor. Şirket dört tüketici için tek platform istiyor: yaklaşık 400 kullanıcılı Power BI, ajanlı bir LLM asistanı, makine öğrenmesi modelleri ve reklam platformlarına kitle aktarımı.

Yaklaşım

Belirleyici hedef tek gerçek kaynağı korumak. Power BI, LLM ve ajanlar aynı soruya aynı sayıyı vermeli. Ritimler farklı: GA4 dakikalar içinde sorgulanabilmeli, rakip dosyaları günde bir kez geliyor, sosyal API’ler yedi güne kadar geçmişi düzeltiyor. Üçüncü endişe maliyet; dört tüketici grubu BigQuery faturasını şişirebilir. Tasarım veriyi katmanlıyor, yayını bir kapıdan geçiriyor ve her tüketiciyi tek bir metrik sözleşmesine bağlıyor.

Mimari

• Alım: GA4 için sunucu tarafı collector ve Pub/Sub, batch dosyalar için Cloud Composer, API’ler için bir Cloud Run konnektörü. Veri ambarı kopyalanmıyor, yetkili görünümlerle okunuyor.
• Katmanlar: ham, staging, ortak anahtarlı conformed ve sertifikalı mart katmanları; Dataform SQL ve testleriyle kuruluyor.
• Yayın kapısı: mart’lar aday olarak kuruluyor, assertion’lar çalışıyor ve bir görünüm değişimiyle yayına alınıyor. Geç gelen batch yarım veri göstermiyor.
• Sunum: metrikler Git’te bir kez tanımlanıyor. Bir metrik API’si çalıştırıyor; Power BI modelleri aynı tanımdan üretiliyor.
• LLM ve ajanlar: model soruyu metrik, filtre ve tarih aralığına çeviriyor. Sayı API’den geliyor. Ajanlar aksiyon önerilerini onay kuyruğuna bırakıyor.

Kararlar ve ödünleşimler

• Tüketiciye ham SQL yok. Text-to-SQL esnek ama tutarsız: aynı soru için iki sorgu iki sayı üretir. Bir cevap Power BI ile ayrıştığı anda güven biter. Sertifikalı metriği olmayan soru reddediliyor ve metrik backlog’una düşüyor. Aynı sayı garantisi prompt’tan değil mimariden geliyor. Bedeli, sahipleri olması gereken bir metrik sözleşmesi; en büyük risk de sahiplik.
• İkinci motor yerine görünüm değişimi. BigQuery’de görünüm değişimi atomik ve kopya istemiyor. Bir batch gecikirse dünkü sayılar dünkü damgasıyla kalıyor; kimse yarım gün görmüyor. GA4 için tazelik bayraklı, geçici bir akış görünümü var. Bedeli, sertifikalı mart’ların bir gün geriden gelmesi.
• Ajanlar öneriyor, uygulamıyor. Ads API’sini ajan değil onay servisi çağırıyor; ajanın servis hesabında bu yetki yok. Her çalıştırmanın bir harcama değişim limiti var, her aksiyon geri alma kaydı tutuyor. Bedeli: her yeni aksiyon türü kendi onay akışını istiyor.
• Bilinçli Google Cloud bağımlılığı. Ambar zaten BigQuery’de, GA4 oraya yerel akıyor. Taşımak iş değeri üretmeden maliyet ve gecikme ekler. Taşınabilirlik bütçesini değerin biriktiği yere harcıyorum: anahtar eşlemeleri, metrik sözleşmesi ve ajan araç tanımları Git’te. Ambar değişirse metrik API’si başka motora bakar, tüketiciler aynı arayüzü görür.
• Ambarı oku, kopyalama. Authorised view’lar aynı satırları okuyor ve ambara yük bindirmiyor. Sahiplik veri ekibinde kalıyor. Bedeli şema değişikliği riski; bu yüzden o ekiple hizmet seviyesi sözleşmenin en kırılgan yeri.
• Maliyet kullanıcıyla değil, veri hacmiyle büyüyor. Power BI import modda; 400 kullanıcının tıklamaları BigQuery’ye gitmiyor. Metrik API’si metrik, filtre ve publish ID ile önbellekliyor; sonuç bir sonraki yayına kadar değişemez. Her tüketici grubunun kendi projesi, rezervasyonu ve kotası var; %80’de bütçe alarmı.

Yeniden ele alacaklarım

• Sunucu tarafı toplayıcı. Yoksa GA4 saatlik gün içi dışa aktarıma düşer ve iki dakika hedefi tutmaz.
• Rakip SKU kapsamı. %90 varsaydım. %95 altındaki kategoriler kapsama uyarısıyla cevap veriyor. Kapsam düşükse önce eşleme kalitesi gelir, mimari değil.
• Birincil BI aracı. Power BI ve Looker Studio birlikte desteklenebilir; ama sertifikasyon işi ve maliyet ikiye katlanır.
• Ambar ekibiyle hizmet seviyesi. Bir authorised view’ın şeması değişmeden ne kadar önce haber geliyor?

Sonuç notları (tasarım varsayımları, ölçüm değil)

Bu bir tasarım çalışmasıdır, teslim edilmiş bir platform değildir. Çıktı: dört sayfalık diyagram seti, tek sayfalık beyaz tahta sürümü ve 16 sayfalık Türkçe PDF. Metrik listesi ve sahipleri (50 varsayıldı) hâlâ açık.

Kaynaklar

• Mimari PDF (Türkçe, 16 sayfa).
• draw.io diyagramları (İngilizce etiketler): dört sayfalık set ve 30 dakikalık tek sayfa sürüm.