1. BigQuery ve Veri Ambarı Mantığı
Veri ambarı (data warehouse), rapor için “bir tablo daha” değildir; organizasyonun veriyi tek yerde tutup, farklı ekiplerin aynı gerçek üzerinden konuşmasını sağlayan bir mimaridir. SEO bağlamında BigQuery yaklaşımı üç şeye hizmet eder:
- •Merkezileştirme: GA4, GSC, Ads, CRM aynı yerde
- •İlişkilendirme: sorgu → landing → dönüşüm zinciri
- •Sürdürülebilirlik: KPI sözlüğü ve şema standart, raporlar bozulmaz
SEO data warehouse’ı neyi çözer?
- •“Aynı landing’de organik + reklam performansı”nı yan yana okursunuz.
- •“Cluster etkisi”ni 6–12 ay geriye gidip ölçersiniz.
- •“Zincir otellerde otel bazlı teşhis”i tek panelde yaparsınız.
- •“Raporlama ritmi”ni otomatikleştirip tablo gezmeyi azaltırsınız.
Mini örnek (çok markalı otel): Antalya ve Bodrum’da iki farklı marka site yapısı kullanıyorsa, GA4/GSC kurulumları farklıysa “toplam rapor” yanıltır. Warehouse yaklaşımı; tek sözlükle normalize edip karşılaştırmayı güvenilir hâle getirir.
Ne yapmalıyım? (3–6 aksiyon)
- • Önce hedef soruları yazın: “Hangi kararları hızlandırmak istiyoruz?”
- • Tek gerçek prensibini benimseyin: KPI tanımı ve filtreler merkezî olsun.
- • Şemayı “minimum viable” başlayıp iteratif büyütün (her şeyi başta yapmayın).
- • Data quality ve changelog disiplinini en baştan kurun (sonradan pahalı olur).
2. Neden Sadece GA4/GSC Panelleri Yetmez?
Panel limitleri ve operasyonel gerçekler
GA4 ve GSC, kendi alanlarında güçlüdür; ama ortak okuma (join) ve uzun dönem portföy analizi söz konusu olduğunda operasyonel zorluklar çıkar:
- •Kaynaklar arası birleşim zorluğu: GSC “sorgu+sayfa”, GA4 “oturum+dönüşüm” düzeyi.
- •Çoklu marka/site karmaşası: her property farklı, sözlük farklı.
- •Segment ve tarih karşılaştırma ihtiyacı: YoY/seasonal, multi-country, device.
- •Backlink/visibility tool + CRM: panel dışı veriler.
Key Statistics / Data Point (yumuşatılmış): GA4 veri saklama sürelerinin kısa tutulduğu ve bazı arayüz kısıtlarının devreye girdiği projelerde, BigQuery entegrasyonu uzun dönem SEO trendlerini daha sağlıklı izlemek için kritik hâle gelir. (Bu bir prensip: veri hacmi büyüdükçe warehouse mantıklı hâle gelir.)
SEO için BigQuery ve veri ambarı kurmaya değer mi?
Değer, proje ölçeğine ve sorularınıza bağlıdır. Eğer raporlarınız “tek kanal/tek site/tek dönem” seviyesindeyse doğrudan BigQuery şart değildir. Ama çok site/çok marka, çok kanal (Ads+CRM) ve uzun dönem trend/segment soruları artıyorsa; veri ambarı, rapor kalitesini ve karar hızını belirgin şekilde artırır.
Ne yapmalıyım? (3–6 aksiyon)
- • “Warehouse şart mı?” sorusunu bütçe değil soru setiyle cevaplayın.
- • Başlangıç için GA4+GSC ile MVP kurun, Ads/CRM’yi ikinci faza alın.
- • Çok markalı yapılarda önce KPI sözlüğünü standardize edin; yoksa warehouse da dağılır.
- • Küçük ölçekli projelerde “hafif” mimari (daha az tablo, daha az pipeline) ile başlayın.
3. SEO Verilerini Tek Havuzda Toplamak
Tek havuz, “her şeyi tek tabloya atmak” değildir. İyi bir data warehouse; katmanlıdır:
- Raw (ham): kaynaklardan geldiği gibi
- Staging (temizleme/normalize): URL, tarih, site_id standardı
- Mart (rapor tabloları): dashboard’a hazır KPI tabloları
- Semantic layer (opsiyonel): KPI sözlüğü/hesaplama standardı
En kritik tasarım kararı: ortak anahtarlar
SEO data warehouse’ta “join” başarısı, ortak anahtarlara bağlıdır:
- •date (tarih)
- •site_id / brand_id (çoklu site/marka)
- •page_url (normalize edilmiş URL)
- •query (GSC sorgu)
- •landing_page (GA4 landing)
- •campaign_id (Ads)
- •lead_id / booking_id (CRM)
Mini örnek: Belek’te bir otelin “/belek-aile-oteli” landing’i GSC’de sayfa olarak, GA4’te landing page path olarak, CRM’de lead source olarak geçer. URL normalize edilmezse join bozulur ve rapor “farklı gerçekler” üretir.
Ne yapmalıyım? (3–6 aksiyon)
- • URL normalize etmeden hiçbir join’e güvenmeyin.
- • Multi-site/multi-brand sözlüğünü baştan çıkarın (site_id, brand_id, region).
- • Staging katmanında “temizlenmiş URL” alanını üretin (tek kaynak).
- • KPI tablolarını “rapor amaçlı” mart katmanında üretin (raw’a dashboard bağlamayın).
4. Hangi Kaynaklar Birleştirilmeli? (GA4, GSC, Ads, CRM)
Kaynak sırası, “değer/efor” oranıyla belirlenmeli. Hepsini aynı anda bağlamak çoğu ekipte mimariyi kilitler.
Faz 1 (MVP) — GA4 + GSC
- •GA4: sessions, events, conversions (landing bazlı)
- •GSC: queries, pages, impressions, clicks, CTR, position
Amaç: sorgu→landing→dönüşüm zincirini ilk kez kurmak.
Faz 2 — Ads (Google Ads vb.)
- •maliyet, tıklama, dönüşüm, kampanya
- •brand/generic rol dağılımı
- •SEO + SEM sinerji raporu
Faz 3 — CRM / PMS / Rezervasyon
- •lead/rezervasyon, gelir, müşteri segmenti
- •“SEO gerçek iş etkisi” (pipeline)
Faz 4 — Backlink / Visibility tool verileri
- •backlink sinyali, share of voice, rakip kıyas
- •cluster otorite okuması
Mini örnek (B2B): CRM bağlandığında “organik dönüşüm” sadece form submit değil; pipeline ve satışa dönüşme oranı olarak okunabilir. Bu, CEO panelini gerçek iş KPI’larına bağlar.
Ne yapmalıyım? (3–6 aksiyon)
- • MVP’yi 30–45 gün hedefleyin: GA4+GSC + 2–3 rapor tablosu.
- • Ads’i “brand/generic” kararlarını iyileştirmek için ikinci faza alın.
- • CRM’yi “iş etkisi” görünür olsun diye üçüncü faza alın.
- • Kaynak ekledikçe KPI sözlüğünü güncelleyin (Refresh Cycle 180).
5. Looker Studio ve Diğer BI Araçlarıyla Üstünde Dashboard Kurmak
Warehouse “mutfak”tır; BI “servis”tir. Dashboard tasarımında kritik kural: tek gerçek, farklı lens (role-based). Aynı veri setinden CEO/pazarlama/içerik/teknik panelleri üretebilirsiniz.
BI katmanında önerilen dashboard blokları
- •Executive (CEO): iş KPI + trend + 3–3–3
- •Growth (Marketing): SEO funnel + segment + kampanya notları
- •Content: topic cluster performansı + refresh backlog
- •Tech: CWV/crawl/index + P0 listesi
- •Ops: haftalık alarm kartları + change log
Looker Studio raporları veri ambarına bağlanınca ne kazanırım?
Dashboard’lar daha tutarlı ve ölçeklenebilir olur: aynı KPI sözlüğüyle farklı paneller üretilir, uzun dönem trendler ve segment analizleri daha esnek yapılır, kaynaklar arası join’ler rapor içinde değil warehouse’da yönetilir. Böylece raporlama süresi azalır, analiz ve aksiyon geliştirme süresi artar.
Ne yapmalıyım? (3–6 aksiyon)
- • Dashboard’u mart tablolarına bağlayın; hesaplamayı BI’da çoğaltmayın.
- • Role-based panelleri aynı veri sözlüğüyle üretin.
- • Haftalık “alarm” panelini standartlaştırın (CTR/dönüşüm/404 sapmaları).
- • Dashboard’larda filtre setini sabitleyin (tarih, site_id, ülke, cihaz).
6. Basit Şema Tasarımı ve Örnek Tablo Yapıları
Türkçe kaynaklarda en eksik kalan yer genelde burası: “Tamam, warehouse kuracağız; peki şema nasıl olacak?” Bu bölüm, basitleştirilmiş ama uygulanabilir bir örnek verir.
Minimum tablo seti (MVP)
- •dim_site (site_id, brand_id, region, domain)
- •dim_page (page_url_normalized, page_type, cluster_id)
- •fct_gsc_daily (date, site_id, page_url, query, impressions, clicks, ctr, position)
- •fct_ga4_daily (date, site_id, landing_page, sessions, engaged_sessions, conversions, revenue_value_if_any)
- •mart_seo_landing_daily (date, site_id, landing_page, gsc_impr, gsc_clicks, gsc_ctr, ga4_sessions, ga4_conversions)
- •(Faz 2) fct_ads_daily (date, campaign, query_cluster, cost, clicks, conversions)
- •(Faz 3) fct_crm_daily (date, lead_id, source, landing_page, status, revenue)
| Katman | Tablo | Amaç | Not |
|---|---|---|---|
| Dimension | dim_site/dim_page | sözlük ve normalizasyon | tek gerçek |
| Fact | fct_gsc_daily | görünürlük | query + page |
| Fact | fct_ga4_daily | davranış/dönüşüm | landing odak |
| Mart | mart_seo_landing_daily | rapor için birleşik | join burada |
Join mantığı
- •GSC: query seviyesinde; GA4: session/dönüşüm seviyesinde
- •MVP’de en pratik yaklaşım: landing bazında birleşik mart üretmek
- •Query→landing ilişkilendirme: “query-to-landing mapping” raporu, ileri faz
Mini örnek: Zincir otellerde her otel için aynı mart tablosu üretirseniz, “tüm grup iyi ama şu otel zayıf” senaryosu tek filtreden görünür.
Ne yapmalıyım? (3–6 aksiyon)
- • MVP’yi landing bazlı mart ile bitirin; query-to-landing’i ikinci iterasyona bırakın.
- • dim_site/dim_page sözlüğünü baştan doğru kurun (sonradan düzeltmesi pahalı).
- • Her yeni kaynak eklediğinizde mart’ı büyütün, dashboard’u değiştirmeden devam edin.
7. Operasyon, Veri Hijyeni ve Sürdürülebilirlik
Warehouse kurulduktan sonra en önemli konu: “bozulmaması”. Bunun için 3 rutin şarttır:
- Change log: event, mapping, schema değişiklikleri
- Data quality checks: bot/spam, kanal mapping, eksik günler
- Ritim: haftalık monitoring, aylık performans, çeyreklik strateji (ops culture)
Technical Not (row): Ölçek küçük projeler için doğrudan BigQuery zorunlu değildir; ancak veri hacmi büyüdükçe, limitsiz analiz ihtiyacı data warehouse’ı mantıklı hâle getirir.
Ne yapmalıyım? (3–6 aksiyon)
- • Veri hijyeni kontrolünü aylık rutin yapın (OK/Risk/Kritik).
- • 180 günde bir şema/pipeline gözden geçirmeyi takvime bağlayın.
- • Raporları warehouse üzerinden standardize edin; “Excel ad hoc”u azaltın.
- • Ajans–müşteri raporlama ritmini (haftalık/aylık/çeyrek) warehouse çıktılarıyla besleyin.
GA4 + GSC + Ads + CRM İçin BigQuery Şema & Pipeline Şablonu — SEO / Data Warehouse (v1.0)
Bu asset, SEO data warehouse’ı “MVP mantığıyla” kurmanız için basit bir şema, join mantığı ve pipeline adımları sunar. GA4 (davranış/dönüşüm), GSC (görünürlük), Ads (maliyet/verim) ve CRM (iş sonucu) verisini tek sözlükte birleştirerek Looker Studio gibi BI araçlarında ölçeklenebilir rapor üretmenizi sağlar. Çok markalı/çok kanallı yapılarda “tek gerçek” prensibini korumayı hedefler.
Kim Kullanır?
Çok kanallı otel ve B2B projeleri, raporlama hacmi yüksek ajanslar, kurum içi veri/SEO ekipleri.
Nasıl Kullanılır?
- MVP şemayı (dim + fact + mart) oluştur ve URL/site sözlüğünü standardize et.
- GA4 ve GSC’yi bağlayıp mart_seo_landing_daily üret; sonra Ads ve CRM’yi ekle.
- Looker Studio’da role-based dashboard seti kur; veri hijyeni ve change log rutinini ekle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ URL normalizasyon standardı yazılı
- ▢ ✅ site_id/brand_id sözlüğü hazır
- ▢ ✅ KPI sözlüğü tek (conversion tanımı sabit)
- ▢ ✅ Mart tablolar dashboard’a bağlanıyor
- ▢ ✅ Change log tutuluyor (event/schema değişikliği)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
8. Sonuç: SEO verisini tek gerçek üzerinden yönetin
BigQuery ve veri ambarı yaklaşımı, SEO raporlamasını panel kısıtlarından çıkarıp çok kaynaklı, uzun dönemli ve segment bazlı analiz seviyesine taşır. GA4, GSC, Ads ve CRM verisi aynı sözlükte birleştiğinde ekipler aynı gerçek üzerinden karar alır.
Başarılı kurulumun temeli; minimum viable şema, doğru URL/site normalizasyonu, sağlam pipeline ve BI katmanında tutarlı KPI sözlüğüdür. Küçük projelerde sade başlamak, büyük yapılarda ise fazlı büyümek en güvenli yoldur.
Bir Sonraki Adım
Çok kanallı otel ve B2B projelerinde SEO verisini tek havuzda toplayıp doğru dashboard mimarisi kurmak isteyen ekipler için.
Sık Sorulan Sorular
SEO için BigQuery ve veri ambarı kurmaya değer mi?▾
GA4 ve Search Console verisini BigQuery’de nasıl birleştiririm?▾
SEO data warehouse’ında hangi tablolar olmalı?▾
Looker Studio raporları veri ambarına bağlanınca ne kazanırım?▾
Küçük projelerde BigQuery yerine ne yapmalıyım?▾
Multi-brand otel gruplarında veri ambarı en çok nerede fayda sağlar?▾
İlgili İçerikler