GA4’te Her Event Dönüşüm Değildir: Lead Generation Siteleri İçin Measurement Mimarisi

Birçok GA4 kurulumunda ölçüm planı şu şekilde başlıyor:

click
form_start
form_submit
phone_click
whatsapp_click

Event’ler çalışıyor.

DebugView’da görünüyor.

Dashboard rakam üretmeye başlıyor.

Ve sonra hepsine dönüşüm muamelesi yapılıyor.

Problem burada.

Çünkü bu event’lerin tamamı aynı kullanıcı davranışını, aynı niyeti veya aynı business outcome’u temsil etmez.

Bir kullanıcının WhatsApp butonuna tıklamasıyla başarılı biçimde lead formu göndermesi aynı şey değildir.

Formu başlatmak ile formun backend tarafından başarıyla kabul edilmesi aynı şey değildir.

Lead oluşturmak ile satış ekibi tarafından qualified lead olarak kabul edilmek de aynı şey değildir.

Bu nedenle sağlıklı bir GA4 measurement mimarisi event listesinden başlamamalıdır.

Business funnel’dan başlamalıdır.

TRAFFIC
↓
BEHAVIOR
↓
CONTACT INTENT
↓
LEAD
↓
QUALIFIED LEAD
↓
CUSTOMER
↓
REVENUE

Event’lerin görevi bu zincirin farklı noktalarını ölçülebilir hale getirmektir.

Event sayısını artırmak measurement sistemini otomatik olarak geliştirmez.

Asıl soru hangi event’in hangi business state’i temsil ettiğidir.

Önce terminolojiyi düzeltelim: GA4’te conversion artık key event olarak geçiyor

Google Analytics 4’te önemli bir terminoloji değişikliği var.

Eskiden Analytics içinde “conversion” olarak işaretlediğimiz önemli event’ler artık key event olarak adlandırılıyor.

Google’ın güncel modeli:

EVENT
↓
KEY EVENT
↓
GOOGLE ADS CONVERSION

şeklinde düşünülebilir.

Event, ölçtüğümüz kullanıcı davranışıdır.

Key event, işletme açısından özellikle önemli olduğunu belirlediğimiz event’tir.

Conversion ise güncel Google terminolojisinde özellikle reklam performansı ve bidding için kullanılan conversion aksiyonuna karşılık gelebilir.

Bu yazıda “GA4 conversion tracking” ifadesini insanların hâlâ bu terimle arama yapması nedeniyle kullanıyorum.

Ancak Analytics mimarisini tasarlarken doğru kavramsal ayrım:

EVENT
≠
KEY EVENT
≠
LEAD
≠
SALE

olmalıdır.

Önce event değil funnel tasarlayın

Lead-generation sitesi için measurement planına:

Hangi event’leri kuralım?

diye başlamak yerine:

Kullanıcının ziyaretçiden müşteriye dönüşme süreci nasıl ilerliyor?

diye başlamak daha kullanışlıdır.

Örneğin:

TRAFFIC
↓
LANDING PAGE
↓
SERVICE EVALUATION
↓
CONTACT INTENT
↓
LEAD
↓
QUALIFIED LEAD
↓
SALE

Şimdi her aşamada hangi observable behavior’ların bulunduğunu belirleyebiliriz.

LANDING PAGE
↓
CTA CLICK
↓
FORM START
↓
FORM SUCCESS
↓
GENERATE LEAD
↓
QUALIFY LEAD
↓
CLOSE CONVERT LEAD

Buradaki avantaj şudur:

Artık event’i yalnız “GTM’de tetiklenebilen şey” olarak değil, funnel’ın hangi bölümüne evidence ürettiği üzerinden değerlendiririz.

Primary conversion, contact intent ve diagnostic event aynı şey değildir

Lead-generation measurement planında event’leri business anlamına göre sınıflandırmak analiz sırasında ciddi karmaşayı önler.

Sınıf	Örnek	Ne anlatır?
Behavior	click	Kullanıcı bir etkileşim gerçekleştirdi.
Micro / Progress	form_start	Kullanıcı lead sürecine başladı.
Diagnostic	form_error	Form sürecinde friction sinyali oluştu.
Contact Intent	whatsapp_click	Kullanıcı WhatsApp iletişim kanalını açmaya çalıştı.
Contact Intent	phone_click	Kullanıcı telefonla iletişim kurma niyeti gösterdi.
Lead	generate_lead	Gerçek lead başarıyla oluşturuldu.
Qualified Lead	qualify_lead	Lead hedef müşteri kriterlerini karşıladı.
Customer	close_convert_lead	Lead müşteriye dönüştü.

Bu tablo tek başına GA4 configuration değildir.

Bir measurement taxonomydir.

Yani event’in adı kadar analitik rolünü de tanımlar.

Her event neden key event yapılmamalı?

GA4 teknik olarak topladığınız herhangi bir event’i key event olarak işaretlemenize izin verir.

Fakat teknik olarak mümkün olan şey measurement açısından doğru olmak zorunda değildir.

Örneğin:

scroll
click
form_start
whatsapp_click
generate_lead

event’lerinin tamamını key event yaptığımızı düşünelim.

Bir süre sonra dashboard:

Bu ay 340 key event gerçekleşti.

der.

Ama işletmenin sormak istediği soru:

Kaç gerçek lead geldi?

ise sayı operasyonel anlamını kaybetmiştir.

Daha sağlıklı yaklaşım event’leri funnel içindeki görevlerine göre ayırmaktır.

DIAGNOSTIC EVENTS
Araştırma ve teşhis

↓

CONTACT INTENT EVENTS
İletişim niyeti

↓

BUSINESS KEY EVENTS
Gerçek lead ve downstream outcome

Böylece event hacmi ile business outcome birbirine karışmaz.

form_submit neden her zaman lead değildir?

Bu ayrım lead-generation sitelerinde özellikle önemlidir.

GA4 Enhanced Measurement form interaction özelliği form_start ve form_submit event’lerini otomatik olarak toplayabilir.

Fakat form_submit temel olarak form submission davranışını ölçer.

Formun işletme sisteminde başarılı bir lead oluşturduğunu otomatik olarak kanıtlamaz.

Şöyle bir veri görebiliriz:

form_submit = 5

generate_lead = 2

Bu fark otomatik olarak tracking’in bozuk olduğu anlamına gelmez.

Önce implementation incelenmelidir.

Örneğin:

• form submit işlemi backend success’ten önce gözlemleniyor olabilir,
• form validation veya uygulama davranışı nedeniyle submit denemeleri oluşabilir,
• aynı kullanıcı yeniden gönderim yapabilir,
• AJAX tabanlı formun success state’i klasik HTML submit davranışından farklı çalışabilir,
• otomatik form tracking gerçek lead definition’ınızla birebir örtüşmeyebilir.

Bu nedenle lead measurement için daha güvenilir model:

FORM START
↓
VALIDATION
↓
FORM REQUEST
↓
SUCCESS RESPONSE
↓
GENERATE_LEAD

olmalıdır.

Ana prensip:

Lead event’ini butona veya submit denemesine değil, doğrulanmış başarı durumuna bağlayın.

lead_form_success ile generate_lead birlikte mi gönderilmeli?

Her zaman iki ayrı GA4 event göndermek zorunda değilsiniz.

Örneğin uygulama veya GTM tarafında:

dataLayer event:
lead_form_success

şeklinde teknik bir success sinyali oluşturabilirsiniz.

Bu sinyal GA4’e:

generate_lead

olarak gönderilebilir.

Yani:

APPLICATION EVENT
lead_form_success

↓

GA4 BUSINESS EVENT
generate_lead

şeklinde ayrım yapmak çoğu durumda daha temizdir.

Aksi halde aynı business outcome için hem lead_form_success hem generate_lead gönderip raporlamayı gereksiz yere çoğaltabilirsiniz.

WhatsApp tıklaması conversion mıdır?

Ölçüm amacına bağlıdır.

whatsapp_click güçlü bir contact-intent event’idir.

Şunu biliyoruz:

Kullanıcı WhatsApp üzerinden iletişime geçmek için ilgili linke tıkladı.

Ama yalnız browser click’i ölçüyorsak şunu bilmiyoruz:

Kullanıcı gerçekten mesaj gönderdi.

Hele şunu hiç bilmiyoruz:

Kullanıcı qualified lead oldu veya satış gerçekleşti.

Dolayısıyla:

WHATSAPP CLICK
=
CONTACT INTENT

≠

GENERATED LEAD
≠
QUALIFIED LEAD
≠
SALE

Bu event işletme açısından çok önemliyse key event olarak işaretlenebilir.

Ama raporlarda generate_lead ile aynı business outcome kategorisine atılmaması gerekir.

Telefon tıklaması da aynı probleme sahiptir

phone_click event’i kullanıcının:

tel:+90...

linkini tetiklediğini ölçebilir.

Bu:

Kullanıcı telefon görüşmesi başlatma niyeti gösterdi.

için güçlü bir sinyaldir.

Ancak web event’i tek başına:

• aramayı gerçekten gerçekleştirdiğini,
• karşı tarafın telefonu açtığını,
• görüşmenin lead’e dönüştüğünü,
• lead’in qualified olduğunu

kanıtlamaz.

Gerçek call outcome gerekli olduğunda call tracking veya CRM verisi gibi downstream kaynaklarla measurement genişletilebilir.

CTA tıklamasını yalnız saymak neden yetmez?

Şöyle bir event düşünelim:

whatsapp_click

Bir ayda 87 kez tetiklenmiş.

Faydalı bilgi.

Ama oldukça sınırlı.

Şunları bilmiyoruz:

• hangi CTA tıklandı?
• hangi sayfada tıklandı?
• hero mu footer mı çalıştı?
• hangi hizmet kullanıcısı daha çok iletişim niyeti gösterdi?
• hangi CTA copy daha iyi performans verdi?

Bu nedenle event’e bağlam eklemek gerekir.

event_name = whatsapp_click

contact_method = whatsapp
cta_text = WhatsApp'tan Fotoğraf Gönder
cta_location = hero
service_context = dis_cephe
page_type = service

Artık yalnız:

Kaç WhatsApp click aldık?

değil:

Hangi sayfadaki hangi CTA hangi hizmet bağlamında daha fazla contact intent üretiyor?

sorusunu da sorabiliriz.

Context measurement neden CRO açısından önemlidir?

CRO’nun analiz etmek istediği şey yalnız kullanıcıların tıklayıp tıklamadığı değildir.

Davranışın hangi deneyim bağlamında gerçekleştiğidir.

Örneğin:

CTA A
"Teklif Al"

location = hero

vs.

CTA B
"WhatsApp'tan Fotoğraf Gönder"

location = after_process

İki CTA aynı event adı altında ölçülürse context parameter’ları hangi temas noktasının daha fazla intent oluşturduğunu anlamaya yardım eder.

Burada event parametrelerinin görevi event sayısını artırmak değildir.

Aynı davranışı açıklayabilmek için gerekli context’i taşımaktır.

Form friction nasıl ölçülür?

Lead formunun yalnız success event’ini ölçmek bize sonucu gösterir.

Problemi anlamak için süreç boyunca farklı sinyaller gerekebilir.

FORM START
↓
FORM ERROR
↓
GENERATE LEAD

form_error GA4’ün standart recommended lead event’i değildir; ihtiyaca göre oluşturulabilecek custom diagnostic event’tir.

Örneğin:

event_name = form_error

field_name = service
error_type = required

veya:

field_name = phone
error_type = invalid_format

gibi düşük-cardinality context parametreleri kullanılabilir.

Böylece:

Form completion düşük.

gibi genel bir sonuç yerine:

Kullanıcılar özellikle telefon alanındaki format validation sırasında hata görüyor.

gibi daha araştırılabilir bir sinyal elde edebiliriz.

Ancak analytics sinyali problemin nedenini her zaman tek başına açıklamaz.

Friction analizinde drop-off ile gerçek neden arasındaki farkı ayrıca ele alıyorum.

Form error tracking yaparken PII göndermeyin

Form measurement’ın en kritik güvenlik sınırlarından biri kullanıcı tarafından girilen kişisel veridir.

GA4’e:

• isim,
• e-posta adresi,
• telefon numarası,
• mesaj içeriği,
• kişiyi tanımlayabilecek form değerleri

gönderilmemelidir.

Örneğin:

field_name = phone
error_type = required

göndermek analiz açısından yeterli olabilir.

Şunu göndermeye ihtiyacımız yoktur:

phone_value = 0532...

Aynı şekilde kullanıcı mesajını event parameter olarak taşımak da gereksiz ve risklidir.

Measurement için field’ın değerini değil, davranış durumunu ölçün.

Form friction yalnız analytics ile anlaşılır mı?

Hayır.

GA4:

Telefon alanında çok sayıda error oluşuyor.

diyebilir.

Fakat kullanıcıların neden hata yaptığını anlamak için başka evidence gerekebilir.

Örneğin kullanıcı:

• +90 yazılması gerekip gerekmediğini anlamıyor olabilir,
• boşluk kabul edilmediğini bilmiyor olabilir,
• error message görünmüyor olabilir,
• mobil keyboard yanlış input type açıyor olabilir.

Usability testing belirli bir görevi yapmaya çalışan gerçek kullanıcıların bu tür form problemlerinde nerede takıldığını gözlemlemek için kullanılabilir.

Yani:

GA4
→ PROBLEM SİNYALİ

USABILITY / RECORDINGS
→ DAVRANIŞ BAĞLAMI

RESEARCH
→ OLASI NEDEN

HYPOTHESIS
→ MÜDAHALE

Contact Intent Rate nedir?

Contact Intent Rate, burada lead-generation siteleri için kullandığım birleşik bir diagnostic metric’tir.

GA4’ün hazır standart metriği değildir.

Temel soru:

Ziyaretlerin ne kadarında kullanıcı anlamlı bir iletişim davranışı gösteriyor?

Örneğin contact-intent seti:

whatsapp_click
OR
phone_click
OR
generate_lead

olarak tanımlanabilir.

Session-level formül:

CONTACT INTENT RATE

Sessions with at least
one contact-intent event
────────────────────────
All Sessions

Örneğin:

1.000 session

120 session içinde:
whatsapp_click
veya phone_click
veya generate_lead var

Contact Intent Rate
=
120 / 1.000
=
%12

Buradaki kritik ayrım event count kullanmamaktır.

Bir kullanıcı aynı session’da WhatsApp’a üç kez tıklayabilir.

Bu üç ayrı contact-intent session değildir.

Neden numerator ve denominator aynı scope’ta olmalı?

Analytics oranlarında sık yapılan hatalardan biri farklı scope’ları birbirine bölmektir.

Örneğin:

Contact Users
─────────────
Sessions

matematiksel olarak hesaplanabilir.

Ama numerator user-level, denominator session-level olduğu için yorumlaması daha bulanıktır.

Daha temiz:

Contact Sessions
───────────────
All Sessions

veya:

Contact Users
────────────
All Users

kullanmaktır.

Aynı prensip:

EVENT
USER
SESSION

scope’larının tamamında geçerlidir.

Oran üretmeden önce numerator ve denominator’ın hangi analitik nesneyi saydığını kontrol edin.

GA4’te session-level Contact Intent Rate nasıl analiz edilebilir?

Explore içinde session segment oluşturulabilir.

Örneğin:

SESSION SEGMENT:

event_name exactly matches
whatsapp_click

OR

phone_click

OR

generate_lead

Daha sonra:

Contact Intent Sessions
vs.
All Sessions

karşılaştırılabilir.

Buradaki amaç tek bir resmi GA4 metriği yaratmak değil, aynı tanımı her raporda tutarlı kullanmaktır.

Segmentasyon olmadan CRO measurement eksiktir

Site geneli ortalama çoğu zaman gerçek problemi gizler.

Örneğin toplam Contact Intent Rate:

%8

olabilir.

Ama channel kırılımı:

Organic Search  %11
Paid Search      %9
Direct          %13
Organic Social   %2

gibi farklı bir tablo gösterebilir.

Ben lead-generation analizinde en az üç temel kırılım kullanırım.

Channel

Organic Search
Paid Search
Organic Social
Direct
Referral

Device

mobile
desktop
tablet

Landing Page

homepage
service pages
contact
articles
campaign landing pages

Bu segmentler acquisition ve CRO fırsatlarını birbirinden ayırmaya yardım eder.

HIGH TRAFFIC
+
LOW CONTACT INTENT
=
CRO / MESSAGE / TRAFFIC QUALITY
ARAŞTIRMA ADAYI

Buna karşılık:

LOW TRAFFIC
+
HIGH CONTACT INTENT
=
ACQUISITION
FIRSATI OLABİLİR

Bu formüller otomatik karar kuralları değildir.

Research’ü nereye yönlendireceğimizi belirleyen diagnostic pattern’lerdir.

Landing page bazında measurement neden özellikle değerlidir?

Aynı trafik kaynağından gelen kullanıcıların farklı landing page’lerde farklı davranışlar göstermesi normaldir.

Örneğin:

Landing Page	Sessions	Contact Intent Sessions	Rate
Service A	1.000	70	%7
Service B	500	75	%15
Blog Article	4.000	40	%1

Bu tablo:

Service B daha iyi sayfa.

demek için tek başına yeterli değildir.

Intent ve trafik kalitesi farklı olabilir.

Ama bize hangi sayfalarda farklı kullanıcı davranışı oluştuğunu gösterir.

Küçük örneklemde conversion rate neden yanıltabilir?

Şöyle bir veri düşünelim:

3 sessions
2 contact sessions

Rate:

2 / 3
=
%66,7

Matematik doğrudur.

Fakat:

Bu landing page’in gerçek Contact Intent Rate’i %66,7.

sonucu için veri son derece zayıftır.

Bir sonraki kullanıcı contact intent göstermediğinde:

2 / 4
=
%50

olur.

Tek ziyaret bütün oranı ciddi biçimde değiştirmiştir.

Bu nedenle düşük hacimli analizde:

RATE
+
ABSOLUTE COUNT
+
> TIME WINDOW
+
SEGMENT SIZE

birlikte okunmalıdır.

Ana ders:

Yüzde doğru olabilir ama o yüzdeden yaptığınız çıkarım yanlış olabilir.

Event parameter ile custom dimension arasındaki fark nedir?

Event parameter veriyi toplar.

Custom dimension ise bu parametreyi GA4 raporları ve Explore içinde analiz edilebilir bir dimension haline getirir.

Örneğin event:

whatsapp_click

ve parameter:

cta_location = hero

gönderiyoruz.

Bu parametreyi raporlamada düzenli kullanmak istiyorsak GA4 Admin içinden event-scoped custom dimension tanımlamamız gerekir.

Örneğin:

Dimension	Event parameter
CTA Location	cta_location
CTA Text	cta_text
Service Context	service_context
Form Field	field_name
Error Type	error_type

Custom dimension tasarımında her parametreyi kaydetmeyin

GA4 standard property’lerde custom dimension sayısı sınırsız değildir.

Ayrıca yüksek-cardinality dimension’lar raporlamayı zorlaştırabilir.

Bu nedenle:

Parameter gönderiyoruz, custom dimension da açalım.

otomatik kural olmamalıdır.

Önce:

• bu information gerçekten analiz edilecek mi?
• standart GA4 dimension zaten var mı?
• kaç farklı değer oluşacak?
• bu bilgi karar değiştirecek mi?

diye bakılmalıdır.

Örneğin service_context gibi 10–20 stabil değer faydalı olabilir.

Her kullanıcı için benzersiz ID veya rastgele uzun değerler custom dimension için kötü adaylardır.

Custom dimension oluşturmayı measurement’ın sonuna bırakmayın

Custom event parameter toplamak ile onu raporda kullanıma açmak ayrı adımlardır.

Google, custom dimension oluşturulduktan ve data gönderildikten sonra raporlarda görünmesinin genellikle 24–48 saat sürebileceğini belirtiyor.

Bu nedenle production’a event’i gönderip haftalar sonra:

Bu parametreyi Explore’da niye göremiyorum?

noktasına gelmemek için reporting requirement baştan tanımlanmalıdır.

Pratikte custom definition’ı oluşturduğunuzda eski dönemlerin otomatik olarak eksiksiz biçimde geriye doldurulacağını varsaymayın.

Measurement planını mümkün olduğunca deployment ile birlikte tamamlayın.

GA4 lead tracking form submission’da bitmemeli

Lead-generation sitelerindeki en büyük measurement boşluklarından biri budur.

Site:

generate_lead

ölçer.

Ve sistem burada biter.

Fakat işletme açısından asıl süreç:

GENERATE LEAD
↓
QUALIFY LEAD
↓
WORKING LEAD
↓
CLOSE CONVERT LEAD

şeklinde ilerleyebilir.

GA4 bugün lead-generation use case’leri için bu lifecycle’a özel recommended event’ler de sunuyor:

Event	Business State
generate_lead	Yeni lead oluşturuldu.
qualify_lead	Lead qualification kriterlerini karşıladı.
disqualify_lead	Lead uygun bulunmadı.
working_lead	Lead aktif satış sürecinde.
close_convert_lead	Lead müşteriye dönüştü.
close_unconvert_lead	Lead satışa dönüşmeden kapandı.

Bu event’ler CRM veya offline süreçlerle entegre edildiğinde measurement mimarisi yalnız “form kaç kere gönderildi?” seviyesinden çıkabilir.

Neden qualified lead ölçmek conversion rate’ten daha değerlidir?

Şöyle bir CRO değişikliği düşünelim.

Formdaki alan sayısını 8’den 3’e düşürdük.

Sonuç:

generate_lead
+40%

İlk bakışta başarılı.

Ama CRM verisi:

qualified_lead
-15%

diyorsa tablo değişir.

Daha fazla form gönderimi alınmıştır fakat doğru müşteri oranı düşmüştür.

Bu yüzden:

PRIMARY
Lead volume

+

GUARDRAIL
Qualified lead rate

gibi bir measurement hierarchy kurulabilir.

Local conversion artışı sistemin tamamının iyileştiği anlamına gelmez.

Revenue measurement neden ayrı katman olmalıdır?

Lead-generation sitelerinde web analytics ile business analytics aynı noktada bitmez.

Gerçek sistem:

GA4
Traffic + Behavior + Lead

↓

CRM
Qualification + Pipeline

↓

SALES
Customer

↓

FINANCE
Revenue

olabilir.

Bu nedenle GA4 bütün measurement mimarisinin tamamı değil, önemli veri katmanlarından biridir.

Özellikle uzun satış döngülü B2B sitelerde:

Hangi landing page daha fazla lead üretti?

sorusunun yanında:

Hangi landing page daha fazla qualified pipeline ve revenue üretti?

sorusu da önemlidir.

Gerçek measurement audit’te form_submit ile lead neden ayrıldı?

Bir lead-generation sitesinde gerçekleştirdiğimiz measurement audit sırasında otomatik form event sayısı ile gerçek başarılı lead sayısının aynı olmadığını gördük.

Kurulum kabaca:

form_submit
↓
conversion

mantığıyla değerlendirilmişti.

Ancak form davranışı incelendiğinde form_submit sayısının gerçek başarı state’iyle birebir örtüşmediği görüldü.

Bu nedenle lead tanımı:

FORM INTERACTION
↓
SUCCESS STATE
↓
GENERATE_LEAD

şeklinde ayrıldı.

Buradaki ders yalnız teknik trigger problemi değildir.

Measurement definition’ın business definition ile eşleşmesi gerektiğidir.

GTM’de çalışan tag doğru olabilir.

Ama yanlış davranışı business conversion olarak tanımlıyorsa measurement sistemi yine yanlıştır.

Lead-generation sitesi için örnek measurement blueprint

SESSION
│
├── SOURCE / MEDIUM
├── DEVICE
└── LANDING PAGE
        │
        ▼
   PAGE EXPERIENCE
        │
        ▼
   CONTACT INTENT
   ├── whatsapp_click
   ├── phone_click
   └── form_start
          │
          ├── form_error
          │
          ▼
      generate_lead
          │
          ▼
      qualify_lead
          │
          ▼
      working_lead
          │
          ▼
   close_convert_lead
          │
          ▼
        REVENUE

Event context:

traffic_source
device
landing_page
service_context
cta_location
cta_text
contact_method
field_name
error_type

Burada source, device ve landing page gibi bilgilerin bir bölümü GA4’te zaten standart dimensions olarak bulunabilir.

Aynı veriyi gereksiz custom dimension olarak tekrar üretmeyin.

Measurement blueprint nasıl dokümante edilmeli?

Her event için en azından şu alanları tanımlamak faydalıdır:

Alan	Soru
Event Name	Event’in adı ne?
Business Meaning	Hangi kullanıcı/business state’i temsil ediyor?
Trigger	Hangi kesin koşulda tetikleniyor?
Parameters	Hangi context gönderiliyor?
Scope	Event, session veya user analizinde nasıl kullanılacak?
Key Event?	İş açısından key event olarak işaretlenecek mi?
QA	Doğru çalıştığı nasıl doğrulanacak?
Owner	Measurement tanımından kim sorumlu?

Bu tablo event tracking’i tag listesinden measurement architecture’a dönüştürür.

GA4 measurement QA nasıl yapılmalı?

Kurulum tamamlandığında yalnız GA4 Realtime’da event görmek yeterli değildir.

En azından şu zincir doğrulanmalıdır:

USER ACTION
↓
APPLICATION STATE
↓
DATA LAYER / TRIGGER
↓
GTM
↓
GA4 REQUEST
↓
DEBUGVIEW
↓
REPORTING
↓
BUSINESS DEFINITION

Örneğin generate_lead için:

Event geldi.

kontrolünün yanında:

Event yalnız gerçek lead oluşturulduğunda mı geliyor?

sorusu daha önemlidir.

Bir event’in doğru çalışması ne demektir?

Üç farklı doğruluk katmanı vardır.

1. Technical correctness

GA4 request gönderiliyor mu?

2. Semantic correctness

Event adı gerçekten meydana gelen davranışı temsil ediyor mu?

3. Business correctness

Event’i dashboard’da hangi business outcome olarak yorumladığımız doğru mu?

Örneğin:

phone_click

teknik olarak kusursuz çalışabilir.

Semantic olarak doğru biçimde telefon linki click’ini temsil edebilir.

Ama bunu:

Telefon lead’i.

olarak raporlarsak business interpretation yanlış olabilir.

Lead-generation measurement’ta sık yapılan hatalar

Her event’i key event yapmak

Behavior ile business outcome birbirine karışır.

form_submit’i otomatik olarak lead saymak

Submit davranışı gerçek success state ile doğrulanmalıdır.

WhatsApp click’i mesaj gönderimi sanmak

Click iletişim niyetidir; downstream iletişimi tek başına kanıtlamaz.

Event parameter olmadan CTA tracking yapmak

Event sayılır fakat hangi CTA’nın çalıştığı anlaşılamaz.

PII göndermek

Measurement için gerekli olmayan kullanıcı verilerini GA4’e taşımak ciddi veri yönetişimi problemidir.

Event count’u session rate gibi yorumlamak

Bir session içinde aynı event birden fazla kez gerçekleşebilir.

User ile session scope’unu karıştırmak

Oranların numerator ve denominator’ı aynı analitik scope’ta tutulmalıdır.

Küçük sample’daki yüksek oranı başarı ilan etmek

Absolute volume olmadan yüzde ciddi biçimde yanıltıcı olabilir.

Lead’de measurement’ı bitirmek

Lead quality, sale ve revenue görülmüyorsa acquisition kalitesinin önemli bir bölümü görünmez kalabilir.

Tool configuration’ı measurement strategy sanmak

Tag’in çalışıyor olması doğru business question’ın ölçüldüğü anlamına gelmez.

Lead-generation measurement için pratik framework

1. BUSINESS OUTCOME
Gerçek başarı ne?

↓

2. FUNNEL
Kullanıcı bu sonuca nasıl ilerliyor?

↓

3. OBSERVABLE BEHAVIORS
Hangi davranışları gerçekten ölçebiliriz?

↓

4. EVENT TAXONOMY
Behavior / Intent / Lead / Quality ayrımı ne?

↓

5. CONTEXT
Event'i açıklamak için hangi parameter gerekli?

↓

6. SCOPE
Event, session veya user seviyesinde hangi metriği kuruyoruz?

↓

7. QA
Event business definition ile gerçekten eşleşiyor mu?

↓

8. SEGMENT
Channel, device ve landing page farkı ne?

↓

9. DOWNSTREAM DATA
Lead quality ve revenue ne söylüyor?

↓

10. LEARN
Hangi measurement sonucu hangi kararı değiştirdi?

Sonuç: Measurement’ın amacı daha fazla event toplamak değildir

Lead-generation measurement sisteminin başarısı:

42 farklı custom event kurduk.

cümlesiyle ölçülmez.

Daha güçlü soru şudur:

Kullanıcının traffic’ten revenue’ya ilerleyişini hangi güvenilir business state’lerle ölçebiliyoruz?

Sağlıklı model:

TRAFFIC
↓
BEHAVIOR
↓
CONTACT INTENT
↓
LEAD
↓
QUALITY
↓
CUSTOMER
↓
REVENUE

şeklindedir.

Bu zincirde:

CLICK
≠
LEAD

FORM SUBMIT
≠
SUCCESSFUL LEAD

WHATSAPP CLICK
≠
MESSAGE

EVENT
≠
BUSINESS OUTCOME

ayrımlarını korumak gerekir.

GA4’ün görevi bize mümkün olan en fazla event’i vermek değildir.

Measurement mimarisinin görevi doğru davranışı doğru business anlamıyla eşleştirmektir.

CRO da ancak bundan sonra sağlıklı çalışabilir.

Çünkü yanlış tanımlanmış conversion üzerine yapılan optimizasyon, yalnız yanlış metriği daha verimli hale getirir.

Sık Sorulan Sorular

GA4’te conversion artık ne olarak geçiyor?

Google Analytics’te işletme açısından önemli event’ler güncel terminolojide key event olarak adlandırılır. Google Ads kampanya performansı ve bidding tarafında kullanılan conversion aksiyonları bu key event’lerden oluşturulabilir.

GA4’te her event key event yapılmalı mı?

Hayır. Teknik olarak birçok event key event olarak işaretlenebilir; ancak measurement mimarisinde yalnız işletme açısından gerçekten önemli davranışların bu seviyeye çıkarılması raporların yorumlanmasını kolaylaştırır.

form_submit conversion sayılmalı mı?

Otomatik olarak hayır. Form submit davranışı gerçek lead success state’iyle aynı olmayabilir. Lead event’i mümkün olduğunda formun backend veya uygulama tarafından başarılı biçimde kabul edildiği durumla ilişkilendirilmelidir.

generate_lead ne zaman tetiklenmeli?

Kullanıcının lead oluşturan bilgileri başarıyla gönderdiği ve sistemin bunu gerçek lead olarak kabul ettiği noktada tetiklenmelidir.

WhatsApp tıklaması conversion mıdır?

WhatsApp click önemli bir contact-intent event’i ve ihtiyaca göre key event olabilir. Ancak yalnız click ölçülüyorsa kullanıcının mesaj gönderdiğini, qualified lead olduğunu veya satış ürettiğini kanıtlamaz.

Telefon tıklaması nasıl değerlendirilmelidir?

Telefon linki click’i iletişim niyetini ölçer. Gerçek telefon görüşmesi veya lead sonucunu ölçmek için call tracking veya CRM gibi ek sistemler gerekebilir.

Contact Intent Rate nedir?

Contact Intent Rate, en az bir iletişim niyeti event’i içeren session’ların tüm session’lara oranı olarak tanımlanabilecek custom diagnostic metriktir. GA4’ün hazır standart metriği değildir.

GA4 event parameter’ları için custom dimension gerekli mi?

Custom event parameter’larını standart raporlarda ve Explore’da dimension olarak analiz etmek istediğinizde event-scoped custom dimension oluşturmanız gerekebilir. GA4’te zaten bulunan standart dimension’lar için gereksiz custom definition üretmemek gerekir.

Form error tracking sırasında telefon veya e-posta gönderilebilir mi?

Hayır. Google Analytics’e kişisel olarak tanımlanabilir bilgi gönderilmemelidir. Field adı veya error type gibi davranış bağlamı ölçülebilir; kullanıcının gerçek telefon, e-posta veya mesaj değeri gönderilmemelidir.

Lead tracking neden generate_lead event’inde bitmemeli?

Lead sayısı tek başına acquisition kalitesini göstermez. Mümkün olduğunda qualified lead, satışa dönüşen lead ve revenue gibi downstream business sonuçları da measurement mimarisine bağlanmalıdır.