GA4 e-ticaret kurulumu yalnızca birkaç etkinlik eklemekten ibaret değildir. Sağlıklı bir ölçüm yapısı; kullanıcının ürünle etkileşiminden satın alma ve iade süreçlerine kadar her adımın hangi koşulda, hangi veriyle ve kaç kez gönderileceğini tanımlar. Bu nedenle asıl soru “Etkinlik gönderiliyor mu?” değil, “Gönderilen veri iş kararları almak için güvenilir mi?” olmalıdır.
Bu rehberde önce ölçüm planını ve veri sözleşmesini oluşturacak, ardından ürün ve işlem seviyesindeki parametreleri ayıracağız. Son bölümde GTM Preview, DebugView ve işlenmiş GA4 raporlarıyla doğrulama yaparak purchase ve gelir farklarını nasıl inceleyebileceğinizi ele alacağız.
GA4 e-ticaret hunisi nedir?
GA4 e-ticaret hunisi; ürün listeleme ve ürün detay görüntüleme, ürün seçimi, sepete ekleme, sepet görüntüleme, ödeme başlangıcı, kargo ve ödeme bilgisi, satın alma ve iade gibi gerçek kullanıcı aksiyonlarına karşılık gelen standart etkinliklerle kurulabilir.
Standart önerilen e-ticaret etkinlik adlarını kullanmak, GA4’ün önceden hazırlanmış e-ticaret raporlarının doğru verilerle doldurulmasına yardımcı olur.
Pratikte bu yapı, müşterinin hangi noktada kaybedildiğini görmek için bir akış oluşturur. Ürün detayından sepete geçiş düşükse ürün sunumu veya etkileşim ölçümü; ödeme başlangıcından purchase’a geçiş düşükse ödeme akışı, yönlendirme ya da satın alma etiketinin dönüş sayfasında çalışmaması incelenebilir. Bu yorumların anlamlı olabilmesi için her adımın tetiklenme koşulu önceden tanımlanmalıdır.
Kuruluma başlamadan önce tracking plan hazırlayın
İlk adım, bir tracking plan hazırlamaktır. Bu planda her huni adımı için etkinlik adı, tetiklenme koşulu, etkinlik seviyesindeki parametreler, items alanları, verinin kaynağı, beklenen tetiklenme sayısı ve test sonucu yer almalıdır. Böylece ölçüm kurulumu geliştirici, analist ve pazarlama ekipleri arasında ortak bir veri sözleşmesine dönüşür.
Örneğin ürün detay sayfasının gerçekten görüntülenmesi view_item için tetikleyici olabilir. Sepete ekleme onayının başarıyla gerçekleşmesi add_to_cart için kabul koşulu olarak yazılabilir. Purchase ise yalnızca başarılı siparişin oluştuğu ve sipariş kimliğinin kullanılabildiği durumda gönderilmelidir. Bu ayrım, buton tıklaması ile gerçekleşmiş iş sonucu arasındaki farkı görünür kılar.
Tracking plan yalnızca teknik bir doküman değil, kabul testi listesidir. Her etkinlik için “hangi kullanıcı aksiyonunda oluşmalı?”, “hangi veri zorunlu?”, “kaç kez oluşması bekleniyor?” ve “hangi sistemle karşılaştırılacak?” sorularına yanıt verilmelidir.
Ürün ve işlem seviyesindeki verileri ayırın
Ürün bilgileri items dizisinde; işlem veya kullanıcı aksiyonunu açıklayan value, currency, coupon, shipping ve tax gibi bilgiler ise etkinlik seviyesinde gönderilmelidir.
Bu ayrımın temel amacı, ürünün özellikleriyle işlemin toplamını birbirine karıştırmamaktır. item_id, item_name, price ve quantity gibi alanlar ürün satırını; value, currency, shipping ve tax gibi alanlar ise işlemin genel bağlamını açıklar. Bir ürünün fiyatını işlem toplamı alanına yazmak veya toplam indirim bilgisini ürün alanı gibi modellemek raporların yorumlanmasını zorlaştırabilir.
items dizisi bir etkinlikte birden fazla ürün taşıyabilir; dokümantasyondaki sınıra göre tek etkinlikte 200 ürüne kadar ürün gönderilebilir.
Bu nedenle sepet ve purchase kontrollerinde yalnızca etkinliğin oluştuğunu görmek yeterli değildir. Ürün sayısı, ürün kimlikleri, birim fiyatlar ve miktarlar sipariş ya da sepet ekranındaki gerçek içerikle karşılaştırılmalıdır.
value, currency ve gelir hesaplamasını doğrulayın
value gönderiliyorsa currency parametresi etkinlik seviyesinde açıkça belirtilmelidir.
purchase içindeki value, ürün fiyatı ve miktarların toplamını temsil eder; tax, shipping, coupon ve ürün seviyesindeki indirimler ayrıca gönderilebilir.
GA4 item revenue değerini items dizisindeki price ve quantity bilgilerine göre türetir; bu nedenle birim fiyat ve gerçek ürün adedi ayrıca doğrulanmalıdır.
Gelir kontrolünde tek bir toplam rakama bakmak yerine üç katmanlı bir mutabakat yapılmalıdır: sipariş sistemindeki toplam, purchase içindeki value ve items dizisindeki price ile quantity kombinasyonu. Vergi, kargo, indirim, iade ve iptal kurallarının hangi katmanda temsil edildiği ayrıca belgelenmelidir.
GA4 geliri ile ödeme sistemi toplamının birebir eşleşmemesi tek başına ölçüm hatıtı kanıtlamaz; iş kuralları ve veri işleme gecikmeleri fark yaratabilir.
purchase etkinliğini ve transaction_id kullanımını güvenceye alın
purchase etkinliğinde transaction_id, işlemi tanımlamak için kullanılmalı; aynı işlem kimliğinin tekrar gönderilmesi mükerrer satın alma ve gelir sorunlarına yol açabilir.
purchase etkinliği, eski ecommerce_purchase etkinliğinin yerine geçer; iki adlandırmanın birlikte kullanılması raporlama ve ölçüm karmaşası oluşturabilir.
Purchase için temel kabul testi, başarılı siparişin onay sayfasında tek bir işlem kimliğiyle ve doğru sipariş içeriğiyle ölçülmesidir. Sayfa yenileme, geri dönme veya aynı onay sayfasının tekrar açılması gibi senaryolarda aynı transaction_id’nin yeniden gönderilmediği kontrol edilmelidir.
Purchase etkinliğini yalnızca ödeme butonuna bağlamak yerine, mümkün olduğunda siparişin gerçekten tamamlandığını gösteren güvenilir bir durum üzerinden tasarlamak daha sağlam bir ölçüm yaklaşımıdır. Bu yaklaşım, başarısız ödeme ile tamamlanmış siparişi birbirinden ayırmaya yardımcı olur.
İade ölçümünü purchase kadar ciddiye alın
refund etkinliği transaction_id ile ilişkilendirilmeli; ürün seviyesinde iade analizi için item_id ve quantity gibi ürün bilgileri de gönderilmelidir.
İade verisi, yalnızca satın alma sayısını değil, ölçülen gelirin iş açısından ne kadar sürdürülebilir olduğunu anlamak için de önemlidir. Tam ve kısmi iadeler farklı senaryolarsa, tracking plan içinde hangi işlem kimliği ve hangi ürün miktarıyla temsil edilecekleri açıkça tanımlanmalıdır.
Gelir mutabakatında iade ve iptal kurallarını dışarıda bırakmak, GA4 ile sipariş sistemi arasındaki farkı yanlış yorumlamaya neden olabilir. Bu nedenle rapor karşılaştırmalarında satın alma, iade ve iptal dönemleri aynı kapsamla ele alınmalıdır.
Data layer ve GTM bağlantısını kontrol edin
Data layer, olayları ve değişkenleri GTM ile etiketlere taşımak için kullanılan yapılandırılmış veri katmanıdır; her sayfa yüklemesinde ve mümkünse GTM container kodundan önce hazır olmalıdır.
Data layer yapısında tutarlı anahtar adları ve veri tipleri kullanılmalıdır. Bir sayfada event, başka bir sayfada farklı bir olay anahtarı kullanılması; items dizisinin yanlış isimlendirilmesi; veri katmanının üzerine yazılması veya büyük-küçük harf farkları, etiketin beklediği değeri okuyamamasına yol açabilir.
GTM Preview ve Debug modu, etiketlerin hangi sırayla tetiklendiğini, tetikleyicileri, değişken değerlerini ve gönderilen parametreleri test etmeye yardımcı olur.
GTM Preview incelemesinde yalnızca etiketin tetiklenip tetiklenmediğine bakmayın. Önce dataLayer olayının doğru sırada oluştuğunu, sonra değişkenlerin beklenen değerleri taşıdığını ve son olarak GA4 etiketinin doğru değişkenleri okuduğunu kontrol edin.
DebugView ile gerçek zamanlı doğrulama yapın
DebugView, etkinlikleri ve kullanıcı özelliklerini gerçek zamanlı izlemek için kullanılabilir; çalışması için debug_mode sinyali veya desteklenen bir hata ayıklama yöntemi gerekir.
DebugView’da bir etkinliğin görünmesi, tüm parametrelerin işlenmiş raporlarda doğru kullanılacağını tek başına kanıtlamaz; value, currency, transaction_id ve items içeriği ayrıca incelenmelidir.
Bu nedenle gerçek zamanlı doğrulama iki ayrı soruya bölünmelidir: Etkinlik GA4’e ulaştı mı ve etkinlik doğru içerikle mi ulaştı? Birinci sorunun yanıtı olumlu olsa bile ikinci soru için parametre değerleri, ürün dizisi ve işlem kimliği tek tek incelenmelidir.
Testi temiz bir tarayıcı oturumunda ürün detayından purchase’a kadar sırayla tamamlamak, akışın hangi adımında veri kaybı oluştuğunu izlemeyi kolaylaştırır. Her adımda ekran davranışı, dataLayer olayı, GTM etiketi ve GA4 parametreleri birlikte kontrol edilmelidir.
Çok adımlı ödeme akışlarını ve yönlendirmeleri test edin
Ödeme akışında kargo ve ödeme bilgileri, yalnızca kullanıcının ilgili bilgiyi gerçekten sağladığı aşamada ölçülmelidir. Kullanıcı henüz seçim yapmadan tahmini ya da varsayılan değerleri göndermek, huninin gerçek davranışını bozabilir.
Harici ödeme sağlayıcısı veya farklı domain kullanılıyorsa purchase’ın onay sayfasına dönüşte korunup korunmadığı özel olarak test edilmelidir. Yönlendirme, consent durumu, etiketin sayfada bulunması ve dönüş URL’si birlikte incelenmelidir.
Harici ödeme sağlayıcıları, cross-domain akışlar, consent mode, sunucu tarafı etiketleme ve platforma özgü dataLayer yapıları farklı teknik çözümler gerektirebilir; genel GA4 dokümantasyonu tüm altyapı varyasyonlarını kapsamayabilir.
Gerçek zamanlı veriyi işlenmiş raporlarla karıştırmayın
GA4 raporları ve explorations e-ticaret verisini hemen göstermeyebilir; raporların dolması 24 saate, bazı genel veri işleme süreçleri ise 24–48 saate kadar sürebilir.
Bu nedenle doğrulama sırası önemlidir: önce GTM Preview, Tag Assistant veya DebugView ile gönderimin gerçekleştiğini kontrol edin; ardından veri işleme gecikmesini dikkate alarak GA4 raporlarını sipariş sistemiyle karşılaştırın.
Gerçek zamanlı araçlarda etkinliği görememek teknik soruna işaret edebilir; ancak etkinlik gerçek zamanlı araçta göründüğü halde raporda hemen görünmemesi de tek başına implementasyon hatası anlamına gelmez. Test sonucu, kullanılan aracın amacı ve beklenen işleme süresiyle birlikte değerlendirilmelidir.
Google Analytics ve Google Tag Manager arayüzlerindeki menü adları ve ekran yolları zaman içinde değişebilir; içerikte kalıcı olması için kavramlar ve test mantığı öne çıkarılmalıdır.
GA4 ile sipariş sistemi arasındaki farkları analiz edin
GA4 ve sipariş sistemi arasında fark gördüğünüzde doğrudan “ölçüm bozuk” sonucuna gitmeyin. Önce purchase etkinliğinin kaç kez gönderildiğini, transaction_id değerlerinin tekilliğini, value ve currency alanlarını, items içeriğini ve dönüş sayfasındaki etiket varlığını kontrol edin.
Teknik kontrollerden sonra vergi, kargo, indirim, iade, iptal, saat dilimi, consent ve veri işleme farklarını ayrı başlıklar halinde inceleyin. Farkın kaynağını bu katmanlara ayırmak, tek bir toplam sayı üzerinden yapılan belirsiz yorumlardan daha sağlıklı bir teşhis sağlar.
Karşılaştırmayı aynı tarih aralığı, aynı sipariş kapsamı ve mümkün olduğunca aynı iş kurallarıyla yapmak gerekir. Ayrıca beklenen etkinlik sayısı ile gerçek etkinlik sayısını tracking plan üzerinden düzenli olarak karşılaştırmak, veri kaybını rapor farkı büyümeden fark etmeye yardımcı olur.
Uygulanabilir son kontrol listesi
Kurulum tamamlandıktan sonra şu sırayla ilerleyin: tracking planı ve veri sözleşmesini gözden geçirin; ürün ve işlem seviyesindeki alanları ayırın; view_item ve add_to_cart içindeki items dizisini kontrol edin; purchase için transaction_id, value ve currency alanlarını birlikte doğrulayın; aynı işlem kimliğinin tekrarlanmadığını test edin; refund senaryolarını inceleyin; ardından gerçek zamanlı araçlar ve işlenmiş raporlar arasında karşılaştırma yapın.
Bu kontrol listesi, GA4 e-ticaret hunisini yalnızca rapor ekranında görünen bir dizi etkinlik olmaktan çıkarır. Her adımın tetiklenme koşulu, veri içeriği ve kabul testi tanımlandığında ölçüm yapısı pazarlama kararlarını destekleyecek denetlenebilir bir sisteme dönüşür.
Promogo açısından bu yaklaşım; ölçüm planı hizmetinde tracking plan şablonlarıyla, reklam optimizasyonunda güvenilir purchase ve gelir kontrolleriyle, dönüşüm analizinde ise beklenen ve gerçek etkinlik sayılarının karşılaştırılmasıyla ilişkilendirilebilir. Değer, yalnızca kurulumu yapmakta değil, kurulumun gerçekten çalıştığını kanıtlamaktadır.
Kaynaklar
- https://developers.google.com/analytics/devguides/collection/ga4/ecommerce
- https://support.google.com/analytics/answer/12924131?rd=1
- https://developers.google.com/analytics/devguides/collection/ga4/events
- https://support.google.com/analytics/answer/7201382
- https://developers.google.com/analytics/devguides/collection/ga4/set-up-ecommerce
- https://support.google.com/analytics/answer/9267735
- https://developers.google.com/certification/mws-study-guide.pdf
- https://support.google.com/tagmanager/answer/6107056
- https://developers.google.com/identity/casestudies/ticketmaster-smartlock-casestudy.pdf
- https://developers.google.com/static/business-communications/rcs-business-messaging/files/hbr-pulse-survey.pdf
- https://developers.google.com/identity/casestudies/aliexpress-smartlock-casestudy.pdf
- https://support.google.com/analytics/answer/11198161
- https://developers.google.com/media/pdf/2016-HTML5-Video-Whitepaper.pdf
- https://support.google.com/analytics/answer/12200568
- https://developers.google.com/tag-platform/tag-manager/datalayer
- https://support.google.com/tagmanager/answer/10039345
- https://support.google.com/tagmanager/answer/13355721
- https://support.google.com/tagmanager/answer/14842769
- https://support.google.com/tagmanager/answer/15212893
- https://support.google.com/tagmanager/answer/17165450
- https://support.google.com/tagmanager/answer/6311518
