E‑Ticaret 2025: Veri Odaklı Yaklaşım

E‑Ticarette Veri Odaklı Karar Verme Rehberi​

Veri odaklı e‑ticaret, panoda çok sayıda grafik göstermek değildir. Önce hangi kararı vereceğinizi, o kararı temsil eden olay ve finansal kaydı, veri kalitesi koşullarını ve değişiklik sonrası kabul ölçütünü tanımlamaktır. Aksi hâlde eksik `purchase` olayını gerçek satış, brüt geliri kâr veya aynı müşterinin yinelenen olayını iki sipariş sanabilirsiniz.

Başlıktaki 2025 ifadesi arşiv niteliğindedir; rehber Temmuz 2026'da güncellenmiştir. Amaç tek bir analitik aracını merkeze koymak değil, müşteri davranışı verisini sipariş, ödeme, iade, stok ve maliyet kayıtlarıyla uzlaştıran karar döngüsü kurmaktır.

---

Güvenilir e-ticaret analizi; davranış olaylarını sipariş ve finans kayıtlarıyla eşleştirerek karar üretir.

Önce Kararı, Sonra Metriği Tanımlayın​

“Dönüşümü artırmak” tek başına karar değildir. Hangi sayfada, hangi müşteri grubunda ve hangi müdahaleyi değerlendireceğinizi yazın.

• Karar: Mobil ürün sayfasındaki varyant seçiciyi değiştirelim mi?
• Birincil ölçüt: Uygun ürünü sepete ekleyebilen oturumların oranı
• Koruyucu ölçüt: Yanlış varyant, iptal/iade, sayfa hatası ve INP bozulmamalı
• Birim: Kullanıcı, oturum, sipariş veya ürün; payda açık olmalı
• Pencere: Satın alma ve iadenin olgunlaşmasına yetecek süre
• Eylem kuralı: Hangi sonuçta yayın, geri alma veya yeni test yapılacağı

Bir metrik eylemi değiştirmiyorsa dashboard'u kalabalıklaştırabilir. Her karta “bu değer değişirse ne yapacağız?” sorusunu ekleyin.

Kanonik Ticaret Olay Sözlüğü Kurun​

Google Analytics'in önerilen e-ticaret olayları; ürün listesi/detay görüntüleme, sepete ekleme/çıkarma, checkout başlatma, satın alma ve iade gibi aşamaları ölçebilir. İsimleri kullanmak tek başına yeterli değildir; olayın tam olarak ne zaman ve hangi sistem gerçeğiyle üretileceği tanımlanmalıdır.

• `view_item`: Ürün verisi gerçekten görüntülendiğinde mi, yalnız sayfa isteğinde mi?
• `add_to_cart`: Sepet sunucu tarafından kabul edildiğinde mi, düğmeye tıklanınca mı?
• `begin_checkout`: Checkout görünümünde mi, ilk geçerli bilgi gönderiminde mi?
• `purchase`: Doğrulanmış başarılı siparişte bir kez mi üretiliyor?
• `refund`: Talep açıldığında mı, finansal iade kesinleştiğinde mi?

Olay sözlüğünde tetikleyici, zorunlu parametre, veri tipi, örnek, kaynak sistem, sahibi ve doğrulama testi bulunmalıdır. Web, mobil uygulama ve sunucu aynı kavramı farklı adlarla göndermemelidir.

Kimlikleri ve Para Alanlarını Tutarlı Kullanın​

Ürün adı değişebilir; analiz için sabit ürün/SKU kimliği gerekir. İşlem kimliği her gerçek sipariş için benzersiz olmalı ve yinelenen başarı sayfası, sayfa yenileme veya tekrar webhook olayında yeni satın alma üretmemelidir.

• Sipariş ve analitik `transaction_id` eşleşiyor mu?
• Ürün `item_id`, varyant ve SKU ilişkisi belgeli mi?
• Değer ile para birimi birlikte gönderiliyor mu?
• Vergi, kargo, indirim ve ürün geliri aynı tanıma göre mi hesaplanıyor?
• İade/kısmi iade doğru ürün ve işlem kimliğine bağlanıyor mu?
• Test siparişleri canlı rapordan ayırt edilebiliyor mu?

Google'ın güncel e-ticaret dokümanı, `value` gönderildiğinde olay düzeyinde `currency` kullanılmasını ve ürünlerin `items` dizisiyle iletilmesini önerir. Kullandığınız aracın şemasını doğrudan resmî kaynaktan doğrulayın.

Analitik ile Finansal Gerçeği Ayırın​

Tarayıcı analitiği reklam engelleyici, izin tercihi, ağ kesintisi veya etiket hatası nedeniyle eksik olabilir. Sipariş yönetimi, ödeme sağlayıcısı ve banka/muhasebe kayıtları ise farklı aşamaları temsil eder. Hiçbiri tek başına bütün gerçeği anlatmaz.

Günlük uzlaştırmada şu sayıları ayrı tutun:

• Analitikteki benzersiz satın alma olayları
• Sipariş sistemindeki oluşturulan, ödenen, iptal edilen ve iade edilen siparişler
• Ödeme sağlayıcısındaki başarılı, belirsiz, iade ve itiraz işlemleri
• Banka/sağlayıcı ödeme raporundaki brüt tutar, ücret ve net ödeme

Analitik gelirini muhasebe geliri olarak kullanmayın. Aradaki farkı oran ve neden koduyla izleyin: izin/veri eksikliği, yinelenen olay, zaman dilimi, para birimi, iade gecikmesi veya entegrasyon hatası.

Kaynak kuralı' Alıntı:

Davranış analitiği “müşteri ne yaptı?” sorusuna; sipariş/ödeme/finans kayıtları “hangi parasal işlem kesinleşti?” sorusuna cevap verir.

Genişletmek için tıkla ...

Huniyi Paydası Açık Biçimde Kurun​

Ürün görüntüleme → sepete ekleme → checkout → ödeme → tamamlanan sipariş zincirinde her oran için payda ve zaman penceresi yazın.


“Uygun” tanımı; test, bot, ücretsiz sipariş, havale bekleyen veya risk incelemesindeki işlemlerin nasıl ele alınacağını belirtir. Kullanıcı, oturum ve işlem paydalarını aynı grafikte karıştırmayın.

Gelirden Katkı Marjına İnin​

Ciro büyürken işletme zarara gidebilir. Ürün, kanal veya kampanya kararında sipariş başına katkıyı izleyin:


Maliyet verisi gecikmeli veya tahmini olabilir; raporda veri tarihi ve yöntemini gösterin. Brüt marj, katkı marjı ve net kâr kavramlarını birbirinin yerine kullanmayın.

Segmentasyonu Hipotez İçin Kullanın​

Toplam ortalama farklı davranışları gizleyebilir. Cihaz, yeni/geri dönen müşteri, kanal, ülke/bölge, ürün kategorisi, ödeme yöntemi ve teslimat seçeneği gibi iş açısından anlamlı segmentleri inceleyin.

Fakat küçük gruplardan kesin sonuç çıkarmayın. Onlarca segmenti rastgele tarayıp yalnız en iyi veya en kötü sonucu seçmek yanlış pozitif riskini artırır. Önce hipotezi ve segmenti belirleyin, yeterli örnek oluşmasını bekleyin ve keşifsel bulguyu yeni test olarak doğrulayın.

Değişiklikleri Kontrollü Deneyle Sınayın​

Önce/sonra karşılaştırması kampanya, sezon, fiyat, stok veya kanal karmasındaki değişiklikten etkilenir. Mümkünse kullanıcıları aynı dönemde kontrol ve varyanta rastgele ayırın; deney birimini ve maruz kalmayı kaydedin.

• Birincil hipotez ve ölçüt test başlamadan yazıldı mı?
• Koruyucu ölçütler: hata, iade, performans, destek ve marj belirlendi mi?
• Aynı kullanıcı iki varyant arasında gidip geliyor mu?
• Deney süresi haftanın günlerini ve satın alma/iade gecikmesini kapsıyor mu?
• Test sırasında kampanya, fiyat veya başka büyük değişiklik kaydedildi mi?
• Sonuç yalnız istatistiksel sinyale değil iş etkisi ve riskine göre değerlendirildi mi?

Deney yapılamıyorsa karşılaştırılabilir dönem, kesintili zaman serisi veya kademeli yayın gibi yöntemleri kullanabilirsiniz; nedensellik sınırını açıkça yazın.

Gizlilik ve Çerez Tercihini Tasarıma Dâhil Edin​

Analitik planı, “önce her şeyi topla sonra kullanırız” yaklaşımına dayanmamalıdır. Amaç, veri alanı, erişim, saklama süresi ve paylaşımı daha etiket kurulmadan belirleyin. KVKK'nın Çerez Uygulamaları Hakkında Rehberi, çerezler yoluyla kişisel veri işlenmesine ilişkin değerlendirme çerçevesi sunar.

• Zorunlu ve zorunlu olmayan depolama/etiketler envanterde mi?
• Tercih ekranındaki açıklama gerçek sağlayıcı ve amaçlarla uyuşuyor mu?
• Ret veya tercih değişikliği teknik olarak uygulanıyor mu?
• Olaylara e-posta, telefon, açık ad veya gereksiz kişisel veri ekleniyor mu?
• Analitik/etiket erişimi rol ve iş ihtiyacına göre sınırlı mı?
• Saklama ve dışa aktarma ayarları belgeli mi?

Hukuki dayanak ve yükümlülükleri somut kullanımınız için uzmanla doğrulayın; araçtaki varsayılan ayar tek başına uyum sağlamaz.

Veri Kalitesi İçin Otomatik Test ve Alarm Kurun​

• Şema testi zorunlu alan, tür, para birimi ve ürün dizisini doğrulasın.
• Gerçek test siparişi ile analitik, sipariş ve ödeme kaydı karşılaştırılsın.
• Yinelenen işlem kimliği ve olağandışı satın alma artışı alarm üretsin.
• Ani olay kaybı, `value=0`, bilinmeyen SKU veya para birimi farkı izlensin.
• Etiket sürümü ve dağıtım zamanı raporlara açıklama olarak işlensin.
• Geri ödeme ve sipariş iptali analitik/finans raporlarına doğru zamanda yansısın.
• Dashboard sorguları ve tanımları sürüm kontrolünde veya veri sözlüğünde tutulsun.

Haftalık Karar Toplantısını Kısa Tutun​

Her hafta yüzlerce grafiği sunmak yerine üç bölüm kullanın: veri sağlığı, iş sonuçları ve kararlar. Her karar için sahip, beklenen etki, koruyucu ölçüt, son tarih ve geri okuma zamanı kaydedin. Sonraki toplantıda yalnız metrik değişimini değil kararın uygulanıp uygulanmadığını da kontrol edin.

Varsayımsal örnek: mobil checkout düşüşü görülüyor. Ekip hemen formu kısaltmak yerine olay kaybı olup olmadığını, ödeme sağlayıcısı reddini, cihaz performansını ve kargo seçimi hatasını ayırıyor. Sorun yalnız belirli tarayıcı sürümünde ödeme bileşeni hatasıysa pazarlama teklifini değiştirmek yerine teknik düzeltme yapılır. Veri, doğru sorunu seçmeye yarar.

İç Bağlantılar​

• E-ticaret yayın öncesi kontrol listesi
• E-ticaret bakım rutini
• E-ticaret performans ve ölçüm rehberi
• E-ticaret ve ödeme başlangıç rotası

Dış Kaynaklar​

• Google Analytics: e-ticaret ölçümü
• Google Analytics: e-ticaret olaylarını kurma
• Google Analytics: olay ve ürün kapsamları
• KVKK: Çerez Uygulamaları Hakkında Rehber
• web.dev: Core Web Vitals

Özetle​

Kararı tanımlayın → olay sözlüğü ve kimlikleri standardize edin → analitiği sipariş/finansla uzlaştırın → paydası açık huni ve katkı marjı kurun → segmenti hipotezle test edin → gizlilik ile veri kalitesini tasarıma ekleyin → kararı sahibi ve geri okuma tarihiyle kaydedin. Veri odaklılık, en çok veriyi toplamak değil; güvenilir veriden hangi eylemin çıkacağını önceden bilmektir.

Güncelleme: 15 Temmuz 2026. Gizlilik ve hukuki yükümlülükler somut veri akışı için uzmanla doğrulanmalıdır.

---