GA4 e-ticaret takibi, ziyaretçinin ürün incelemesinden satın almaya kadar ilerleyişini ve gerçekleşen iadeleri ölçmek için kullanılır. Ancak sayfaya bir analitik etiketi eklemek ürün, sipariş ve iade verilerinin doğru aktarıldığını göstermez. Güvenilir rapor için olayların tetiklenme koşulları, sipariş kimliği ve parasal değerler birlikte doğrulanmalıdır.
Bu rehber e-ticaret yöneticisinin geliştiriciye iletebileceği bir kontrol planıdır. Kullanılan altyapı veya eklentiye göre kurulum değişir. Amaç, reklam kararlarını etkileyen eksik gelir, çift sayım ve hatalı iade verilerini bulmaktır.
Olay adlarını mağazanın gerçek akışıyla eşleştirin
Google'ın e-ticaret ölçüm rehberi, ürün ve alışveriş davranışları için önerilen olayları açıklar. Bu olaylar gerekli verilerle ayrıca uygulanmalıdır; temel sayfa görüntüleme kurulumu tek başına yeterli değildir.
| Olay | İzlenen aşama | İşletmenin kontrol sorusu |
|---|---|---|
view_item_list | Ürün listesinin görüntülenmesi | Hangi kategori veya liste gösteriliyor? |
view_item | Ürün detayının görüntülenmesi | Doğru ürün ve varyant mı iletiliyor? |
add_to_cart | Sepete ürün ekleme | Miktar ve ürün bilgisi doğru mu? |
begin_checkout | Ödeme sürecine başlama | Hangi sepetle başlanıyor? |
purchase | Satın alma | İşletmenin başarı koşulu gerçekten sağlandı mı? |
refund | İade | Hangi siparişin hangi ürünü iade edildi? |
İlk uygulamada bu akışın doğru çalışmasını sağlayın. Daha ayrıntılı kargo ve ödeme adımı ölçümü gerekiyorsa ek olayları planlayın. Kullanıcının henüz gerçekleştirmediği davranışı sadece sayfa yüklendi diye olmuş kabul etmeyin.
Satın alma olayının veri sözlüğünü hazırlayın
Google'ın purchase ve refund parametre referansına göre satın alma için benzersiz transaction_id ve ürünleri içeren items dizisi temel alanlardır. Parasal değer gönderildiğinde para birimi de belirtilmelidir. value, ürünlerin fiyat ve miktar toplamını temsil eder; vergi ve kargo ayrı alanlardır. İndirimli üründe gerçek indirimli birim fiyat kullanılmalıdır.
Veri sözlüğünde alanın yalnızca adını değil kaynağını da yazın. Sipariş kimliği hangi sistemden geliyor? Varyant ayrı bir ürün koduyla mı izleniyor? İndirim tutarı ürünlere nasıl dağıtılıyor? Para birimi mağazanın görüntüleme tercihi mi, gerçekleşen siparişin birimi mi? Bu sorular yanıtlanmadan rapordaki toplamın doğru olduğu varsayılamaz.
Kurgusal bir kontrol örneğinde iki ürünün indirimli birim fiyatı 200 TL, miktarı ikişer adet olsun. Ürün toplamı 800 TL'dir. Ayrı hesaplanan vergi ve kargo varsa kendi alanlarında tutulur; aynı tutar ürün toplamına tekrar eklenmez. Gerçek uygulamada mağazanın vergi dahil fiyat yapısını doğru alanlara dönüştürmek gerekir.
Sipariş oluşturmak ile ödeme almak aynı an mı?
Kart, havale ve kapıda ödeme gibi yöntemler farklı iş akışlarına sahip olabilir. İşletmenin satın alma olayını hangi doğrulanmış sipariş durumunda göndereceğini belirleyin ve raporda bunu açıkça tanımlayın. Henüz kabul edilmemiş ödeme denemesini başarılı alışveriş saymayın. Tahsil edilmiş gelir raporuyla kabul edilmiş sipariş raporunu karıştırmayın.
Aynı siparişe her seferinde yeni kimlik üretmeyin
Sipariş tamamlandı ekranının yenilenmesi veya ödeme sağlayıcısından tekrar dönüş, aynı satın alma olayını yeniden tetikleyebilir. Uygulama aynı gerçek sipariş için tutarlı kimlik kullanmalı ve tekrar gönderimi kontrol etmelidir. Google'ın referansı transaction_id alanının satın alma tekrarlarını önlemeye yardımcı olduğunu belirtir; bunu bütün veri yollarını otomatik düzelten bir güvence gibi görmeyin.
Hazır e-ticaret eklentisi, tema içindeki etiket ve GTM aynı anda satın alma gönderiyor olabilir. Kurulum envanterinde hangi bileşenin hangi olayı gönderdiğini yazın. Tarayıcı ve sunucu tarafı akışları birlikte kullanılıyorsa aynı işlemin nasıl yönetildiğini ayrıca test edin. Her gönderimde rastgele yeni kimlik üretmek tekrarları ayırt etmeyi zorlaştırır.
Bir sipariş kimliği örneği üzerinden zaman çizelgesi çıkarın: ödeme sonucu, mağazanın sipariş kaydı, olayın tetiklenmesi ve raporda görünmesi. Hatanın hangi katmanda oluştuğunu bu şekilde daraltabilirsiniz. Müşterinin adını veya e-posta adresini sipariş kimliği yerine kullanmayın.
İadeyi sipariş kaydıyla ilişkilendirin
İade takibinde orijinal siparişin transaction_id değerini kullanın. Ürün bazlı analiz için iade edilen ürünleri ve miktarları da gönderin. Kısmi iadede siparişin tamamını iade edilmiş gibi işaretlemek geliri yanlış düşürür. İade talebi açılması ile iadenin gerçekten işlenmesi farklı durumlardır; olayın hangi koşulda gönderileceğini belirleyin.
İade çoğu zaman müşteri yeniden siteyi ziyaret etmeden gerçekleşir. Bu nedenle yalnızca tarayıcıdaki teşekkür sayfasına bağlı kurulum yeterli olmayabilir. Kullanılan platformun iade entegrasyonunu inceleyin; gerekiyorsa sunucu tarafı akışı geliştirme ekibiyle planlayın. Bu akışta erişim anahtarları tarayıcıya veya sayfa kaynak koduna konulmamalıdır.
Aynı iade bildiriminin tekrar işlenmesini ve bir sipariş için farklı tarihlerde yapılan kısmi iadeleri ayrı test edin. İade gönderildiğini görmek kadar doğru sipariş ve tutarla işlendiğini doğrulamak da önemlidir.
Yayın öncesi test matrisi
Testleri ayrı test mülkünde veya açıkça ayrılmış geliştirme düzeninde yürütün. Gerçek ödeme gerektirmeyen sağlayıcı test araçlarını tercih edin. GA4 DebugView olay ve parametre akışını incelemeye yardımcı olur; nihai rapor kontrolünün yerini tek başına almaz.
| Senaryo | Kontrol edilecek sonuç |
|---|---|
| Tek ürün ve tek adet | Ürün kimliği, tutar ve para birimi doğru |
| Birden fazla ürün ve adet | Ürün toplamı fiyat × miktar hesabıyla tutarlı |
| İndirimli sipariş | İndirim öncesi tutar yanlışlıkla gelir olarak gönderilmiyor |
| Ödeme reddi veya yarım kalan doğrulama | Başarılı satın alma oluşmuyor |
| Onay ekranını yenileme | Aynı sipariş yeniden gelir üretmiyor |
| Tam iade | Doğru sipariş ve işlenmiş iade tutarı |
| Kısmi ve tekrarlı iade bildirimi | Yalnız doğru ürün/miktar işleniyor; tekrar önleniyor |
| İzin tercihi değişikliği | Seçilen izin düzeniyle uyumlu ölçüm davranışı |
Sonra belirli bir sipariş örneklemini mağaza kayıtlarıyla karşılaştırın. Tarih aralığı, saat dilimi, para birimi, indirim, vergi, kargo ve iade yaklaşımı aynı olmalıdır. İzin tercihleri, reklam engelleyiciler, veri işleme süresi ve ilişkilendirme nedeniyle toplamlar birebir eşit olmayabilir. Açıklanamayan büyük farkları “analitik her zaman farklıdır” diyerek geçiştirmeyin.
Sık sorulan sorular
Satın alma sayısı doğruysa gelir de doğru mudur?
Hayır. Olay sayısı doğru olsa bile para birimi, adet, indirim veya vergi alanları hatalı olabilir. Sipariş adedi ve parasal tutar ayrı kontrol edilmelidir.
GA4 muhasebe kaydının yerine geçer mi?
Hayır. Analitik, davranış ve kanal değerlendirmesi için kullanılır. İşletmenin sipariş ve muhasebe kayıtlarıyla tanımları eşleştirilerek yorumlanmalıdır. Reklam kârlılığı rehberi, doğrulanan veriyi maliyetlerle birlikte ele alır.
Ölçüm tamamlandığında sepet terk etme kontrol listesi üzerinden alışveriş akışını inceleyebilirsiniz. Ocakcolor'un raporlama ve analiz hizmeti için e-ticaret altyapınızı, mevcut etiketlerinizi ve örnek sipariş senaryolarınızı paylaşarak doğrulama kapsamını netleştirebilirsiniz.