1. GTM container yapısı nasıl planlanır?
Net cevap : İyi bir GTM container yapısı; (1) klasörleme, (2) isimlendirme standardı, (3) ortam ayrımı (staging/prod), (4) versiyonlama ve (5) yayın öncesi test checklist’inden oluşur. Otellerde bu plan; rezervasyon motoru, çok dil ve çok otel senaryoları dikkate alınarak “büyüyebilir” şekilde tasarlanmalıdır.
“GTM mimarisi” dediğimiz şey tam olarak ne?
GTM arayüzünde üç ana varlık üzerinden yaşarsınız:
- •Tags: GA4 event, Ads conversion, Meta pixel vb. gönderimler
- •Triggers: Tag’in ne zaman çalışacağı (click, pageview, custom event)
- •Variables: Tag ve trigger’ın kullandığı değerler (DLV, URL, DOM, constants)
Mimari; bu üçlüyü “rastgele” değil, standart bir düzen içinde yönetmektir. Çünkü otel siteleri zamanla büyür: yeni kampanya sayfaları, yeni dil, yeni otel, yeni booking engine… Düzen yoksa, 3 ay sonra şu cümle başlar: “Bu tag’i kim ekledi, nerede çalışıyor, neden iki kez ateşliyor?”
Oteller için pratik “container blueprint”
Başlangıç için sürdürülebilir bir blueprint:
- •Klasörler: Kanal bazlı (GA4 / Ads / Meta) + amaç bazlı (Core Conversions / Micro Events / QA Tools)
- •Naming standardı: her varlık türü için sabit önekler
- •Ortam ayrımı: staging testi yapılmadan prod yayın yok
- •Dokümantasyon: her kritik değişiklikte versiyon notu + test kanıtı
Önerilen naming standardı (örnek)
Tag’ler:
- •GA4 - Event - booking_complete
- •GA4 - Event - click_whatsapp
- •ADS - Conversion - booking_complete
- •META - Pixel - lead
Trigger’lar:
- •TRG - CE - booking_complete (Custom Event)
- •TRG - PV - thank-you (Page View)
- •TRG - CLK - tel_link (Click)
Variable’lar:
- •VAR - DLV - transaction_id
- •VAR - DLV - value
- •VAR - CONST - currency_EUR
- •VAR - URL - page_path
Bu standardın değeri şudur: arama yaptığınızda her şey “tek dil” konuşur. Ajans, otel ve developer aynı isimleri görür.
Mini Check
- • Tag/trigger/variable için naming standardı yazılı mı?
- • Klasör düzeni “kanal + amaç” mantığıyla kurulmuş mu?
- • Staging test olmadan prod yayın yapılıyor mu? (yapılıyorsa risk)
- • Versiyon notu “ne değişti / neden / nasıl test edildi” içeriyor mu?
Ne yapmalıyım?
- • 1. Bir sayfalık “GTM sözlüğü” çıkar: klasörler + naming standardı.
- • 2. Container’ı bu standarda göre refactor et (1 sprint).
- • 3. Staging test adımını süreçte zorunlu hale getir.
- • 4. Her publish’i “versiyon notu + test kanıtı” ile kilitle.
2. Tek site vs çok site / çok otel senaryoları (multi-property)
Otel gruplarında GTM en çok burada zorlanır: tek bir web sitesi mi var, yoksa her otelin ayrı sitesi mi var? Rezervasyon motoru ortak mı, otel bazlı mı? Bu kararlar GTM mimarisini doğrudan etkiler. Burada “tek doğru” yok; ama doğru sorular var.
Senaryo 1 — Tek marka sitesi (tek domain) + tek booking engine
Bu en temiz senaryo. Genelde tek container yeterlidir. Yapmanız gerekenler:
- •Otel seçimi/site içi segment bilgisi varsa dataLayer’a koymak
- •Event’lerde property_id / hotel_code gibi bir alanla segmentlemek
- •Raporlamayı bu segmente göre kurmak
Risk: Segment alanı yoksa tüm oteller “tek otel” gibi görünür.
Senaryo 2 — Çok otel, çok domain (her otelin ayrı sitesi)
Bu senaryoda iki yaklaşım var:
A) Her siteye ayrı container
- •Artı: Risk izolasyonu (bir oteldeki hata diğerini etkilemez)
- •Eksi: Yönetim yükü (kopya işler artar)
B) Tek container + çok domain
- •Artı: Merkezi yönetim, standartlar tek yerde
- •Eksi: Hata yayılırsa etkisi büyük (governance şart)
Otel sayısı arttıkça, çoğu ekip “merkezi” ister; ama bunun bedeli disiplinli versiyonlama ve erişim yönetimidir.
Senaryo 3 — Çok dil / çok pazar (tek site)
Bu senaryoda GTM tarafında genelde “tek container” yeterli olur; kritik nokta:
- •Dil ve pazar bilgisinin rapora taşınması (language, market)
- •Bazı ülkelerde izin/consent davranışının farklı olması (etiket koşulları)
Çok otelli yapılarda naming önerisi (otel kodu ekleme)
Çok otelli bir yapıda, aynı event’in otel bazlı varyasyonları varsa isim standardı şu şekilde daha okunur olur:
- •GA4 - Event - booking_complete - HTL_A
- •GA4 - Event - booking_complete - HTL_B
Ama bu yaklaşımı “her şeyi çoğaltmak” için kullanmayın. İdeal olan; ortak event + dataLayer’da hotel_code. Çoğaltma ancak teknik zorunluluk varsa.
Mini Check
- • Otel sayısı ve site sayısı net mi? (kaç domain?)
- • Segment alanı var mı? (hotel_code / property_id)
- • Hata izolasyonu mu, merkezi yönetim mi öncelik?
- • Rezervasyon motoru ortak mı, otel bazlı mı?
Ne yapmalıyım?
- • 1. Önce senaryonu seç: tek domain mi, çok domain mi?
- • 2. Segment stratejini yaz: “ortak event + hotel_code” ideal.
- • 3. Çok domain + tek container yapıyorsan governance’ı sıkılaştır.
- • 4. Otel sayısı büyüdükçe yılda en az 1 mimari gözden geçirme yap.
3. Tag, trigger ve variable organizasyonu (klasörleme + sözlük)
Bu bölüm, günlük GTM kullanımını “daha az hata” ile yönetmenizi sağlar. Çünkü hataların önemli bir kısmı teknik değil, organizasyoneldir: yanlış trigger, yanlış variable, yanlış yerde çalışan tag.
Klasörleme mantığı: “kanal” + “işlev”
Sadece kanal bazlı klasör (GA4 / Ads / Meta) yetmez; aynı kanal içinde de işlev vardır. Önerilen ikili yapı:
- •01 - Core Conversions: booking_complete, lead, purchase benzeri
- •02 - Funnel/Micro Events: booking_start, view_room_detail, click_to_call
- •03 - QA & Debug: debug etiketleri, test tag’leri (sadece staging)
- •04 - Consent & Privacy: consent koşulları, tag firing kuralları
- •05 - Archive: deprecate edilmiş ama silinmemiş varlıklar (tarih notlu)
Bu yapı, “kritik varlıkları” güvenli bir yerde tutar.
Trigger tasarım prensipleri (otel özelinde)
- •Dar trigger iyidir: “contains” ile her yerde ateşleme yerine, net URL/selector
- •Custom event tercih et: booking engine ve SPA yapılarda daha güvenilir
- •Çift sayımı önle: aynı event’i hem page view hem custom event ile tetikleme (ya o, ya bu)
Variable yönetimi: “DLV-first” yaklaşımı
Otel projelerinde en iyi pratik, mümkün olduğunca dataLayer variables kullanmaktır. DOM’dan değer çekmek (CSS selector) kırılgandır; site tasarımı değişince ölçüm kırılır.
- •Önce dataLayer’a koy → sonra DLV ile kullan
- •Constant’ları (currency gibi) ayrı tut → yanlışlıkla değiştirmeyi zorlaştır
- •Variable isimlerini standartlaştır → mapping hatasını azalt
“Rakiplerin söylemediği” mini bölüm (competitor gap)
Birçok içerik GTM’yi “tag ekle, çalıştı” diliyle anlatır. Otel gibi gelir odaklı ve çok kanal içeren yapılarda asıl fark şudur:
- •GTM bir deployment pipeline gibi yönetilmezse, küçük hatalar “veri kirliliği”ne dönüşür.
- •Veri kirliliği sadece raporu bozmaz; optimizasyonu da bozar.
Bu yüzden klasörleme ve sözlük “nice to have” değil, “risk kontrol” katmanıdır.
Mini Check
- • Core conversion tag’leri tek klasörde mi?
- • Trigger’lar dar mı, “her yerde” çalışmıyor mu?
- • DOM variable sayısı gereksiz şişmiş mi? (kırılganlık)
- • Archive klasörü var mı (silmeden önce güvenli emeklilik)?
Ne yapmalıyım?
- • 1. Core conversions klasörünü kilitle: sadece yetkili kişi değiştirsin.
- • 2. Variable’larda DLV-first yaklaşımına geç (DOM’u azalt).
- • 3. Trigger’ları daralt: regex/equals kullan, contains’ı abartma.
- • 4. “Archive + change log” ile sürdürülebilir temizlik yap.
4. Versiyonlama mantığı (neden kritik, nasıl yapılır?)
Kısa cevap : Versiyon yönetimi, GTM’de her publish’in bir “snapshot” olarak kayıt altına alınması ve gerektiğinde geri dönülebilmesidir. Otellerde önemlidir çünkü yanlış bir tag yayınlamak, rezervasyon ölçümünü bozabilir ve kampanya optimizasyonunu yanlış sinyale sürükleyebilir.
Sheet’teki veri noktasıyla uyumlu bir gözlem: Düzenli versiyon yönetimi olan hesaplarda, hatalı yayınlardan sonra toparlanma süresi çok daha kısa olur. Bunun nedeni basit: neyin değiştiği kayıtlıdır ve geri dönüş adımı bellidir.
İyi bir versiyon notu nasıl yazılır?
Versiyon notu “publish yaptım” değildir. Üç soruyu cevaplamalı:
- Ne değişti? (hangi tag/trigger/variable)
- Neden değişti? (hangi hedef/KPI)
- Nasıl test edildi? (hangi senaryo, hangi kanıt)
Örnek format:
- •v2026.01.29-01 — “booking_complete tag’ine transaction_id eklendi; DebugView test edildi; staging’de 3 senaryo geçti.”
Versiyon stratejisi: küçük ve sık mı, büyük ve seyrek mi?
Otel ekipleri genelde “büyük release” ister; ajanslar “küçük ve kontrollü” ister. Risk azaltma açısından öneri:
- •Küçük ve kontrollü publish: daha az sürpriz
- •Her publish sonrası 24–72 saat “izleme”
- •Kritik sezon dönemlerinde publish penceresi (gece/yoğun saat dışı)
Ortam ayrımı: staging / prod
Staging ortamı yoksa versiyon yönetimi tek başına yetmez; çünkü test edemediğiniz şeyi yayınlarsınız. Minimum pratik:
- •Staging domain veya parametre ile test
- •GTM’de staging tag’lerini prod’da ateşlemeyecek şekilde koşullamak
- •QA tag’lerini “prod’da kapalı” tutmak
Mini Check
- • Versiyon notları “ne/neden/test” içeriyor mu?
- • Publish penceresi var mı? (yoğun saatler dışında)
- • Staging test rutini var mı?
- • Kritik sezon öncesi “freeze” kuralı uygulanıyor mu?
Ne yapmalıyım?
- • 1. Versiyon not şablonunu sabitle (3 soru).
- • 2. Küçük publish’leri tercih et; büyük değişiklikleri sprint’e böl.
- • 3. Staging test yoksa “prod’da test” riskini minimize et (kısıtlı yayın).
- • 4. Sezonda “tag freeze” uygulaması koy (sadece kritik fix).
5. Yayın (Publish) öncesi test süreci (checklist + onay akışı)
Bu bölüm, hataların %80’ini “yayınlamadan” yakalamanızı sağlar. Publish öncesi test, otellerde iki nedenle daha önemlidir:
- •Rezervasyon akışı tek bir tag hatasında tamamen bozulabilir (özellikle booking_complete).
- •Aynı GTM container bazen birden fazla oteli etkiler (multi-property risk).
Publish öncesi “altın sıra”
- GTM Preview: tag doğru tetikleniyor mu?
- GA4 DebugView: event GA4’e düşüyor mu, parametreler dolu mu?
- Kaynak doğruluğu: cross-domain/referral sapması var mı? (varsa yayın durur)
- Çift sayım kontrolü: aynı aksiyonda iki event oluşuyor mu?
- Onay: pazarlama + teknik (kimin hangi rolde onayladığı kayıtlı)
Yayın akışı tablosu (tek tablo – konuyla en uygun)
| Adım | Amaç | Sorumlu | Araç | Çıktı/Kanıt |
|---|---|---|---|---|
| 1. Değişiklik tasarımı | Ne yapılacak net | Ajans + Pazarlama | Plan/Not | Değişiklik listesi |
| 2. Staging uygulama | Prod riskini azalt | Dev / Ölçüm | GTM Workspace | Workspace linki |
| 3. Preview test | Trigger/tag doğruluğu | Ölçüm | GTM Preview | Ekran görüntüsü |
| 4. DebugView test | Event/parametre doğruluğu | Ölçüm | GA4 DebugView | Event kanıtı |
| 5. Cross-domain kontrol | Attribution sapmasını engelle | Ölçüm | GA4 rapor/real-time | Kaynak kontrolü |
| 6. Onay | Sorumluluk netliği | Pazarlama + Teknik | Onay notu | “OK” kaydı |
| 7. Publish | Yayına alma | Yetkili | GTM Publish | Versiyon numarası |
| 8. İzleme | Sapma var mı? | Ajans | Rapor/Alarm | 24–72 saat kontrol |
| 9. Rollback (gerekirse) | Hızlı toparlanma | Yetkili | GTM Versions | Geri dönüş kanıtı |
Kritik event’ler için “zorunlu test senaryoları”
En az 3 senaryo yazın (otel örneği):
- •Senaryo A: Kampanya sayfası → booking_start → booking_complete
- •Senaryo B: Oda detay → booking_start → booking_complete
- •Senaryo C: Mobil header → click_to_call / click_whatsapp (lead sinyali)
Mini Check
- • Preview + DebugView testleri kanıtlanıyor mu? (screenshot/not)
- • Cross-domain/referral sapması kontrol ediliyor mu?
- • Onay akışında “kim onayladı” kayıtlı mı?
- • Publish sonrası 24–72 saat izleme rutini var mı?
Ne yapmalıyım?
- • 1. Yayın öncesi test sırasını SOP yap (her seferinde aynı).
- • 2. Kritik event’ler için 3 senaryo yaz ve versiyon notuna ekle.
- • 3. Onayı “sözlü” değil “kayıtlı” hale getir.
- • 4. Publish sonrası izleme olmadan “tamamlandı” deme.
6. Rollback ve hata yönetimi (yanlış yayınladım, ne yapmalıyım?)
Kısa cevap : Yanlış bir şey yayınladıysanız, önce etkiyi sınırlayın (kritik dönüşüm mü bozuldu?), sonra bir önceki stabil versiyona rollback yapın, ardından staging’de kök nedeni düzeltip yeniden test ederek kontrollü yayınlayın.
Sesli arama senaryosu (“gtm’de yanlış bir şey yayınladım, ne yapmalıyım?”) için en kısa akış:
- •Hemen rollback → kritik dönüşümler geri geldi mi kontrol → kök neden analizi → staging’de düzelt → yeniden publish.
Rollback “panik butonu” değil, süreç adımıdır
Rollback’i “başarısızlık” değil, risk yönetimi olarak görün. İyi bir GTM operasyonu şu iki şeyi birlikte taşır:
- •Hızlı geri dönüş (rollback hazır)
- •Aynı hatanın tekrar etmemesi (kök neden + SOP güncelleme)
Hatalı yayınlarda en sık 5 kök neden
- Trigger çok geniş (yanlış sayfalarda çalıştı)
- Double fire (iki farklı tag aynı event’i gönderdi)
- Variable mapping bozuk (value/currency boş geldi)
- Consent koşulu yanlış (etiket hiç çalışmadı)
- Staging senaryosu prod’dan farklıydı (test yanıltıcı)
“Kök neden → kalıcı önlem” mini playbook
- •Trigger hatası → trigger daralt + regex/equals + test senaryosu güncelle
- •Double fire → tek kaynak event kuralı + tag sayısını azalt
- •Variable hatası → dataLayer sözlüğü + DLV-first yaklaşımı
- •Consent hatası → privacy klasörü + koşul standardı
- •Test farkı → staging prod parity kontrol listesi
Yönetim perspektifi: neden bu kadar önemli?
Dönüşüm hataları sadece “rapor sayısı”nı bozmaz; akıllı teklif stratejilerinin karar kalitesini de bozar. Bu yüzden rollback + yeniden test süreci, performans ekipleri için “operasyonel sigorta”dır.
Mini Check
- • Rollback adımı kimin yetkisinde? (net mi)
- • “Son stabil versiyon” tanımı var mı? (hangi versiyon?)
- • Rollback sonrası doğrulama senaryoları yazılı mı?
- • Kök neden analizi ve SOP güncellemesi yapılıyor mu?
Ne yapmalıyım?
- • 1. Rollback “1 sayfalık playbook” olarak yaz ve ekipte paylaş.
- • 2. Yetkileri sınırla: herkes publish yapamasın.
- • 3. Her hatadan sonra SOP’u güncelle (aynı hatayı ikinci kez yapma).
- • 4. Otel sayısı/ekip büyüklüğü değiştikçe GTM mimarisini tekrar gözden geçir.
7. Yetkiler ve erişim politikaları (governance katmanı)
GTM’de herkesin her şeyi düzenleyebildiği kontrolsüz yapılarda, küçük hataların bile ciddi veri sorunlarına yol açabileceği gerçeğini net kabul etmek gerekir. Bu yüzden minimum governance:
- •Role-based access: Publish yetkisi sınırlı
- •Change log: Kim neyi değiştirdi kayıtlı
- •Approval: Kritik değişiklikler onaysız yayınlanmaz
- •Environment discipline: Staging test zorunlu
İç link önerisi (Internal Link Targets ile uyumlu)
- •Dönüşüm takibi hub: https://dgtlface.com/tr/sem/donusum-takibi-tag-manager
- •Veri analiz ve raporlama: https://dgtlface.com/tr/veri-analiz-ve-raporlama (Varsayım: URL bu şekilde yayında.)
- •Web sitesi geliştirme: https://dgtlface.com/tr/yazilim/web-sitesi-gelistirme
8. Kapanış – GTM’yi “kurulum” değil “operasyon” olarak yönetin
GTM’de mimari + süreç + rollback disiplini kurduğunuzda, ölçüm hataları azalır; hata olursa da hızlı toparlanırsınız. Bu, doğrudan rapor güvenine ve optimizasyon kalitesine yansır.
9. GTM Yayın Öncesi Kontrol ve Rollback Checklist’ini İndir — SEM / GTM Governance
GTM Yayın Öncesi Kontrol ve Rollback Checklist’ini İndir — SEM / GTM Governance (v1.0)
Bu asset’in amacı, otel GTM operasyonunu “kontrollü yayın” seviyesine taşımaktır: yayın öncesi test adımlarını standartlaştırır, onay akışını netleştirir ve hata durumunda rollback’i panik değil süreç adımı haline getirir. Sonuç; veri kirliliğinin ve hatalı publish’lerin azalması, hatadan sonra toparlanmanın hızlanmasıdır.
Kim Kullanır?
Otel pazarlama/performans ekibi + ajans + GTM publish yetkilisi (gerekirse developer).
Nasıl Kullanılır?
- Her publish öncesi checklist’i uygula ve test kanıtını (screenshot/not) versiyon notuna ekle.
- Kritik event’ler için 3 senaryoyu (booking funnel + mobil lead) mutlaka çalıştır.
- Hata görürsen rollback yap; kök nedeni staging’de düzelt; yeniden test edip kontrollü yayınla.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Değişiklik kapsamı net mi? (hangi tag/trigger/variable)
- ▢ ✅ Core conversion’lar listelendi mi? (booking_complete, lead vb.)
- ▢ ✅ Bu yayın “kritik sezon” içinde mi? (publish penceresi uygun mu)
- ▢ ✅ Staging ortamı hazır mı? (test domain/parametre)
- ▢ ✅ Publish yetkisi olan kişi/rol net mi?
- ▢ ✅ Rollback yapılacak “son stabil versiyon” belirlendi mi?
- ▢ ✅ İzleme planı var mı? (24–72 saat kontrol)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Çok otelli/çok sayfalı yapılarda GTM risklerini azaltmak ve sürdürülebilir süreç kurmak isteyen ekipler için.
Sık Sorulan Sorular
GTM container mimarisi nasıl olmalı?▾
Oteller için GTM’de versiyon yönetimi neden önemli?▾
Publish öncesi hangi kontroller yapılmalı?▾
Hatalı tag yayına aldığımda ne yapmalıyım?▾
Tek site mi, her otel için ayrı container mı daha doğru?▾
Tag, trigger ve variable’ları nasıl organize etmeliyim?▾
Rollback planı nasıl hazırlanır?▾
GTM’de yetkiler nasıl ayarlanmalı?▾
Bu süreç ne sıklıkla gözden geçirilmeli?▾
İlgili Yazılar