İzmir Şirketleri İçin GA4 Event Taxonomy, Data Layer ve Marketing Tracking Plan Rehberi
Ölçüm Sorunu Çoğu Zaman GA4'te Değil, Ölçüm Planında Başlar
Birçok şirkette Google Analytics 4, Google Tag Manager, Meta Pixel ve Google Ads Conversion Tracking teknik olarak kurulu olabilir.
Ancak birkaç ay sonra raporlara bakıldığında şu sorunlarla karşılaşılır:
Aynı form üç farklı isimle ölçülüyor.
Bazı butonlar event gönderirken bazıları göndermiyor.
Purchase değeri ile e-ticaret sistemi cirosu uyuşmuyor.
UTM kaynakları birbirinden farklı yazılıyor.
Bir ekip "form_submit", başka ekip "lead_form", diğer ekip "generate_lead" kullanıyor.
Sonuçta teknik olarak çok fazla veri vardır ancak güvenilir analiz yapılamaz.
İzmir GA4 event tracking altyapısında en önemli adımlardan biri kod yazmadan önce hangi davranışın neden ve nasıl ölçüleceğini tanımlamaktır.
1. Tracking Plan Nedir?
Tracking Plan, web sitesi veya uygulamada hangi kullanıcı davranışlarının ölçüleceğini tanımlayan dokümandır.
Basit bir tracking plan şu alanları içerebilir:
Event Name
Event Description
Trigger
Parameters
Data Type
Platform
Business Purpose
Owner
QA Status
Böylece ölçüm sistemi geliştirici, reklam ekibi ve analytics ekibinin hafızasına bağlı kalmaz.
2. Önce İş Sorusu, Sonra Event
En sık yapılan hatalardan biri mümkün olan her tıklamayı ölçmeye çalışmaktır.
Analytics sisteminin amacı daha fazla event üretmek değildir.
Önce iş sorusu belirlenmelidir.
Örneğin:
Kullanıcıların kaçı fiyat sayfasını görüntülüyor?
Hangi hizmet sayfasından daha fazla kaliteli lead geliyor?
Checkout'ın hangi aşamasında kullanıcı kaybediliyor?
WhatsApp butonuna hangi kampanyadan gelen kullanıcılar tıklıyor?
Daha sonra bu soruları cevaplayacak event yapısı oluşturulmalıdır.
3. Event Taxonomy Nedir?
Event Taxonomy, tracking sistemindeki event isimlerinin ve parametrelerinin ortak bir standart içerisinde tanımlanmasıdır.
Örneğin aynı davranış için:
formSubmit
Form_Send
submit_form
lead_sent
gibi farklı isimlerin kullanılmasını engeller.
Tüm ekip tek bir standart kullanır.
Örneğin:
generate_lead
Bu sayede raporlama, BigQuery ve reklam entegrasyonları daha sürdürülebilir hale gelir.
4. Google'ın Recommended Events Yapısını Önceliklendirin
GA4 içerisinde mümkün olduğunda Google'ın önerdiği event isimlerinin kullanılması faydalıdır.
Örneğin e-ticarette:
view_item
add_to_cart
view_cart
begin_checkout
add_payment_info
purchase
refund
gibi event'ler kullanılabilir.
Lead generation tarafında ise:
generate_lead
login
sign_up
search
share
gibi standart event'ler bulunur.
Google önerilen event'lerin ilgili parametrelerle birlikte kullanılmasının hazır raporlar ve gelecekteki entegrasyonlardan daha fazla yararlanmayı sağlayabileceğini belirtmektedir.
5. Her Şeyi Custom Event Yapmayın
GA4 içerisinde önerilen event mevcutsa aynı davranış için gereksiz custom event oluşturmak veri yapısını karmaşıklaştırabilir.
Örneğin satın alma için:
order_complete
yerine:
purchase
kullanmak genellikle daha sağlıklı olacaktır.
Custom event yalnızca mevcut GA4 event modelleri ihtiyacı karşılamadığında kullanılmalıdır.
6. Event İsimleri Case Sensitive'dir
GA4 event isimleri büyük ve küçük harfe duyarlıdır.
Örneğin:
generate_lead
Generate_Lead
iki farklı event olarak değerlendirilebilir.
Bu nedenle event naming convention belirlenmeli ve bütün ekip aynı yazım standardını kullanmalıdır.
7. Event Naming Convention Nasıl Olmalı?
Pratik yaklaşım:
küçük harf kullan,
kelimeleri underscore ile ayır,
Türkçe karakter kullanmaktan kaçın,
eylemi açık anlat,
gereksiz varyasyon oluşturma.
Örneğin:
contact_form_submit
pricing_cta_click
whatsapp_click
download_case_study
Ancak GA4 önerilen event'i varsa öncelikle o isim kullanılmalıdır.
8. Event ile Parameter Arasındaki Fark
Her küçük farklılık için yeni event oluşturmak yerine parametre kullanılabilir.
Örneğin:
Event:
generate_lead
Parameters:
form_name = contact
service = google_ads
lead_type = consultation
page_type = service
Böylece tek event altında farklı form türleri analiz edilebilir.
9. Parametre Kullanmak Neden Daha Sağlıklı?
Her hizmet için ayrı event oluşturduğunuzu düşünelim:
google_ads_form
meta_ads_form
seo_form
web_design_form
production_form
Bu yapı büyüdükçe yüzlerce event oluşabilir.
Daha sağlıklı yapı:
generate_lead
service = google_ads
şeklindedir.
Event davranışı, parameter ise davranışın bağlamını anlatır.
10. Data Layer Nedir?
Data Layer, web sitesi ile Google Tag Manager arasında çalışan yapılandırılmış veri katmanıdır.
Web sitesindeki önemli davranış ve ticari bilgiler data layer içerisine aktarılabilir.
Örneğin:
event adı,
ürün bilgisi,
sipariş tutarı,
form tipi,
müşteri tipi,
sayfa kategorisi
data layer üzerinden GTM'e iletilebilir.
11. DOM Scraping Yerine Data Layer
Google Tag Manager ile sayfadaki HTML elementlerinden veri okumak mümkün olabilir.
Ancak tasarım değiştiğinde class veya element yapısı değişebilir ve tracking bozulabilir.
Data Layer web sitesinin tasarımından daha bağımsız bir ölçüm katmanı oluşturur.
Örneğin ürün fiyatını HTML içerisinden okumak yerine backend veya frontend uygulaması:
value: 2499.90
şeklinde doğrudan data layer'a gönderebilir.
12. E-Ticaret Data Layer Örneği Nasıl Düşünülmeli?
Bir kullanıcı ürünü görüntülediğinde veri katmanında şu bilgiler bulunabilir:
Event → view_item
Item ID → SKU12345
Item Name → Erkek Koşu Ayakkabısı
Category → Spor Ayakkabı
Price → 2.499 TL
Currency → TRY
Sepete eklendiğinde event:
add_to_cart
olarak değişir.
Böylece bütün e-ticaret funnel'ı ortak ürün kimlikleriyle ölçülebilir.
13. SKU Kimliği Neden Her Sistemde Aynı Olmalı?
Web sitesinde ürün:
SKU123
Merchant Center'da:
ABC-123
ERP'de:
45893
olarak kayıtlıysa farklı veri kaynaklarını eşleştirmek zorlaşır.
Mümkünse ortak product identifier yapısı kullanılmalıdır.
Bu özellikle GA4 + Merchant Center + BigQuery + ERP analizlerinde kritik hale gelir.
14. Purchase Event İçerisinde Neler Bulunmalı?
Purchase event'i e-ticaret measurement sisteminin en kritik event'lerinden biridir.
Temel alanlar arasında:
transaction_id
value
currency
items
yer alabilir.
İhtiyaca göre:
coupon
shipping
tax
gibi alanlar da gönderilebilir.
En kritik noktalardan biri transaction_id'nin benzersiz olmasıdır.
15. Duplicate Purchase Problemi
Kullanıcı teşekkür sayfasını yenilediğinde purchase event yeniden tetiklenirse aynı sipariş iki kez ölçülebilir.
Bu durum:
GA4 gelirini,
Google Ads conversion value'yu,
ROAS'ı
yapay biçimde artırabilir.
Purchase measurement sipariş kimliği ve uygulama mantığı kullanılarak duplicate event riskine karşı test edilmelidir.
16. Lead Form Tracking Sadece Submit Butonuna Bağlanmamalı
Kullanıcının submit butonuna tıklaması formun başarılı biçimde gönderildiği anlamına gelmez.
Formda validation hatası olabilir.
Bu nedenle lead conversion mümkünse gerçek başarılı form gönderimi sonrasında tetiklenmelidir.
Örneğin:
Backend success response
veya
Form Success Callback
üzerinden event oluşturulabilir.
17. Form Start ve Form Submit Ayrı Ölçülebilir
Formu açan veya doldurmaya başlayan kullanıcıların kaçı tamamlıyor?
Bunun için funnel kurulabilir:
form_start
↓
generate_lead
Örneğin:
1.000 Form Start
400 Submit
Form Completion Rate → %40
Bu veri CRO çalışmaları için değerlidir.
18. WhatsApp Tıklaması Lead midir?
Her WhatsApp tıklamasını doğrudan lead olarak saymak yanlış olabilir.
Kullanıcı butona tıklamış ancak mesaj göndermemiş olabilir.
Bu nedenle measurement hierarchy kurulabilir.
whatsapp_click → Micro Conversion
qualified_conversation → Lead
opportunity → Sales Conversion
Böylece reklam algoritması ile yönetim raporu aynı davranışı farklı anlamlarda kullanmaz.
19. Micro Conversion ve Macro Conversion
Her kullanıcı aksiyonu eşit değerde değildir.
Micro Conversion:
video izleme,
fiyat sayfası görüntüleme,
PDF indirme,
WhatsApp tıklama.
Macro Conversion:
lead,
randevu,
satın alma,
qualified opportunity.
Reklam teklif algoritmalarının hangi conversion'lara optimize edildiği dikkatli seçilmelidir.
20. GA4 Key Event Nedir?
GA4 içerisinde işletme açısından önemli event'ler Key Event olarak işaretlenebilir.
Ancak her event'i key event yapmak doğru değildir.
Örneğin:
page_view
scroll
gibi düşük ticari değerli aktiviteleri key event yapmak conversion raporlarını gereksiz biçimde şişirebilir.
Key event yapısı işletmenin gerçek hedefleriyle uyumlu olmalıdır.
21. GA4 Custom Dimensions
Custom parameter toplamak tek başına bu parametrenin standart GA4 raporlarında kolayca kullanılacağı anlamına gelmez.
İhtiyaç duyulan kategorik özel parametreler custom dimension olarak kayıt edilebilir.
Örneğin:
lead_type
customer_type
content_category
form_name
gibi alanlar custom dimension haline getirilebilir.
Ancak gereksiz custom dimension oluşturmak property limitlerini tüketebilir.
22. Her Parameter Custom Dimension Olmak Zorunda Değil
Özellikle BigQuery kullanan şirketlerde bütün parametreleri GA4 UI içerisinde custom dimension olarak tanımlamak gerekmeyebilir.
Parametre BigQuery event data içerisinde analiz edilebilir.
GA4 UI'da düzenli olarak raporlanacak alanlar custom dimension olarak seçilebilir.
Bu yaklaşım custom definition limitlerinin daha verimli kullanılmasını sağlar.
23. User Property Ne Zaman Kullanılmalı?
Event parameter belirli bir aksiyonun bağlamını anlatır.
User Property ise kullanıcı hakkında daha kalıcı bir özelliği temsil edebilir.
Örneğin:
customer_type = premium
veya:
membership_type = business
gibi özellikler uygun senaryolarda user property olarak kullanılabilir.
Ancak kişisel tanımlayıcı bilgilerin GA4'e gönderilmemesi gerektiği unutulmamalıdır.
24. PII Analytics'e Gönderilmemeli
Kullanıcıların:
e-posta adresi,
telefon numarası,
adı soyadı
gibi kişisel olarak tanımlanabilir bilgiler Analytics event parameter'larına gelişigüzel gönderilmemelidir.
CRM ve advertising eşleştirme sistemleri farklı veri politikalarına ve teknik yöntemlere sahiptir.
Analytics tracking plan hazırlanırken hangi verinin hangi sisteme gönderilebileceği açıkça tanımlanmalıdır.
25. UTM Governance Nedir?
UTM parametreleri reklam ve kampanya trafiğinin kaynak bilgisini taşır.
Ancak ekip içerisinde standart yoksa veriler kısa sürede parçalanır.
Örneğin:
utm_source=instagram
utm_source=Instagram
utm_source=ig
utm_source=meta
aynı trafik dört farklı kaynak gibi raporlanabilir.
Bu nedenle şirket genelinde UTM Governance standardı oluşturulmalıdır.
26. UTM Naming Convention Örneği
Basit standart:
utm_source → platform
utm_medium → kanal tipi
utm_campaign → kampanya adı
utm_content → kreatif / reklam
utm_term → keyword / targeting
Örneğin:
utm_source=linkedin
utm_medium=paid_social
utm_campaign=b2b_lead_generation
utm_content=crm_carousel_v2
Bu yapı CRM ve analytics attribution analizini kolaylaştırır.
27. Kampanya İsimlerinde Tarih Kullanılmalı mı?
Kampanya adlandırma sistemi işletmeye göre değişebilir.
Örneğin:
TR_B2B_GOOGLE_SEARCH_LEADGEN_2026Q4
gibi yapı:
ülke,
iş birimi,
platform,
kampanya tipi,
hedef,
dönem
bilgilerini tek isimde taşıyabilir.
En önemli nokta ekip içerisindeki bütün kullanıcıların aynı standardı uygulamasıdır.
28. Referrer Trafiği Attribution'ı Bozabilir
Ödeme sağlayıcısından siteye geri gelen kullanıcı bazı yanlış kurulumlarda yeni referral session olarak ölçülebilir.
Bu durumda gerçek acquisition source kaybolabilir.
Özellikle e-ticaret ve ödeme altyapılarında unwanted referrals / cross-domain measurement yapıları kontrol edilmelidir.
Analytics QA yalnızca event'lerin çalışmasına değil attribution'ın korunmasına da bakmalıdır.
29. Cross-Domain Tracking
Kullanıcı birden fazla domain arasında ilerliyorsa aynı kullanıcı yolculuğu parçalanabilir.
Örneğin:
www.marka.com
↓
booking.marka.com
↓
payment.marka.com
gibi yapı varsa cross-domain measurement gerekebilir.
Aksi halde aynı kullanıcı üç ayrı session gibi görünebilir.
30. Tracking QA Nedir?
Tracking yayına alınmadan önce test edilmelidir.
QA sürecinde:
event doğru anda tetikleniyor mu?
iki kez tetikleniyor mu?
parametre değerleri doğru mu?
currency doğru mu?
transaction_id var mı?
consent durumu uygulanıyor mu?
mobil ve desktop aynı mı?
kontrol edilmelidir.
Ölçüm sistemi test edilmeden reklam algoritmasına veri göndermek risklidir.
31. DebugView ve Tag Assistant
GA4 DebugView ve Google Tag Assistant event tracking kurulumlarını test etmek için kullanılabilir.
Event'in:
doğru isimle,
doğru parametrelerle,
doğru sırada
gönderilip gönderilmediği kontrol edilebilir.
Ancak yalnızca tarayıcı testinin yeterli olmadığı durumlarda backend, server-side ve BigQuery verileri de karşılaştırılmalıdır.
32. Data Reconciliation Nedir?
Analytics verisi işletmenin gerçek sistemleriyle karşılaştırılmalıdır.
Örneğin:
E-Ticaret Sistemi → 1.000 sipariş
GA4 → 940 purchase
Google Ads → 420 attributed purchase
Bu değerlerin tamamen aynı olması beklenmeyebilir çünkü sistemlerin attribution ve measurement yöntemleri farklıdır.
Ancak aradaki farkın neden oluştuğu anlaşılmalıdır.
Özellikle ani ve büyük sapmalar tracking problemi gösterebilir.
33. Tracking Coverage KPI'ı
Ölçüm altyapısının sağlığı ayrıca KPI olarak izlenebilir.
Örneğin:
Backend Orders → 10.000
GA4 Purchases → 9.600
Tracking Coverage → %96
Bu oran zaman içerisinde düşmeye başlarsa teknik ekip uyarılabilir.
Böylece tracking problemi reklam performansı düşmeden fark edilebilir.
34. Data Layer Versioning
Web sitesindeki data layer yapısı zaman içerisinde değişebilir.
Yeni ürün alanları eklenebilir veya event mantığı güncellenebilir.
Bu nedenle tracking schema versiyonlanabilir.
Örneğin:
tracking_schema_version = 2.1
gibi bir alan veri kalitesini ve migration süreçlerini takip etmeyi kolaylaştırabilir.
35. Tracking Değişiklikleri Dokümante Edilmeli
Bir geliştirici purchase event'inde değişiklik yaptığında analytics ekibi bundan haberdar değilse veri aniden değişebilir.
Bu nedenle değişiklik günlüğü tutulabilir.
Örneğin:
07 Ekim → Yeni checkout yayına çıktı.
09 Ekim → generate_lead event parametreleri değişti.
12 Ekim → Consent Mode güncellendi.
Raporlarda anormal değişim görüldüğünde teknik değişikliklerle ilişki kurulabilir.
36. Measurement Ownership
Analytics altyapısının sahibi belli değilse zaman içerisinde bozulması kaçınılmazdır.
Örneğin sorumluluk:
Marketing → Measurement Requirements
Development → Data Layer
Analytics → GTM / GA4
Legal → Consent / Privacy
Sales → CRM Outcomes
şeklinde dağıtılabilir.
Ancak merkezi bir measurement owner bütün sistemi koordine etmelidir.
37. Tracking Plan ile CRM Birbirine Bağlanmalı
Web sitesinde:
generate_lead
event'i oluşuyor ancak CRM içerisinde lead'in hangi formdan geldiği bilinmiyorsa measurement zinciri yarım kalır.
Tracking plan içerisinde web event'leri ile CRM alanları eşleştirilebilir.
Örneğin:
GA4 form_name → CRM Lead Form
GA4 service → CRM Service Interest
UTM Campaign → CRM Campaign
Böylece web analytics ile satış verisi arasında ortak veri modeli oluşur.
38. Tracking Plan ile BigQuery
Event taxonomy düzgün kurulmuşsa BigQuery analizleri çok daha kolay hale gelir.
Örneğin analyst:
generate_lead event'lerinin tümünü sorgulayıp service parameter'ına göre gruplayabilir.
Ancak her form farklı event ismiyle gönderilmişse SQL sorguları karmaşıklaşır ve veri temizliği gerekir.
Doğru taxonomy ileride yapılacak analytics projelerinin teknik maliyetini azaltır.
39. Tracking Plan Yapay Zeka İçin de Kritik
Predictive analytics veya AI tabanlı marketing modelleri temiz geçmiş veriye ihtiyaç duyar.
Eğer aynı davranış üç yıl boyunca farklı isimlerle ölçülmüşse modelin eğitilmesi zorlaşır.
Bu nedenle Event Taxonomy yalnızca bugünün dashboard'larını değil gelecekteki AI ve machine learning projelerini de etkiler.
40. Tracking Debt Nedir?
Teknik dünyadaki technical debt gibi pazarlamada da tracking debt oluşabilir.
Yıllar boyunca:
rastgele event eklemek,
GTM'e yüzlerce tag bırakmak,
eski event'leri silmemek,
UTM standardı kullanmamak,
dokümantasyon yapmamak
ölçüm altyapısının giderek karmaşıklaşmasına neden olur.
Bir noktadan sonra yeni analiz yapmak yerine önce eski ölçüm sistemini temizlemek gerekir.
41. Measurement Audit Nasıl Yapılır?
Mevcut şirketlerde sıfırdan kurulum yerine measurement audit ile başlanabilir.
Kontrol edilebilecek alanlar:
GA4 Property
Google Tag Manager
Data Layer
Google Ads Conversions
Meta Pixel / CAPI
UTM Standards
Consent Mode
CRM Attribution
Purchase Values
Key Events
BigQuery Export
Daha sonra eksikler öncelik sırasına göre düzeltilir.
42. Measurement Maturity Model
Şirketin tracking olgunluğu aşamalar halinde değerlendirilebilir.
Seviye 1 — Basic:
Pageview ve temel conversion.
Seviye 2 — Structured:
Event taxonomy + data layer.
Seviye 3 — Integrated:
CRM + advertising + ecommerce.
Seviye 4 — Advanced:
Server-side + BigQuery + first-party data.
Seviye 5 — Intelligent:
Predictive analytics + value-based bidding + AI optimization.
Her şirketin doğrudan Seviye 5'e geçmesi gerekmez.
Önce temel ölçümün güvenilir olması gerekir.
43. En Büyük Hata: Araç Satın Alıp Mimariyi Sonra Düşünmek
Şirketler bazen yeni CRM, CDP, attribution platformu veya AI analytics aracı satın alarak measurement problemini çözeceğini düşünür.
Ancak temel event ve data model yanlışsa yeni araç yalnızca kötü veriyi farklı dashboard'da gösterir.
Doğru sıra:
Business Questions
↓
Measurement Plan
↓
Event Taxonomy
↓
Data Layer
↓
Tracking
↓
Data Warehouse
↓
Reporting
↓
Optimization
şeklinde olmalıdır.
44. İyi Measurement Sisteminin Sonucu
Sağlam tracking mimarisi yalnızca doğru Analytics raporu üretmez.
Aynı veri:
Google Ads Smart Bidding'i,
Meta optimizasyonunu,
CRM Lead Scoring'i,
BigQuery analizlerini,
RevOps raporlarını,
predictive modelleri
besler.
Bu nedenle tracking şirketin dijital pazarlama altyapısındaki en temel katmanlardan biridir.
Ideio Creative İle Pazarlama Ölçüm Altyapınızı Standartlaştırın
Ideio Creative; İzmir'deki şirketler, e-ticaret markaları ve B2B işletmeler için GA4 measurement plan, Google Tag Manager, Data Layer, Event Taxonomy, ecommerce tracking, UTM governance, Google Ads Conversion Tracking, CRM attribution ve BigQuery entegrasyonlarını bütünsel şekilde kurgular.
Amacımız yalnızca daha fazla event toplamak değil; reklam, web sitesi, CRM ve satış ekiplerinin aynı veri dilini kullandığı, güvenilir ve sürdürülebilir bir measurement altyapısı oluşturmaktır.