Çoğu e-pin satıcısı veri saklama süresini bir "teknik detay" sanır. Panelini kurar, siparişler akmaya başlar, log tabloları şişer ve kimse aylarca dönüp bakmaz. Ta ki bir sabah panel açılmaz, sipariş listesi otuz saniyede yüklenir, hosting firması "veritabanı kotanız doldu" mailini atar ya da bir müşteri sekiz ay önceki teslim edilmemiş kodunu sorar da elinde tek bir kayıt kalmadığını fark edersin. İşte o an anlarsın: saklama süresi teknik detay değil, doğrudan nakit akışını ve itibarını belirleyen bir işletme ayarıdır.
Gerçek şu ki bu ayarın iki ucu da tehlikelidir. Her şeyi sonsuza kadar tutarsan sistemi taşıyamaz hale gelirsin; hem sunucu maliyeti artar hem de kişisel veriyi gereksiz süre elinde tuttuğun için hukuki olarak savunmasız kalırsın. Hiçbir şey tutmazsan da ilk itirazda, ilk chargeback'te, ilk vergi sorusunda elin boş kalır. Doğru kurgu "ne kadar çok tutarsam o kadar iyi" değil, hangi verinin hangi amaçla ne kadar süre gerektiğini ayrı ayrı tanımlamaktır. İyi bir e-pin satış scripti sana bunu tek bir slider'la değil, veri türü bazında verir. Pinova'nın saklama politikası modülü de tam bunun için var.
Neden "her şeyi sonsuza kadar sakla" en pahalı tercihtir?
Bir e-pin panelinde en hızlı büyüyen tablo sipariş tablosu değildir. Genelde erişim logları, webhook kayıtları, API istek-yanıt gövdeleri ve otomatik teslimat denemelerinin izleridir. Günde 300 sipariş alan bir bayide sipariş tablosu yılda 100 bin satır büyürken, log tarafı rahatlıkla milyonlara çıkar. Çünkü tek bir sipariş arkasında ödeme bildirimi, stok çekme, kod ayırma, mail gönderimi ve tekrar denemeler gibi onlarca olay üretir.
Bu satırların hepsi indekslenir, yedeklenir, her gece dump'a girer. Bir noktada yedek dosyası o kadar büyür ki gece yedeklemesi satış saatine sarkar; veritabanı kilitlenir ve en yoğun saatte teslimat gecikir. Yani teknik olarak "sadece disk" gibi görünen şey, pratikte iade talebine ve olumsuz yoruma dönüşür. Dijital ürün satış yazılımı seçerken "log tutuyor mu" diye sormak yeterli değil, "logu nasıl buduyor" diye sormak gerekir.
Hangi veri ne kadar durmalı? Süreyi amaç belirler, his değil
Saklama süresini belirlemenin tek doğru yolu her veri türüne "bunu neden tutuyorum" sorusunu sormaktır. Cevap "bir gün lazım olabilir" ise o veri silinmeye adaydır. Cevap "itiraz halinde kanıt", "vergi yükümlülüğü" veya "dolandırıcılık tespiti" ise net bir süre çıkar ortaya.
Ayrımın kritik noktası şudur: mali kayıt ile operasyonel iz aynı şey değildir. Siparişin tutarı, tarihi, fatura bilgisi uzun yıllar durmalıdır. Ama o siparişi oluşturan tarayıcı bilgisi, IP, oturum kimliği, ham webhook gövdesi haftalar mertebesinde bir ömre sahiptir. Teslim edilen e-pin kodunun kendisi ise en hassas kalemdir: müşteri onayladıktan ve itiraz penceresi kapandıktan sonra açık halde tutmanın hiçbir iş gerekçesi yoktur; maskelenmiş son dört hanesi kanıt için fazlasıyla yeterlidir.
| Veri türü | Saklama gerekçesi | Önerilen süre | Süre sonunda |
|---|---|---|---|
| Sipariş başlığı (tutar, tarih, müşteri no) | Mali kayıt, muhasebe | 10 yıl | Arşiv tablosuna taşı |
| Teslim edilen kod (açık hali) | İtiraz kanıtı | 60-90 gün | Maskele, son 4 haneyi bırak |
| Ödeme sağlayıcı webhook gövdesi | Mutabakat, chargeback | 180 gün | Özetle, gövdeyi sil |
| Giriş ve oturum logları | Güvenlik incelemesi | 90 gün | Kalıcı sil |
| API istek-yanıt izleri | Hata ayıklama | 14-30 gün | Kalıcı sil |
| Terk edilmiş sepet / tamamlanmamış sipariş | Pazarlama, dönüşüm analizi | 30 gün | Anonimleştir |
| Kapatılmış destek talebi | Tekrarlayan şikâyet takibi | 2 yıl | Arşivle |
Silmek mi, arşivlemek mi, maskelemek mi? Üçü aynı şey değil
Panellerde en sık yapılan hata "temizlik" denince her şeyi DELETE ile uçurmaktır. Oysa üç ayrı işlem vardır ve her veri türü bunlardan birine denk gelir. Arşivleme, kaydı sıcak tablodan çıkarıp ayrı bir tabloya veya dosyaya almaktır; performans kazanırsın, veri durmaya devam eder. Maskeleme, kaydı tutar ama hassas alanı okunamaz hale getirir; kanıt izi kalır, risk kalmaz. Silme ise geri dönüşü olmayan işlemdir ve yalnızca gerçekten gereksiz operasyonel izler için uygundur.
İyi kurgulanmış bir e-pin yazılımı bu üçünü zamanlanmış görevlerle sırayla uygular: önce soğutma, sonra maskeleme, en son silme. Ve her adımı kendi log'una yazar. Kulağa aşırı titiz gelebilir ama bir gün "o kaydı kim sildi" sorusu geldiğinde bu izin varlığı seni kurtarır. Pinova'da bu zincir ürün ve işlem türü bazında ayrı ayrı tanımlanabiliyor; detayları özellikler bölümünde görebilirsin.
Bir yıllık panelde veri hacminin dağılımı
- Sistem ve API logları 45%
- Ödeme ve webhook kayıtları 25%
- Sipariş ve stok verisi 20%
- Destek, mail, diğer 10%
İtiraz penceresi: süreyi belirleyen görünmez takvim
Dijital üründe en pahalı senaryo, müşterinin kodu kullandıktan sonra "ürün gelmedi" diyerek ödeme itirazı açmasıdır. Bu tartışmayı kazanmanın tek yolu, teslimatın zaman damgalı ve değiştirilemez kaydıdır: kodun hangi saniyede ayrıldığı, hangi oturuma gösterildiği, mailin hangi adrese iletildiği ve varsa kodun kullanıldığına dair tedarikçi geri bildirimi.
Bu yüzden saklama süresini belirlerken keyfi bir sayı yazmak yerine çalıştığın ödeme sağlayıcısının itiraz penceresini baz almalısın. Pencere 90 gün ise teslimat kanıtını 120 gün tut; pencere 180 gün ise 210. Aradaki fark senin güvenlik payındır. Çünkü itiraz bildirimi genelde son güne yakın gelir ve cevap için birkaç günün olur. Kanıtın tam o hafta temizlenmişse, tutarı da komisyonu da cezayı da sen ödersin.
Yeni saklama politikasını canlıya alırken önce rapor modunda çalıştır: "şu kurallarla kaç satır silinecek" listesini al, gözden geçir, sonra uygula. İlk çalıştırmada yıllık birikim bir anda gittiği için veritabanı kilitlenebilir; parti parti, gece dilimlerinde ilerle.
KVKK tarafında seni zorlayan asıl soru ne?
Kişisel veri mevzuatının ruhu tek cümlede özetlenebilir: veriyi topladığın amaç ortadan kalktıysa elinde tutamazsın. Bu, e-pin satıcısı için çok somut sonuçlar doğurur. Üç yıl önce bir kez alışveriş yapmış, bir daha dönmemiş bir müşterinin telefon numarasını, IP geçmişini ve tarayıcı parmak izini panelinde tutuyorsan açıklaman gereken bir durum var.
İkinci ve daha sık atlanan konu, silme talebine verilecek cevaptır. Müşteri hesabının silinmesini istediğinde mali kaydı silemezsin ama kişiyle bağını koparabilirsin. Doğru davranış, sipariş satırını tutup kimlik alanlarını anonim bir referansla değiştirmektir. Bunu elle yapmak imkânsızdır; dijital ürün satış scripti düzeyinde tek tuşla çalışan bir anonimleştirme akışı gerekir. Ayrıca sadece canlı veritabanını değil yedekleri de hesaba katmalısın: yedek saklama süresi ana politikadan uzunsa, sildiğini sandığın veri aylarca dosyalarda yaşamaya devam eder.
Kurulumdan önce neye bakacaksın? Kontrol listesi
Aşağıdaki tabloyu yeni panel kurarken ya da mevcut kurulumunu denetlerken satır satır geç. Her satırda "var" diyemiyorsan orada bir risk birikiyor demektir. Fiyatlandırmaya göre hangi paketin hangi otomasyonu getirdiğini fiyat bölümünden karşılaştırabilirsin.
| Kontrol | Neden önemli | Durum |
|---|---|---|
| Veri türü bazında ayrı süre tanımı | Tek genel süre ya çok siler ya hiç silmez | Zorunlu |
| Zamanlanmış otomatik temizlik görevi | Elle temizlik hiçbir zaman düzenli yapılmaz | Zorunlu |
| Kod maskeleme (son 4 hane) | Kanıt kalır, hassas veri riski gider | Zorunlu |
| Silme işleminin kendi denetim izi | "Kim ne zaman sildi" sorusuna cevap | Zorunlu |
| Rapor / kuru çalıştırma modu | İlk çalıştırmada kaza önler | Önerilir |
| Arşiv tablosuna taşıma | Sıcak tablo küçük kalır, panel hızlanır | Önerilir |
| Müşteri talebiyle anonimleştirme | Yasal silme talebine uyum | Zorunlu |
| Yedek saklama süresinin politikayla hizası | Sildiğin veri yedekte yaşamasın | Önerilir |
| Parti parti (batch) silme | Canlı satışta kilitlenmeyi önler | Önerilir |
Doğru kurgu paneli nasıl hafifletir?
Saklama politikasını düzgün kuran bayilerde ilk fark edilen şey hız olur. Sipariş listesi, ciro raporu ve stok ekranı aynı sunucuda birkaç kat hızlanır; çünkü sorgular artık milyonlarca ölü satırın arasından geçmez. İkinci fark yedek sürelerinde görülür: gece dump'ı dakikalara iner, taşınma ve geri yükleme senaryoları gerçekten uygulanabilir hale gelir.
Üçüncü ve en değerli fark ise zihinseldir. Hangi verinin nerede, ne kadar durduğunu bildiğin an, gelen her itirazda, her destek talebinde ve her denetim sorusunda nereye bakacağını bilirsin. Epin yazılım tarafında olgunluk tam olarak burada başlar: panelin sana veri üretmesi değil, gereksiz veriyi kendi kendine temizlemesi.
Saklama politikasını tahmine bırakma
Pinova, veri türü bazında saklama süresi, otomatik maskeleme ve arşivleme akışlarını hazır getirir. Kendi kurulumun için doğru süreleri birkaç dakikada tanımla.
Teslim ettiğim e-pin kodlarını panelde süresiz tutmak sorun mu?
Evet, hem güvenlik hem uyum açısından sorunludur. Kod satıldıktan ve itiraz penceresi kapandıktan sonra açık halini tutmanın iş gerekçesi kalmaz. Doğrusu, itiraz süresinin bitiminde kodu maskeleyip son dört haneyi kanıt olarak bırakmaktır.
Logları kaç günde bir temizlemeliyim?
API ve hata izleri için 14-30 gün, giriş ve güvenlik logları için 90 gün yaygın ve makul bir aralıktır. Önemli olan süre değil, temizliğin elle değil zamanlanmış bir görevle düzenli çalışmasıdır.
Eski siparişleri silerim, cirom bozulmaz mı?
Sipariş başlığını silmemelisin. Yapılması gereken, mali kaydı arşiv tablosuna taşıyıp yanındaki operasyonel izleri temizlemektir. Böylece raporların tutarlı kalır, panel yine hafifler.
Müşteri hesabının silinmesini istedi ama faturası var, ne yapmalıyım?
Mali kaydı korur, kişiyi tanımlayan alanları anonim bir referansla değiştirirsin. Sipariş satırı tutar ve tarihle durmaya devam eder, ama artık bir kişiyle ilişkilendirilemez. Bu akışın yazılımda tek tuşla çalışması şart.
Veri saklama süresi, panelinin en sessiz ama en belirleyici ayarıdır: doğru kurduğunda kimse varlığını fark etmez, yanlış kurduğunda her şey aynı anda bozulur. Kendi rakamlarınla oynamak, süreleri veri türü bazında denemek ve otomatik temizliğin nasıl raporlandığını görmek istersen canlı demo üzerinden saklama politikası ekranını incele; ardından kurulum adımına geçtiğinde politikanı ilk günden doğru kurgulamış olursun.