Ödeme sistemleri dönüşüm kanallarını nasıl etkiler?

Pazarlama müdürü raporu açıyor, direct trafikten gelen ciro ayın en büyük kalemi. Kimse kampanya yapmadı, kimse e-posta göndermedi, ama direct patlamış. İlk refleks memnuniyet oluyor, ikinci refleks şüphe. Şüphe haklı.

E-ticarette conversion attribution’ını bozan sorunların başında ödeme yönlendirmeleri geliyor. Müşteri kartını girmek için bankanın sayfasına gidiyor, işlemi tamamlayıp geri dönüyor, ve GA4 bu dönüşü yeni bir ziyaret sanıyor. Satışı getiren kanal hakkını kaybediyor, satış direct’e ya da bankanın domainine yazılıyor.

Sorun raporlarda değil, işlem verisinde

Bu kirliliğin en can sıkıcı tarafı, trafik raporlarında görünmemesi. Genel direct oranınız normal seyrediyor olabilir. Ama sadece purchase event’i içeren oturumlara baktığınızda direct payı iki katına çıkıyorsa, cevap orada.

Attribution sorunları satın alma anına yakın noktalarda yoğunlaşır, çünkü o noktada kullanıcı siteden çıkıp geri dönüyor. Ana sayfada gezinen kullanıcı hiçbir yere gitmiyor, oturumu bölünmüyor.

Türkiye’de neden daha sık

Global örneklerde ödeme genelde tek bir sağlayıcı üzerinden akar. Bizde akış neredeyse her zaman üçüncü bir alan adına uğrar: sanal POS sağlayıcısı, ödeme kolaylaştırıcı, ve müşterinin kartını hangi banka çıkardıysa o bankanın 3DS sayfası.

Tek bir sitede ödeme yolunda dört beş farklı domain görmek olağan. Yani “iki tane geçit ekledim, hallettim” diye kapanan bir liste değil bu. Müşteri portföyünüzdeki kart çeşitliliği kadar uzuyor.

Bir de tek tıkla ödeme çözümleri ve cüzdan uygulamaları var. Bazıları tarayıcı dışına çıkıp geri dönüyor, bazıları farklı bir domainde iframe içinde çalışıyor. Davranışları sağlayıcıya göre değişiyor, o yüzden varsaymak yerine her sağlayıcıyı kendi akışında test etmek gerekiyor.

İkinci ve daha sinsi yol: bazı yönlendirmeler referrer bilgisini tamamen siliyor. GA4 kaynağı bilemeyince trafiği direct kovasına atıyor. Bu yüzden “direct arttı” şikayeti çoğu zaman bir trafik hikayesi değil, ölçüm hikayesidir.

Teşhis: beş dakika

Arayüzde başlayın. Trafik edinimi raporunu açın, boyutu session source / medium yapın, purchase dönüşümlerinin hangi kaynaklara düştüğüne bakın. Banka domainleri, ödeme sağlayıcısı domainleri veya direct altında şüpheli yükseklikte bir satış payı varsa teşhis konmuştur.

Kesin ölçüm BigQuery’de. Purchase event’lerini oturum kaynağına göre gruplayın, sonra aynı kullanıcının bir önceki oturum kaynağıyla karşılaştırın. Önceki oturumu paid ya da organic olan, ama satın alma oturumu geçide yazılmış işlemlerin payı, kirliliğin ölçülmüş hali.

Karşılaştırmayı iki seviyede yapmak da faydalı: tüm oturumlarda kanal dağılımı, bir de yalnızca purchase içeren oturumlarda kanal dağılımı. Aradaki makas doğrudan sorunun büyüklüğünü verir. Sağlıklı bir kurulumda bu iki dağılım birbirine yakın seyreder.

İki pratik not. event_timestamp değerini yerel saat dilimine çevirmeden gün bazlı karşılaştırma yapmayın, yoksa gece yarısına yakın işlemler iki tarafta farklı günlere düşer. Ve en az 30 günlük pencereye bakın; bazı desenler günlük bazda cılız görünüp aylık toplamda ciddi tutar.

Çözüm

Ödeme yolundaki tüm alan adlarını çıkarın. Ödeme sağlayıcınız, 3DS doğrulama sayfaları, çalıştığınız bankaların domainleri, varsa cüzdan sağlayıcıları. Ödeme ekibinin verdiği liste genelde eksik olur; bir haftalık referral verisi tam listeyi çıkarır.

Bunları GA4’te “İstenmeyen yönlendirmeleri listele” alanına ekleyin. Yönetici, Veri akışları, Etiket ayarlarını yapılandır. Bundan sonra satın alma, müşterinin siteye geldiği oturumda kalır.

Referrer’ı silen yönlendirmeler için ayar yetmez. Orada çözüm akış tarafında: parametre taşıma, ya da sağlayıcı destekliyorsa ödeme adımını kendi alan adınızda veya iframe içinde tutmak.

Düzeldiğini nasıl anlarsınız

İki hafta sonra aynı ölçümü tekrarlayın. Beklenen tablo net: purchase oturumlarındaki direct ve geçit payı düşer, paid ve organic kaybettikleri satışları geri alır, toplam işlem sayısı değişmez.

Toplam işlem sayısı değiştiyse durun. Exclusion ayarı hiçbir event’i silmez, sadece hangi oturuma yazıldığını değiştirir. Sayı oynuyorsa başka bir sorununuz var.

En sağlam doğrulama işlem bazında olur: aynı transaction_id’lerin ayar öncesi ve sonrası hangi kaynağa yazıldığını karşılaştırın. Bu, tartışmayı bitiren tablodur.

Bir kez değil, sürekli

Şişmiş direct kozmetik bir sorun değil. Gerçekten dönüşüm getiren kanalların ölçülen ROAS’ını bastırır, bütçe yanlış yöne kayar, ve aynı event’ler üzerine kurulan LTV modelleri de hatayı devralır.

Üstelik tek seferlik bir temizlikle kapanmıyor. Her yeni ödeme sağlayıcısı, her yeni banka entegrasyonu listeyi eskitiyor. Düzenli attribution kontrolü, ölçüm kurulumunun rutin bakımının parçası olmalı. Ayda bir bakılan bir rapor, üç ay boyunca yanlış yere akan bütçeden çok daha ucuz.