Çoğu e-pin satıcısı bayi fiyatının panelde "gizli" olduğunu sanır. Bayi grubunu oluşturursun, o gruba özel indirimli fiyatı girersin, perakende müşteriye de normal etiketi gösterirsin. Ekranda her şey doğru göründüğü için mesele kapanmış kabul edilir. Oysa fiyat tek bir ekranda saklanmış olabilir; sistemin geri kalanında hâlâ serbestçe dolaşıyordur. Ürün listesini besleyen JSON çıktısında, önbelleğe alınmış sayfa kopyasında, arama önerisinde, XML ürün akışında, hatta "sepete ekle" isteğinin döndüğü yanıtta aynı rakam açık açık durur.
Bu yüzden sızıntıyı fark ettiğin an genelde geç olur: bir perakende müşteri sana ekran görüntüsü atar, "ben bunu 58 liraya alıyorum ama senin sistemde 41 lira yazıyor" der. O andan sonra tüm perakende marjın pazarlık masasına düşer. Doğru kurulmuş bir e-pin satış scripti fiyatı gizlemez, fiyatı hesaplamaz: yetkisi olmayan bir oturum için bayi fiyatı hiç üretilmez, dolayısıyla hiçbir katmandan da kaçamaz. Aşağıda bu farkı adım adım açıyorum.
Fiyatı gizlemekle fiyatı üretmemek aynı şey mi?
Değil, ve bütün sorun buradan çıkıyor. Pek çok epin yazılım kurulumunda mantık şöyle işler: sistem önce tüm fiyat katmanlarını hesaplar, sonra şablonda "kullanıcı bayi mi?" diye sorar ve değilse indirimli satırı basmaz. Yani veri zaten üretilmiştir, sadece ekrana yazılmamıştır. Üretilen her veri bir yerde iz bırakır: şablona giden değişken dizisi, sayfa altındaki JavaScript nesnesi, sepet hesaplayıcısına gönderilen ara toplam, log dosyası.
Doğru yaklaşım, yetkilendirmeyi sorgu katmanına indirmektir. Kullanıcının fiyat grubu oturum açıldığı anda belirlenir; ürün sorgusu yalnızca o gruba ait fiyatı çeker. Perakende müşterinin oturumunda bayi fiyatı diye bir alan yoktur. Bu tasarım farkı, sızıntıyı bir "dikkat konusu" olmaktan çıkarıp yapısal olarak imkânsız hale getirir. Bir dijital ürün satış scripti değerlendirirken sorman gereken soru "bayi fiyatını gizliyor mu?" değil, "yetkisiz oturumda bayi fiyatını hiç sorgulamıyor mu?" olmalı. Pinova'nın fiyat katmanı tam olarak bu prensip üzerine kurulu; ayrıntıları özellikler bölümünde görebilirsin.
Sızıntının asıl adresi neresi: sayfa mı, önbellek mi?
Saha tecrübesi şunu gösteriyor: sayfa HTML'i genelde temizdir, çünkü herkes önce oraya bakar. Sızıntı ikinci ve üçüncü halkada olur. En sık görülen üç adres: tam sayfa önbelleği, ürün akışı dosyaları ve otomatik tamamlama uçları. Önbellek, bayi oturumuyla üretilmiş bir sayfayı diske yazar; sonraki ziyaretçi kim olursa olsun aynı kopyayı görür. Tek bir bayi ziyareti, saatlerce herkese indirimli fiyat gösterebilir.
Ürün akışı tarafı daha sinsidir. Fiyat karşılaştırma sitelerine ya da reklam platformlarına gönderdiğin XML/CSV dosyasını genelde "en iyi fiyat" ile beslersin ki rekabetçi görünsün. O dosya çoğu zaman kimlik doğrulaması olmadan açıktır ve arama motorlarına düşer. Otomatik tamamlama uçları ise hız için ayrı bir tablo kullanır; o tabloya fiyat yazıldıysa yetki kontrolü es geçilmiş demektir. Aşağıdaki tabloda her kanalın risk profilini çıkardım.
| Sızıntı kanalı | Görünürlük | Tespit zorluğu | Kalıcı çözüm |
|---|---|---|---|
| Sayfa HTML'i | Yüksek | Kolay | Sorgu katmanında grup filtresi |
| JSON / AJAX yanıtı | Orta | Orta | Uçta oturum grubu doğrulaması |
| Tam sayfa önbelleği | Yüksek | Zor | Fiyat grubuna göre önbellek anahtarı |
| XML / CSV ürün akışı | Çok yüksek | Zor | Token'lı erişim + perakende fiyat |
| Arama önerisi tablosu | Düşük | Çok zor | Öneri verisinden fiyatı çıkarmak |
| Sipariş / fatura PDF'i | Orta | Orta | Rastgele dosya adı + yetki kontrolü |
| Hata ve sorgu logları | Düşük | Çok zor | Log maskeleme, erişim kısıtı |
Bayi kendi fiyatını paylaşırsa ne yapacaksın?
Teknik sızıntıyı kapattın diyelim. İkinci cephe insan cephesi. Bayin, aldığı fiyatı bir forumda, sohbet sunucusunda ya da mesaj grubunda paylaşır. Bunu tamamen engelleyemezsin ama izlenebilir hale getirebilirsin. Yöntem şu: her bayiye teknik olarak aynı ama görünürde farklı fiyat kuyruğu ver. 41,00 yerine 41,03 ve 41,07 gibi kuruş farkları kullan. Bir ekran görüntüsü dolaşıma girdiğinde kaynağı saniyeler içinde bulursun.
İkinci önlem, bayi sözleşmesine "fiyat gizliliği" maddesi koymak ve panelde bu maddeyi oturum açarken onaylatmak. Onay kaydı zaman damgalı tutulursa, ihlal durumunda bayilik iptalini tartışmasız hale getirir. Üçüncü önlem, indirimin tamamını fiyata değil ciro primine yansıtmak: bayiye perakendeye yakın bir fiyat ver, ay sonunda hacim üzerinden prim öde. Böylece sızacak bir "düşük fiyat" kalmaz, sadece bir prim oranı kalır ve o rakam müşterin için anlamsızdır.
Bayi fiyatı sızıntısının gerçek kaynakları
- API ve önbellek katmanı 45%
- Bayinin kendi paylaşımı 25%
- Ürün akışı ve dosyalar 20%
- Personel ve manuel teklif 10%
Çok katmanlı fiyat mimarisi nasıl kurulur?
Sağlam bir e-pin satış yazılımı fiyatı tek bir sütunda tutmaz. Doğru model üç seviyelidir: temel maliyet, grup kuralı, kampanya kuralı. Temel maliyet tedarikçiden gelen alış fiyatıdır ve hiçbir ön yüz sorgusunda görünmez. Grup kuralı, yüzde ya da sabit tutar olarak maliyetin üzerine biner. Kampanya kuralı ise grup kuralının çıktısına uygulanır ve süreli çalışır.
Bu yapının en büyük faydası şudur: fiyatı elle güncellemezsin, kuralı güncellersin. Tedarikçi zam yaptığında tek alanı değiştirirsin, 400 ürünün 6 bayi grubundaki fiyatı aynı anda doğru olur. Elle güncellenen sistemlerde sızıntının bir numaralı nedeni de budur zaten: birisi yanlış sütuna yazar, perakende etiketi bayi fiyatı olur ve kimse haftalarca fark etmez. Kural tabanlı mimaride yanlış sütun diye bir şey yoktur. Fiyat planlarını incelerken kaç fiyat grubu desteklendiğine ve kuralların üst üste binip binmediğine mutlaka bak.
Tarayıcında gizli pencere aç, hiç giriş yapmadan ürün listesinin JSON ucunu çağır ve yanıtı kaydet. Sonra bir bayi hesabıyla aynı ucu çağır. İki yanıtta ortak hiçbir fiyat alanı bulunmuyorsa mimarin doğrudur; bulunuyorsa sızıntın vardır.
Sızıntıyı fark ettiğin gün ilk 60 dakikada ne yapmalısın?
Panik kararı en pahalıya gelir. Sırasıyla ilerle: önce önbelleği tamamen temizle, çünkü en geniş yayılım oradadır. İkinci adım, açık ürün akışı dosyalarını erişimden kaldır ve arama motoru önbelleğinden silinme talebi gir. Üçüncü adım, hangi ürünlerin sızdığını tespit et ve o ürünlerin perakende fiyatını düşürmek yerine paket haline getir; müşteri kıyaslayacak birebir bir kalem bulamaz.
Dördüncü adım iletişim. Sızıntıyı gören müşteriye "o fiyat 500 adet üzeri toptan alımın fiyatı" demek, hem doğruysa hem belgelenebiliyorsa itirazı bitirir. Bu yüzden panelinde minimum bayi alım eşiği tanımlı olmalı; eşik varsa açıklaman inandırıcıdır, yoksa savunmada kalırsın. Son adım: aynı sızıntının tekrarını engelleyecek kontrolü kod tarafına kalıcı olarak yaz ve haftalık otomatik teste bağla.
Hangi kontrolleri ayda bir çalıştırmalısın?
Fiyat güvenliği tek seferlik bir iş değil; her yeni entegrasyon, her yeni ödeme sağlayıcısı, her yeni rapor ekranı yeni bir sızıntı yüzeyi açar. Bu yüzden kontrolü listeye bağlayıp ayda bir tekrar etmek gerekir. Aşağıdaki tabloyu panelinin yanına asabileceğin bir denetim listesi olarak hazırladım.
| Kontrol | Nasıl yapılır | Sıklık | Kritiklik |
|---|---|---|---|
| Misafir JSON yanıtı | Gizli pencerede uç çağrısı, fiyat alanı taraması | Aylık | Çok yüksek |
| Önbellek anahtarı | Bayi girişi sonrası misafir sayfası karşılaştırması | Aylık | Çok yüksek |
| Ürün akışı erişimi | Token'sız indirme denemesi | Aylık | Yüksek |
| Fatura/PDF yetkisi | Başka kullanıcının dosya adıyla erişim denemesi | Aylık | Yüksek |
| Kuruş imzası | Bayi bazlı fiyat kuyruklarının doğrulanması | Üç aylık | Orta |
| Personel yetkisi | Fiyat görebilen hesapların listelenmesi | Aylık | Yüksek |
| Log maskeleme | Son 1000 satırda fiyat araması | Üç aylık | Orta |
| Bayi sözleşme onayı | Onay kayıtlarının eksiksizliği | Altı aylık | Orta |
Fiyat katmanını yapısal olarak kapat
Pinova, bayi ve perakende fiyatını ayrı sorgu yolunda tutar; yetkisiz oturumda indirimli fiyat hiç üretilmediği için sızacak veri kalmaz. Kural tabanlı fiyatlandırma, grup bazlı önbellek ve token'lı ürün akışı kutudan çıkar.
Bayi fiyatını sadece şablonda gizlemek yeterli değil mi?
Hayır. Şablonda gizlemek, verinin üretilmesini engellemez. Aynı fiyat AJAX yanıtında, önbellek kopyasında veya ürün akışında görünmeye devam eder. Yetkilendirme sorgu katmanında olmalı.
Kuruş imzası müşteriye tuhaf görünür mü?
Görünmez, çünkü sadece bayi fiyatlarında kullanılır ve fark 1-9 kuruş düzeyindedir. Perakende etiketler yuvarlak kalır. Buna karşılık bir ekran görüntüsünün kaynağını dakikalar içinde bulabilirsin.
Önbelleği tamamen kapatsam sorun çözülür mü?
Sızıntı çözülür ama site yavaşlar ve dönüşüm düşer. Doğru çözüm önbelleği kapatmak değil, önbellek anahtarına fiyat grubunu eklemek. Böylece her grup kendi kopyasını görür.
Bayi fiyatını hiç göstermeyip sadece prim vermek mantıklı mı?
Çoğu senaryoda evet. Tek fiyat ve ay sonu ciro primi modeli sızacak veriyi ortadan kaldırır, nakit akışını da rahatlatır. Bayilerin bir kısmı anlık indirim ister; iki modeli birlikte sunmak en dengeli çözüm.
Fiyat mimarisi, e-pin işinde marjı belirleyen tek görünmez kaldıraçtır: doğru kurulduğunda kimse konuşmaz, yanlış kurulduğunda her müşteri pazarlık yapar. Kendi panelinde bugün beş dakikalık sızıntı testini çalıştır, sonucu bir yere yaz ve grup bazlı fiyatlandırmanın gerçekten sorgu katmanında çalıştığı bir sistemin nasıl davrandığını görmek için canlı demo üzerinden bayi ve perakende hesapları yan yana dene; farkı ilk tıkta anlarsın.