GA4 ve GTM Dönüşüm Auditi Adım Adım Nasıl Yapılır?

Q: GA4 ve GTM dönüşüm audit’i adım adım nasıl yapılır?

Önce measurement plan ve envanter çıkarılır; GA4 property/stream, event–conversion ve parametreler kontrol edilir; GTM tag/trigger/variable denetlenir; cross-domain/referral ve data hygiene doğrulanır; bulgular aksiyon planına dönüştürülür.

Q: Hangi event ve tag’leri kontrol etmeliyim?

Öncelik makro dönüşümlerdedir: booking_complete/purchase ve form_submit gibi. Gelir parametreleri (value/currency/transaction_id), double-fire riski ve geniş trigger’lar özellikle kontrol edilmelidir.

Q: Audit sonrası ne değişir?

Gereksiz event/tag’ler temizlenir, eksik conversions’lar tamamlanır, double-fire ve cross-domain sorunları düzeltilir. Rapor sapmaları azalır ve kampanya optimizasyonu daha güvenilir veriyle yapılır.

1. Niye audit gerekir?

Kısa cevap : Audit; ölçüm yapınızın doğru çalıştığını kanıtlar, yanlış/eksik event’leri ve sapma nedenlerini bulur, dönüşüm verisini güvenilir hale getirir. Bu da kampanya optimizasyon kararlarını doğrudan iyileştirir.

Audit’i gerekli yapan tipik sinyaller

•Ads/GA4/PMS rakamları aşırı sapıyor
•Conversion sayısı “anormal” dalgalanıyor
•ROAS bir anda uçuyor veya çöküyor
•Rezervasyon motoru değişti, kimse ölçümü güncellemedi
•GTM’de yıllardır biriken tag/trigger “çöplüğü” var

Mini Check

• Rapor sapması son dönemde arttı mı?
• Yeni engine/site release sonrası sayı bozuldu mu?
• Conversion seti şişti mi?
• GTM’de kim neyi neden ekledi bilinmiyor mu?

Ne yapmalıyım?

• Audit’i “kriz” değil “periyodik bakım” olarak planla (365).
• Önce envanter çıkar; sonra düzelt.
• Düzeltmeleri staging’de test etmeden prod’a taşıma.
• Sonucu aksiyon planı + versiyon notu ile dokümante et.

2. Audit öncesi hazırlık (measurement plan + envanter)

Audit’in ilk adımı “ne var?” sorusudur. Ölçüm planınız yoksa veya güncel değilse, audit sadece “tag listesi”ne döner; ama karar verdirmez.

Audit dosyasına koyacağınız 3 giriş belgesi

Measurement plan (v1.0): hedef–KPI–event haritası
Event sözlüğü: event adı + parametre + tetik yeri
Rapor beklentisi: PMS/engine/Ads hedef KPI’lar

Envanter çıkarma (pratik)

•GA4: mevcut event’ler, conversions, data stream ayarları
•GTM: tag/trigger/variable listesi + klasörleme
•Domain: ana site + booking engine + staging
•Uygulamalar: call tracking/CRM/offline conversions varsa not

Audit hazırlık ve envanter adımlarını otel ölçümünde ayıran görsel

Mini Check

• Measurement plan güncel mi? (son 6–12 ay)
• Event sözlüğü tek kaynak gerçek mi?
• Envanter listesi (GA4 + GTM) çıkarıldı mı?
• Domain/engine/staging haritası yazıldı mı?

Ne yapmalıyım?

• Ölçüm planı yoksa audit’ten önce mini plan çıkar (1 sayfa yeter).
• Envanteri “kopyala-yapıştır” değil, owner ve amaç ile yaz.
• Gereksiz event/tag’leri işaretle (silmeden önce archive).
• Audit çıktısını “aksiyon listesi”ne bağlayacağını baştan yaz.

3. GA4 yapısının kontrolü (property, data stream, events, conversions)

Bu bölümde amaç: GA4’ün temel yapı taşları doğru mu? Otellerde en kritik GA4 kontrol başlıkları şunlardır:

1) Property ve Data Stream

•Doğru domainler ölçülüyor mu?
•Currency ayarı doğru mu? (çoklu para birimi riski)
•Staging verisi prod’a karışıyor mu?

2) Events ve Conversions

•Measurement plan’daki macro conversion’lar var mı?
•booking_complete / purchase tekil mi (double fire yok)?
•Lead/form, call/WhatsApp event’leri tutarlı mı?
•Gereksiz event’ler raporu şişiriyor mu?

3) Parametre doğruluğu (gelir katmanı)

•value number formatında mı?
•currency her dönüşümde geliyor mu?
•transaction_id ile tekilleştirme var mı?

4) Debug ve doğrulama (spot test)

•DebugView’da event + parametre görünüyor mu?
•Gerçek zamanlı raporda tutarlılık var mı?

Teknik not: Audit sırasında yapılacak değişiklikleri prod’da rastgele uygulamak yerine, ayrı bir versiyonda tutup önce test ortamında denemek gerekir.

Mini Check

• Currency ve value tutarlı mı?
• Conversions seti sade mi (2–5 makro)?
• Staging/test verisi karışmıyor mu?
• DebugView’da booking_complete payload doğrulandı mı?

Ne yapmalıyım?

• Önce GA4 temel ayarlarını (stream/currency) doğrula.
• Sonra conversion setini sadeleştir ve tekilleştir.
• Gelir parametrelerini kontrol et (value/currency/ID).
• Değişiklikleri staging’de test edip kontrollü yayınla.

4. GTM container kontrolü (tag, trigger, variable)

GTM tarafında audit’in amacı “kaç tag var?” değil; hangi tag neden var, nerede çalışıyor, risk üretir mi? sorusunu cevaplamaktır.

1) Container mimarisi ve naming

•Klasörleme var mı (Core conversions / Micro events / QA)?
•Tag/trigger/variable naming standardı tutarlı mı?
•Archive/Deprecated alanı var mı?

2) Tag kontrolü

•GA4 event tag’leri doğru event adını mı gönderiyor?
•Ads/Meta tag’leri çakışıyor mu?
•Aynı event iki farklı tag’den mi gidiyor? (double fire riski)

3) Trigger kontrolü

•Trigger’lar dar mı, yoksa “her yerde” mi ateşliyor?
•booking_complete tetik noktası net mi? (thank you vs dataLayer)
•SPA/booking engine akışında custom event kullanılıyor mu?

4) Variable kontrolü

•DLV-first mi, DOM’dan kırılgan çekim mi?
•value/currency/transaction_id mapping doğru mu?
•Constant değerler yanlışlıkla değiştirilebilir mi?

GTM container ve GA4 yapı kontrolünü ayıran otel audit görseli

Mini Check

• Double fire riski olan tag’ler işaretlendi mi?
• Trigger’lar daraltıldı mı?
• Variable mapping (value/currency) doğru mu?
• Değişiklikler ayrı bir workspace/versiyonda mı?

Ne yapmalıyım?

• Core conversion tag’lerini izole klasöre taşı ve kilitle.
• Double fire üreten yapıları düzelt (tek kaynak event kuralı).
• DLV-first yaklaşımıyla kırılgan DOM variable’ları azalt.
• Publish öncesi Preview kanıtı olmadan yayına alma.

5. Cross-domain ve referral kontrolü (otel rezervasyon gerçeği)

Otel projelerinde sapmanın en sık kaynağı: booking engine farklı domain/subdomain ve cross-domain yanlış. Bu, attribution’ı bozar; direct/referral şişer; rapor farklılaşır.

Kontrol listesi

•booking engine referral olarak görünüyor mu?
•Oturum bölünmesi var mı?
•Referral exclusion ve cross-domain yapılandırması doğru mu?
•Rezervasyon onayı event’i doğru domain/akışta mı?

İpucu: “Sapma” ile “hata”yı ayır

Bazı farklar metodoloji farkıdır; cross-domain bozukluğu ise gerçek hatadır. Audit’te amaç ikisini ayırmaktır.

Mini Check

• Booking engine referral listesinde mi?
• GA4’te source/medium kayıyor mu?
• Rezervasyon akışı test senaryosuyla doğrulandı mı?
• Cross-domain düzeltmesi staging’de test edildi mi?

Ne yapmalıyım?

• Cross-domain’i düzeltmeden kanal raporlarına güvenme.
• Test senaryosu yaz: Ads tıklama → booking → onay.
• Referral sapması düzeldikten sonra raporu kıyasla.
• Her engine güncellemesinde yeniden kontrol et.

6. Rapor ve KPI’ların uyum kontrolü + Quick Wins

GA4 GTM audit akışını envanterden aksiyon planına otel için gösteren diyagram

Audit’in çıktısı “hata listesi” değil; önceliklendirilmiş aksiyon planı olmalı.

KPI uyumu (tek sayfada kontrol)

•PMS direct revenue vs GA4 booking value (aylık kıyas)
•Ads conversion value vs GA4 value (trend kıyas)
•Funnel: booking_start → booking_complete dönüşüm oranı
•İç/test/bot trafiği veri hijyeni (etiket/filtre)

Quick Wins (en hızlı etki)

•Double fire kapat (gelir şişmesini düzeltir)
•Currency/value formatını düzelt (ROAS yorumunu temizler)
•Conversion setini sadeleştir (algoritma sinyali netleşir)
•Staging verisini ayır (rapor güveni artar)
•Trigger daralt (yanlış sayfada event çalışmasını durdurur)

Key Statistics / Data Point: İyi yapılmış bir audit sonrası, dönüşüm verisinde %5–20 arası sapmaların düzeltilmesi bazı hesaplarda mümkün olabilir; bu da optimizasyon kararlarını doğrudan iyileştirir. (Kesin garanti değil; sapmanın kaynağına bağlıdır.)

Sapma double fire currency ve cross-domain audit KPI kartı

Bulgular & Aksiyon Planı (impact/effort)

B) Bulgular & Aksiyon Planı (impact/effort)

Bulgu	Etki (Impact)	Efor (Effort)	Öncelik	Çözüm	Test	Sahip
—	—	—	—	—	—	—

Mini Check

• Bulgular Impact/Effort ile önceliklendirildi mi?
• Değişiklikler staging’de test edildi mi?
• Versiyon notu ve rollback planı var mı?
• 30 gün izleme ve aylık bakım ritmi tanımlı mı?

Ne yapmalıyım?

• Audit bulgularını “quick wins” ve “proje işleri” diye ayır.
• Tüm değişiklikleri ayrı versiyonda tut ve test et.
• Yayın sonrası 24–72 saat izleme yap, sonra aylık rutine bağla.
• Audit’i 365 döngüsünde güncelle (GA4/GTM değiştikçe).

7. Dönüşüm Audit Checklist & Aksiyon Planı Şablonunu İndir — GA4 + GTM Audit

Dönüşüm audit checklist ve quick wins adımlarını otel için özetleyen kart

PDFv1.0Checklist + Sprint

Dönüşüm Audit Checklist & Aksiyon Planı Şablonunu İndir — GA4 + GTM Audit (v1.0)

Bu şablon, GA4 ve GTM dönüşüm audit’ini otel ölçüm projelerine uyarlanmış bir sağlık kontrolü formatında yürütmenizi sağlar. Envanter çıkarma, GA4 yapı kontrolü, GTM container denetimi, cross-domain/referral kontrolü ve rapor–PMS uyum kıyası adımlarını tek listede toplar; bulguları impact/effort ile önceliklendiren aksiyon planına dönüştürür. Audit sırasında yapılan değişikliklerin ayrı bir versiyonda tutulması ve önce test ortamında denenmesi kuralını da kilitler.

Kim Kullanır?

Otel pazarlama/ajans + developer/QA + raporlama (ortak audit dokümanı).

Nasıl Kullanılır?

Envanteri doldur (GA4 + GTM + domain/engine).
Checklist’i sırayla uygula; her bulgu için kanıt ve risk notu ekle.
Bulguları quick wins / proje işleri diye ayır; staging’de test edip kontrollü yayınla.

Ölçüm & Önceliklendirme (Kısa sürüm)

PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu

Şablonu İndir ↓Ücretsiz • PDF / Excel

8. Audit, ölçümü “güvenilir” yapar

Audit raporu ve aksiyon planı deliverables çıktısını otel için özetleyen kart

GA4+GTM audit’i, ölçüm altyapınızın sürdürülebilirliğini artırır: gereksiz event’leri temizler, eksik dönüşümleri bulur, rapor sapmalarını azaltır ve optimizasyon kararlarını daha güvenli hale getirir.

Bir Sonraki Adım

Ölçüm yapınızın doğru çalıştığından emin olmak ve sapmaları azaltmak isteyen oteller ve ajans ekipleri için.

GA4 + GTM Dönüşüm Audit Hizmeti Talep Et →

Sık Sorulan Sorular

Dönüşüm audit’i nedir, neden yapılmalı?▾

Dönüşüm audit’i, ölçüm yapınızın planlandığı gibi çalışıp çalışmadığını kontrol eder. Hatalı/eksik dönüşümleri ve rapor sapmalarını bulup optimizasyon kararlarının güvenilir olmasını sağlar.