GA4 Anahtar Olay (Key Event) Kurulumu: Form ve Satın Alma

Her form gönderimi anahtar olay olmak zorunda değildir. Google Analytics yardım sayfası anahtar olayı, işinizin başarısı için özellikle önemli bir eylemi ölçen olay olarak tanımlar. Yani ölçütünüz "bir şey oldu mu" değil, "bu eylem işimin sonucunu gerçekten değiştiriyor mu" sorusudur.

Yazı pazarlamacılar, e-ticaret yöneticileri ve analitik uzmanları için. Tek bir etkileşimin (WhatsApp ve telefon tıklaması) ölçümü için ayrıca GA4 WhatsApp ve telefon tıklaması olayı yazısına bakabilirsiniz.

Dönüşüm yerine anahtar olay: terim değişimi

GA4 arayüzünde ve yardım sayfalarında artık "key event" ifadesi kullanılıyor. Eski alışkanlıkla "dönüşüm olayı" diyen ekipler çoğu zaman aynı şeyi kastediyor, ama iki terim aynı nesneye bağlı değil. Bu ayrımı baştan netleştirmek, rapor okurken ve reklam hesabıyla konuşurken karışıklığı önler.

Belgenin tanımı

Analytics yardım sayfasına (yeni sekmede açılır) göre anahtar olay, işinizin başarısı için özellikle önemli bir eylemi ölçen olaydır. Kullanıcı böyle bir olayı tetiklediğinde Analytics bunu kaydeder ve raporlarda gösterir. Sayfanın akışı basit: önce bir olay toplanır, sonra o olay anahtar olay olarak işaretlenir. Toplanan her olay işaretlenebilir; ancak her olayın işaretlenmesi gerektiği anlamına gelmez.

Sayfa "dönüşüm" kavramını kendi içinde tanımlamaz, ayrı bir "About conversions" konusuna yönlendirir. Dolayısıyla "anahtar olay dönüşümün yeni adıdır" gibi kesin bir eşitlik cümlesi o sayfada yoktur. Güvenli okuma şudur: Analytics tarafındaki önemli eylem artık anahtar olay diye adlanıyor, reklam tarafındaki dönüşüm ise ayrı bir nesne.

Raporlarda nerede görünür

Yardım sayfasına göre Landing pages ve User acquisition gibi raporlarda "Key events" sütunu bulunur. "All events" menüsüyle tek bir anahtar olaya göre filtreleme yapılabilir. Keşif (Explorations) raporlarında "Key events" ve "Session key event rate" metrikleri kullanılabilir. Reklam bölümündeki Pathing ve Attribution raporları ise anahtar olaya giden yoldaki temas noktalarına farklı atıf modelleriyle kredi verir.

Bu liste kurulumun pratik sonucunu gösteriyor: işaretlediğiniz her olay, açılış sayfası ve edinim raporlarında yeni bir sütun ya da metrik olarak karşınıza çıkar. Yanlış olayı işaretlerseniz yanlış sayıyı hem kanal hem sayfa kırılımında okursunuz. Bu yüzden işaretleme kararı raporun okunabilirliğini doğrudan etkiler.

Google Ads ile ilişki

Aynı sayfa, bir anahtar olaydan Google Ads dönüşümü oluşturabileceğinizi ve ayarlarını hem Google Ads hem Analytics içinde yönetebileceğinizi söyler. Listelenen yararlar arasında iki araçtaki dönüşüm sayılarının eşleşmesi, Google dışı ve organik kanalların raporlanması, dönüşüme göre teklif verme ve yeniden pazarlama kitleleri oluşturma var. Sayfa ayrıca Google Ads dönüşümlerinin standart Google Analytics raporlarında görünmediğini, bunları Google Ads içinde ya da Analytics'in Advertising bölümünde değerlendirmek gerektiğini belirtir.

Pratik sonuç: reklam hesabınızda gördüğünüz dönüşüm sayısı ile GA4 standart raporlarındaki anahtar olay sayısını aynı şey saymayın. Karşılaştırma yapacaksanız aynı olay, aynı tarih aralığı ve aynı sayım yöntemiyle yapın. Sayım yöntemini değiştirme konusu ayrı bir yardım sayfasında anlatılır.

Belgelerde bu bölümde yer almayan şeyler de var: mülk başına anahtar olay sınırı, değişikliğin geçmiş veriyi etkileyip etkilemediği ve varsayılan anahtar olay listesi bu sayfada anlatılmıyor. Bu konuları kurulumdan önce yardım merkezindeki ilgili sayfalardan güncel hâliyle kontrol edin; sınırlar ve davranışlar zamanla değişebilir.

Hangi olay anahtar olur

Ölçüt tek cümlede toplanabilir: işinizin sonucunu doğrudan temsil eden ya da sonuca giden zincirin vazgeçilmez halkası olan eylemler anahtar olur. Geri kalanı normal olay olarak kalır ve analiz için hâlâ değerlidir.

Dönüm noktası testi

Her aday olay için üç soru sorun. Birincisi, bu eylem gerçekleşmeseydi iş sonucu da gerçekleşir miydi? Eylem olmadan sonuç mümkün değilse güçlü bir adaydır. İkincisi, bu eylemin sayısı arttığında bir kararı değiştirir misiniz, örneğin bütçeyi, sayfayı ya da kanalı? Karar değişmiyorsa rapor süsüdür. Üçüncüsü, eylem kullanıcının niyetini mi gösteriyor yoksa sadece ilgisini mi? Sayfa kaydırmak ilgidir; teklif formunu göndermek niyettir.

Bu testten sonra anahtar olay listesinin kısa kalması beklenir. Bu istenen bir durumdur: az sayıda, anlamı net olay, yüz tane gevşek olaydan daha çok iş görür.

Form gönderimi: hepsi mi, bazıları mı

Her form gönderimi anahtar olay olmalı mı? Cevap hayır. Bir sitede genellikle birbirinden çok farklı formlar bulunur. Bülten kaydı, iletişim formu, teklif talebi, destek talebi, ürün sorusu ve üyelik başvurusu aynı değerde değildir. Hepsini tek bir "form_submit" altında işaretlerseniz rapordaki anahtar olay sayısı büyür ama içerdiği sinyal bulanıklaşır.

Daha sağlam yol, formları iş değerine göre ayırmak. Satış ekibinin takip ettiği teklif formu anahtar olay olur. Bülten kaydı, işiniz içerik aboneliğiyse anahtar olay, değilse yalnızca normal olay olabilir. Destek talebi genellikle bir müşteri memnuniyeti metriğidir, kazanım metriği değildir; bunu anahtar olay yaparsanız edinim raporunda destek isteyen mevcut müşterileri "başarı" olarak sayarsınız.

Spam ve test gönderimlerini de unutmayın. Bir form, bot ya da test kayıtlarıyla doluyorsa bunları anahtar olay saymak raporu şişirir. Sunucu tarafında doğrulama sonrası tetiklenen bir olay, yalnızca düğme tıklamasına bağlı olaydan daha güvenilirdir.

Satın alma ve sepet adımları

E-ticarette satın alma, kuşkusuz anahtar olaydır. Ara adımlar için karar daha incelikli. Sepete ekleme, ödeme başlatma ve ödeme bilgisi girişi huni analizi için değerli olaylardır, ancak çoğu durumda anahtar olay olarak işaretlenmeleri gerekmez. Bunları anahtar yaparsanız "Key events" sütunu bir satın alma sayısı değil, karışık bir adım sayısı gösterir ve oturum başına anahtar olay oranı gerçek sonucu yansıtmaz.

İstisna, ürününüzün satış döngüsü uzunsa ortaya çıkar. Örneğin satın alma çevrimdışı tamamlanıyor ve çevrimiçi son adım "talep gönderildi" ise, o talep sizin sonuç olayınızdır. Bu durumda talep olayını işaretleyin ve hangi iş sonucuna karşılık geldiğini belgeleyin.

Açılış sayfası hedefleri

Kampanya açılış sayfalarında sorun şu: sayfanın "amacı" çoğu zaman bir formdur, ama bazen bir indirme, bir arama ya da bir randevu bağlantısıdır. Açılış sayfasındaki asıl eylemi tek bir olay olarak tanımlayın ve sayfa türüne göre adı sabit tutun. Sayfa yüklendi olayı (sayfa görüntüleme) bir hedef değil, bir ziyaret kaydıdır; bunu anahtar olay yapmak hedef ile trafik arasındaki farkı siler.

Açılış sayfası raporunda "Key events" sütununu yorumlarken sayfaları kendi içinde karşılaştırın. Aynı formu taşıyan iki açılış sayfasını aynı olay adıyla ölçerseniz hangisinin daha iyi çalıştığını rahatça görürsünüz. Farklı formları farklı adlarla ölçmek ise karşılaştırmayı zorlaştırır.

Karar tablosu

İşaretlemeden önce kontrol listesi

• Olayın iş sonucuyla bağlantısı tek cümlede yazılı mı?
• Olay yalnızca bir kez, gerçek eylem tamamlandığında mı tetikleniyor?
• Spam, test ve çift gönderim filtrelenmiş mi?
• Olay adı ekibin kullandığı adlandırma standardına uyuyor mu?
• Bu olayın sayısı artınca hangi karar değişecek, belli mi?
• Olayı raporlayacak kişi ve rapor yeri belirlenmiş mi?

Olay adı ve parametre tutarlılığı

Doğru olayı işaretlemek işin yarısı. Diğer yarısı, aynı eylemin her sayfada, her dilde ve her cihazda aynı adla gelmesidir. Tutarsız adlandırma, raporda aynı formun üç ayrı satır olarak görünmesine neden olur ve işaretleme yalnızca tek ada uygulanır.

Ad standardı

Basit bir kural seti yeterlidir. Küçük harf kullanın, sözcükleri alt çizgiyle ayırın, eylemi fiil ya da nesne-fiil sırasıyla ifade edin ve dili adın içine koymayın. Örneğin "teklif_formu_gonderildi" ile "quote_form_submit" aynı eylemi iki dilde adlandırır ve raporda iki satır oluşturur. Tek bir dil seçin ve arayüz dilinden bağımsız kalın.

Ad değişikliğinin geçmişe etkisini önceden düşünün. Bir olayın adını değiştirirseniz yeni ad yeni bir olay olarak toplanır; eski ad geçmiş veride kalır. Raporlarda iki adı birlikte okumak gerekir. Bu yüzden adı kurulumdan önce kesinleştirmek, sonradan düzeltmekten ucuzdur.

Parametre ile ad ayrımı

Bir eylemin farklı varyasyonlarını ayrı olay adı yapmak yerine parametre ile taşıyın. Tüm formlar için "form_gonderildi" adlı tek bir olay kullanıp hangi formun gönderildiğini "form_adi" gibi bir parametreyle belirtebilirsiniz. Ancak burada bir denge var: anahtar olay işaretlemesi olay adı üzerinden yapıldığı için, tüm formlar tek ada bağlanırsa hepsi birlikte anahtar olay olur. Önceki bölümde söylediğimiz gibi bu istenmiyorsa değerli formlar için ayrı bir olay adı ayırın.

Özet kural: işaretlenecek eylemlerin her biri kendi adını taşısın, işaretlenmeyecek varyasyonlar ise ortak bir olay adı ve parametrelerle taşınsın. Parametre değerlerini de sabit sözlükten seçin; "Teklif", "teklif" ve "TEKLIF" farklı değerler olarak okunur.

Ad ve parametre sözlüğü örneği

Tablodaki adlar bir örnek standarttır; kendi ekibinizin sözlüğünü yazarken bunları uyarlayın. Satın alma gibi standart e-ticaret olaylarında ürün adı, tutar ve işlem kimliği gibi alanların nasıl doldurulacağı ayrı bir teknik konudur.

Çift sayımı önlemek

Aynı eylem hem sayfada hem etiket yöneticisinde hem de sunucuda tetikleniyorsa olay iki kez sayılabilir. Satın alma sonrası teşekkür sayfası yenilendiğinde olay tekrar çalışıyorsa sayı şişer. Önlem olarak işlem kimliğini olayla gönderin, teşekkür sayfasında olayı yalnızca ilk görüntülemede tetikleyin ve test siparişlerini ayırın. Çift sayım, anahtar olay oranını yapay olarak yükselttiği için karar kalitesini doğrudan bozar.

Çerez onayı ve ölçüm kaybı

Anahtar olay kurulumu doğru olsa bile, çerez onayı verilmeyen ziyaretlerde olaylar tam ölçülmeyebilir. Onay modunun teknik ayrıntıları ayrı bir yazıda anlatılıyor.

Neden sayılar ile gerçek arasında fark çıkar

Ziyaretçi çerez bannerında analitik çerezlerini reddederse, standart ölçüm o ziyaret için kesilebilir ya da sınırlı kalabilir. Sonuç olarak GA4'teki anahtar olay sayısı, kendi siparişlerinizin ya da form kayıtlarınızın sayısından düşük çıkar. Bu bir hata değil, ölçüm yöntemi ile gerçeklik arasındaki doğal boşluktur. Boşluğun büyüklüğü sitenizin kitlesine, banner tasarımına ve ayarlarına göre değişir; belgelerde genel bir oran verilmediği için bir rakam varsaymayın.

Ayrıntılı çerçeve için çerez onayı, KVKK ve ölçüm kaybı rehberine bakın.

Kendi kayıtlarınızla çapraz kontrol

Anahtar olaylar için bir "gerçek kaynak" belirleyin. Satın almada sipariş veritabanı, form gönderiminde CRM ya da e-posta kutusu bu rolü üstlenir. Ayda bir GA4 sayısını gerçek kaynakla karşılaştırın ve oranı not edin. Oran sabit kalıyorsa ölçüm yöntemi tutarlıdır ve GA4 trend okuması için güvenilirdir. Oran aniden değişirse bir etiket kırılmış, banner değişmiş ya da site güncellenmiş olabilir.

Veri eşiği ve gizlenen satırlar

Küçük örneklemlerde bazı satırların raporda görünmemesi de ayrı bir konudur. Düşük hacimli bir anahtar olayı kırılım yaptıkça satırlar kaybolabilir; nedenlerini GA4 veri eşiği yazısında anlattık. Eksik bir satırı "sıfır olay" diye okumayın.

Sorumluluk notu

Onay yönetimi hukuki ve teknik bir konu birlikte. Hangi çerezlerin onay gerektirdiği, banner metni ve saklama süreleri için hukuk danışmanınıza ve mevcut mevzuata başvurun.

Doğrulama: DebugView ve rapor kontrolü

Kurulum bittiğinde "çalışıyor gibi" görünmesi yetmez. Üç katmanda doğrulama yapın: olay gönderiliyor mu, doğru adla ve parametrelerle mi gönderiliyor, anahtar olay olarak işaretli mi ve raporlarda görünüyor mu.

DebugView ile anlık kontrol

GA4 yönetim alanındaki DebugView, hata ayıklama modundaki bir cihazdan gelen olayları gerçek zamanlı gösterir. Test sırasında şunlara bakın: eylemi yaptığınızda olay bir kez mi görünüyor, olay adı sözlükteki adla birebir aynı mı, parametreler dolu ve beklenen değerlerde mi. Arayüzü Türkçe kullanıyorsanız menü adları farklı görünebilir.

Testi farklı koşullarda tekrarlayın: masaüstü ve mobil, çerez onayı verilmiş ve verilmemiş, formun başarılı ve hatalı gönderimi. Hatalı gönderimde olayın tetiklenmemesi gerekir; tetikleniyorsa sayılar şişecektir.

İşaretleme ve rapor kontrolü

Olay doğru geldikten sonra "Mark as key event" benzeri seçeneği, olayın göründüğü olaylar listesinden uygulayın. Menü adları arayüz dilinize göre değişebilir. Yardım sayfası işaretleme adımlarını ayrıntılı vermediği için, adımlar için yönetim ekranındaki güncel yönlendirmeyi izleyin. İşaretledikten sonra Landing pages ve User acquisition raporlarında "Key events" sütununun göründüğünü doğrulayın. Yeni olayın bu sütuna yansıması için biraz beklemeniz gerekebilir; kesin bir süre belgede yok.

Doğrulama adımları

1. Tanım: olay adı, parametreler ve iş sonucu yazılı sözlükte yer alsın.
2. Tetikleyici: eylem tamamlandığında bir kez çalıştığını DebugView'da görün.
3. Olumsuz test: hatalı ya da boş gönderimde olayın çalışmadığını kontrol edin.
4. İşaretleme: olayı anahtar olay olarak işaretleyin.
5. Rapor: Landing pages ve User acquisition raporlarında sütunun geldiğini doğrulayın.
6. Çapraz kontrol: bir hafta sonra gerçek kaynak sayısıyla karşılaştırın.
7. Kayıt: kurulum tarihini ve sürümü not alın, sonraki sayfa güncellemelerinde yeniden test edin.

Kanal kırılımı: kampanya etiketi ve organik doğrulama

Anahtar olay tek başına "kaç" sorusunu cevaplar; "nereden" sorusu için trafik kaynağının doğru etiketlenmesi gerekir. Kampanya bağlantılarında UTM parametreleri bu işi görür.

UTM zorunlulukları

Analytics'in URL oluşturucu yardım sayfası (yeni sekmede açılır), bir URL'ye parametre eklerken her zaman utm_source, utm_medium ve utm_campaign kullanmanız gerektiğini söyler. Parametre değerleri büyük küçük harfe duyarlıdır: utm_source=google ile utm_source=Google farklı değerlerdir. Eksik parametreler raporlarda (not set) değerine neden olur. Etiketlemeyi tek bir sözlükte tutun; tutarsız yazım, anahtar olayları parçalı kaynak satırlarına dağıtır.

UTM bilgisi, Landing page + query string ve Page path + query string boyutlarında yer almaz; Page location boyutunda görünür. Bu nedenle kampanya ayrımı yaparken oturum kaynağı, ortamı ve kampanya boyutlarına bakın. Etiket sözlüğünün ayrıntıları ayrı bir konudur; burada yalnızca anahtar olaya etkisine bakıyoruz.

Organik tarafta Search Console'u yanına koyun

Organik arama trafiği için GA4'ün anahtar olay sütununu Search Console Performans raporuyla birlikte okuyun. Search Console yardım sayfasına (yeni sekmede açılır) göre rapor tıklama, gösterim, tıklama oranı ve ortalama konum metriklerini verir. GA4 ise oturum ve olay sayar. İki araç aynı birimi ölçmez, bu yüzden tıklama sayısı ile oturum sayısı ya da anahtar olay sayısı birebir eşleşmez; fark beklenen bir şeydir. Organik trafiğin okunması için GA4 ile organik trafik analizi yazısını da kullanabilirsiniz.

Okuma tablosu

Örnek senaryo: üç sayfalı küçük bir hizmet sitesi

Örnek senaryo: Bir muhasebe bürosunun sitesinde ana sayfa, hizmetler sayfası ve iletişim sayfası var. İletişim sayfasında teklif formu, ana sayfada bülten kaydı ve alt bilgide destek bağlantısı bulunuyor. İlk kurulumda büronun dijital sorumlusu üç eylemi de aynı "form_submit" olayıyla topluyor ve hepsini anahtar olay yapıyor. Rapor ilk ay iyi görünüyor, çünkü anahtar olay sayısı yüksek. Ancak satış ekibi gelen talebin yalnızca bir kısmının gerçek teklif olduğunu söylüyor.

Düzeltme planı üç adımdan oluşuyor. Birincisi, teklif formu için ayrı bir olay adı tanımlanıyor ve yalnızca sunucu doğrulamasından sonra tetikleniyor. İkincisi, bülten kaydı normal olay olarak kalıyor, abonelik büronun hedefi olmadığı için anahtar olay yapılmıyor. Üçüncüsü, eski olay anahtar olay listesinden çıkarılıyor ve geçiş tarihi kayıt altına alınıyor. Sonraki raporlarda anahtar olay sayısı düşüyor ama satış ekibinin sayısıyla uyuşuyor. Sayının düşmesi kayıp değil, doğruluğun artmasıdır.

Bu örnekten çıkan ders: anahtar olay sayısının yüksek olması başarı değil, tanımın gevşek olması anlamına gelebilir. Geçiş döneminde eski ve yeni tanımlar arasındaki dönemi raporlarda ayrı gösterin; aksi hâlde sayı düşüşü sonuç kaybı gibi okunabilir.

Bakım takvimi: kurulumu canlı tutmak

Anahtar olay kurulumu bir kez yapılıp bırakılan bir iş değildir. Siteler değişir, formlar yenilenir, ödeme sağlayıcıları güncellenir ve ekipler el değiştirir. Küçük bir bakım düzeni, kurulumun aylar sonra da güvenilir kalmasını sağlar.

Haftalık, aylık ve üç aylık kontroller

Haftalık kontrol kısa olmalıdır: anahtar olayların sayısına bakın ve önceki haftalara göre ani bir sıfırlanma ya da sıçrama var mı görün. Aylık kontrolde gerçek kaynakla çapraz karşılaştırma yapın ve oranı not edin. Üç aylık kontrolde ise sözlüğü gözden geçirin: hâlâ kullanılmayan olaylar, artık iş sonucunu temsil etmeyen anahtar olaylar ve yeni eklenen eylemler var mı? İş modeli değiştiyse anahtar olay listesi de değişmelidir.

Sürüm öncesi test şablonu

Siteye yeni bir form, yeni bir ödeme adımı ya da yeni bir açılış sayfası eklendiğinde yayından önce üç şey sorulmalıdır: bu sayfada hangi olay tetiklenecek, adı sözlükte var mı, anahtar olay mı? Bu üç soruyu sürüm listesine ekleyin. Test bitince DebugView ekran görüntüsünü ya da notunu değişiklik defterine koyun. Bir ay sonra sayı değiştiğinde nedenini bulmak için bu kayıt değerlidir.

Ekip içi iletişim

Anahtar olayı yalnızca analitik uzmanı bilirse, geliştirici formu değiştirirken olayı bozabilir. Sözlüğü ortak bir yerde tutun, olay adını kodla ilişkilendirin ve yeni işe başlayan birine bir sayfada anlatabilecek kadar kısa tutun. Raporu kullanan satış ve pazarlama ekiplerine de "Key events" sütununun neyi saydığını yazılı verin; aynı sayıya farklı anlamlar yüklenmesi, kararların tartışmalı hâle gelmesinin en sık nedenidir.

Devir teslimde ne verilmeli

Bir ajans ya da yeni bir çalışan işi devraldığında en az şu belgeler gerekir: olay sözlüğü, hangi olayların anahtar olarak işaretlendiği ve nedeni, gerçek kaynak ile GA4 arasındaki son karşılaştırma ve değişiklik defteri. Bu dört belge olmadan yapılan bir devir, kurulumu sıfırdan keşfetmek anlamına gelir.

Yaygın hatalar ve düzeltmeleri

Tek olay, çok anlam

Farklı eylemleri aynı olay adı altında toplamak en yaygın hata. Düzeltme: değeri farklı eylemleri ayrı olay adlarına bölün, ortak kalan varyasyonları parametre yapın.

Geç ve sessiz değişiklikler

Site güncellendiğinde form bileşeni değişir ve olay tetikleyicisi sessizce kırılır. Düzeltme: her sürüm sonrası kısa bir DebugView testi, kritik olaylar için haftalık sayı kontrolü ve sıfıra düşme uyarısı.

Geçmişi yeniden yazmaya çalışmak

Olay adını ya da anahtar olay tanımını değiştirdiğinizde geçmiş raporların aynı kalacağını varsaymayın. Yardım sayfasında geriye dönük davranış anlatılmıyor; bu nedenle değişiklik tarihini kayıt altına alın ve raporu o tarihte bölerek okuyun.

Reklam ve analitik sayılarının eşitlenmesini beklemek

Google Ads dönüşümleri standart GA4 raporlarında görünmez ve iki araç farklı yöntemlerle sayabilir. Fark çıktığında hangi raporun hangi sorunun cevabı olduğunu yazın, tek sayıyı iki yerde aramayın.

Yönetişim eksikliği

Kimin olay ekleyebildiği, kimin anahtar olay işaretleyebildiği belli değilse sözlük çabuk bozulur. Küçük bir değişiklik defteri tutun: tarih, kim, ne değişti, neden. Bu defter, rapor sayısı ani değiştiğinde ilk bakılacak yer olur.

Sık Sorulan Sorular

GA4'te anahtar olay ile dönüşüm aynı şey mi?

Google Analytics yardım sayfası anahtar olayı, işin başarısı için özellikle önemli bir eylemi ölçen olay olarak tanımlar ve dönüşümü kendi içinde tanımlamaz. Reklam tarafında ise bir anahtar olaydan Google Ads dönüşümü oluşturulabilir. Günlük kullanımda iki sözcük karışabilir, ama raporlarda ve reklam hesabında ayrı nesnelerdir.

Her form gönderimi anahtar olay olarak işaretlenmeli mi?

Hayır. Yalnızca işin sonucunu temsil eden ya da sonuca giden zincirin vazgeçilmez halkası olan formlar işaretlenmelidir. Teklif talebi genellikle uygundur; destek talebi ya da bülten kaydı iş modeline göre normal olay olarak kalabilir. Her formu işaretlemek raporu şişirir ve sinyali bulanıklaştırır.

Anahtar olay kurulumundan sonra veri ne zaman görünür?

Yardım sayfasında kesin bir süre belirtilmiyor. DebugView ile olayın geldiğini anlık görebilirsiniz; raporlara yansıması için biraz beklemek gerekebilir. Güncel davranış için yardım merkezini kontrol edin.

Çerez onayı vermeyen ziyaretçilerin anahtar olayları sayılır mı?

Standart ölçüm onay verilmeyen ziyaretlerde sınırlı olabilir, bu yüzden GA4 sayısı gerçek sipariş ya da form sayınızdan düşük çıkabilir. Belgelerde genel bir kayıp oranı yok; kendi gerçek kaynağınızla düzenli karşılaştırma yapın. Onay konusunda uzmana danışın.

Olay adını sonradan değiştirirsem geçmiş veri ne olur?

Yeni ad yeni bir olay olarak toplanır, eski ad geçmiş veride kalır. Yardım sayfası geriye dönük davranışı anlatmıyor, bu yüzden değişiklik tarihini kaydedip raporu o tarihte bölerek okumak güvenlidir.

Google Ads dönüşümleri neden GA4 standart raporlarında yok?

Yardım sayfası Google Ads dönüşümlerinin standart Google Analytics raporlarında görünmediğini, Google Ads içinde ya da Analytics'in Advertising bölümünde değerlendirilmesi gerektiğini söyler. Bu nedenle iki yerdeki sayı farklı çıkabilir.

Search Console tıklaması ile GA4 anahtar olayı neden eşleşmiyor?

Search Console Performans raporu tıklama ve gösterim sayar; GA4 oturum ve olay sayar. İki araç farklı birimleri ölçtüğü için birebir eşleşme beklenmez. Trendleri karşılaştırın, sayıları eşitlemeye çalışmayın.

İlgili rehberler: Dönüşüm Oranı Optimizasyonu (CRO) Nedir? İlk Adımlar, Başvuru ve İletişim Formu Tasarımı ve Dönüşüm, Açılış Sayfasında Sosyal Kanıt ve Yorumlar.

Sonuç

GA4 anahtar olay kurulumunun özü sadelik ve tutarlılıktır: işinizin sonucunu temsil eden az sayıda eylemi işaretleyin, her birine tek ve sabit bir ad verin, çerez onayının ölçümde bıraktığı boşluğu gerçek kaynağınızla karşılaştırarak yönetin ve her değişiklikten sonra DebugView ile doğrulayın. Her form gönderimini işaretlemek yerine, bir kararı değiştirecek olayları seçin. Belgelerde yer almayan sınırlar ve davranışlar için yardım merkezinin güncel sayfalarına bakın.

Anahtar olaylarınızı ölçeceğiniz bir kampanya ya da görünürlük çalışması planlıyorsanız Akua Adforce'ta reklam alanlarını inceleyebilirsiniz; kapsam ve koşullar ilgili sayfada yazılıdır.