GA4 / Google Analytics

GA4 Otomatik Toplanan Event'ler: CRO İçin Görmezden Gelinen Bedava Veri

DDijital Kafa20 Ağustos 20269 dk okuma

GA4 otomatik toplanan event'lerin CRO analizinde kullanımı

GA4, siz hiçbir kurulum yapmadan 40'tan fazla event'i kendi kendine toplar. Kullanıcı sayfayı kaydırdı mı, forma başladı mı, uygulamayı sildi mi, video izledi mi. Hepsi orada duruyor. Buna rağmen çoğu ekip bu veriye hiç bakmaz, çünkü "nasılsa otomatik toplanıyor" diye kurulum gerektiren özel event'lere odaklanır. Oysa dönüşüm hunisindeki sürtünme noktalarının en erken sinyalleri, tam da bu otomatik toplanan event'lerde (automatically collected events) gizlidir.

Bu yazıda hangi event'lerin gerçekten işe yaradığını web ve app tarafı için ayrı ayrı ele alıyor, bu event'leri CRO'da nasıl okuyacağınızı ve hangi veriyle eşleştirdiğinizde anlam kazandıklarını anlatıyoruz. Tek başına bakıldığında bu event'ler gürültüdür. Doğru veriyle birleştirildiğinde ise hangi sayfada neyi test etmeniz gerektiğini söyleyen bir hipotez üreticisine dönüşür.

Otomatik toplanan event nedir, gelişmiş ölçümden farkı ne?

GA4'te üç katman event vardır ve bu ayrımı bilmek önemlidir:

  • Otomatik toplanan event'ler: Google etiketi veya Firebase SDK kurulduğu anda toplanmaya başlar. session_start, first_visit, first_open, user_engagement gibi. Kapatamazsınız, ayar gerektirmez.

  • Gelişmiş ölçüm event'leri (enhanced measurement): scroll, click, file_download, form_start, form_submit, video event'leri ve view_search_results. Bunlar da kod gerektirmez ama mülk ayarlarında açık olması gerekir. İlk kontrol noktanız bu: Yönetici > Veri akışları > Gelişmiş ölçüm bölümüne girip hangi anahtarların açık olduğuna bakın.

  • Özel event'ler: add_to_cart, purchase, generate_lead gibi sizin (veya GTM'in) tanımladığı event'ler.

Bu yazının konusu ilk iki katman. Yani hiçbir geliştirici eforu harcamadan elinizde olan veri.

Web tarafında en kritik event'ler

Web akışında (Google etiketi ile) toplanan event'lerden CRO açısından en değerlileri şunlar:

  • first_visit - Kullanıcının siteye ilk gelişi. Yeni ve geri dönen kullanıcı ayrımının temelidir. Dönüşüm oranını bu ikisi için ayrı okumadan hiçbir CRO kararı vermeyin, çünkü iki grup bambaşka davranır.

  • session_start - Her oturumun başlangıcı. Tek başına sıradan görünür ama user_engagement ile oranladığınızda etkileşimsiz oturumların payını verir.

  • user_engagement - Kullanıcı sayfada 1 saniyeden fazla odaklandığında ateşlenir. Etkileşim oranının (engagement rate) hammaddesidir.

  • scroll - Kullanıcı sayfanın %90'ına ulaştığında ateşlenir. Tek eşik olduğunu unutmayın, %25 veya %50 derinliği görmek isterseniz GTM ile özel kurulum gerekir.

  • form_start ve form_submit - Forma başlama ve formu gönderme. CRO için web tarafının en değerli çifti budur.

  • view_search_results - Site içi arama yapıldığında ateşlenir. Kullanıcının navigasyonda bulamadığı şeyi size kendi kelimeleriyle söylediği tek event'tir.

  • file_download - PDF, katalog, fiyat listesi indirmeleri. B2B'de niyet sinyali olarak altın değerindedir.

  • video_start, video_progress, video_complete - Gömülü YouTube videoları için izleme davranışı.

  • App tarafında en kritik event'ler

    Uygulama akışında (Firebase SDK ile) toplanan event'lerden öne çıkanlar:

    • first_open - Kullanıcının uygulamayı indirdikten sonra ilk açışı. Web'deki first_visit'in karşılığıdır ve aktivasyon hunisinin sıfır noktasıdır.

    • app_remove - Kullanıcı uygulamayı sildiğinde ateşlenir (yalnızca Android'de toplanır, iOS bu sinyali vermez). Çoğu ekibin varlığından bile haberdar olmadığı bu event, onboarding ve değer önerisi sorunlarının en net göstergesidir.

    • app_update - Kullanıcı yeni sürüme geçtiğinde ateşlenir. Sürüm bazlı davranış karşılaştırmasının anahtarıdır.

    • app_exception - Uygulama çöktüğünde veya hata verdiğinde oluşur. Dönüşüm düşüşünün teknik mi davranışsal mı olduğunu ayırt etmenizi sağlar.

    • in_app_purchase - App Store ve Play Store üzerinden yapılan uygulama içi satın almalar. Gelir tarafının otomatik gelen kısmıdır.

    • notification_open ve notification_dismiss - Push bildirimlerinin açılma ve kapatılma davranışı. Push stratejinizin gerçekten çalışıp çalışmadığını gösterir.

    • screen_view - Web'deki page_view'in karşılığı, ekran bazlı akış analizinin temelidir.

    Web ve app'i aynı mülkte topluyorsanız bu ayrımı raporlarınızda da koruyun. Aynı isimli davranışlar iki platformda farklı anlama gelir ve karışık okumak iki tarafı da bozar.

    Neden takip etmelisiniz: sıfır maliyet, ama iki tuzakla birlikte

    Bu event'lerin en güçlü yanı kurulum maliyetinin sıfır olması. Veri zaten akıyor, tek yapmanız gereken bakmak. Ama iki tuzağa dikkat etmeden bu veriye güvenmeyin:

    Tuzak 1: Gelişmiş ölçüm ayarlarını kimse kontrol etmemiştir. Mülk kurulurken hangi anahtarların açıldığını çoğu ekip bilmez. Form etkileşimi kapalıysa form_start hiç toplanmaz ve siz "formlara kimse başlamıyor" diye yanlış teşhis koyarsınız. GA4 denetimlerimizde ilk baktığımız maddelerden biri budur.

    Tuzak 2: Her event her yerde güvenilir ateşlenmez. form_submit özellikle tek sayfa uygulamalarda (SPA) ve iframe içine gömülü formlarda kaçırabilir veya sayfa yapısına göre çift ateşlenebilir. Sahada çalıştığımız hesaplarda kritik bir event'in çift ateşlendiğini ve tekilleştirme yapılmadan okunan her raporun şişkin çıktığını defalarca gördük. Kural basit: Bir event'i karar verisine çevirmeden önce DebugView ile gerçekten ve bir kez ateşlendiğini doğrulayın.

    CRO'daki rolü: event'leri tek tek değil, çift olarak okuyun

    Otomatik event'lerin CRO değeri tek tek sayılarında değil, oranlarında saklıdır. İşe yarayan okuma her zaman bir çifttir:

    • form_start / form_submit - Forma başlayıp göndermeyenlerin oranı, form terk oranınızdır. Bu oran %70'in üzerindeyse sorun trafikte değil formun kendisindedir. Alan sayısı, hata mesajları, zorunlu üyelik. Detaylı çözüm için form optimizasyonu yazımıza bakabilirsiniz.

  • scroll / dönüşüm event'i - Kullanıcı sayfanın sonuna kadar iniyor ama dönüşmüyorsa içerik ilgi çekiyor, teklif ikna etmiyor demektir. Kaydırma yoksa sorun daha yukarıda, ilk ekranda başlıyordur.

  • view_search_results / çıkış - Site içi arama yapıp sonrasında siteyi terk edenler, navigasyonunuzun karşılamadığı talebin listesini bırakır. Arama terimlerini düzenli okuyun, en sık arananlar menünüzde yoksa oraya taşıyın.

  • session_start / user_engagement - Oturum açılıp etkileşim oluşmuyorsa o trafik kaynağı size ziyaretçi değil, sekme açıp kapatan insanlar getiriyordur.

  • first_open / app_remove - İlk açılıştan kısa süre sonra gelen silmeler, uygulamanın vaadi ile ilk deneyimi arasındaki boşluğu ölçer. İlk 7 gün içindeki silme oranı, onboarding'inizin gerçek karnesidir.

  • video_start / video_complete - Ürün videonuzu başlatanların ne kadarı bitiriyor? Tamamlanma düşükse videonun uzunluğu veya ilk 10 saniyesi sorunludur.

  • Bu çiftlerin her biri bir test hipotezidir. CRO'da en pahalı hata neyi test edeceğini bilmeden test etmektir ve bu çiftler size test sırasını bedavaya verir. Hangi adımda kaybettiğinizi daha derin görmek için bu event'leri Huni Keşfi ile adım adım bağlamak bir sonraki seviyedir.

    Hangi veriyle eşleşirse anlam kazanır?

    Otomatik event'ler bağlamsız okunduğunda yanıltır. Dört eşleştirme bu veriyi karar verisine çevirir:

    1. Dönüşüm event'leriyle: Yukarıdaki tüm çift okumaların sağ tarafına gerçek dönüşümünüzü koyun. purchase, generate_lead veya sizin için para eden her ne ise. Scroll oranı yüksek ama dönüşmeyen sayfa listesi, test edilecek sayfa listenizdir.

    2. Trafik kaynağıyla: Aynı sayfada farklı kanallar bambaşka davranır. Etkileşimsiz oturumların hangi kampanyadan geldiğini bulduğunuzda, bu bir CRO bulgusu olmaktan çıkıp medya bütçesi kararına dönüşür. Bu köprüyü kurarken GA4 ile Ads verisinin neden birebir tutmadığını da aklınızda tutun.

    3. Cihaz ve platform kırılımıyla: form_start / form_submit oranını bir de mobil ve masaüstü için ayrı hesaplayın. Çoğu hesapta form terki mobilde belirgin şekilde yüksektir ve genel ortalama bu yarayı gizler. App tarafında da app_remove'u işletim sistemi sürümü ve cihaz modeliyle kırın, bazen "değer sorunu" sandığınız şey belirli cihazlarda yaşanan bir performans sorunudur.

    4. BigQuery ile ham event analizi: GA4 arayüzü size örneklenmiş ve modellenmiş veri gösterir. Otomatik event'lerin tamamı BigQuery'ye ham olarak aktarılabilir ve form terki ile silme analizlerinin gerçek derinliği oradadır. Kullanıcı bazında "forma 3 kez başlayıp hiç göndermeyenler" gibi segmentler yalnızca ham veride görünür.

    Sonuç: bedava veriyi karar verisine çevirin

    GA4'ün otomatik topladığı event'ler için kimseden bütçe istemenize gerek yok, veri zaten toplanıyor. Yapılacak iş üç adım: Gelişmiş ölçüm ayarlarının açık ve doğru olduğunu kontrol edin, kritik event'lerin gerçekten ateşlendiğini DebugView ile doğrulayın, sonra yukarıdaki çiftleri kendi huninize göre kurup her ay aynı gözle okuyun. CRO'ya GA4 metrikleriyle başlama rehberimiz bu okumayı düzenli bir rutine çevirmenize yardım eder.

    Dijital Kafa yorumu

    Yıllardır gördüğümüz tablo şu: Ekipler binlerce lira harcayıp özel event mimarileri kurarken, sıfır maliyetle zaten toplanan bu veriye hiç bakmıyor. Oysa bir hesabı denetlerken ilk açtığımız yer burasıdır, çünkü form terki, etkileşimsiz trafik ve uygulama silme sinyalleri daha ilk günden hangi taşın altına bakacağımızı söyler.

    Biz veri ölçümleme çalışmalarında önce bu otomatik katmanın sağlığını doğruluyor, sonra dönüşüm optimizasyonu tarafında bu event çiftlerini önceliklendirilmiş bir test listesine çeviriyoruz. GA4'ünüzde bu verinin ne söylediğini birlikte okumak isterseniz bizimle iletişime geçebilirsiniz.

    İlgili Yazılar