Sepet Terk Kurtarma: İzin ve Senaryo Kuralları

Sepete ürün ekleyip ödeme adımına gelmeden çıkan ziyaretçiler, e-ticaret ekiplerinin en sık takip ettiği kayıplardan biridir. Bu kaybı genelleştirilmiş CRO taktikleriyle değil, ölçülebilir olaylara bağlı otomatik akışlarla yönetmek isteyen işletmeler için doğru sepet terk kurtarma yazılımı seçimi kritik hale gelir. Yazılım; sepet olaylarını izler, doğru kanaldan hatırlatma gönderir ve stok ile kupon kurallarını bozmadan dönüşümü destekler. Bu rehberde ölçümden entegrasyona kadar seçim sürecini adım adım ele alıyoruz.

Sepet terk nasıl ölçülür ve hangi olaylar izlenir?

Kurtarma yazılımı seçmeden önce “terk”i yalnızca sepet sayfasında çıkış olarak tanımlamayın. Modern sistemler sipariş hunisindeki her kritik adımı olay olarak kaydeder. En az şu olayların panelle veya analitik katmanıyla eşleştiğinden emin olun:

• Sepete ekleme: ürün, varyant, adet, birim fiyat ve sepet kimliği
• Sepet güncelleme: adet değişimi, ürün çıkarma, kupon uygulama denemesi
• Ödeme adımına giriş: adres, kargo ve ödeme yöntemine geçiş
• Ödeme başlatma / yarıda bırakma: 3D Secure veya banka sayfasına yönlendirme sonrası dönüş
• Satın alma tamamlama: sipariş oluşturuldu sinyali (kurtarma mesajını kesmek için zorunlu)

Ölçümde net tanım kullanın: örneğin “son sepet aktivitesinden sonra X dakika işlem yok ve sipariş oluşmadı”. Bu süre mobil ve masaüstünde farklı olabilir. Ayrıca misafir sepet ile üye sepeti ayırın; e-posta veya telefon olmadan kurtarma kanalı sınırlı kalır. Yazılımın hem sunucu tarafı hem tarayıcı olaylarını (pixel, dataLayer, webhook) desteklemesi, reklam engelleyici ve çerez kısıtlarında dayanıklılığı artırır.

Kurtarma kanalları: e-posta, SMS ve site içi mesaj

Tek kanallı hatırlatma çoğu mağazada yetersiz kalır. Seçtiğiniz sepet terk kurtarma yazılımı en az üç kanalı aynı akışta yönetebilmelidir.

E-posta

En esnek kanaldır: ürün görselleri, varyant özeti, kargo süresi ve güven mesajları birlikte sunulabilir. Aranan özellikler arasında şablon editörü, ürün bloğu senkronu, UTM parametreleri, abonelikten çıkma bağlantısı ve gönderim itibarı (bounce, spam şikâyeti) raporları yer alır. E-posta, acil stok uyarısından çok “hatırlatma + güven” senaryolarında güçlüdür.

SMS

Kısa, zaman duyarlı ve yüksek görünürlüklü bir kanaldır. Özellikle sepet tutarı yüksekse veya stok sınırlıysa faydalıdır. Seçimde açık rıza kaydı, şablon onayı, gönderim saati kısıtı ve kısa bağlantı (tracking) desteği arayın. Mesaj metninde gereksiz vaat ve aşırı kupon baskısından kaçının; net ürün hatırlatması ve güvenli ödeme linki yeterlidir.

Site içi mesaj ve panel tetikleyicileri

Kullanıcı siteye geri döndüğünde çıkış niyeti, sepet ikonu animasyonu veya üst bant mesajı gibi sakin uyarılar dönüşüme destek olabilir. Bunlar e-posta/SMS’in yerini almaz; mevcut oturumda sürtünmeyi azaltır. Canlı sohbet ekipleriyle çalışıyorsanız, terk riski yüksek sepetleri destek paneline düşürmek de mümkündür; bu noktada canlı destek yazılımı seçimi ile kurtarma akışınızı yan yana kurgulayabilirsiniz.

Tetikleyici kurallar, segmentasyon ve zamanlama

Güçlü bir sepet terk kurtarma yazılımı yalnızca “sepet terk edildi” diye mesaj atmaz; kural motoru ve segmentasyon sunar. Pratik bir kurguda şu katmanları arayın:

1. Zamanlama penceresi: ilk hatırlatma (ör. 30–60 dk), ikinci hatırlatma (24 saat civarı), son hatırlatma (48–72 saat). Süreleri kendi dönüşüm verinize göre A/B test edin.
2. Sepet değeri eşiği: düşük tutarlı sepetlerde SMS maliyetini sınırlayın; yüksek tutarda daha erken ve çok kanallı akış açın.
3. Ürün tipi: bozulabilir, hızlı tükenen veya kişiselleştirilmiş ürünlerde farklı mesaj tonu kullanın.
4. Müşteri statüsü: ilk alışveriş, tekrar alım, sadakat üyesi, B2B hesap gibi segmentler ayrı akış ister.
5. Cihaz ve kanal kaynağı: mobil terk ile masaüstü terk davranışı farklı olabilir; mesaj uzunluğunu buna göre ayarlayın.

Tetikleyiciler, sipariş oluşunca veya sepet temizlenince anında durmalıdır. Aksi halde müşteriye “zaten aldığınız ürün hâlâ sepetinizde” mesajı gider ve güven zedelenir. Kural motorunun koşullu mantık (VE / VEYA), frekans sınırı (aynı kişiye günde en fazla N mesaj) ve sessiz saat tanımlarını desteklemesi operasyonel hatayı azaltır. Otomasyon mantığını daha geniş süreçlerle birleştirmek isterseniz iş akışı otomasyonu yaklaşımı da yardımcı olur.

Kupon, stok ve fiyat tutarlılığı kontrolleri

Kurtarma yazılımı seçiminde en sık gözden kaçan konu, mesajın arkasındaki ticari tutarlılıktır. Yanlış kupon veya tükenmiş ürün linki, kurtarma yerine şikâyet üretir.

Stok kontrolü

• Mesaj üretilmeden önce sepet satırlarının anlık stok sorgusu yapılabilmeli
• Stok yetersizse “benzer ürün” veya “favorilere ekle” senaryosuna düşebilmeli
• Varyant bazlı (beden/renk) stok doğrulaması zorunlu olmalı

Fiyat tutarlılığı

• Mesajdaki fiyat, müşterinin sepete eklediği an ile güncel fiyat arasında net kurala bağlanmalı
• Flash indirim bittiyse otomatik kupon veya “fiyat güncellendi” uyarısı tanımlanabilmeli
• KDV, kargo ve para birimi gösterimi sepet özeti ile aynı olmalı

Kupon güvenliği

• Her sepet için tek kullanımlık veya sınırlı kod üretimi tercih edin
• Minimum sepet tutarı, kategori istisnası ve üst üste kullanım yasağı yazılımda tanımlı olsun
• Kodun geçerlilik süresi SMS/e-posta metninde net yazılsın
• İndirim yalnızca terk kurtarma segmentine açılsın; genel kupon sızıntısını engelleyin

Bu kontroller panelle senkron çalışmazsa operasyon ekibi manuel düzeltmeye mahkûm kalır. Seçim görüşmelerinde “mesaj gönderilmeden önce stok ve fiyat API’si çağrılıyor mu?” sorusunu mutlaka sorun.

Entegrasyon kontrol listesi

Yazılım ne kadar şık görünürse görünsün, mağaza altyapınıza temiz bağlanmıyorsa akış kırılır. Kurulum öncesi şu kontrol listesini kullanın:

• E-ticaret platformu uyumu: sepet, sipariş, müşteri ve ürün API/webhook erişimi
• Kimlik eşleştirme: e-posta, telefon, üye ID ve misafir sepet birleştirme kuralları
• Ödeme ve sipariş sinyali: başarılı siparişte kurtarma serisinin anında iptali
• Stok ve fiyat kaynağı: ana panelin mi, PIM’in mi, ERP’nin mi otorite olduğu
• İletişim altyapısı: e-posta sağlayıcı, SMS operatörü, domain SPF/DKIM/DMARC
• Rıza ve tercih yönetimi: pazarlama izni, kanal tercihi, ret listesi senkronu
• Gizlilik ve erişim: personel yetkileri, log tutma, veri saklama süresi
• Test ortamı: canlıya almadan önce sahte sepetlerle uçtan uca deneme

Bağlantı kopukluğu çoğu zaman “yazılım zayıf” sanılır; asıl sorun olayların gecikmeli veya eksik gelmesidir.

Başarı metrikleri: neyi izlemelisiniz?

Seçim sonrası yalnızca “kaç e-posta gitti?” diye bakmak yanıltıcıdır. Aşağıdaki metrik seti, yazılımın ticari katkısını daha doğru gösterir:

• Kurtarılabilir sepet oranı: iletişim bilgisi olan ve sipariş oluşmamış sepetlerin payı
• İletişim teslim oranı: e-posta delivered, SMS iletim ve hata kodları
• Açılma / tıklama / dönüşüm: kanal bazında huniyi izleyin
• Kurtarılan sipariş adedi ve ciro: yalnızca son tıklama değil, destekli dönüşüm de raporlansın
• Kupon maliyeti: indirimle dönen siparişlerin marj etkisi
• Şikâyet ve ret oranı: spam şikâyeti, SMS opt-out, destek talebi artışı
• Yanlış içerik oranı: stoksuz ürün veya hatalı fiyat içeren mesaj sayısı (sıfıra yaklaşmalı)

İlk ayı “öğrenme dönemi” kabul edin: zamanlama pencerelerini daraltın veya genişletin, SMS’i yalnızca yüksek sepetlere açın, kuponu test grubuyla sınırlayın. Yazılımın rapor ekranı ham olayı, kanal performansını ve sipariş bağını birlikte göstermiyorsa ekip karar veremez.

Uygulanabilir seçim adımları

Karar sürecini hızlandırmak için pratik bir yol haritası:

1. Mevcut sepet terk tanımınızı ve olay listenizi yazılı hale getirin.
2. Hangi kanallarda yasal iletişim izniniz olduğunu netleştirin.
3. Stok, fiyat ve kupon için “mesaj öncesi kontrol” zorunluluğunu şartnameye yazın.
4. Demo veya pilotta gerçek ürünlerle misafir + üye senaryolarını koşturun.
5. Sipariş oluşunca serinin durduğunu, stoksuz üründe mesajın değiştiğini doğrulayın.
6. Raporlarda kurtarılan ciro, kupon maliyeti ve ret oranını aynı ekranda görün.
7. Operasyon ekibinin şablon, segment ve sessiz saatleri kendi başına yönetebildiğini test edin.

Misafir sepetlerde kurtarma mümkün mü?

Evet, fakat iletişim bilgisi toplama noktanız net olmalıdır: ödeme adımında e-posta/telefon, çıkış niyeti formları veya üyeliksiz sipariş alanları. Bilgi yoksa yalnızca site içi mesaj ve yeniden pazarlama pikselleri devreye girer; yazılımın bu ayrımı desteklemesi gerekir.

Her sepete kupon vermek gerekir mi?

Hayır. Kupon, özellikle fiyat duyarlı segmentlerde ve ikinci-üçüncü hatırlatmada kullanılabilir. İlk mesajda çoğu zaman sepet özeti, stok durumu ve güven unsurları yeterlidir. Sürekli indirim, marka algısını ve marjı zorlar.

Kurtarma yazılımı CRO’nun yerini tutar mı?

Tutmaz. Ürün sayfası netliği, ödeme sürtünmesi, kargo şeffaflığı ve hız ayrı konular. Sepet terk kurtarma yazılımı, hunide zaten ilerlemiş ama tamamlamamış talebi geri çağırır; kök sorunları çözmez, tamamlar.

Doğru seçilmiş bir sepet terk kurtarma yazılımı; ölçülebilir olaylar, çok kanallı hatırlatma, sıkı stok-kupon kontrolleri ve temiz entegrasyon üzerine kurulur. Kurulumu aceleye getirmeden pilot akışla başlayın, metrikleri izleyin ve mesaj tonunu markanıza uygun sade tutun. Operasyonel netlik sağlandığında kurtarma akışı, satış ekibinin günlük takibinden bağımsız ve güvenli biçimde çalışır.

Sepet kurtarma mesajı eski fiyatı veya tükenmiş ürünü vaat etmemelidir. Gönderim anında sepetin geçerliliğini yeniden kontrol edin. Siparişini başka kanaldan tamamlayan müşteriyi de mümkün olan eşleştirmelerle akıştan çıkarın.