Mağazanızda GA4 etiketi çalışıyor olabilir; bu, satışların doğru ölçüldüğü anlamına gelmez. Sepete ekleme olayı yanlış ürünü taşıyabilir, başarısız ödeme satın alma sayılabilir veya aynı sipariş iki kez kaydedilebilir. Kurulum teklifini ve teslimi, panelde görünen tek bir sayıya göre değil, gerçek alışveriş senaryolarının beklenen veriyi üretip üretmediğine göre değerlendirin.

Önce hangi kararlar için ölçüm gerektiğini yazın

Ürün ve kategori performansı mı, ödeme adımındaki kayıp mı, yoksa kampanyaların getirdiği siparişler mi öncelikli? Bu sorular, kurulacak olayların ve raporların kapsamını belirler. Teklifte mağaza altyapısı, ödeme akışı, mevcut etiketler, erişim sorumluları ve kullanılacak GA4 mülkü açıkça yer almalı.

Google, e-ticaret olaylarının kendiliğinden toplanmadığını; siteye veya etiket yöneticisine ayrıca eklenmesi gerektiğini açıklıyor. Bu nedenle “GA4 kurulu” ifadesi yerine hangi davranışın hangi olayla ve hangi veri alanlarıyla ölçüleceğini gösteren bir olay planı isteyin.

  • Hangi karar için hangi olay ve rapor kullanılacak?
  • Olayı mağaza, etiket yöneticisi veya özel koddan hangisi gönderecek?
  • Mevcut ölçümle yeni kurulumun çakışması nasıl kontrol edilecek?

Alışveriş yolundaki olayları örnek ürünle deneyin

En az bir ürün görüntüleme, sepete ekleme, ödeme başlangıcı ve tamamlanan alışveriş akışını izleyin. GA4 bu adımlar için sırasıyla view_item, add_to_cart, begin_checkout ve purchase gibi önerilen olay adları tanımlar. Her mağazada her adımın aynı şekilde çalışacağını varsaymayın; varyant seçimi, hızlı satın alma ve farklı ödeme yöntemleri olayın ne zaman tetiklendiğini değiştirebilir.

Olay adını görmek tek başına yeterli değildir. Ürün kimliği veya adı, miktar, fiyat ve varyant gibi bilgilerin ilgili items listesinde doğru ürünü anlattığını kontrol edin. Ürün düzeyindeki bilgiyle sipariş düzeyindeki toplamı karıştıran bir kurulum, raporları okumayı zorlaştırır.

Satın alma tutarı ve sipariş kimliği neyi göstermeli?

Teklifte purchase olayının hangi iş anında gönderileceği kararlaştırılmalı. Ödeme başarısız olduğunda veya sipariş henüz tamamlanmadığında satın alma kaydı oluşmamasını test edin. Başarılı işlemde GA4’e giden transaction_id, value, currency ve items alanlarını gerçek sipariş kaydıyla karşılaştırın. Google’ın tanımına göre value, ürünlerin indirim sonrası birim fiyatları ile miktarlarının toplamıdır; vergi ve kargo ayrı alanlarda gönderilir. Bu hesaplama kuralını teslim notuna yazın.

Google, web akışında aynı transaction_id ile gelen yinelenen purchase olaylarını tekilleştirdiğini, boş kimliğin ise ölçümü bozabileceğini belirtiyor. Her sipariş için benzersiz ve boş olmayan bir kimlik kullanın; teşekkür sayfasını yenileme veya geri dönme durumunu ayrıca deneyin. Bu kontrol, iki ayrı etiketin aynı satışı göndermesi gibi kurulum hatalarını arama ihtiyacını ortadan kaldırmaz.

Hangi ters senaryolar kabul testine girmeli?

Başarılı tek ürün siparişinin yanına farklı varyant, çok ürünlü sepet, kupon, başarısız ödeme ve tekrar açılan teşekkür sayfası senaryolarını koyun. İade ölçülecekse hangi iade durumunda refund olayının gönderileceğini ve orijinal transaction_id ile nasıl ilişkileneceğini de belirleyin. Google’ın e-ticaret rehberi iade için ayrı refund olayını ve ilişkili sipariş kimliğini tarif ediyor.

Her senaryoda “beklenen olay ve parametreler” ile “görülen olay ve parametreler” yan yana kaydedilmeli. Böylece bir düzeltmenin yalnızca kodda yapıldığını değil, müşteri yolculuğunda doğrulandığını görürsünüz.

DebugView ve raporları farklı amaçlarla okuyun

Google’ın DebugView aracı, test cihazından gelen olayları ve parametreleri gerçekleşirken incelemek için kullanılabilir; önce test cihazında hata ayıklama modunu açmanız gerekir. Olayın doğru isimle geldiğini, items içeriğini ve satın alma değerini burada kontrol edin. Kullanılan gizlilik ayarları bazı olayların DebugView’da görünmesini etkileyebilir; eksik görünen bir olayda önce etiketin ve izin ayarlarının durumunu inceleyin.

Sonra GA4 raporundaki sipariş ve gelir eğilimini mağazanın sipariş kayıtlarıyla karşılaştırın. İki sistemin anlık olarak birebir aynı görünmesini teslim ölçütü yapmayın: Google, rapor verisinin işlenme sırasında değişebildiğini ve bazı verilerin 24–48 saat içinde tamamlandığını belirtiyor. Farklar için kontrol yöntemi ve sorumlu kişi belirleyin.

Teslim paketinde ne bulunmalı?

Olay planı, tetiklenme koşulları, alan eşlemeleri, kullanılan hesap ve etiket erişimleri, test siparişleri, bulunan sorunlar ve düzeltme kayıtları birlikte teslim edilmeli. Reklam platformlarına aktarım da kapsamdaysa hangi olayın hangi hesapta kullanılacağını ayrı belirtin; yalnızca GA4 ekran görüntüsü bağlantının doğrulandığını göstermez.

Son kabul görüşmesinde ekibinizin yeni bir ürün veya ödeme yöntemi eklendiğinde ölçümü nasıl yeniden test edeceğini de konuşun. Bu kısa işletim notu, ilk kurulumdan sonraki değişikliklerde veri kalitesini korumaya yardımcı olur.

İlgili hizmetler

Konuyu projenize uygulayın

İlgili rehberler

Okumaya devam edin

Sık sorulanlar

Konuyla ilgili kısa cevaplar

GA4 etiketi kurulunca e-ticaret ölçümü de hazır olur mu?

Hayır. E-ticaret olayları ve ürün ile sipariş parametreleri ayrıca kurulup gerçek alışveriş akışında doğrulanmalıdır.

Test siparişini DebugView’da görmek teslim için yeterli mi?

Hayır. Olay parametrelerini sipariş kaydıyla karşılaştırın; tekrar, başarısız ödeme ve iade gibi kararlaştırılan senaryoları da test edin.

GA4 geliri mağaza paneliyle neden anında aynı görünmeyebilir?

Rapor işleme süresi ve ölçüm kapsamı fark yaratabilir. Önce aynı dönem, sipariş durumu, para birimi ve test siparişlerini karşılaştırın; kalan farkı kayıt düzeyinde inceleyin.