Google Analytics 4 için raporlarınızı başınızı ağrıtmadan nasıl yeni sürüme geçirebilirsiniz?

Google Analytics Universal (GAU) kullanıcılarının 2023 yazında Google Analytics 4'e (GA4) geçmek zorunda kalacaklar. Bununla ilgili temel sorun, GA4'teki veri modelinin ve metrik hesaplama mantığının GAÜ'ye kıyasla kökten farklı olmasıdır. GA4'e geçiş yapıldıktan sonra geçmiş verilerin bir kısmı GAU yapısında, yeni veriler ise GA4 yapısında saklanacaktır. Bu nedenle, işletmeler geçiş yaptıktan sonra (orta düzey veri analistleri için en az 100 saatten fazla çalışma) yıldan yıla (YoY) metrikleri değerlendirmek için ciddi çaba sarf etmelidir.

Analistler için bu, Google Analytics Universal ve Google Analytics 4 metrikleri arasında uyum sağlamak için SQL sorgularının sayfalarını yazmak ve düzenlemek için her gün harcayacakları anlamına gelir. Ancak, bunu aşmanın bir yolu var! Analistler, SQL sorgularını sürekli olarak yeniden yazmadan dakikalar içinde geçici raporlar oluşturabilir ve bu makalede size nasıl yapılacağını anlatacağız.

Universal Analytics 1 Temmuz 2023'te kullanımdan kaldırılacak ve yerini Google Analytics 4 alacaktır. Google Analytics 360 (GA'nın ücretli sürümü) müşterileri için geçiş süresi 1 Temmuz 2024'e kadar uzatılmıştır. GA'nın hangi sürümünü kullanırsanız kullanın, raporlarınızın yeni veri şemasına göre güncellenmesi an meselesidir.

Bu geçiş ışığında, analistler için en zorlu görevlerden biri, Google Analytics Universal ve Google Analytics 4'ten gelen verileri birleşik bir biçimde sağlamaktır.

Bu görevi zorlaştıran durumlar:

• Metrik hesaplama mantığı GAU ve GA4 arasında önemli ölçüde farklılık gösterir. Özellikle, bu ürün sürümleri, geleneksel ölçümleri bile farklı şekilde hesaplar. GAÜ ve GA4'teki tüm metrikleri tek bir tabloya sürükleyip her şeyin yolunda gitmesini bekleyemezsiniz.
• Google BigQuery veri şemaları da önemli ölçüde farklıdır. Universal Analytics, oturuma dayalı veri şemaları uygularken, Google Analytics 4'te olaya dayalı veri şemaları bulunur.
• Panolar, yıllık metrikleri ve sezonluk trendleri içerir. Öyleyse soru, tüm bu ölçümlerle gösterge tablolarını kullanmaya nasıl devam edileceğidir.

Belirli bir örneğe bakalım. Bu kontrol paneline sahip olduğumuzu varsayalım:

Bu kontrol panelinin en önemli kısmı, mevcut ve geçmiş dönemler için belirli metriklerin karşılaştırmasını temsil eden sezonluk metriklerdir. Geçmiş ve operasyonel veriler, pazarlama panolarında YY metriklerini desteklemek için aynı formatta olmalıdır.

Bu durumda analistin karşılaştığı zorluk, pazarlama ekibi için güvenilir raporlar sağlamak üzere N+ eski SQL sorgusunu yükseltmektir. SQL sorgularındaki küçük düzeltmelerden bile etkilenebilecek her şeyi test etmek ve hata ayıklamak zordur.

Geçiş riskleri de dikkate alınmalıdır. Bir raporu yeni kaynağa (GAU'dan GA4'e) aktardıktan sonra analistler, veri şeması ve metrik hesaplama mantığındaki temel farklılıkları hesaba katamayabilir. Örneğin, oturumlar farklı şekilde oluşturulur: GA4'te yalnızca ilk kullanıcı kaynağı dikkate alınır ve bir oturuma götüren diğer tüm kaynaklar ihmal edilir. Bu nedenle, bazı trafik kaynakları raporda görünmez.

İlk başta, bu fark edilmeyebilir. Ancak iki ila üç çeyrekte, yanlış bir pano, %30 veya daha yüksek bütçe kaçağıyla verimsiz reklam harcamalarına yol açacaktır.

Dashboard hazırlamak ve oluşturmak bize Jenga'yı hatırlatıyor. Ne zaman bir rapordaki bir bloğu değiştirmeleri gerekse, analistler parmaklarını çapraz tutar ve tüm yapının yıkılmamasını umarlar.

OWOX'ta, müşterilerimizin raporlarını Universal Analytics (veya GA 360) veri şemasından Google Analytics 4 veri şemasına aktarırken benzer sorunları zaten başarıyla çözüyoruz. Bu nedenle çözümümüzü ve bazı SQL sorgularımızı blog okuyucularımızla paylaşmak istiyoruz. Umarız bu bilgiler, raporlarınızı başınızı ağrıtmadan aktarmanıza yardımcı olur.

Rapor hazırlama yaklaşımımız (oluşturuldukları iş alanından bağımsız olarak) modellenmiş veriler yerine ham verilere dayanmaktadır.

Bir veri modeli, veri varlıklarını, özniteliklerini ve varlıklar arasındaki ilişkileri tanımlar. Örneğin, kullanıcıların web sitesindeki eylemleri belirli bir oturum için birleştirilir ve bir kullanıcı bir oturumda birkaç çevrimiçi dönüşüm gerçekleştirebilir.

Eylemler, Kullanıcılar, Oturum ve Çevrimiçi dönüşüm olmak üzere dört nesne ve üç bağlantı vardır: oturumlar ve eylemler arasında birden çoğa, kullanıcı ile çevrimiçi dönüşümler arasında birden çoğa ve oturumlar ile çevrimiçi dönüşümler arasında birden çoğa. çevrimiçi dönüşümler.

Veri modeli, gerçek dünyaya ilişkin algımızı yansıtır veverilerimiz ne hakkındadır?Nasıl ilişkilidir?Verilerle çalışırken hangi koşulları ve kısıtlamaları uyguluyoruz?İnsanların birbirini net bir şekilde anlaması için bir veri modeli gereklidir.

Veri modelleme, verileri, veri modelinizin gereksinimlerini karşılayan bir biçime dönüştürme işlemidir.

• Analitik çalışmalarının değerini ve verimliliğini şu yollarla artırın:
• Rapor yapıları ve metrik hesaplama mantığındaki değişiklikleri hızlandırma
• Destekleyici raporların ve panoların maliyetinin düşürülmesi
• Rapor tartışmalarını ve onaylarını basitleştirme
• Raporlardaki veri kalitesini şu şekilde artırın:
• Parametre ve metrik hesaplama mantığını uygularken tekrardan kaçınma
• Doğru verilerin kaynağı olan tek bir veri katmanına sahip olmak

Veri modeli, çok sayıda aracın yerini alır ve nesneleri ve bunların hesaplama mantığını (tüm raporlar için geçerlidir) tanımladığı için bir raporun mantığını açıklar.

OWOX BI, ham verileri analitiğe hazır bir formata dönüştürerek size saatlerce süren veri hazırlığından tasarruf ettirir. Hem Universal Analytics hem de Google Analytics 4 verilerini raporlarınıza sorunsuz bir şekilde entegre eder.

Aşağıda, Google Analytics verilerine dayalı olarak oluşturulmuş bir veri modeli örneği verilmiştir:

Gördüğünüz gibi oturumlar, işlemler, sayfalar ve cihazlar dahil olmak üzere birçok nesne var.

Burada en ilginç ve önemli olan şey ise bu nesnelerin yapısının birbirine bağlı olmaması ve veri kaynakları ile bir ilgisinin olmamasıdır. Bu nesneleri canlı verilerle doldurmak için hangi kaynakların kullanıldığı önemli değildir (Matomo, Adobe, Google Analytics, vb.). Veri kaynağı ne olursa olsun, model, işletmenizi temsil eden veri modeliyle aynı nesneleri döndürür. Çalıştığınız gerçek dünya nesnelerini ve ölçümlerini gösterir.

Gerçek dünyada nasıl göründüğüne bakalım.

Universal Analytics'ten dışa aktarılan oturumlar veya Google Analytics 4'ten dışa aktarılan olaylar gibi ham verilerin üzerine SQL sorguları yazmak yerine, modellenmiş veriler oluşturabilirsiniz. Oturumlar, kullanıcılar ve sayfa görünümleri gibi gerçek dünyadaki nesneleri ve varlıkları temsil eden evrensel ve anlaşılması kolay tablolardır.

Spesifik örnekleri ve veri şemalarını ele alalım.

İşte bir ham veri örneği. Bunlar, Google Analytics Universal (solda) ve Google Analytics 4 (sağda) için Google BigQuery veri şemasının ekran görüntüleridir.

Yukarıda yazdığımız gibi, veri şemaları farklıdır. Bu verileri Google Data Studio kontrol paneline bağlamanın bir yolunu bulmalıyız.

Deneyimlerimize dayanarak, modellenmiş tablolar oluşturmak, veri hazırlamayı basitleştirmenin en iyi yoludur. İşte nasıl görünebilecekleri:

Bunlar, yukarıdaki veri modelindeki nesne listeleridir. Google Analytics 360 ve Google Analytics 4 için nesne listesinin aynı olduğunu görebilirsiniz.

Bu, aynı sorguları kullanarak pano sorgunuzu bu verilerle bağlayabileceğiniz anlamına gelir. Bu sorgunun yapısı aynıdır.

Raporlarınızı ham veriler yerine modellenmiş veriler üzerinde oluşturmayı düşünmeniz için önemli nedenleri görelim.

1. Veri meyve gibidir: Karıştırmadan önce temizlemelisiniz.Analistler, farklı hizmetlerden ve sistemlerden veri toplar. Doğal olarak, bu verilerin yapısı ve formatı kaynaklar arasında farklılık gösterir. Rapor oluşturmak için farklı kaynaklardan gelen verilerin doğru şekilde birleştirilmesi gerekir. Bağlayıcılar veya çeşitli ETL hizmetleri aracılığıyla yüklenen veriler kendi başına hatalıdır (hatalar, tekrarlar ve tutarsızlıklar içerir) ve birleşik bir mantık ve yapıdan yoksundur. Hatalı ve parçalanmış veriler temizlenmeli ve analize hazır bir formatta normalleştirilmelidir.

OWOX BI ile verileri manuel olarak temizlemeniz, yapılandırmanız ve işlemeniz gerekmez. Hizmet, ham verileri otomatik olarak analize hazır bir biçime normalleştirir.

2. Her rapor için iş mantığını kopyalayıp yeniden yazmanız gerekmez;örneğin, şunları yapmanıza gerek yoktur:

• Tekilleştirilmiş işlemler
• Bot ve dahili trafiği filtreleyin
• Kanal gruplandırma kurallarını tanımlayın
• Yeni ve geri gelen kullanıcılar için ölçüt tanımlayın
• UTM parametre izlemeyi düzeltin

Her veri analistinin pazarlamacılardan şu tür talepler aldığına şüphe yok: Geçmiş verilere dayalı olarak kanal gruplama kurallarımızı ayarlamak veya iyileştirmek istiyoruz veya İşleyiş şekliyle olmayan yeni ve geri gelen kullanıcılar için kriterler belirlemek istiyoruz Google Analytics'te, ancak kendi yöntemimizle veya Yalnızca son altı ay içinde satın alma işlemi gerçekleştiren kullanıcıları geri döndürmek istiyoruz.

Raporları ham verilere dayalı olarak oluşturursanız, tüm veri dönüşümleri ve hazırlık etkinliklerinin rapor düzeyinde yürütülmesi gerekir. Bu, iş mantığını her rapora kopyalamak için çok zaman harcamanız gerektiği anlamına gelir.

Modellenmiş veriler üzerinde raporlar oluşturursanız, iş mantığını kopyalamanız gerekmez. Modelleme aşamasında bir kez yaratırsınız.

3. Modellenmiş verilere dayalı raporlar oluşturmak, ad hoc analizi hızlandırır.Yıllık analizi etkinleştirmek için yeni SQL ve düzenleme dönüşümleri yazarken zamandan tasarruf edebilirsiniz.

4. Veri modelleme sayesinde tüm raporlar için tek bir doğruluk kaynağı oluşturabilirsiniz.Bir rapordaki veri kaynağını değiştirdiğinizde, artık sorunlu her sorguyu çözmeniz gerekmez. Oturumlar, işlemler ve olay verileri için bu kaynağa güvenebilirsiniz.

5. Raporlama katmanını basitleştirin.Modellenmiş veriler üzerine raporlar oluşturmak, bazı karmaşık pencere işlevleri ve hatta JSON ayıklama işlevleri yazmakla birlikte, iç içe geçmiş alanlar ve kayıt alanlarıyla uğraşmaktan daha kolaydır.

1. Modellenmiş veriler bir başka orta katmandır.Ayarlamak zaman alır ve ayrıca modellenmiş verileri izlemeniz ve hatalarını ayıklamanız gerekir.

2. Normalleştirmeler için karmaşık JOIN'ler.

3. Ekstra veri işleme.Verileri bir model biçiminde dönüştürmek için verileri sorgulamanız gerekir. Bir tarihte bir bölüm tablosu kullanmanızı tavsiye ederiz. Tarih boyutları etrafında oluşturulmuş bir bölümleme tablosu ile yalnızca gerekli verileri güncelleyebilirsiniz. Tüm devasa tabloları yeniden yazmanız ve Google BigQuery'de işlenen tüm veriler ve gigabayt veya terabaytlarca veri için ödeme yapmanız gerekmez. İhtiyacınız olan bölümü yükseltebilir ve güncelleyebilirsiniz. Bu yaklaşım, tüm veri tablolarını işlemekten daha ekonomiktir.

Bu eksileri halletmenize yardımcı olmak için, Google Analytics 360 ve Google Analytics 4 verilerini modellemek için SQL şablonları hazırladık. Bu makalede sağlanan ek malzemeleri indirerek bunları kontrol edebilirsiniz.

Raporlarınızı yeni Google Analytics 4 veri şemasına güncellemek ne kadar kolay? Modellenmiş verileri kullanın. Ham veriler üzerine raporlar oluşturmak yerine, GA Universal ve GA 4 şemalarının üzerinde evrensel ve kolay anlaşılır düz tablolar oluşturabilirsiniz.

Bunu yapmak, verileri kopyalama ve normalleştirme mantığını düzinelerce SQL sorgusuna ekleme ihtiyacını ortadan kaldıracaktır. Veri modelleme aşamasında bir kez yapacaksınız. Her proje için sihirli bir değnek olmasa da, düzenli olarak özel raporlara ihtiyaç duyanlar için en uygun yöntemdir.

Modellenmiş tabloları kurmak ve düzenlemek istiyorsanız OWOX BI demosuna kaydolun. Verilerinize dayalı olarak projelerinizde benzer tabloların nasıl hazırlanacağı ile ilgili detayları memnuniyetle paylaşacağız.