1. Multi-domain ve multi-property yapı nedir?
Multi-domain; birden fazla domainin (ör. farklı otel siteleri veya farklı markaların siteleri) tek ölçüm stratejisinde ele alınmasıdır. Multi-property ise birden fazla otelin (ve çoğu zaman birden fazla markanın) aynı “grup” içinde yönetilmesidir. Özetle: domain sayısı dijital varlıkları; property sayısı ise işin organizasyonel ve raporlama sınırlarını anlatır.
Zincir otel örnekleri (mini)
- •Aynı grup altında farklı destinasyonlarda oteller: her biri ayrı domain
- •Aynı destinasyonda iki farklı marka: marka bazlı domainler
- •Tek marka, her otel için alt domain: hotelA.brand.com, hotelB.brand.com
Buradaki kritik soru şudur: “Bu yapıların raporda nasıl ayrışmasını istiyorum?” Eğer “otel bazlı P&L” gibi raporlar üretiyorsanız, segmentleme ihtiyacı artar. Eğer “grup genel performans” odaklıysanız merkezileştirme daha cazip olur.
Neden yanlış tanım pahalıya patlar?
Çünkü GA4 ve GTM tarafında verdiğiniz karar; ileride yeni otel eklerken “kopyala-yapıştır” mı yapacağınızı, yoksa “tek şablonla” mı büyüyeceğinizi belirler. Yanlış tasarım, ölçüm yapısını yeniden yazmaya kadar gidebilir.
Ne yapmalıyım?
- • Domain/marka/otel envanterini tek sayfada çıkarın.
- • Raporlamada “ayrıştırma anahtarı”nı seçin (hotel_code, brand, destination).
- • Yeni otel ekleme ve olası bölünme senaryosunu karar kriterlerine ekleyin.
- • Mimari seçimi “bugün” değil “2 yıl sonra” da çalışacak şekilde yapın.
2. Tek GA4 mülkü mü, birden fazla mı?
Bu karar, “veriyi nerede topluyoruz?” sorusudur. GA4’te bir mülk (property) tek bir ölçüm evreni gibidir; içindeki data stream’ler web/app kaynaklarıdır. Çok otelli yapılarda iki yaygın yaklaşım var:
Seçenek A — Tek GA4 mülkü + çoklu data stream / segmentleme (merkezi model)
Ne sağlar?
- •Standart metrik tanımları tek yerde (governance kolay)
- •Grup genel raporları hızlı çıkar
- •Ajans/merkez ekip tek mülkten yönetir
Ne ister?
- •Otel/marka ayrımı için güçlü bir “segment anahtarı” (örn. hotel_code)
- •Data stream ve domain ilişkisi net olmalı
- •Veri erişimi/yetki yönetimi iyi tasarlanmalı
Mini örnek: Tek mülkte tüm oteller var; raporda hotel_code ile filtreleniyor. Bu model “tek mi çok mu GA4 otel grubu” sorusunda merkezi yönetişimi seven gruplar için uygundur.
Seçenek B — Birden fazla GA4 mülkü (ayrışmış model)
Ne sağlar?
- •Hata izolasyonu ve otel bazlı kontrol daha güçlü
- •Otel bazlı ekipler “kendi mülkünde” daha rahat çalışır
- •Bir oteli satma/bölme gibi senaryolarda daha az operasyon
Ne ister?
- •Birden fazla mülk yönetimi (süreç ve bakım yükü)
- •Grup geneli rapor için birleştirme (BI / veri ambarı ihtiyacı artar)
- •Standartları aynı tutmak daha zor (drift riski)
“Her otel için ayrı data stream mi, tek property altında filtre mi?”
Bu soru genelde şu yanlış ikilemle gelir: “Ya hepsi ayrı olsun ya da hepsi aynı.” Pratikte daha esnek bir çözüm de mümkündür:
- •Tek mülkte data stream’leri otel bazlı ayırıp, raporda stream + hotel_code birlikte kullanmak
- •Ya da marka bazlı bir mülk + otel bazlı stream’ler (grup çok büyükse)
Ne yapmalıyım?
- • Önce rapor granülerliği kararını verin (otel/marka/grup).
- • Tek mülk düşünüyorsanız “segment anahtarını” zorunlu hale getirin (hotel_code).
- • Çoklu mülk düşünüyorsanız “standart sözlük” ve bakım ritmini yazın (drift’i engelleyin).
- • Gelecek planlarını (yeni otel ekleme, birleşme/bölünme) karara dahil edin.
3. Tek GTM container vs birden fazla container
GTM tarafındaki karar, “deploy riskini ve operasyon yükünü nasıl yöneteceğiz?” sorusudur. GA4 mülkü tek olsa bile GTM container’ları farklı kurgulanabilir; ama en sağlıklı mimari genelde “ölçüm sınırı” ile “deploy sınırı”nı tutarlı kılar.
Seçenek A — Tek GTM container (merkezi container)
Artıları
- •Tek yerden standart yönetim (tag governance)
- •Ortak şablonlar, daha hızlı yayılım
- •Ajans/merkez ekip için operasyon kolaylığı
Eksileri
- •Hata etkisi geniş: yanlış publish tüm otelleri etkileyebilir
- •Yetki yönetimi şart (herkes publish yapamaz)
- •Test/staging disiplini olmadan risk büyür
Seçenek B — Otel/marka başına GTM container (izole container)
Artıları
- •Hata izolasyonu yüksek: bir oteldeki hata diğerini etkilemez
- •Otel bazlı ekipler için kontrol alanı net
- •Farklı altyapılar varsa uyum daha kolay
Eksileri
- •Yönetim yükü artar (çok sayıda container)
- •Standartların dağılma riski (naming/trigger farkları)
- •Bir değişikliği tüm otellere yaymak daha yavaş
Otel bazlı naming ve klasörleme (multi-property pratiği)
Multi-property yapılarda tek container kullanıyorsanız, risk azaltmak için “otel kodu” ile isim standardı faydalıdır:
- •GA4 - Event - booking_complete - HTL_ANT_01 gibi
Ama ideal olan; tek tag + dataLayer’da hotel_code taşımaktır. Otel kodunu tag adına eklemek sadece teknik zorunluluk varsa tercih edilmelidir.
Ne yapmalıyım?
- • Merkezi yönetim istiyorsanız tek container + sıkı governance kurun (yetki, test, rollback).
- • Altyapılar çok farklıysa veya izolasyon kritikse çoklu container düşünün.
- • Seçimden bağımsız, “ortak sözlük + ortak QA”yı zorunlu kılın.
- • Multi-property büyüdükçe yılda en az 1 container mimarisi gözden geçirin.
4. Otel bazlı raporlama ihtiyaçları (karar verdiren kriterler)
“Mimari” tartışmasının özü rapordur. Çünkü GA4/GTM kararını en çok belirleyen şey, raporlama granülerliği ve operasyonel sorumluluk dağılımıdır. Aşağıdaki ihtiyaçlar, seçimi doğrudan etkiler:
Tipik rapor ihtiyaçları (5–7 madde)
- Otel bazlı rezervasyon ve gelir raporu (P&L yakın raporlama)
- Destinasyon bazlı performans (örn. şehir vs resort)
- Marka bazlı kanal karması (brand equity/awareness)
- Kanal bazlı optimizasyon (Google Ads / Meta / OTA)
- Çok dilli/pazar bazlı kırılım (TR/UK/DE gibi)
- Call center/WhatsApp kapanışının otel bazlı takibi
- Bütçe tahsisi: otel başına CAC/ROAS hedefleri
“Filtreleme ve raporlama kolaylığı” vs “hata izolasyonu”
- •Tek yapı: raporlama kolaylaşır; ama hata etkisi büyüyebilir.
- •Çoklu yapı: izolasyon artar; ama grup geneli rapor için ekstra katman (BI) gerekebilir.
Key Statistics / Data Point (sheet): Doğru mimari seçilmediğinde, ileride property/container bölme veya birleştirme süreçleri maliyetli ve riskli olabilir. Bu yüzden karar “hemen kurulum” değil “sürdürülebilirlik” perspektifiyle verilmelidir.
Ne yapmalıyım?
- • “Zorunlu raporlar” listesini çıkarın (10 satır).
- • Her rapor için “ayrıştırma anahtarı” belirleyin (hotel_code/brand/destination).
- • GA4 içi mi BI mı karar verin; çoklu mülkte BI ihtiyacı artar.
- • Rapor ihtiyacına göre mimariyi seçin; tersi değil.
5. Domain, property ve (görünüm) yapı örnekleri (pratik mimari senaryoları)
GA4’te “view” kavramı UA’daki gibi yok; ama raporlama ve erişim için farklı yaklaşımlar (segment, filter, audience, explorations, BI) kullanılır. Bu yüzden burada “yapı örnekleri”ni GA4 property/stream + GTM container üzerinden anlatalım.
Mimari Örnek 1 — Merkezi: Tek GA4 mülk + Tek GTM container
Ne zaman mantıklı?
- •Tek merkez ekip yönetiyor
- •Ortak booking engine ve benzer site altyapısı var
- •Hızlı standartlaşma hedefleniyor
Nasıl çalışır?
- •Tüm domainler aynı GA4 mülküne bağlı
- •DataLayer’da hotel_code zorunlu
- •GTM’de klasörleme + yetki + staging/publish disiplini zorunlu
Mimari Örnek 2 — Hibrit: Tek GA4 mülk + Çoklu GTM container
Ne zaman mantıklı?
- •Ölçüm evreni ortak (tek rapor dili)
- •Deploy riski izolasyonu isteniyor (otel bazlı publish)
- •Otel siteleri altyapı olarak farklılaşmış
Nasıl çalışır?
- •GA4 mülk tek; her otel ayrı container ile event gönderir
- •DataLayer sözlüğü aynı; aksi halde rapor parçalanır
- •QA rutini: her container aynı checklist’ten geçer
Mimari Örnek 3 — Ayrışmış: Çoklu GA4 mülk + Çoklu GTM container
Ne zaman mantıklı?
- •Oteller operasyonel olarak bağımsız
- •Satın alma/elden çıkarma (bölünme) ihtimali yüksek
- •Her otelde ayrı ajans/ekip çalışıyor
Nasıl çalışır?
- •Her otelin mülkü ayrı; otel ekibi özgür
- •Grup geneli rapor için BI katmanı zorunlu hale gelebilir
- •Standartları korumak için “merkezi sözlük” ve audit periyodu şart
Ne yapmalıyım?
- • Üç mimari örneği kendi yapınıza uyarlayın (en yakın olanı seçin).
- • Seçtiğiniz mimaride “zorunlu standartlar”ı yazın (hotel_code, naming, QA).
- • Yeni otel ekleme prosedürünü plana koyun (template üzerinden).
- • Birleşme/bölünme senaryosuna göre “taşıma planı” baştan düşünün.
6. Artı/eksi analizi ve “karar matrisi” ile net seçim
Bu bölüm “multi-property mimarisi nasıl seçilir?” sorusunu kriter bazlı kapatır. Aşağıdaki tablo, hızlı karar için en uygun tek tablodur.
Mimari seçenekler – Artı/Eksi Karşılaştırma Tablosu
| Seçenek | En iyi olduğu durum | Artılar | Eksiler | Risk profili |
|---|---|---|---|---|
| Tek GA4 + Tek GTM | Merkezi ekip + benzer altyapı | Standart ve hızlı yönetim, tek rapor dili | Hata etkisi geniş, governance şart | Orta–Yüksek (disiplin yoksa) |
| Tek GA4 + Çok GTM | Rapor birliği + deploy izolasyonu | Ölçüm tek yerde, otel bazlı publish kontrolü | Çok container yönetimi, QA yükü | Orta |
| Çok GA4 + Çok GTM | Oteller bağımsız + bölünme ihtimali | İzolasyon güçlü, otel bazlı kontrol | Grup raporu zor, standard drift | Düşük (izole) / Orta (drift) |
| Marka bazlı GA4 + otel bazlı stream | Çok marka + ortak rapor | Marka düzeyi yönetişim, otel segmenti | Tasarım karmaşıklığı | Orta |
Kriter bazlı karar listesi
Multi-property mimarisi nasıl seçilir? (kriterler):
- Rapor granülerliği: otel mi marka mı grup mu?
- Ekip yapısı: merkezi mi, otel bazlı mı, ajans sayısı kaç?
- Altyapı benzerliği: CMS/booking engine aynı mı?
- Hata izolasyonu ihtiyacı: yanlış publish’in etkisi ne kadar tolere edilebilir?
- Büyüme planı: 12–24 ayda kaç otel eklenecek?
- Birleşme/bölünme olasılığı: otel satışı/marka ayrışması var mı?
- BI kapasitesi: grup raporu için data warehouse/BI var mı?
Predictive keywords (doğal kullanım): Bu karar, “multi property ga4 otel” kurgularında en sık tartışılan konudur; “birden fazla otel icin gtm yapisi” seçimi ise deploy riskini belirler; “tek mi cok mu ga4 otel grubu” sorusunun cevabı her zaman bu kriterlere bağlıdır.
GA4/GTM Mimari Karar Matrisi Şablonunu İndir — SEM / Multi-Property Setup (v1.0)
Bu şablon, çok otelli ve çok domain’li yapılarda GA4 mülkü ve GTM container sayısını “hisle” değil, kriter bazlı puanlayarak seçmenizi sağlar. Marka/destinasyon yapısı, ekip modeli, rapor granülerliği, hata izolasyonu ve büyüme planlarını tek matriste toplar; karar sonrası uygulanacak governance maddelerini de kilitler.
Kim Kullanır?
Grup otel pazarlama lideri + ajans yöneticisi + teknik lider (ortak karar dokümanı).
Nasıl Kullanılır?
- Aşağıdaki kriterleri 0–5 arası puanlayın (0=önemsiz, 5=çok kritik).
- Her mimari seçeneğin “uygunluk puanını” çıkarın; en yüksek puanlı 1–2 opsiyonu shortlist yapın.
- Shortlist opsiyonları için “governance gereksinimleri” checklist’ini doldurun; karar verip yol haritasına bağlayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Shortlist (en yüksek 2): ___, ___
- ▢ ✅ Zorunlu segment anahtarı: hotel_code/brand/destination belirlendi
- ▢ ✅ Naming sözlüğü tek kaynak gerçek dokümanda kilitlendi
- ▢ ✅ Staging→prod test akışı tanımlandı
- ▢ ✅ Publish yetkileri sınırlandı (kim publish edebilir?)
- ▢ ✅ Rollback playbook yazıldı
- ▢ ✅ Yeni otel ekleme prosedürü (template) yazıldı
- ▢ ✅ Yıllık mimari gözden geçirme tarihi belirlendi (365)
- ▢ ✅ Kriterleri “bugün” değil “2 yıl sonrası” için de puanla.
- ▢ ✅ Puan verirken tek kişi değil, pazarlama+teknik birlikte karar ver.
- ▢ ✅ Shortlist opsiyonları mutlaka “yanlış publish” ve “yeni otel ekleme” senaryosunda test et.
- ▢ ✅ Seçim yaptıktan sonra governance checklist’i dolmadan kurulum sprint’ine başlama.
- ▢ ✅ Dokümanı versiyonla: v1.0 → v1.1 (değişiklikleri change log ile tut).
- ▢ ✅ Shortlist örneği: Tek GA4 + Çok GTM veya Çok GA4 + Çok GTM (BI kapasitesine göre)
- ▢ ✅ Deliverable
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Ne yapmalıyım?
- • Karar matrisiyle her seçeneği puanla (ekiplerle birlikte).
- • “En riskli 2 senaryoyu” simüle et: yanlış publish + yeni otel ekleme.
- • Seçtiğin mimari için minimum governance’ı yaz (yetki, QA, rollback).
- • 365 günlük gözden geçirme takvimi koy: özellikler ve ekip değiştikçe mimariyi güncelle.
7. Kapanış – Mimari karar “kurulum” değil, stratejik yatırımdır
Doğru GA4/GTM mimarisi seçilmediğinde, ileride bölme/birleştirme maliyetli ve riskli hale gelir. Bu yüzden karar; ekip yapısı, rapor granülerliği ve büyüme planı birlikte değerlendirilerek verilmelidir.
Bir Sonraki Adım
Zincir oteller ve grup yapılarında mimariyi doğru seçip sürdürülebilir ölçüm kurmak isteyen ekipler için.
Sık Sorulan Sorular
Birden fazla otel için GA4 nasıl yapılandırılmalı?▾
Tek mi çok mu GA4/GTM kullanmalıyım?▾
Multi-property otel yapısında raporlama nasıl kurgulanır?▾
Farklı domain’leri tek ölçüm yapısında toplayabilir miyim?▾
Tek container kullanırsam hata riski artar mı?▾
Çoklu GA4 mülkü kullanmanın en büyük dezavantajı nedir?▾
Mimari kararda “gelecek planı” neden önemli?▾
Kriter bazlı en basit seçim yöntemi nedir?▾
İlgili İçerikler
İlgili Yazılar