GA4 mülkünüz geçen ay 4,180 satın alma işlemi bildirdi. Sipariş tablonuz ise 4,690 diyor. Hangisinin doğru olduğu sorulduğunda, dürüst cevap ikisi de değil, ta ki eksik 510 siparişin nereye gittiğini söyleyene kadar. Bu bir düzen sorunu değil. Ürettiğiniz her deney sonucu ve her önceliklendirme puanı, bilinmeyen bir miktarda ve bilinmeyen bir yönde yanlış olan bir sayı üzerinden hesaplanıyor.
Google, ölçülmemiş büyük bir dilimi normal kabul ediyor: Onay modu için davranışsal modelleme, bir özellik kayıt yapana kadar devreye girmiyor. günde en az 1,000 etkinlik ile analytics_storage='denied' en az 7 günBunun altında kalan veriler ise eksik olarak kalır.
Bu, e-ticaret ekibinde analitik veya CRO'dan sorumlu olan herkes içindir. Sonunda bir uzlaştırma tablosuna, her biri için test içeren, adlandırılmış nedenlere göre açığın ayrıştırılmasına ve savunabileceğiniz bir tolerans değerine sahip olacaksınız.
Satın alma mutabakatının aslında neyi ölçtüğü
Uzlaşma, "sayıları eşleştirmek" anlamına gelmez. Sayılar asla eşleşmez ve onları eşleştirmeye zorlayan bir ekip genellikle aradaki farkı olduğu gibi bırakmaktan daha kötü bir şey yapmıştır. Üç soruyu yanıtlar: fark ne kadar büyük, hangi mekanizmalar bu farkı oluşturuyor ve ne kadarı hangi maliyetle geri kazanılabilir? Herhangi bir deney yapmadan önce bunu gerçekleştiririz, çünkü siparişlerin bilinmeyen bir kısmını sessizce düşüren bir dönüşüm olayında ölçülen bir test, bir deney değildir.
Adım 1: Sipariş kimliği üzerinden birleştirilebilen iki tabloyu seçin.
Her iki sistemden de, aynı takvim aralığı için, her sipariş için bir satıra ihtiyacınız var; bu satırlarda her iki tarafta da mevcut bir anahtar bulunmalıdır.
- Arka uç: Sipariş kimliği, işletmenin raporlama saat dilimindeki oluşturulma zaman damgası, GA4'te yapılandırdığınız aynı vergi ve kargo esasına göre sipariş değeri, ödeme yöntemi, cihaz, ülke, durum.
- GA4: BigQuery dışa aktarımı, kullanıcı arayüzü değil. Sorgu
purchaseolaylarlaecommerce.transaction_id,event_timestamp,ecommerce.purchase_revenueCihaz kategorisi ve trafik kaynağı.
BigQuery'yi bilinçli olarak kullanın. Onay modundan elde edilen modellenmiş veriler GA4 standart raporlarında ve bazı araştırmalarda görünür, ancak Google bunun değil BigQuery dışa aktarımında, kitleler, kullanıcı gezgini, kohort veya elde tutma keşifleri veya tahmine dayalı metrikler bulunur. Kullanıcı arayüzünü sipariş tablonuzla karşılaştırdığınızda, bir tahmini bir gerçekle karşılaştırmış olursunuz.
Ardından sipariş kimliğine göre tam dış birleştirme yapın. Artık üç kategoriye sahipsiniz: her ikisinde de, yalnızca arka uçta ve yalnızca GA4'te. Üçüncü kategori daha küçük ancak en teşhis edici olanıdır.
Adım 2: Boşluğu tek bir şekilde değil, üç farklı şekilde ifade edin.
Tek bir aylık yüzde her şeyi gizler. Üçünü de hesaplayın:
- Sipariş sayısı farkı: (arka uç siparişleri eksi eşleşen GA4 satın alımları) / arka uç siparişleri. Bu, takip kaybını izole eder.
- Gelir farkı: Değer üzerinde de aynı hesaplama yapılır. Eğer sayım farkı %3 ve gelir farkı %11 ise, bir takip sorununuz değil, değer tanımlama sorununuz var demektir (vergi, kargo, indirimler, para birimi, hediye kartları).
- Günlük fark varyansı: Günlük sipariş sayısı farkını grafik üzerinde gösterin. Düz bir çizgi, onay veya engelleyiciler gibi yapısal bir nedeni gösterir. Ani yükselişler ise dağıtımları, kampanya patlamalarını veya bir ödeme sağlayıcısı olayını gösterir.
3. Adım: Boşluğu adlandırılmış nedenlere ayırın.
Bu tabloyu inceleyin. Her bir nedenin, bir saatten kısa sürede doğrulanmasını veya elenmesini sağlayabilecek bir testi vardır.
| Sebeb olmak | Nasıl test edilir | Verilerdeki imza |
|---|---|---|
| Onay verilmedi, etiket ateşlenmedi. | CMP'nizin onay durumu kaydını, aynı dönem için GA4 oturumlarıyla karşılaştırın. | Günlük yüzdesel düşüş istikrarlı; ağırlıklı olarak AB ve Türkiye trafiğinden kaynaklanıyor. |
| Reklam ve izleyici engelleyiciler | Onay URL'si için sunucu günlük isteklerini sayın ve bu URL'deki GA4 satın alma olaylarıyla karşılaştırın. | Masaüstü, Firefox ve gizlilik odaklı tarayıcılarda sorunlara yol açar; zaman içinde istikrarlıdır. |
| Onay sayfası hiç yüklenmiyor. | Sunucu günlüklerinde onay URL'si hiç istenmemiş olan yalnızca arka uçtan gelen siparişleri sayın. | Banka yönlendirmeli ve 3DS ödeme yöntemlerinde yoğunlaşmıştır. |
| Yinelenen satın alma etkinlikleri | GA4 satın alma olaylarını sayın transaction_id | GA4 bazı günlerde arka uç performansını aşıyor; sayfaları yenilemek ve geri düğmesine basmak çok zaman alıyor. |
| Alanlar arası bağlantı bozuk. | İnceleyin _gl ödeme sağlayıcısından dönüş yolculuğunu atlatır | Satın alımlar, ödeme alanına yönlendirme olarak atfedilen yeni oturumlarda gerçekleşir. |
| Çerez ömrü sıfırlama | Tarayıcıya göre yeni kullanıcı oranını segmentlere ayırın | Safari ve iOS'ta yeni kullanıcı ve doğrudan trafik artışı yaşandı. |
| Modellenmiş veriler ile ham veriler arasındaki fark | Aynı tarih aralığı için GA4 kullanıcı arayüzü toplamlarını BigQuery ile karşılaştırın. | Sipariş tablosunu açmadan önce bile iki Google rakamı birbirini uyuşmuyor. |
| Değer tanımı | Vergi, kargo ve indirimler dahil ve hariç olmak üzere arka uç gelirlerini yeniden hesaplayın. | Sayımlar eşleşiyor, gelir eşleşmiyor. |
| Zaman dilimi sınırı | Tam haftalara yeniden toplayın | Haftalık bazda fark sıfıra doğru küçülüyor. |
İkisi daha fazla özen gerektiriyor. transaction_id Tekrarlanan verilerin kaldırılması yalnızca web akışlarında çalışır, uygulama akışlarında çalışmaz ve Google, boş bir dize göndermenin Analytics'in tekrarlanan verileri kaldırmasına neden olacağı konusunda uyarıda bulunur. her satın alma etkinliği taşıyan transaction_id=''Bu tek hata, bir günün büyük bir bölümünü silebilir. Ayrıca, istenmeyen yönlendirmeler listesi, veri akışı başına 50 alan adıyla sınırlandırılmıştır; bu da birden fazla ödeme işlemcisi, cüzdan ve banka sayfası kullanıyorsanız sorun yaratır.
[DAHİLİ VERİLER GEREKLİ: Okuyucuların hangi nedenlerin genellikle baskın olduğunu görebilmeleri için, bu dokuz nedenin Switas uzlaşma çalışmalarındaki gözlemlenen dağılımı.]
4. Adım: Savunabileceğiniz bir tolerans belirleyin.
Google kabul edilebilir bir sapma oranı yayınlamıyor ve yaygın olarak alıntılanan "%5 sorun değil" ifadesi, bulabildiğimiz hiçbir Google belgesinde yer almıyor. Kendi oranınızı, yalnızca sayıya değil, ayrıştırmaya bağlı olarak belirleyin.
| Aylık sipariş sayısı farkı | Okuma | Action |
|---|---|---|
| Up 2% etmek | Saat dilimi sınırları ve normal veri tekilleştirme | Sebepleri kaydedin, üç ayda bir tekrar kontrol edin. |
| 2% 5% için | Her puanın belirli bir nedene bağlanması şartıyla kabul edilebilir. | Önce belgeleyin, sonra deneylere geçin. |
| 5% 10% için | Yapısal nedenlerden en az biri giderilmemiş durumda. | Mutlak dönüşüm sayılarına güvenmeden önce düzeltme yapın. |
| 10 üzerinde | Deney yapmaya uygun değil | Sorun çözülene kadar GA4 satın alımlarını birincil deney ölçütü olarak kullanmayı bırakın. |
Bunlar bizim işletme eşiklerimiz, sektör standardı değil. Asıl önemli nokta şu: Açıklanamayan %3, açıklanan %8'den daha kötü.
Adım 5: Saat başına en fazla siparişi kurtaran sırayla düzeltme yapın.
- Değer tanımı ve saat dilimi. Yapılandırma, mühendislik değil ve genellikle bir öğleden sonra sürer.
- Yinelenen ve boş işlem kimlikleri. Bir veri katmanı düzeltmesi.
- Alanlar arası ve istenmeyen yönlendirmeler. Her ikisini de yapılandırın, ardından test ortamındaki değil, canlı ödeme iade yolunu yeniden test edin.
- Sunucu tarafında gerçekleşen satın alma işlemi. Ölçüm Protokolünü kullanarak sipariş sisteminizden satın alma işlemini gönderin.
client_idOluşturulan web etiketiniz. Google, bu olayların orijinal istemci tarafı olay zaman damgasından itibaren 48 saat içinde gerçekleşmesini gerektirir, aksi takdirde ilişkilendirme beklendiği gibi işlenmeyebilir. Bu, engelleyiciler ve hiç görüntülenmeyen onay sayfaları nedeniyle kaybolan siparişleri kurtaran şeydir. - Onay mimarisi. En yavaş ve en politik olanı. Geri kalanını bilinen, boyutlandırılmış, belgelenmiş bir boşluk olarak ele alın.
Türkiye'de veya AB'de satış yaparsanız neler değişir?
İki bölgesel faktör rakamları etkiliyor.
Türkiye'de de onay isteğe bağlıdır, ancak Google'ın sağladığı güvenlik ağı olmadan. Türkiye Veri Koruma Kurumu, 2022/1358 sayılı kararıyla (23 Aralık 2022), yasal dayanağı olmadan reklam ve pazarlama çerezleri kullanan bir web sitesi işletmecisine 300,000 TL para cezası verdi ve zorunlu olmayan çerezler için aktif onay alınmasını şart koştu. Birçok Türk sitesi, onay modu sinyalleri gönderen bir banner yerine, Google etiketini doğrudan engelleyen bir banner ile yanıt verdi. Bu ayrım pahalıya mal oluyor: modelleme ihtiyaçları analytics_storage='denied' Olayların var olması için. Hiçbir şey tetiklemeyen bir banner, Google'a modelleme yapabileceği hiçbir şey vermez, bu nedenle veriler tahmin edilmek yerine kaybolur.
Türkiye'deki 3DS akışları, alıcıya POST yoluyla iade edilir. iyzico ile satıcı, çözümlenmiş bir 3DS sayfası oluşturur ve OTP onayının ardından iyzico, satıcının sayfasına yönlendirir. callbackUrl 'da status, paymentId hem de mdStatusPOST isteğiyle gelen bir geri dönüş, Google'ın alanlar arası ölçümü bozma olarak adlandırdığı şeydir, çünkü yönlendirmeler verileri silebilir. _gl Hedef yüklenmeden önce. Eğer kartla ödemelerde farkınız varken, kapıda ödemelerde farkınız sıfıra yakınsa, sebebi budur.
Yaygın olarak tekrarlanan ancak doğrulayamadığımız iki iddia
"Safari, birinci taraf çerezlerinin saklanma süresini 7 günle sınırlandırıyor." Kesin değil. WebKit'in belgelerinde ITP'nin JavaScript çerezlerini ve diğer komut dosyasıyla yazılabilir depolama alanlarını 7 gün sonra sildiği belirtiliyor. kullanıcı etkileşimi yokAyrıca, açılış sayfasına sınıflandırılmış bir alan adından bağlantı yoluyla ulaşıldığında JavaScript çerezlerinin süresini 24 saatle sınırlandırıyor. Simo Ahava'nın testleri, sürenin takvim günleri yerine tarayıcı kullanım günlerine göre işlediğini, bu nedenle geri dönen bir müşterinin bir tanımlayıcıyı bir haftadan çok daha uzun süre elinde tutabileceğini ortaya koydu.
"Yüzde 5'lik bir sapma kabul edilebilir." Bu rakam için Google'da herhangi bir kaynak bulamadık. Satıcı bloglarında ve forum cevaplarında dolaşıyor. Bunu bir eşik değer olarak değil, halk arasında yaygın bir bilgi olarak kullanın.
Bu yöntemin başarısız olduğu nokta
Uygulama içi yayınları kapsamaz. transaction_id Tekrarlanan kayıtların kaldırılması veya "bir siparişin" tek bir olay olmadığı abonelik ve kısmi gönderim modelleri uygulanmaz. Onay vermeyen bir kullanıcının kimliğini kurtaramaz, yalnızca hacmi tahmin edebilir. Ayrı ve daha zor bir sorun olan kanal atamasını düzeltmez. Ayrıca sipariş tablonuzun temiz olduğunu varsayar: iptal edilen ve dolandırıcılık nedeniyle engellenen siparişler iki tarafta tutarsız bir şekilde sayılırsa, yalnızca sorgunuzda var olan bir boşluğu kovalayacaksınız.
Sık Sorulan Sorular
Bunu ne sıklıkla çalıştırmalıyız? Önce tam olarak bir kez çalıştırın, ardından günlük fark grafiği oluşturun. Ödeme işlemi, CMP, ödeme sağlayıcısı veya etiket yöneticisinde herhangi bir değişiklik olduğunda tam ayrıştırmayı yeniden çalıştırın.
BigQuery yerine GA4 arayüzünü neden kullanmıyorsunuz? Arayüz, dışa aktarma işleminde bulunmayan modellenmiş kullanıcıları ve oturumları içerebilir; bu nedenle iki Google verisi birbiriyle çelişmektedir. Bir tahmine göre uzlaştırmak, aradaki farkı ayrıştırmayı imkansız hale getirir.
Sunucu tarafı etiketleme bu açığı tamamen kapatacak mı? Hayır. Engelleme yapan sistemler ve hiç görüntülenmeyen onay sayfaları nedeniyle kaybolan siparişleri kurtarır. Onay vermeyi reddeden kullanıcıları kurtarmaz.
GA4, arka uç sistemimizden daha yüksek performans gösteriyor. Bu mümkün mü? Evet. Genellikle sayfa yenilemelerinden kaynaklanan yinelenen satın alma olayları, boş veya yeniden kullanılan sayfalar. transaction_idveya üretim ortamına yönlendirilen emirlerin hazırlanması.
Onay modu, Türkiye'deki onay açığını düzeltiyor mu? Kısmen. Engellenen sinyaller, Google'ın hacim eşiklerine bağlı olarak modellemeyi mümkün kılar. Türk kurallarına göre yasal bir banner'ın yerini tutmaz.
İyi bir aralık ne anlama gelir? Her yüzde puanının bir adı olduğu bir yer. Belgelenmiş bir %8, açıklanamayan bir %3'ten daha iyidir.
Bu sorunu düzelttikten sonra geçmişe ait raporları yeniden düzenlemeli miyiz? Hayır. Düzeltme tarihini not edin ve dönemleri ayrı seriler olarak ele alın. İzlenen dönüşümlerin yeniden belirtilmesi denetim izini yok eder.
Fark %10'un üzerindeyken A/B testleri yapabilir miyiz? Bunları test aracı içinde ölçülen göreceli metrikler üzerinden çalıştırın, ancak fark ayrıntılı olarak incelenene kadar GA4'ün mutlak gelir etkisini raporlamayın.
Bu ay kendi mağazanızda bu mutabakat işlemini gerçekleştirin veya Analiz ekibimizin bunu sizinle birlikte yürütmesini sağlayın. ve size ayrıştırmayı, toleransı ve düzeltme sırasını teslim eder.
kaynaklar
- [GA4] Onay modu için davranışsal modelleme, Google Analytics Yardım
- [GA4] İşlem kimlikleriyle yinelenen anahtar olaylarını en aza indirme, Google Analytics Yardım
- [GA4] İstenmeyen yönlendirmeler, Google Analytics Yardımı
- [GA4] Alanlar arası ölçüm, Google Analytics Yardımı
- Ölçüm Protokolü etkinliklerini Google Analytics ve Google Geliştiriciler için gönderin.
- Onay modu parametreleri, Google Etiket Platformu dokümantasyonu
- WebKit'te İzleme Engelleme
- Simo Ahava'ya göre, WebKit tarayıcılarında JavaScript çerezlerinden süre sonu sınırı kaldırıldı.
- KVKK Kurul Kararı 2022/1358, 23 Aralık 2022
- 3DS Uygulaması, iyzico geliştirici dokümantasyonu
