E‑Ticaret Siteleri İçin Log Analizi: Dönüşüm Kaybı, 4xx/5xx ve Ödeme Hatalarını Yakalamak

E‑ticarette Log Analizi Neden Bu Kadar Önemli?

E‑ticaret tarafında büyüme konuşulan her toplantıda mutlaka iki kelime geçer: dönüşüm oranı ve kaybolan sepetler. Trafik satın alır, kampanyalar kurgular, tasarımı iyileştirirsiniz; fakat bazı kullanıcılar tam ödeme adımında sessizce kaybolur. Analytics araçları size belli bir seviyeye kadar yol gösterir, ancak teknik sorunlar başladığında gerçekten ne olduğunu söyleyen tek yer sunucu loglarıdır.

Sunucunun gözünden bakınca her şey çok nettir: hangi URL kaç milisaniyede yanıt verdi, hangi istekte 4xx/5xx döndü, hangi kullanıcı ödeme callback çağrısında 500 hatası aldı, hangi ödeme isteği gateway’e hiç ulaşamadı… Dönüşüm kaybının önemli bir kısmı aslında bu loglarda saklıdır. Sorun şu ki, birçok e‑ticaret ekibi bu altın madeniyle sistematik olarak çalışmıyor.

Bu yazıda DCHost ekibi olarak, e‑ticaret sitelerinde sunucu loglarından dönüşüm kaybını, 4xx/5xx ve ödeme hatalarını nasıl yakalayabileceğinizi adım adım anlatacağız. Apache/Nginx erişim loglarından, uygulama ve ödeme loglarına; basit komutlarla hızlı analizden merkezi loglama ve alarm kurallarına kadar pratik, sahada defalarca denenmiş bir yol haritası paylaşacağız.

Dönüşüm Kaybını Anlamak İçin Hangi Loglara Bakmalısınız?

Önce resme yukarıdan bakalım: E‑ticaret sitenizde kullanıcı yolculuğu kabaca şöyle işler:

• Ürün listeleme ve detay sayfaları
• Sepete ekleme
• Sepet görüntüleme
• Ödeme/checkout adımları
• Ödeme sonucu (başarılı/başarısız)

Bu yolculuğun her adımında farklı loglar devreye girer. Dönüşüm kaybının kök nedenini bulmak için bu logları birlikte okumak gerekir.

1. Web sunucu erişim logları (access.log)

Apache veya Nginx erişim logları, her HTTP isteğini satır satır kaydeder. Tipik bir satırda şunlar bulunur:

• IP adresi
• Tarih ve saat
• HTTP metodu (GET/POST vb.)
• İstenen URL ve query string
• HTTP durum kodu (200, 301, 404, 500 vb.)
• Cevap boyutu
• Referer (hangi sayfadan gelmiş)
• Kullanıcı ajanı (tarayıcı bilgisi)

Bu loglar sayesinde:

• Sepet ve ödeme URL’lerinde kaç istek yapıldığını,
• Bu URL’lerin ne kadarının 4xx/5xx ile sonuçlandığını,
• Hangi saatlerde hata oranının yükseldiğini

hızlıca görebilirsiniz. Apache/Nginx formatlarını ve 4xx/5xx okumayı daha temelden öğrenmek istiyorsanız, ayrıntılı bir başlangıç için Apache ve Nginx ile 4xx–5xx hatalarını teşhis rehberi yazımıza da mutlaka göz atın.

2. Web sunucu hata logları (error.log)

Erişim logları bize “ne oldu”yu söyler; hata logları ise çoğu zaman “neden oldu”yu gösterir. Örneğin:

• PHP fatal error nedeniyle patlayan ödeme sayfası
• 3. parti ödeme API’sine bağlanamayan cURL çağrıları
• Veritabanı bağlantı hataları (too many connections, timeout vb.)

Ödeme adımında kullanıcı 500 hatası görüyorsa, genellikle detaylı neden error.log dosyasında kayıtlıdır. Bu yüzden dönüşüm kaybı analizi yaparken access.log ile error.log’u mutlaka birlikte incelemek gerekir.

3. Uygulama ve framework logları

Eğer WooCommerce, Laravel, Symfony, custom PHP veya Node.js tabanlı bir e‑ticaret uygulamanız varsa, uygulama seviyesi loglar işin röntgeni gibidir. Örneğin:

• “cart_add”, “checkout_started”, “payment_initiated”, “payment_success”, “payment_failed” gibi olay logları
• Hata detayları (exception mesajları, stack trace)
• Kullanıcı veya sepet ID’si, sipariş numarası gibi korelasyon alanları

Bu logları yapılandırılmış (JSON gibi) formatta tutarsanız, daha sonra merkezi bir log sistemi ile (ELK, Loki vb.) çok güçlü sorgular ve paneller kurabilirsiniz. Bu konuyu daha ileri taşımak için Grafana Loki + Promtail ile merkezi loglama rehberimizi özellikle tavsiye ederim.

4. Ödeme sağlayıcı ve banka logları

Ödeme sürecinde genellikle şu adımlar vardır:

• Ödeme isteği: Sitenizden banka/ödeme kuruluşuna istek gönderilir.
• 3D Secure veya kart doğrulama ekranı (kullanıcı bankanın sayfasına gider).
• Callback/Webhook: Banka, son sonucu sizin siteye bildirir.

Burada iki tür log kritik:

• Sizin uygulamanızdaki ödeme logları: ödeme isteği, dönen hata kodları, sipariş ID’leri.
• Ödeme sağlayıcının logları: genelde dashboard üzerinden raporlar veya .csv export olarak alırsınız.

Sunucu loglarını bu ödeme raporları ile birleştirdiğinizde, hangi teknik sorunların reddedilen veya yarım kalan ödemelere neden olduğunu daha net görürsünüz.

5. Veritabanı ve kuyruk logları

Orta ve büyük ölçekli e‑ticaret sitelerinde sıkça gördüğümüz bir model var: sipariş oluşturma ve e‑posta/entegrasyon işleri, kuyruk (queue) sistemleriyle asenkron çalışıyor. Bu durumda:

• Veritabanı hata logları ve slow query logları
• Queue worker logları (örneğin Laravel Queue, Horizon vb.)

özellikle kampanya dönemlerinde kritik hale gelir. Veritabanı yavaşladığında ya da queue tüketemez hale geldiğinde, ödeme almanız mümkün olsa bile siparişiniz “beklemede” kalabilir. Bu da kullanıcı tarafında güven kaybı ve destek yükü demektir.

6. Log saklama süreleri ve disk yönetimi

Log analizi konuşurken gözden kaçan ama üretimde en çok sorun çıkaran başlık: disk dolması. Logları uzun süre saklamak istersiniz, ancak bu defa da disk dolduğu için site hata vermeye başlar. Bu dengeyi doğru kurabilmek için:

• logrotate ile günlük/haftalık döndürme ve sıkıştırma
• İşletme olarak ihtiyaç duyduğunuz log saklama sürelerini (örneğin 90 gün, 6 ay) belirleme
• Gerekirse eski logları daha ucuz bir depolama alanına taşıma

gibi önlemleri mutlaka planlamalısınız. Bu konuda pratik adımları görmek için logrotate ile disk dolma hatasını önleme rehberimize bakabilirsiniz. Ayrıca hosting ve e‑posta altyapısında log saklama süreleri yazımız, hangi logu ne kadar tutmanız gerektiği konusunda iyi bir çerçeve sunuyor.

4xx ve 5xx Hatalarından Dönüşüm Kaybı Nasıl Yakalanır?

HTTP durum kodları, log analizinde ilk bakmanız gereken yer. Dönüşüm kayıplarının önemli bir bölümü kullanıcıya yansımayan ama loglara düşen bu kodların arkasına saklanır.

4xx hataları: Kullanıcı veya istemci kaynaklı görünen sorunlar

En sık göreceğiniz 4xx kodları:

• 404 Not Found: Kaynak bulunamadı. Sık rastlanıyorsa yanlış linkler, bozuk butonlar veya eksik yönlendirmeler olabilir.
• 403 Forbidden: Yetkisiz erişim. Doğru kullanıcılar yanlışlıkla engelleniyorsa güvenlik kuralları (WAF, firewall) agresif olabilir.
• 429 Too Many Requests: Rate limiting devrede. Kampanya dönemlerinde ödeme veya sepet adımlarında 429 artışı görüyorsanız, limitleri gözden geçirmek gerekir.

Özellikle sepet ve ödeme URL’lerinde 4xx oranının artması, direkt dönüşüm kaybı demektir. Örneğin /sepet, /checkout, /odeme gibi URL’ler için 404 ve 403’leri günlük olarak takip etmenizi öneririz.

5xx hataları: Sunucu taraflı gerçek problemler

5xx kodları doğrudan sizin altyapınızla ilgilidir:

• 500 Internal Server Error: Genelde uygulama hataları (PHP exception, kod bug’ı).
• 502 Bad Gateway: PHP-FPM, Node.js veya upstream servis yanıt veremedi/yanlış yanıtladı.
• 503 Service Unavailable: Servis geçici olarak kullanılamıyor; bakım, limit aşımı veya aşırı yük altında.
• 504 Gateway Timeout: Arkadaki servis belirlenen sürede yanıt veremedi (genelde yavaş DB veya API).

Bu kodları zaman, URL ve kullanıcı akışı ile birlikte analiz ettiğinizde, dönüşüm kayıplarını nokta atışı yakalayabilirsiniz.

Basit komutlarla 4xx/5xx istatistikleri çıkarmak

Küçük ve orta ölçekli sitelerde, SSH erişiminiz varsa basit komutlarla bile hızla içgörü elde edebilirsiniz. Örneğin Nginx access.log için:

• En çok görülen 5xx hataları:
  grep " 5" access.log | awk '{print $9}' | sort | uniq -c | sort -nr | head
• En çok 404 dönen ilk 10 URL:
  awk '$9 == 404 {print $7}' access.log | sort | uniq -c | sort -nr | head
• Sepet sayfasında son bir saatte oluşan 5xx sayısı:
  grep "/sepet" access.log | grep " 5" | tail -n 2000 | wc -l

Bu temel analiz bile, tasarımda görünmeyen kırık linkleri, yanlış yönlendirmeleri ve ödeme adımındaki ani hata artışlarını ortaya çıkarabilir.

Kritik funnel sayfalarına ayrı gözle bakmak

Tüm sitenin hata oranına değil, satış hunisinin kritik adımlarına odaklanmalısınız. Örneğin:

• Ürün detay sayfaları: /urun/, /product/ vb.
• Sepet: /sepet, /cart
• Checkout: /odeme, /checkout, /payment
• Sonuç sayfası: /siparis-tamam, /order-success vb.

Her bir adım için ayrı ayrı:

• Toplam istek sayısı
• 4xx oranı
• 5xx oranı

çıkardığınızda, örneğin checkout sayfasının genel siteye göre 5 kat fazla 500 hatası verdiğini görüp doğrudan oraya odaklanabilirsiniz.

Sepet ve Ödeme Adımlarında Log Tabanlı Funnel Analizi

Log analizi sadece hataları saymak değildir; aynı zamanda kullanıcı yolculuğunu aşama aşama takip etmektir. Bunu e‑ticaret özelinde basit bir funnel kurgusuyla yapabilirsiniz.

URL desenleriyle adımları tanımlamak

İlk adım, access.log içinde sepet ve ödeme sürecine ait URL’leri netleştirmektir. Örneğin:

• Adım 1 – Sepet görüntüleme: /sepet
• Adım 2 – Adres/fatura bilgileri: /odeme/adres
• Adım 3 – Ödeme yöntemi seçimi: /odeme/yontem
• Adım 4 – Ödeme sonucu: /odeme/sonuc

Ardından loglarda bu URL’leri filtreleyerek, belirli bir zaman aralığında:

• Kaç benzersiz kullanıcı (IP+user agent/oturum) bu adımlara girdi?
• Hangi adımda kaç kişi kayboldu?
• Hangi adımda 4xx/5xx oranı anormal yüksek?

sorularına yanıt ararsınız. Daha detaylı örnek funnel kurguları ve alarm senaryoları için e‑ticaret sepet ve ödeme adımlarını izleme rehberimizi inceleyebilirsiniz.

Uygulama loglarına olay bazlı kayıt eklemek

Sadece URL ile çalışmak bir yere kadar götürür. Daha derin analiz için, uygulama seviyesinde şu tip olay logları üretmenizi tavsiye ediyoruz:

• cart_viewed, cart_updated, checkout_started
• payment_initiated, payment_redirected, payment_callback_received
• payment_success, payment_failed

Bu olayları tek satırlık JSON logları olarak yazarsanız, örneğin:

{"event":"payment_failed","order_id":12345,"reason":"3d_auth_failed","user_id":678}

sonradan merkezi log sisteminizde şu tip sorgular yapabilirsiniz:

• Son 24 saatte payment_failed oranı nedir?
• Hangi bankalarda veya kart türlerinde hata oranı daha yüksek?
• Hangi saat aralığında teknik nedenli ödeme hataları artmış?

Oturum bazlı funnel ve korelasyon

İşin ideal hali, her kullanıcıya veya sepete özel bir korelasyon ID’si kullanmaktır (örneğin session_id, cart_id, order_id). Bu ID’yi:

• access.log’taki her isteğe (örneğin cookie aracılığıyla),
• uygulama loglarına,
• ödeme loglarına

eklediğinizde, tek bir kullanıcının sepetten ödemeye kadar yaşadıklarını uçtan uca takip edebilirsiniz. Bu sayede, belirli bir hata tipinin gerçekten kaç kullanıcıyı ve ne kadar ciroyu etkilediğini hesaplamak çok kolay hale gelir.

Ödeme Hatalarını Sunucu Loglarından Yakalamak

Ödeme adımı, dönüşüm kaybının en can acıtan noktasıdır. Burada kaçırılan her sipariş, doğrudan ciro kaybı demektir. Ödeme hataları kabaca ikiye ayrılır:

• Kullanıcı/banka kaynaklı hatalar: yetersiz bakiye, kartın reddedilmesi, 3D şifre hatası vb.
• Teknik hatalar: timeout, 5xx, yanlış imza, callback’in işlenememesi vb.

İşin güzel tarafı, teknik hataların neredeyse tamamını doğru log stratejisiyle yakalayabilirsiniz.

Ödeme sağlayıcı hata kodlarını normalleştirmek

Farklı bankalar ve ödeme sağlayıcılar farklı hata kodları ve mesajlar kullanır. Bunları uygulama tarafında birkaç kategoriye indirgemek, log analizi için hayat kurtarıcıdır. Örneğin:

• technical_error (timeout, 5xx, network, imza doğrulama hatası)
• bank_decline (banka reddi, limit yetersiz vb.)
• user_canceled (kullanıcı iptali, 3D sayfasından geri dönme)

Uygulama logunuza, her ödeme girişimi için bu normalleştirilmiş bir alan eklerseniz, log tarafında şu tip sorgular yapabilirsiniz:

• Son 1 saatte technical_error oranında ani artış var mı?
• Hangi kampanya veya trafik kaynağında bank_decline oranı daha yüksek?

Timeout ve performans kaynaklı ödeme problemleri

Ödeme sürecinde en sık gördüğümüz teknik problemlerden biri timeout’lardır. Senaryolar genelde şöyle gelişir:

• Kampanya döneminde trafik artar.
• Veritabanı yavaşlar veya kilitlenir.
• Ödeme isteğinin işlendiği PHP/uygulama kodu zamanında yanıt veremez.
• Kullanıcı ya hata görür ya da banka sayfasında takılı kalır.

Bu tip problemleri loglardan yakalamak için:

• access.log’da uzun süren istekleri (örneğin > 2 sn) işaretlemek,
• error.log’da gateway timeout veya connection timeout mesajlarını filtrelemek,
• uygulama loglarında ödeme fonksiyonlarının çalışma sürelerini ölçmek

çok işe yarar. Altyapı tarafında performans optimizasyonu gerekiyorsa, WooCommerce ve büyük katalog siteleri için MySQL indeksleme rehberi veya PHP tarafında doğru memory_limit ve max_execution_time ayarları gibi yazılarımızdan da faydalanabilirsiniz.

Callback ve webhook sorunlarını loglardan yakalamak

Ödeme süreçlerinde belki de en az fark edilen ama en kritik adım, banka/ödeme kuruluşunun sizin sitenize gönderdiği callback/webhook istekleridir. Bu isteklerde yaşanan problemler:

• Kullanıcı kartından para çekilmiş olsa bile siparişin sisteminizde oluşmamasına,
• Siparişin “beklemede” kalmasına,
• Stok ve muhasebe kayıtlarının tutmamasına

neden olabilir. Callback sorunlarını loglardan yakalamak için:

• Callback URL’sine gelen tüm istekleri ayrı bir log dosyasında toplamak,
• Bu istekler için HTTP durum kodlarını (200, 400, 500) düzenli izlemek,
• Başarısız callback’ler için otomatik alarm üretmek

olmazsa olmazdır. Özellikle 500 ve 4xx kodları artıyorsa, çoğu zaman uygulama validasyon kuralları veya güvenlik ayarları (örneğin WAF) callback’leri yanlışlıkla engelliyor demektir.

Alarm, Rapor ve Otomasyon: Log Analizini Günlük Rutine Çevirmek

Log analizi bir kerelik bir çalışma değil, yaşayan bir süreç olmalıdır. Bunu gerçekten faydalı hale getirmek için üç katmanlı bir yapı öneriyoruz: alarm, gösterge paneli ve düzenli raporlar.

Anlık alarm kuralları

Anlık alarm için hedefiniz, “yangın çıktığında telefona bildirim düşsün” noktasıdır. Örneğin:

• Son 5 dakikada checkout URL’lerinde 5xx oranı %3’ü geçtiyse alarm.
• Son 10 dakikada payment_failed içeren log satırı sayısı normalin 2 katına çıktıysa alarm.
• Callback URL’sinde üst üste 10 adet 500 hatası oluştuysa alarm.

Merkezi loglama (Loki, ELK vb.) ve metrik sistemleri (Prometheus, Netdata) burada devreye giriyor. Daha önce bahsettiğimiz Grafana Loki + Promtail ile log yönetimi yazımızda, bu tür alarm kurallarının nasıl tanımlanabileceğine dair somut örnekler bulabilirsiniz.

Gösterge panelleri (dashboard) ile büyük resmi görmek

Günlük işlerin içinde kaybolmamak için, loglardan beslenen birkaç temel gösterge paneli kurmanızı öneriyoruz:

• Genel hata oranı (4xx/5xx) – zaman serisi
• Sepet ve ödeme funnel’ı – adım adım dönüşüm oranı
• Ödeme hata kategorileri (technical_error, bank_decline, user_canceled) dağılımı
• En çok hata üreten ilk 10 URL

Bu paneller, ekip toplantılarında “hissiyat” yerine veriye dayalı konuşmanızı sağlar. Örneğin, yeni bir tema güncellemesinden sonra checkout sayfasında 500 hata oranının arttığını net biçimde görebilirsiniz.

Crontab ile düzenli raporlar üretmek

Her ekibin merkezi log sistemi veya gelişmiş dashboard altyapısı olmayabilir. Böyle durumlarda bile, basit bash script’leri ve cron job’lar ile günlük özet raporlar üretmek mümkündür. Örneğin:

• Gün sonunda son 24 saate ait 4xx/5xx istatistiklerini çıkaran bir script
• Sepet ve ödeme URL’leri için hata oranlarını hesaplayan küçük bir araç
• Bu çıktıları e‑posta ile teknik ekibe gönderen bir yapı

Bu tarz otomasyonlar için cron tarafında dikkat etmeniz gereken noktalar hakkında, Linux crontab en iyi uygulamalar rehberimizde bolca pratik öneri bulursunuz.

DCHost Altyapısında Log Analizi İçin Pratik Öneriler

DCHost olarak hem paylaşımlı e‑ticaret hosting paketlerinde hem de VPS/dedicated ve colocation altyapılarımızda log analizi yapmayı kolaylaştıracak bazı pratik önerilerimiz var:

• Ayrı log dizini ve yeterli disk alanı: Özellikle yüksek trafikli mağazalar için loglar ayrı bir disk bölümünde tutulmalı ve büyüme hızı izlenmelidir.
• Standart log formatı: Tüm web sunucularınızda (Nginx/Apache) aynı log formatını kullanın ki merkezi analizde zorlanmayın.
• Merkezi loglama: Birden fazla web, uygulama ve veritabanı sunucunuz varsa, logları merkezi bir sisteme (Loki/ELK tarzı) akıtmak, e‑ticaret ekipleri için ciddi zaman kazandırır. Bu mimari için birden fazla sunucuda log yönetimi rehberimiz iyi bir başlangıç noktasıdır.
• Test/staging ortamında da loglamak: Canlıya çıkmadan önce staging ortamında sepet ve ödeme akışını aynı log yapısıyla test etmek, hataların prod’a yansımadan yakalanmasını sağlar.
• Destek ekibi ile ortak dil: DCHost tarafındaki destek ekibimizle konuşurken erişim logu, hata logu, zaman aralığı ve örnek URL’leri net verirseniz, sorun tespit süresi dramatik şekilde kısalır.

Sonuç ve Yol Haritası: Logları Okuyan E‑Ticaret Kazanır

Dönüşüm kaybı çoğu zaman “kullanıcı alışkanlıkları” veya “pazarlama performansı” gibi başlıklara yıkılır. Oysa sunucu logları bize başka bir hikâye anlatır: 5 dakika boyunca checkout sayfasında 500 hatası alan kullanıcılar, 404 dönen ürün sayfaları, timeout nedeniyle yarım kalan ödemeler, callback’i işlenemediği için sistemde görünmeyen siparişler… Bunlar sadece pazarlama değil, doğrudan altyapı ve uygulama kalitesi problemidir.

Bu yazıda DCHost ekibi olarak, e‑ticaret siteniz için:

• Hangi logların kritik olduğunu,
• 4xx/5xx hatalarından dönüşüm kaybını nasıl yakalayabileceğinizi,
• Ödeme hatalarını loglardan nasıl ayrıştırabileceğinizi,
• Alarm, dashboard ve cron raporlarıyla bu süreci nasıl otomatikleştirebileceğinizi

özetledik. Bundan sonraki adım, siteniz için küçük ama somut bir plan yapmak olabilir: bugün access.log ve error.log’unuzu kontrol edip sepet/ödeme URL’lerinizin hata oranlarını çıkarın; sonraki hafta uygulama loglarına event bazlı kayıt ekleyin; ardından da basit bir alarm kuralı kurun.

Eğer DCHost üzerinde çalışan bir e‑ticaret siteniz varsa veya yeni bir VPS/dedicated/colocation mimarisi planlıyorsanız, log stratejinizi projelendirme aşamasında birlikte tasarlayabiliriz. Böylece sepetlerin ve ödemelerin kaybolduğu anları yalnızca hissederek değil, loglarla kanıtlayarak görebilir; sorunları dakikalar içinde yakalayıp saatlerce, hatta günlerce sürecek ciro kaybının önüne geçebilirsiniz.