Data Stream Nedir?

Sayılarla ne demek?

GA4'te yapı üç katmanlıdır: hesap, mülk ve veri akışı. Mülk, raporların toplandığı yerdir; veri akışı ise verinin nereden geldiğini tanımlar.

Üç tür akış vardır: web akışı, Android uygulama akışı ve iOS uygulama akışı. Aynı işletmenin sitesi ve uygulaması, tek bir mülk altında ayrı akışlar olarak birleşebilir.

Akış yapısı basit görünür ama sonradan değiştirmek zordur. Yanlış kurulan bir yapı — örneğin her alan adı için ayrı mülk — kullanıcı yolculuğunu parçalara böler ve bu geriye dönük düzeltilemez.

Yapı nasıl kurulmalı?

Üçüncü satır en sık yanlış kurulan durum. Ödeme sayfası ayrı bir alan adında olduğu için ayrı akış ya da ayrı mülk açılıyor; kullanıcının ürün sayfasından ödemeye geçişi iki farklı kişi gibi kaydediliyor.

Nasıl yönetilir?

1. Akış sayısını az tutun. Platform başına bir.
2. Test ortamını ayırın. Deneme verisi canlıya karışmasın.
3. Alan adlarını bağlayın. Aynı akışta birden çok alan adı olabilir.
4. Akış ayarlarını belgeleyin. Otomatik ölçüm ve filtreler.
5. Silmeden önce düşünün. Silinen akışın verisi geri gelmez.

Uygulamada ne oluyor?

En sık hata, aynı site için birden çok web akışı açılması. Bir akış eski kurulumdan, diğeri yeni kurulumdan kalıyor; veri ikiye bölünüyor ve raporlar ikisinin toplamını gösteriyor.

İkinci gözlem, test ortamının canlı akışa bağlanması. Geliştirici denemeleri gerçek satış gibi kaydediliyor ve özellikle küçük hacimli sitelerde veriyi ciddi biçimde bozuyor.

Üçüncüsü, alt alan adları için ayrı mülk açılması. Blog, mağaza ve destek sayfaları farklı mülklerde olduğunda içerikten satışa giden yol hiç görünmüyor.

Dördüncüsü, uygulama ve web verisinin ayrı mülklerde tutulması. Aynı kullanıcının iki platformdaki davranışı birleştirilemiyor ve toplam müşteri yolculuğu okunamıyor.

Beşincisi, akış ayarlarının bilinmemesi. Otomatik ölçüm özellikleri akış düzeyinde açılıp kapanıyor; kimin neyi açtığı bilinmediğinde yeni olaylar nereden geldiği anlaşılmadan raporlara giriyor.

Altıncısı, eski akışın silinmesi. Kullanılmadığı düşünülen bir akış siliniyor ve geçmiş veri kalıcı olarak kayboluyor.

Yedincisi, akış ile mülk kavramının karıştırılması. Filtreler, veri saklama ve anahtar etkinlikler mülk düzeyinde; akış düzeyinde arandığında bulunamıyor.

Sekizincisi, ajans tarafından kurulan yapının devralınmaması. Mülk ajansın hesabında kalıyor; ilişki bittiğinde işletme kendi verisine erişemiyor.

Dokuzuncusu, farklı ülke sitelerinin tek akışta toplanması. Dil ve para birimi farklıyken tek akış kullanıldığında gelir raporları karışıyor; bu durumda dikkatli bir parametre yapısı gerekiyor.

Onuncusu, akış kimliği ile ölçüm kimliğinin karıştırılması. Kurulumda yanlış değer kullanıldığında veri başka bir yere gidiyor ya da hiç gitmiyor.

On birincisi, yapının büyüme planıyla düşünülmemesi. Bugün yalnızca site var ama yakında uygulama gelecekse, mülkü şimdiden ikisini kapsayacak şekilde kurmak ileride taşıma zahmetini ortadan kaldırıyor.

On ikincisi, mülk sahipliğinin belgelenmemesi. Kimin yönetici olduğu, hangi e-postaya bağlı olduğu yazılı değilse, o kişi ayrıldığında bütün analitik yapıya erişim tek bir hesaba takılı kalabiliyor.

Neyi çözmez?

Doğru akış yapısı, eksik olay kurulumunu tamamlamaz. Verinin nereden geldiğini düzenler; ne geldiğini değil.

Sıkça sorulan sorular

Kaç akış açmalıyım?

Platform başına bir: web için bir, her uygulama için bir.

Ödeme alt alan adı için ayrı akış gerekir mi?

Gerekmez. Aynı akışta alan adları arası ölçüm ayarlanmalı.

Test sitesini nereye bağlamalıyım?

Ayrı bir mülke. Deneme verisi canlı raporlara karışmamalı. Yakından ilişkili bir kavram olan Third Party Data, markayla doğrudan ilişkisi olmayan dış kaynaklardan (veri brokerları, çerezler) toplanan veridir; gizlilik nedeniyle azalmaktadır.

Bu kavramın bütün resim içindeki yerini Dönüşüm Takibi ve Ölçümleme Rehberi içinde ayrıntılı anlattım.