Çoğu kişi kurulumu bitirdiğinde işin bittiğini sanır. Ürünler girildi, ödeme tanımlandı, tema seçildi, alan adı yönlendirildi. Oysa kurulumdan sonra geriye en kritik iş kalır: demo verisini temizlemek. Bu, kozmetik bir düzenleme değildir. Arkada kalan bir test siparişi raporlarını bozar, unutulan bir test e-pin kodu gerçek bir müşteriye gidebilir, silinmemiş bir test kullanıcısı ise panelinde açık bir kapı bırakır.
Demo verisi ürünün suçu değildir; aksine iyi bir e-pin scripti, sistemi anlamanı sağlamak için örnek kayıtlarla gelir. Sorun, bu kayıtların canlıya geçişte arkada unutulmasıdır. Üstelik en tehlikelileri vitrinde görünenler değil, veritabanında sessizce duranlardır. Bu yazıda hangi kayıtların hangi sırayla temizleneceğini, hangilerinin asla silinmemesi gerektiğini ve canlıya geçmeden önce yapılması gereken son testleri anlatıyorum.
Demo verisi neden sadece görüntü meselesi değil?
Test verisi sistemin her katmanına dağılır. Bir demo siparişi yalnızca sipariş tablosunda durmaz; bakiye hareketi oluşturur, stok düşer, fatura numarası tüketir, rapor toplamlarına girer ve bazen bildirim kuyruğunda bekler. Bunları tek tek silmeden canlıya geçtiğinde ilk ayın ciro raporu daha baştan yanlış çıkar. Yanlış rapor, kötü karar üretir; çünkü hangi ürünün gerçekten sattığını göremezsin.
İkinci boyut güvenliktir. Kurulum sırasında oluşturulan örnek yönetici veya bayi hesapları çoğunlukla tahmin edilebilir şifrelerle gelir. Bunlar silinmediğinde, dijital ürün satış yazılımının en hassas bölümüne açık bir davetiye bırakmış olursun. Aynı şey test amaçlı açılmış API anahtarları, webhook adresleri ve sandbox ödeme tanımları için de geçerlidir. Canlı ortamda duran her test kaydı, potansiyel bir olay kaydıdır.
Hangi kayıtlar silinmeli, hangileri kalmalı?
Temizlik körlemesine silme değildir. Bazı demo kayıtları aslında yapı taşıdır: varsayılan kategori ağacı, para birimi tanımları, vergi ayarları, e-posta şablonları ve dil dosyaları genelde örnek içerikle gelir ama silinmesi değil düzenlenmesi gerekir. Bunları silmek sistemi bozar; içeriklerini kendi işletmenle değiştirmek ise doğru hamledir.
Silinmesi gerekenler ise hareket kayıtlarıdır: test siparişleri, test ödemeleri, test bakiye yüklemeleri, örnek e-pin stokları, demo kullanıcılar, örnek kuponlar, test destek talepleri, sahte yorum ve değerlendirmeler, bir de kurulum sırasında oluşan log kayıtları. Bu ayrımı yaparken temel kural şudur: bir kayıt bir olayı temsil ediyorsa sil, bir yapılandırmayı temsil ediyorsa düzenle.
| Veri türü | İşlem | Risk seviyesi | Unutulursa ne olur |
|---|---|---|---|
| Test siparişleri | Sil | Orta | Ciro raporu ve sayaçlar şişer |
| Örnek e-pin kodları | Sil | Yüksek | Gerçek müşteriye geçersiz kod gider |
| Demo kullanıcı hesapları | Sil | Yüksek | Zayıf şifreli erişim açık kalır |
| Sandbox ödeme tanımı | Kapat / değiştir | Kritik | Ödeme alınır ama para gelmez |
| Test kuponları | Sil | Orta | Sızarsa indirimli satış zinciri |
| Örnek yorumlar | Sil | Düşük | Güven kaybı, sahte izlenimi |
| Kategori ve vergi ayarları | Düzenle | — | Silinirse yapı bozulur |
| E-posta şablonları | Düzenle | — | Müşteriye demo metni gider |
| Kurulum log kayıtları | Arşivle / sil | Düşük | Gereksiz yer ve karışıklık |
Test e-pin kodu tuzağı tam olarak nasıl işliyor?
En sinsi hata budur. Kurulum sırasında bir ürüne beş adet örnek kod eklersin, çalıştığını görürsün, sevinirsin ve o ürünü olduğu gibi bırakırsın. Sonra gerçek stoğunu aynı ürüne yüklersin. Sistem stok sırasına göre teslimat yaptığı için ilk gerçek müşteriye gidecek olan kod, senin yazdığın TEST-0001 olur. Müşteri kodu girer, çalışmaz, destek açar, güveni sarsılır ve ilk yorum olumsuz gelir.
Bu tuzaktan kurtulmanın yolu basittir: gerçek stok yüklemeden önce ilgili ürünün stok listesini tamamen boşalt, ardından yükle ve ilk kaydın ne olduğunu gözünle doğrula. Ek olarak, test kodlarını yazarken baştan ayırt edilebilir bir önek kullan; böylece arama yaparak hepsini tek seferde bulabilirsin. Bir e-pin satış scriptinde otomatik teslimat, doğru çalıştığı için tehlikelidir; yanlış veriyi de aynı hızla teslim eder.
Canlıya geçişte yaşanan sorunların kaynak dağılımı
- Temizlenmemiş test stoğu 38%
- Ödeme yapılandırma hatası 28%
- E-posta ve bildirim ayarı 22%
- Yetki ve hesap artıkları 12%
Temizliğe başlamadan önce hangi yedeği almalısın?
Silme işlemi geri alınamaz. Bu yüzden temizliğe başlamadan önce iki ayrı yedek al: birincisi veritabanının tam dökümü, ikincisi dosya sisteminin kopyası. İkisini aynı sunucuda değil, farklı bir yerde sakla. Yedek almadan yapılan bir toplu silme işlemi, yanlış bir koşul yüzünden kategori ağacını veya ürün kayıtlarını da götürebilir ve o noktada kurulumu baştan yapmaktan başka çaren kalmaz.
Yedeğin sadece alınmış olması yetmez, geri yüklenebilir olduğunu da doğrulamalısın. Yedek dosyasının boyutuna bak, sıkıştırılmış dosyayı aç, içindeki tablo sayısını kontrol et. Sıfır baytlık veya yarım kalmış bir döküm, olmayan yedekten daha tehlikelidir; çünkü sana yanlış bir güven duygusu verir ve riskli işlemleri rahatça yapmanı sağlar.
Siparişleri silmek yeterli değildir. Sipariş ve fatura numarası sayaçlarını da başlangıç değerine çek; aksi halde ilk gerçek siparişin numarası 1 yerine 87 olarak başlar ve muhasebe tarafında açıklaması zor bir boşluk oluşur.
Canlıya geçmeden yapılması gereken son testler neler?
Temizlik bitince sistem boş görünür ama çalıştığı kanıtlanmamıştır. Bu yüzden canlı ortamda kontrollü tek bir gerçek test yapmalısın: düşük tutarlı bir ürün oluştur, gerçek ödeme yöntemiyle kendi kartından satın al, kodun geldiğini doğrula, e-postanın spam'e düşmediğini kontrol et, ardından iade sürecini de işlet. Bu tek döngü, ödemeden teslimata kadar tüm zinciri aynı anda doğrular.
Testten sonra o ürünü ve o siparişi de temizlemeyi unutma; ama bu kez kayıtları silmeden önce ekran görüntüsünü al. Böylece ileride bir sorun çıktığında sistemin canlıya geçerken doğru çalıştığına dair elinde kanıt olur. Son olarak arama motorlarına kapalı kalmış bir ayar, aktif kalmış bir bakım modu veya unutulmuş bir test alan adı yönlendirmesi olup olmadığını kontrol et; bu üçü, sitenin ilk hafta neden ziyaretçi almadığının en sık sebebidir.
| Adım | Yapılacak | Doğrulama yöntemi |
|---|---|---|
| 1 | Veritabanı + dosya yedeği al | Dosya boyutu ve içerik kontrolü |
| 2 | Test sipariş ve ödemelerini sil | Rapor ekranı sıfır göstermeli |
| 3 | Örnek stok kodlarını boşalt | Ürün stok listesi boş olmalı |
| 4 | Demo kullanıcı ve bayileri kaldır | Kullanıcı listesinde sadece gerçek hesaplar |
| 5 | Sayaçları sıfırla | Yeni sipariş numarası 1'den başlamalı |
| 6 | Ödeme tanımını canlıya al | Sandbox anahtarı kalmamalı |
| 7 | E-posta şablonlarını kendi metninle değiştir | Kendine test maili gönder |
| 8 | Gerçek ödemeyle uçtan uca test | Kod teslimi + mail + iade |
| 9 | Arama motoru ve bakım modu ayarı | Kaynak kodda noindex kontrolü |
Canlıya geçişi tahminle değil kontrol listesiyle yap
Pinova, e-pin ve dijital ürün satan işletmelerin stok, teslimat ve bayi süreçlerini tek panelden yöneten bir satış yazılımıdır.
Demo verisini toplu silmek güvenli mi?
Yedek aldıysan ve silinecek kayıtları önce listeleyip gözden geçirdiysen güvenlidir. Doğrudan toplu silme komutu çalıştırmadan önce aynı koşulla bir listeleme yapıp kaç kaydın etkileneceğini görmek en temel güvenlik önlemidir.
Sipariş numarası sayacını sıfırlamak zorunda mıyım?
Zorunlu değil ama şiddetle önerilir. Sayaç sıfırlanmazsa ilk gerçek siparişin yüksek bir numarayla başlar ve muhasebe kayıtlarında açıklanması gereken bir numara boşluğu oluşur.
Test için canlı ortamda gerçek ödeme yapmalı mıyım?
Evet, en az bir kez. Sandbox testleri ödeme sağlayıcısının canlı yapılandırmasını doğrulamaz. Düşük tutarlı tek bir gerçek işlem, ödemeden teslimata kadar tüm zinciri test etmenin en kesin yoludur.
Örnek ürün açıklamalarını kullanabilir miyim?
Kullanmamalısın. Hazır demo metinleri hem başka kurulumlarda da bulunduğu için özgün değildir hem de ziyaretçiye sitenin tamamlanmadığı izlenimi verir. Her ürün için kısa da olsa kendi metnini yaz.
Canlıya geçiş bir an değil, bir kontrol listesidir. Yedeği al, hareket kayıtlarını temizle, yapılandırmaları düzenle, sayaçları sıfırla ve tek bir gerçek işlemle zinciri baştan sona doğrula. Bu sırayı takip ettiğinde ilk gerçek müşterin, senin test ettiğin sistemin aynısıyla karşılaşır. Panelin bu adımları nasıl kolaylaştırdığını görmek istersen canlı demo üzerinden stok, teslimat ve raporlama ekranlarını inceleyebilir, özellikler bölümünden kurulum sonrası araçları, fiyat bölümünden de kapsamı değerlendirebilirsin.