Bir e-ticaret sitesinin Google Analytics raporlarında en yüksek ciroyu bir banka sanal pos sayfası, bir cüzdan servisi veya başka bir 3. parti ödeme kanalı getiriyorsa, kaynak / araç raporu gerçeği yansıtmıyor demektir. Bu cironun gerçek sahibi organik arama, ücretli reklam, e-posta ya da sosyal medya olabilir. Kaynağı yanlış okumak bütçe dağılımını, kanal önceliklerini ve performans değerlendirmelerini yanlış yönlendirir. Bu rehberde sorunun neden oluştuğunu, geçmiş verideki ciroyu Model Karşılaştırma Aracı ile gerçek trafik kanallarına nasıl dağıtabileceğinizi ve sorunu kalıcı olarak nasıl çözeceğinizi adım adım ele alıyoruz.

Ciro Neden Ödeme Kanalına Yazılır?

Birçok e-ticaret altyapısında kullanıcı, ödeme adımında siteden ayrılıp güvenli ödeme sayfasına yönlendirilir. İşlem tamamlandığında ise sitedeki “Sipariş Tamamlandı” sayfasına geri döner. Google Analytics açısından bu akış, standart çalışma mantığına uygun biçimde yorumlanır ve ölçümde çarpıklığa yol açar.

Oturumun Bölünmesi Mekanizması

Kullanıcı reklamdan ya da arama sonucundan siteye geldiğinde ilk oturum (session) başlar. Ödeme sayfasına geçtiğinde site dışına çıkar. Geri döndüğünde Analytics, trafiğin bir yönlendirme (referral) üzerinden geldiğini görür ve yeni bir oturum açar. Bu ikinci oturumun kaynağı ödeme sağlayıcısının alan adıdır. Satın alma dönüşümü ve ciro da bu yeni oturuma yazılır. Sonuçta kaynak / araç raporunda ödeme sağlayıcısı, gerçekte hiçbir pazarlama faaliyeti yürütmediği halde en çok ciro getiren “kanal” gibi görünür.

Bu davranış bir hata değil, ölçüm kurgusunun doğal sonucudur. Sorun, kurgunun ödeme akışına göre uyarlanmamış olmasıdır. Dolayısıyla çözüm de Analytics’in mantığını bilerek yapılandırma ve geçmiş veriyi ayrıca yorumlama üzerine kurulur.

Yönlendirme Hariç Tutma Yönteminin Sınırı

Standart çözüm, ödeme sağlayıcısının alan adını hariç tutulan yönlendirmeler (referral exclusion) listesine eklemektir. Bu ayar yapıldığında ödeme sağlayıcısına gidip dönen kullanıcı için yeni oturum açılmaz ve ciro, kullanıcıyı siteye ilk getiren kanala atfedilir. Ancak ayar yalnızca yapıldığı andan sonraki veriyi etkiler. Geçmişe dönük işlenmiş verilerde ciro ödeme kanalında kalmaya devam eder.

Pratikte bu tablo sık yaşanır. Marka yeni bir ödeme altyapısına geçer, ölçüm ekibine haber vermez ve yapılandırma eksik kalır. Sorun haftalar sonra fark edildiğinde, o döneme ait kampanya raporlarının hepsi çarpık veriye dayanır. Tam bu noktada geçmiş dönemi düzeltmeden okumanın bir yolu gerekir.

Model Karşılaştırma Aracı Nedir ve Neden İşe Yarar?

Google Analytics’in ilişkilendirme (attribution) bölümündeki Model Karşılaştırma Aracı, aynı dönüşüm ve ciro verisini farklı ilişkilendirme modelleriyle yan yana göstermenizi sağlar. Son tıklama, ilk tıklama, doğrusal ve konum tabanlı gibi hazır modellerin yanında kendi kurallarınızla özel bir model de oluşturabilirsiniz. Aracın değeri, ham veriyi değiştirmeden aynı satışları farklı bir mercekten göstermesidir.

Bizim amacımız, ödeme sağlayıcısını kredi dağıtımının dışında bırakan bir model kurmaktır. Ödeme kanalı etkileşim zincirinde “kredi almayan” bir nokta haline geldiğinde, ciro bir önceki gerçek temas noktasına, yani kullanıcıyı siteye getiren kanala kayar. Bu yaklaşım, geçmiş dönemi yeniden ölçmeden raporlamanın doğru okunmasını mümkün kılar.

Özel Model Oluşturma Adımları

Aşağıdaki akış, Universal Analytics arayüzündeki ilişkilendirme araçları üzerinden kurgulanır. Ekran adlarında küçük farklar olabilir; mantık değişmez.

  • Aracı açın. Dönüşümler bölümünden İlişkilendirme menüsüne, oradan Model Karşılaştırma Aracı’na girin ve e-ticaret ya da hedef dönüşüm verisini seçin.
  • Yeni özel model oluşturun. Model seçim alanından “Yeni özel model oluştur” seçeneğini kullanın ve modele “Ödeme kanalı hariç” gibi ayırt edici bir ad verin.
  • Başlangıç modelini seçin. Temel model olarak son etkileşim mantığına dayalı bir model belirleyin. Böylece yalnızca ödeme kanalına dair kuralı değiştirmiş olursunuz.
  • Özel kredi kuralı ekleyin. Kaynak alanı, ödeme sağlayıcınızın alan adıyla eşleşen temas noktalarına verilecek kredi çarpanını sıfıra ayarlayın. Alan adını tam ve doğru yazmak kritiktir; birden fazla sağlayıcı varsa her biri için ayrı kural tanımlayın.
  • Geriye bakış penceresi ve etkileşim ayarlarını pasif bırakın. Bu seçenekleri açık bırakmak, modelin sonucunu istemeden değiştirir ve karşılaştırmayı bozar.
  • Karşılaştırma modelini seçin. Özel modelinizi, varsayılan olarak kullanılan doğrudan olmayan son tıklama modeliyle yan yana getirin ve tarih aralığını sorunun yaşandığı döneme ayarlayın.

Bu adımlar tamamlandığında rapor, aynı siparişleri iki farklı ilişkilendirme kurgusuyla gösterir. Ödeme sağlayıcısının payı küçülürken diğer kanalların cirosu artıyorsa model doğru çalışıyor demektir.

Sonuçları Doğru Okumak

Karşılaştırma ekranında her kanal için ciro, dönüşüm sayısı ve iki modele ait fark yüzdesi görünür. Okuma sırasında üç noktaya dikkat edin. Birincisi, ödeme kanalındaki ciro neredeyse sıfıra inmelidir. İkincisi, kaybolan cironun hangi kanallara dağıldığına bakılmalıdır. Üçüncüsü, toplam ciro iki modelde de aynı kalmalıdır. Toplam değişiyorsa kural yanlış kurgulanmıştır.

İlişkilendirme yaklaşımı Ödeme kanalının durumu Ciro dağılımı Kullanım amacı
Son etkileşim Son temas noktası olduğu için tüm krediyi alır Ödeme sağlayıcısında yığılır Sorunun boyutunu görmek
Doğrudan olmayan son tıklama Yönlendirme sayıldığı için yine kredi alır Yalnızca doğrudan trafik dışarıda kalır, ödeme kanalı payı sürer Standart raporlama referansı
Özel model (ödeme kanalı hariç) Kredi çarpanı sıfırdır Ciro gerçek trafik kanallarına kayar Geçmiş dönemi düzeltilmiş okumak

Özel modelden elde ettiğiniz rakamlar analiz ve karar amaçlıdır. Bu veri Analytics’in ham kaynak kayıtlarını değiştirmez; standart raporlardaki rakamlar olduğu gibi kalır. Geçmiş dönem sunumlarında hangi modelin kullanıldığını açıkça belirtmeniz, rakamların ileride tartışma konusu olmasını önler.

Düzeltilmiş Veriyi Karar Sürecine Taşımak

Doğru ciro dağılımı, kanal bazlı yatırım kararlarını doğrudan etkiler. Ödeme kanalına yazılan cironun büyük kısmı aslında ücretli aramadan geliyorsa, Performance Max kampanyası nasıl optimize edilir sorusunun cevabı, teklif ve varlık grubu ayarlarının gerçek getiriye göre yeniden değerlendirilmesini gerektirir. Aynı şekilde organik kanalın payı düşük göründüğü için kısıtlanan bir içerik bütçesi, düzeltilmiş veriyle yeniden ele alınabilir.

Satış hunisi analizinde de benzer bir etki vardır. Dönüşüm oranı optimizasyonu (CRO) çalışmaları kanal bazında dönüşüm oranlarını karşılaştırır. Ödeme kanalı yüzünden oturum sayıları ve dönüşümler bölündüğünde, gerçek kanal performansı olduğundan düşük ya da yüksek görünebilir. A/B testi sonuçlarını yorumlarken de aynı dikkat gerekir; test grubundaki ciro atfı bozuksa kazanan varyasyon yanlış seçilebilir.

Organik performansı ölçenler için de uyarı geçerlidir. Görünürlük ve sıralama metrikleriyle ciro arasında bağ kurarken, atıf hatalı olduğunda bağlantı zayıf görünür. SEO visibility skoru neden tek başına bir KPI olamaz sorusunu, ciro atfının doğruluğu perspektifinden de düşünmek gerekir. Metrikler, ancak doğru ilişkilendirilmiş gelirle birlikte yorumlandığında karar verdirici hale gelir.

Sık Yapılan Hatalar

Özel model kurulumunda en yaygın hata, kaynak alanını yanlış ya da eksik yazmaktır. Ödeme sağlayıcısının alt alan adları farklı olabilir. Bu durumda kuralı düzenli ifade ile genişletmek ya da her alt alan adı için ayrı kural eklemek gerekir. İkinci hata, geriye bakış penceresi ve etkileşim bazlı kredi ayarlarını açık bırakmaktır; bu ayarlar modelin çıktısını sessizce değiştirir ve iki model arasındaki farkı yorumlanamaz hale getirir.

Üçüncü hata, modeli kalıcı çözüm sanmaktır. Model karşılaştırma yalnızca analiz katmanıdır. Panolarda, otomatik raporlarda ve veri ambarına aktarılan tablolarda ödeme kanalı payı hâlâ görünür. Bu nedenle özel modeli geçici bir düzeltme, yönlendirme hariç tutmayı ise asıl çözüm olarak ele almak gerekir. Dördüncü hata ise düzeltilmiş veriyi ham veriyle karıştırmaktır. Raporlarda her rakamın hangi modele ait olduğunu etiketlemek, ekipler arası tutarlılığı korur.

Kalıcı Çözüm İçin Ölçüm Altyapısı Kontrol Listesi

Sorunun tekrarlanmaması için ödeme altyapısı değiştiğinde izlenecek bir kontrol akışı oluşturmak yararlıdır. Her yeni sağlayıcıda alan adı hariç tutma listesine eklenmeli, test siparişiyle oturumun bölünmediği doğrulanmalı ve ilk günlerde kaynak / araç raporu izlenmelidir. Siparişin ardından kaynağın ödeme sağlayıcısı olarak görünmesi, ayarın eksik olduğunun en net işaretidir.

Tekil bir gösterge de erken uyarı sağlar. Ödeme sağlayıcısının kaynak olarak payı birdenbire arttığında, doğrudan trafiğin ve organik dönüşümlerin payı aynı anda düşüyorsa atıf kayması yaşanıyordur. Bu iki hareketi birlikte izlemek, sorunu tatil dönemleri gibi kritik zamanlarda bile hızla fark etmenizi sağlar. Ayrıca ölçüm kurgusunu zero-click search gibi tıklamasız etkileşimlerin de arttığı bir ortamda sürekli doğrulamak, kanal katkısını doğru değerlendirmek için gereklidir.

Google Analytics 4 Tarafında Durum

Universal Analytics’in yerini alan Google Analytics 4’te de aynı sorunla karşılaşılabilir. Burada çözüm, veri akışı ayarları içindeki istenmeyen yönlendirmeler (unwanted referrals) listesine ödeme sağlayıcısının alan adını eklemektir. Bu liste, UA’daki hariç tutma ayarının karşılığıdır ve yalnızca ileriye dönük veriyi etkiler. GA4’ün ilişkilendirme raporları ise veri odaklı ve hazır modellerle çalışır; UA’daki kadar serbest kural tanımlama esnekliği sunmaz. Bu yüzden GA4 kullanan ekiplerde geçmiş verinin düzeltilmesi için ham veriyi dışa aktarıp sorgulama temelli yaklaşım gerekebilir.

Ölçüm sürecini yapay zekâ kaynaklı trafiğin de içinde olduğu daha geniş bir bağlamda ele alıyorsanız, GEO performansı nasıl ölçülür rehberindeki metrik disiplini, doğru atıf kurgusunun neden temel bir gereksinim olduğunu da gösterir. Kanal sayısı arttıkça, gelirin gerçek kaynağına yazılması daha da kritik hale gelir.

Doğru Atıf, Güvenilir Raporlamanın Temelidir

Ödeme kanalına yazılan ciro, Analytics’in kusuru değil, ölçüm kurgusunun ödeme akışına uyarlanmamasının sonucudur. Hariç tutulan yönlendirmeler ayarı gelecekteki veriyi düzeltir; Model Karşılaştırma Aracı ile oluşturulan özel model ise geçmiş dönemi gerçek trafik kanallarına göre yeniden okumanıza imkân tanır. İki yöntem birbirinin alternatifi değil, tamamlayıcısıdır.

Kurumsal raporlamada en sağlam yaklaşım, ölçüm altyapısında yapılan her değişikliği belgelemek, ödeme akışlarını düzenli aralıklarla test etmek ve geçmiş dönem analizlerinde kullanılan modeli açıkça belirtmektir. Gelirin doğru kanala atfedilmesi, bütçe planlamasından içerik yatırımına kadar tüm pazarlama kararlarının güvenilirliğini belirler.