Bir satıcı fiyat izleme ayarlarını yapar, tabloda güzel grafikler görür — ve aslında rakiplerinden çok daha ucuz olan bir ürünün fiyatını düşürmeye karar verir. Tanıdık bir durum mu? Sorun, izleme fikrinde değil, verilerin nasıl toplandığındadır. Fiyat kontrol sistemini yanlış bilgi kaynağına dönüştüren yedi hatayı inceliyoruz ve bunları pratikte nasıl düzeltebileceğinizi gösteriyoruz.
Fiyat izleme doğruluğu neden iş için kritiktir
Wildberries, Ozon, Avito ve Yandex.Market'teki rakip fiyat izleme, tek seferlik bir görev değil, sürekli bir süreçtir ve doğrudan kârlılığı etkiler. Veriler hatalarla toplanıyorsa, satıcı ya gereksiz yere fiyat kırıyor ya da rakiplerin daha pahalı olduğu yerlerde fiyatı artırma fırsatını kaçırıyor. 500-1000 SKU'luk bir katalogda bile %5-10'luk hatalı veriler, her ay binlerce ruble kayıp kâra dönüşmektedir.
Sorun, pazar yerlerinin otomatik veri toplamaya karşı aktif olarak korunmasıdır: bölgeye, cihaza, sipariş geçmişine bağlı olarak farklı fiyatlar gösterirler ve şüpheli etkinliği CAPTCHA'lar ve IP'nin geçici yasakları ile engellerler. İzleme sistemi bu mekanizmaları dikkate almazsa, gerçek piyasa fiyatlarını değil, çarpıtılmış bir tablo toplar — ve işletme sahte verilere dayanarak kararlar alır.
Aşağıda, en sık karşılaşılan belirli hataların analizi yer almakta, neden ortaya çıktıkları ve geliştirici çağırmadan nasıl düzeltileceği açıklanmaktadır.
Hata 1: IP rotasyonu olmadan veri toplama — engellemeler ve CAPTCHA'lar
En yaygın hata, izlemeyi tek bir statik IP adresi veya veri merkezi sunucusundan rotasyonsuz başlatmaktır. Wildberries ve Ozon, kısa bir süre içinde bir IP'den yüzlerce istek gördüğünde ya CAPTCHA göstermeye başlar ya da bilerek çarpıtılmış veriler (örneğin, "ürün mevcut değil" veya önbellekten eski fiyat) sunar ya da tamamen erişimi engeller.
Sonuç olarak, izleme sistemi ya hiç veri alamaz ya da kısmi veri alır — ve raporda birçok kişi "rakipte bu ürün yok" şeklinde yorumladığı boşluklar ortaya çıkar, oysa bu aslında platformdan gelen bir engellemedir.
Çözüm, her istek için otomatik rotasyon ile bir IP havuzu kullanmaktır. Pazar yerlerinde fiyat izleme görevleri için rezidans proxy'leri iyi bir seçenektir: gerçek internet kullanıcılarının IP adreslerini kullanır, bu nedenle platform için organik trafik gibi görünür, bot ağı gibi değil. Bu, rotasyonsuz veri merkezi adreslerine kıyasla CAPTCHA ve engellemelerin sıklığını onlarca kat azaltır.
| Proxy Türü | Uygun Olduğu Alanlar | Engellenme Riski |
|---|---|---|
| Veri merkezi proxy'si | Sert koruma olmayan küçük katalogların hızlı toplanması | Korunan platformlarda yüksek |
| Rezidans proxy'leri | Wildberries, Ozon, Avito için düzenli izleme | Düşük |
| Mobil proxy'ler | Mobil fiyat ve kampanyaların uygulamalarda kontrolü | Minimum |
Hata 2: Coğrafi konum ve bölgesel fiyatların göz ardı edilmesi
Wildberries ve Ozon, gönderim deposuna, teslimat bölgesine ve hatta belirli bir şehre bağlı olarak farklı fiyatlar gösterir. Bir ürün, Moskova'daki bir alıcı için 1200 ruble, Vladivostok'taki bir alıcı için 1450 ruble olabilir — bu, farklı lojistik ve bölgesel depolardaki mevcudiyetten kaynaklanır.
Eğer izleme tek bir bölgeye bağlı bir IP ile başlatılıyorsa, yalnızca o bölge için fiyat alırsınız ve bunu "rakip fiyatı" olarak yanlış bir şekilde kabul edersiniz. Bu, Rusya'nın birkaç bölgesinde satış yapan veya pazar yerinin farklı depolarıyla çalışan satıcılar için özellikle kritiktir.
Doğru yaklaşım, farklı şehirlerden alıcıları taklit ederek fiyatları birden fazla coğrafi noktadan toplamaktır. Bunun için, Rusya'nın belirli bölgelerine yönelik coğrafi hedefleme yapabilen proxy'lere ihtiyaç vardır. Şehir veya bölge seçme imkanı sunan rezidans proxy'leri, ülke genelinde fiyatların tam haritasını oluşturmayı sağlar, tek bir noktayla sınırlı kalmaz. Bu, lojistik maliyetlerinde büyük farklılık olan ürünler için özellikle önemlidir — giyim, büyük ev aletleri, mobilya.
Hata 3: Yanlış toplama sıklığı — eski veriler
Birçok kişi fiyat izlemeyi günde bir kez veya hatta birkaç günde bir başlatır, bunun yeterli olduğunu düşünür. Ancak Wildberries ve Ozon'daki rakipler, günde birkaç kez fiyat değiştirebilir — özellikle indirim dönemlerinde, "Günün Ürünü" kampanyalarında veya sadece birkaç saat süren flaş indirimlerde.
Eğer sisteminiz verileri günde bir kez topluyorsa, ya rakiplerin kısa süreli kampanyalarını kaçırıyorsunuz (ve bu sırada satış kaybediyorsunuz) ya da tam tersine — uzun zamandır geri dönen bir fiyata tepki veriyorsunuz ve gereksiz yere fiyat kırıyorsunuz.
Optimal sıklık, ürün kategorisine bağlıdır: yüksek rekabetçi nişler (elektronik, kozmetik, çocuk ürünleri) için her 2-4 saatte bir toplama önerilir, daha az dinamik kategoriler için günde 1-2 kez yeterlidir. Toplama sıklığını artırdıkça, altyapıya olan yük de artar — burada rezidans proxy'leri aracılığıyla IP rotasyonu zorunlu hale gelir, aksi takdirde sık istekler aynı adreslerden hızlı bir şekilde engellemeye yol açar.
Hata 4: Gerçek kullanıcı taklidi yapmama
Pazar yerleri yalnızca IP adresini değil, aynı zamanda davranışsal kalıpları da analiz eder: sayfalar arasında geçiş hızı, tarayıcı başlıklarının varlığı, çerezler, kullanıcı ajanı, fare hareketleri. Eğer istekler "doğrudan" gerçek bir tarayıcı taklidi olmadan geliyorsa, platform botu insandan kolayca ayırt eder ve koruma sayfaları veya çarpıtılmış içerik gösterir.
Kod yazmayan satıcılar için çözüm, hazır anti-detect tarayıcılar kullanmaktır: Dolphin Anty, AdsPower, Multilogin, Octo Browser. Bu araçlar, her profil için ayrı bir proxy adresi bağlayarak benzersiz dijital parmak izleri (fingerprint) ile profiller oluşturmayı sağlar. Böylece Wildberries'e fiyat kontrolü için giren her "sanal alıcı", benzersiz bir gerçek kişi gibi görünür, bot ağı parçası gibi değil.
Anti-detect tarayıcı + rezidans veya mobil proxy kombinasyonu, yalnızca reklam hesaplarını yönetmek için değil, aynı zamanda sürekli engellemeler olmadan güvenilir bir fiyat izleme sistemi kurmak için de kullanılan etkili bir şemadır.
Hata 5: Kişiselleştirme ve A/B fiyatlarının göz ardı edilmesi
Pazar yerleri, fiyat kişiselleştirmesini giderek daha fazla kullanıyor: aynı ürün, arama geçmişine, kişisel hesabınıza giriş yapmaya, sadakat programına katılmaya (örneğin, Wildberries Cüzdanı) veya hatta rastgele bir A/B fiyatlandırma testine bağlı olarak farklı fiyatlarla gösterilebilir.
Eğer izleme, yetkilendirilmiş bir hesapla veya satın alma geçmişi olan "ısıtılmış" bir profil ile başlatılıyorsa, indirimli kişiselleştirilmiş bir fiyat alabilirsiniz, bu da yeni bir alıcı için gerçek piyasa durumunu yansıtmaz. Ve tam tersi — eğer rakip, yalnızca abonelere özel gizli kampanyalar ayarlıyorsa, sıradan anonim bir tarama bunları göremez.
Maksimum nesnel bir tablo elde etmek için, iki toplama modunu birleştirmeniz önerilir: anonim (yetkilendirme olmadan, temiz profil) temel piyasa fiyatı için ve yetkilendirilmiş (test hesabı ile) kişisel teklifler ve sadakat kampanyalarını takip etmek için. Her iki mod da platformun bunları tek bir oturumda ilişkilendirmemesi için farklı, kesişmeyen IP havuzları kullanmalıdır.
Hata 6: Dinamik içerik ve JS-rendering sorunları
Wildberries ve Ozon'daki ürün kartları, JavaScript'e büyük ölçüde bağımlıdır: fiyat, stok, indirimler, sayfanın ilk yüklemesinden sonra dinamik olarak yüklenir. Eğer izleme aracı yalnızca başlangıç HTML'sini alıyorsa ve scriptleri çalıştırmıyorsa, genellikle boş alanlar veya dinamik indirimler uygulanmadan önce sayfanın önbelleğinde kaydedilmiş eski fiyatı görür.
Bu, "sepete eklerken fiyat" veya "promosyon kodu ile indirim" kampanyalarında özellikle belirgindir; nihai fiyat yalnızca sayfadaki belirli eylemlerden sonra oluşturulur. Basit bir istek, tam sayfa render'ı olmadan bu fiyatı göremez ve yanlış bir değer kaydeder.
Hazır çözümler (kod yazmadan) için bu sorun genellikle dinamik içerik yüklemesini dikkate alan özel pazar yeri tarama hizmetleri ile çözülür. Böyle bir hizmet seçerken, açıklamasında JS-rendering desteği ve "kampanya indirimleri dikkate alınarak güncel fiyatlar" belirtip belirtmediğini kontrol edin, yalnızca ürün kartındaki temel fiyatı değil.
Hata 7: Toplanan verilerin doğrulanmaması
Verilerin doğru bir şekilde toplanması durumunda bile hatalar kaçınılmazdır: ağ kesintileri, geçici engellemeler, pazar yerinin sayfa yapısındaki değişiklikler. Eğer izleme sisteminde toplanan değerlerin kontrol (doğrulama) aşaması yoksa, anormal veriler doğrudan rapora geçer ve fiyatlandırma kararlarını etkiler.
Klasik bir örnek: 2000 ruble olan bir ürün, raporda aniden 20 rubleye "düşer" — bu genellikle bir tarama hatasıdır (örneğin, paket yerine ölçü birimi fiyatı yakalanmıştır), rakipte gerçek bir indirim değildir. Anormal sapmalar için otomatik kontrol olmadan, bu tür hatalar gerçek bir fiyat kırılması olarak kolayca yanlış anlaşılabilir ve gereksiz bir fiyat savaşı başlatılabilir.
Basit bir doğrulama kuralı: eğer yeni fiyat, önceki kaydedilen değerden %50'den fazla bir fark gösteriyorsa, sistem kaydı "kontrol gerektiriyor" olarak işaretlemeli ve otomatik olarak fiyat karar modülüne iletmemelidir. Bu, veri toplama hatalarının çoğunu ortadan kaldıran temel bir filtredir.
Doğru fiyat izleme kontrol listesi
Rakip fiyat izleme sistemini başlatmadan veya gözden geçirmeden önce, aşağıdaki maddeleri kontrol edin:
- Statik veri merkezi adresi yerine rezidans veya mobil proxy'ler aracılığıyla IP rotasyonu kullanılıyor
- Veri toplama, satış coğrafyanıza uygun birden fazla bölgeden gerçekleşiyor
- Toplama sıklığı, ürün kategorisinin dinamiğine uygun (2 saatten günde 1 kez) olarak ayarlanmış
- İstekler, gerçek bir tarayıcıyı taklit ediyor (anti-detect tarayıcı veya fingerprint desteği olan bir hizmet aracılığıyla)
- Kişiselleştirmeyi dikkate almak için anonim ve yetkilendirilmiş veri toplama ayrımı var
- İndirimleri dikkate alarak nihai fiyatı almak için JS-rendering desteği var
- Raporlara geçmeden önce anormal fiyat sapmalarının otomatik doğrulaması ayarlanmış
- Veriler, yalnızca mevcut değerle değil, değişim geçmişiyle saklanıyor — bu, rakiplerin kalıplarını görmeye yardımcı olur
| Hata | Sonuç | Çözüm |
|---|---|---|
| IP rotasyonu yok | CAPTCHA'lar, engellemeler, veri kayıpları | Otomatik rotasyonlu rezidans proxy'leri |
| Coğrafi konumun göz ardı edilmesi | Diğer bölge için yanlış fiyat | Rusya'daki şehirler için coğrafi hedefleme yapan proxy'ler |
| Nadir toplama | Kısa süreli kampanyaların kaçırılması | Toplama sıklığını 2-4 saate artırma |
| Tarayıcı taklidi yok | Veri yerine koruma sayfaları | Her profil için anti-detect tarayıcı + proxy |
| Doğrulama yok | Raporlarda anormal fiyatlar | Sapmaların otomatik kontrolü |
Sonuç
Wildberries, Ozon, Avito ve diğer pazar yerlerindeki rakip fiyat izleme, yalnızca veriler doğru ve düzenli toplandığında gerçek fayda sağlar. Yukarıda açıklanan yedi hata — statik IP nedeniyle engellemeler, coğrafi konumun göz ardı edilmesi, yanlış toplama sıklığı, tarayıcı taklidi yapmama, fiyat kişiselleştirmesi, dinamik içerik sorunları ve doğrulama eksikliği — başlangıçta hemen hemen her satıcıda görülür, ancak tümü geliştiriciler olmadan düzeltilebilir.
Eğer fiyat izleme sisteminizi yeni ayarlıyorsanız veya mevcut verilerin şüpheli bir şekilde sabit veya tam tersine çok dağınık göründüğünü fark ediyorsanız, veri toplama altyapısını kontrol etmeye başlayın. Pazar yerlerinde düzenli bir katalog izleme için rezidans proxy'lerini denemenizi öneririz — bunlar engellenme riskini en aza indirir ve verileri sanki gerçek alıcılar topluyormuş gibi farklı bölgelerden toplamanızı sağlar. Mobil uygulamaların ve yalnızca mobil trafiğe özel kampanyaların mobil versiyonlarını kontrol etmek için ise mobil proxy'leri düşünmelisiniz — bunlar, masaüstü versiyonunun farklı bir tablo sunduğu senaryolarda verilerin güvenilirliğine ek bir düzey sağlar.