Fiyat İzleme için Rotating Proxy

Fiyat ve rekabet izleme dışarıdan bakınca basit bir iştir: rakibin ürün sayfasını açar, fiyatı okur, kendi fiyatınızla karşılaştırırsınız. İş birkaç ürünle sınırlı kaldığında gerçekten de öyledir. Ama izlenen ürün sayısı binlere, rakip sayısı dörde, pazar sayısı ikiye çıktığında soru “fiyatı nasıl okurum” olmaktan çıkar; “her gün kaç istek göndereceğim, bunlar hedeflere nasıl yayılacak ve faturası ne olacak” sorusuna dönüşür. Fiyat izleme için rotating proxy bu ikinci sorunun erişim tarafını çözer: uygulamanız tek bir gateway adresine bağlanır, çıkış IP’si havuzdan atanır ve istekleriniz tek bir adresin üzerinde birikmez.

Bu sayfada izleme hattını üç değişken üzerinden kuruyoruz. Birincisi gözlem noktası sayısıdır: kendi SKU’larınızın rakiplerdeki karşılıklarının toplamı. 2.000 SKU’yu dört rakipte izliyorsanız 8.000 gözlem noktanız vardır ve her biri ayrı bir fiyat geçmişi taşır. İkincisi değişim hızıdır: her gözlem noktası aynı sıklıkla kontrol edilmeyi hak etmez ve bu sıklık tahminle değil, gözlenen değişim geçmişiyle belirlenmelidir. Üçüncüsü hedef başına hız bütçesidir: bir alan adına günde ne kadar istek göndermeyi makul gördüğünüz, rotasyondan bağımsız olarak bir turun ne kadar süreceğini belirler.

Bu üç değişkenin birlikte verdiği sonuç hem GB tüketimini hem tur süresini belirler. Aşağıdaki bölümler sırasıyla gözlem birimini, GB planını, tarama takvimini, hız dağıtımını, ürün ve ülke seçimini ve veri kalitesini ele alıyor. Sonda bir pilot planı, sorun giderme tablosu ve ilk tam turdan önce gözden geçirilecek kontrol listesi var. Örnek kodlar Python ile yazıldı ama mantık her dilde aynıdır.

Fiyatı nereden okuduğunuz, hem maliyeti hem de hedefe bindirdiğiniz yükü en çok etkileyen karardır. Ürün sayfası tek bir SKU için en eksiksiz bilgiyi verir: varyant fiyatları, stok, kargo koşulu, satıcı. Kategori ya da arama sonuç sayfası ise tek yanıtta onlarca ürünün fiyatını taşır ama genellikle daha az ayrıntıyla. İkisini aynı hatta birlikte kullanmak mümkündür ve büyük kataloglarda neredeyse zorunludur.

İki katmanlı gözlem şöyle çalışır. Liste sayfaları düzenli aralıklarla taranır ve her ürünün listedeki fiyatı bir önceki gözlemle karşılaştırılır. Fark yoksa ürün sayfasına hiç gidilmez. Fark varsa yalnız o SKU’nun ürün sayfası istenir ve değişim orada doğrulanır. Böylece ürün sayfası istekleri, katalog büyüklüğüyle değil değişen ürünlerin sayısıyla sınırlı kalır. Rotasyon burada ikinci bir fayda sağlar: doğrulama isteği tespit isteğinden farklı bir çıkış IP’sinden gider ve listedeki farkın önbellekten ya da tek bir ziyaretçiye gösterilen deneme sürümünden kaynaklanıp kaynaklanmadığını da görmüş olursunuz.

Liste sayfasını tetikleyici olarak kullanırken iki kural önemlidir. Birincisi, listede görünen fiyatı asla nihai kayıt saymayın; listeler çoğu zaman en ucuz varyantı, sepette uygulanacak indirimi ya da “başlayan fiyatlarla” ifadesiyle bir alt sınırı gösterir. İkincisi, liste sayfalarını sıralama ve sayfa başına ürün sayısı sabit tutularak isteyin. Sıralama “en çok satanlar” ya da kişiselleştirilmiş bir düzene bağlıysa, aynı ürün bir turda ikinci sayfada, sonraki turda üçüncü sayfada çıkar ve gözlem kaçar. Fiyata ya da ürün adına göre sabit bir sıralama seçeneği varsa onu kullanın ve filtreleri izlediğiniz ürünlerin yoğun olduğu kategorilere daraltın.

GB bazlı rotating paketlerde fatura doğrudan aktarılan veriye bağlıdır. Hesabın iskeleti tek satırdır: aylık GB yaklaşık olarak aylık istek sayısı ile ortalama yanıt boyutunun çarpımına, tekrar payının eklenmesiyle bulunur. Asıl iş, aylık istek sayısını gerçekçi kurmaktır. Aşağıdaki hesaplar üç farklı katalog büyüklüğü için yapıldı. Paket fiyatları RotatingProxy kataloğundan alındı; sayfa ağırlıkları, katman dağılımı ve değişim oranı ise varsayımdır ve kendi pilot ölçümünüzle değiştirilmelidir.

• Varsayım 1: Ürün sayfası yanıtı ortalama 200 KB’tır. Sıkıştırılmış HTML indirilir; görsel, betik ve yazı tipi dosyaları indirilmez.
• Varsayım 2: Liste sayfası yanıtı ortalama 350 KB’tır ve içinde izlediğiniz ürünlerden ortalama 24 tanesi bulunur.
• Varsayım 3: Orta ve büyük katalogda gözlem noktalarının yüzde 10’u sıcak katmanda (günde 6 gözlem), yüzde 30’u ılık katmanda (günde 2 gözlem), yüzde 60’ı soğuk katmandadır (iki günde 1 gözlem). Hibrit modelde katman, liste sayfası düzeyinde atanır.
• Varsayım 4: Hibrit modelde her gün gözlem noktalarının yüzde 3’ünde listede fark görülür ve bunlar ürün sayfasıyla doğrulanır.
• Varsayım 5: Tekrar deneme ve hata payı yüzde 15’tir. 1 GB = 1.000.000 KB, ay 30 gün kabul edilir.

Küçük katalog: 400 SKU’yu üç rakipte izleyen bir mağaza 1.200 gözlem noktasına sahiptir. Bu ölçekte hibrit modele gerek yoktur; her ürün sayfası günde bir kez okunur. 1.200 × 30 = 36.000 istek eder; 36.000 × 200 KB = 7,2 GB, yüzde 15 payla yaklaşık 8,3 GB.

Orta katalog: 5.000 SKU, üç rakip, 15.000 gözlem noktası. Yalnız ürün sayfasıyla katmanlı izleme günde 1.500 × 6 + 4.500 × 2 + 9.000 × 0,5 = 22.500 istek demektir; ayda 675.000 istek ve 135 GB, payla yaklaşık 155,3 GB. Hibrit modelde liste sayfası sayısı, katmandaki nokta sayısının 24’e bölünmesiyle bulunur: sıcak katmanda 63 sayfa günde 6 kez, ılık katmanda 188 sayfa günde 2 kez, soğuk katmanda 375 sayfa iki günde bir taranır. Bu, ayda 28.245 liste isteği ve yaklaşık 9,9 GB eder. Günde 450, ayda 13.500 doğrulama isteği 2,7 GB ekler. Toplam payla yaklaşık 14,5 GB olur.

Büyük katalog: 40.000 SKU, dört rakip, 160.000 gözlem noktası. Aynı katman oranlarıyla yalnız ürün sayfası modeli ayda 7.200.000 istek ve payla yaklaşık 1.656 GB üretir. Hibrit modelde ayda 300.060 liste isteği yaklaşık 105 GB, günde 4.800 doğrulama isteği ise ayda 28,8 GB tutar; toplam payla yaklaşık 153,9 GB.

Tablonun en dikkat çekici satırları ikinci ve sonuncusudur: 15.000 noktalı orta katalogu yalnız ürün sayfasıyla izlemek, on kat büyük katalogu hibrit modelle izlemekle hemen hemen aynı trafiği harcar. Fark proxy fiyatından değil, hiç gönderilmeyen isteklerden gelir. İkinci gözlem paket seçimiyle ilgilidir. IPv4 Datacenter’da 10 GB ile 500 GB arasındaki paketlerin hepsi GB başına 0,60 USD’ye denk gelir; 1.000 GB paketi ise 0,50 USD’ye iner. Paketlerde süre sınırı olmadığı için büyük katalogun hibrit tüketimiyle 1.000 GB paketi yaklaşık 6,5 ay yeter ve aynı 1.000 GB’ı 200 GB’lık paketlerle almaya göre 100 USD daha az ödersiniz. Residential tarafında kademe daha belirgindir: 10–200 GB arası GB başına 1,20 USD, 500 GB paketi 1,10 USD, 1.000 GB paketi 0,90 USD.

Tarama takvimini “önemli ürünler sık, diğerleri seyrek” diye elle kurmak başlangıç için yeterlidir ama hızla eskir. Bir ürünün fiyatının ne sıklıkla değiştiği, o ürünün sizin için ne kadar önemli olduğundan bağımsızdır. En çok sattığınız ürünün rakipteki fiyatı aylarca sabit kalabilir; uzun kuyruktaki bir aksesuarın fiyatı ise rakibin otomatik fiyatlama aracı yüzünden günde birkaç kez oynayabilir. Bu yüzden takvimi gözlemle yönetmek gerekir: her gözlem noktası kendi değişim geçmişine göre katman değiştirir.

Tablodaki aralıklar önceki bölümdeki hesaplarla aynıdır; kendi değerlerinizi kullandığınızda GB hesabını da yeniden yapın. İki ayrıntı takvimin sağlığını belirler. Birincisi, katman değişimi yalnız teyitli değişime bağlanmalıdır. Tek bir gözlemde görülen fark, ikinci bir gözlemle doğrulanmadan noktayı sıcak katmana taşırsa, ayrıştırma hataları takvimi şişirir ve kota boşa gider. İkincisi, aynı katmandaki noktaları aynı dakikaya planlamayın. Dört saatte bir taranacak 63 liste sayfasını tek seferde göndermek yerine dört saatlik pencereye yaymak, hedefe binen anlık yükü düşürür ve bir bağlantı sorunu yüzünden turun tamamen kaybolmasını önler.

Kampanya modu için en iyi kaynak kendi geçmiş kayıtlarınızdır. Bir yıl boyunca tuttuğunuz teyitli değişim kayıtları, rakiplerin fiyat hareketlerini hangi günlerde ve saatlerde yoğunlaştırdığını gösterir: büyük indirim günleri, sezon geçişleri ya da rakibin her hafta aynı saatte çalışan fiyat güncellemesi gibi. Bu örüntüyü bildiğinizde takvimi bütün yıl sık tutmak yerine yalnız o pencerelerde sıklaştırırsınız. Aşağıdaki kod, katman tablosunun sadeleştirilmiş ve sürekli bir sürümüdür; eşikleri tabloyla birebir aynı değildir. Teyitli değişimde aralık yarıya iner, üst üste üç değişmeyen gözlemde ikiye katlanır; alt ve üst sınır sıcak ve soğuk katmanın aralığıdır. Tablodaki gibi 14 günlük pencerede değişim saymak isterseniz kodu buna uyarlayabilirsiniz; her iki durumda da GB hesabını gözlediğiniz gerçek katman dağılımıyla yeniden yapın.

import random
from dataclasses import dataclass, field
from datetime import datetime, timedelta, timezone

EN_KISA = timedelta(hours=4)       # sıcak katman (varsayım)
BASLANGIC = timedelta(hours=12)    # yeni nokta ılık katmandan başlar
EN_UZUN = timedelta(hours=48)      # soğuk katman (varsayım)
SABIR = 3                          # aralığı uzatmadan önce değişmeyen gözlem sayısı


def simdi():
    return datetime.now(timezone.utc)


@dataclass
class GozlemNoktasi:
    sku: str
    hedef: str
    pazar: str
    aralik: timedelta = BASLANGIC
    sabit_sayac: int = 0
    teyitli_fiyat: int | None = None   # en küçük birimde: kuruş, sent
    sonraki: datetime = field(default_factory=simdi)

    def teyitli_gozlem(self, fiyat: int, kampanya: bool = False) -> None:
        """Yalnız iki gözlemle doğrulanmış fiyatla çağrılır."""
        if self.teyitli_fiyat is not None and fiyat != self.teyitli_fiyat:
            self.aralik = max(EN_KISA, self.aralik / 2)
            self.sabit_sayac = 0
        else:
            self.sabit_sayac += 1
            if self.sabit_sayac >= SABIR:
                self.aralik = min(EN_UZUN, self.aralik * 2)
                self.sabit_sayac = 0
        self.teyitli_fiyat = fiyat
        aralik = self.aralik / 2 if kampanya else self.aralik
        # Aynı katmandaki noktalar aynı dakikaya yığılmasın: yüzde 10 sapma
        sapma = aralik.total_seconds() * random.uniform(-0.1, 0.1)
        self.sonraki = simdi() + aralik + timedelta(seconds=sapma)


def zamani_gelenler(noktalar, limit):
    """Vadesi geçen noktaları en çok gecikmiş olandan başlayarak döndürür."""
    hazir = [n for n in noktalar if n.sonraki <= simdi()]
    hazir.sort(key=lambda n: n.sonraki)
    return hazir[:limit]

Rotating proxy’nin en sık yanlış anlaşılan yanı burada ortaya çıkar. Rotasyon, istekleri farklı çıkış IP’lerine dağıtır ve hedefin tek bir IP’ye uyguladığı sınıra takılmanızı önler. Ama hedefin sunucusu her IP’den gelen isteği aynı altyapıda işler: saniyede yirmi isteği yirmi farklı IP’den göndermek, hedef açısından yine saniyede yirmi istektir. Bu nedenle fiyat izleme hattında hız sınırı IP başına değil, alan adı başına tanımlanır. Rotasyonun işi, bu bütçenin içinde kalan trafiği tek bir adrese yığmamaktır.

Alan adı bütçesi, takvimin uygulanabilir olup olmadığını da gösterir. İki istek arasındaki en kısa süreyi bir alan adı için 10 saniye kabul ederseniz, o alan adına günde en fazla 8.640 istek gönderebilirsiniz; 5 saniyede bu sayı 17.280 olur. Bu değerler öneri değil, hesap için seçilmiş varsayımlardır. Hedefin kullanım koşulları bir hız belirtiyorsa ya da robots.txt dosyasında, standart dışı olsa da, bir Crawl-delay yönergesi varsa esas alınacak değer odur. Önceki bölümdeki senaryoları hedef başına günlük isteğe çevirdiğimizde tablo şöyle olur.

Tablo, hibrit modelin yalnız maliyeti değil hedefe binen yükü de düşürdüğünü gösteriyor. Büyük katalogu ürün sayfası üzerinden izlemek, hedef başına makul bir tempoda günün içine sığmıyor. Daha fazla IP ya da daha fazla paralel bağlantı bu açığı kapatmaz, çünkü sınır alan adının kendisidir. Böyle bir durumda doğru hamle temponun artırılması değil, gözlem biriminin ya da sıklığın değiştirilmesidir. Orta katalogun yalnız ürün sayfası satırı da sınırdadır: 10 saniyelik aralıkla gün neredeyse doluyor ve yeniden denemelere ya da geciken turlara yer kalmıyor.

Aşağıdaki kod bu ilkeyi uygular. Her alan adı için ayrı bir sıra tutulur; 429 yanıtında yalnız o isteği değil, bütün alan adını Retry-After süresi kadar durdurur ve temposunu kalıcı olarak yavaşlatır. 403 yanıtı yeniden denenmez. Toplam eşzamanlılık farklı alan adları arasında kullanılır.

import asyncio
import random
import time
from urllib.parse import urlsplit

import httpx

PROXY = "http://KULLANICI:ŞİFRE@GATEWAY:PORT"
VARSAYILAN_ARALIK = 10.0   # aynı alan adına iki istek arası saniye (varsayım)
OZEL_ARALIK = {}           # koşullarında hız belirten hedefler: {"alan.adi": saniye}
EN_FAZLA_DENEME = 3


class AlanSirasi:
    """Rotasyon çıkış IP adresini değiştirir; tempo ise alan adı başına tutulur."""

    def __init__(self, aralik):
        self.aralik = aralik
        self.kilit = asyncio.Lock()
        self.son = 0.0
        self.bayt = 0

    async def sira_bekle(self):
        async with self.kilit:
            hedef = self.son + self.aralik * random.uniform(1.0, 1.3)
            kalan = hedef - time.monotonic()
            if kalan > 0:
                await asyncio.sleep(kalan)
            self.son = time.monotonic()

    def duraklat(self, saniye):
        # Bütün alan adı Retry-After kadar durur, tempo kalıcı olarak yavaşlar
        self.son = max(self.son, time.monotonic() + saniye)
        self.aralik = min(self.aralik * 2, 300)


siralar = {}


def sira(url):
    alan = urlsplit(url).hostname or ""
    if alan not in siralar:
        siralar[alan] = AlanSirasi(OZEL_ARALIK.get(alan, VARSAYILAN_ARALIK))
    return siralar[alan]


async def getir(istemci, url):
    s = sira(url)
    for _ in range(EN_FAZLA_DENEME):
        await s.sira_bekle()
        try:
            yanit = await istemci.get(url)
        except httpx.ProxyError:
            return url, 407, None  # kimlik ya da whitelist hatası: yeniden deneme yok
        except httpx.TransportError:
            continue  # yeni bağlantı, büyük olasılıkla yeni çıkış IP adresi
        s.bayt += yanit.num_bytes_downloaded
        if yanit.status_code == 429:
            bekle = yanit.headers.get("Retry-After", "")
            s.duraklat(int(bekle) if bekle.isdigit() else 120)
            continue
        if yanit.status_code == 403:
            return url, 403, None  # yeniden deneme yok: hedefin kurallarını gözden geçir
        return url, yanit.status_code, yanit.text
    return url, None, None


async def tur(urller):
    limitler = httpx.Limits(max_connections=20, max_keepalive_connections=0)
    async with httpx.AsyncClient(
        proxy=PROXY,
        limits=limitler,
        timeout=httpx.Timeout(25.0, connect=10.0),
        headers={"Accept-Encoding": "gzip, deflate", "Accept-Language": "tr-TR,tr;q=0.9"},
        follow_redirects=True,
    ) as istemci:
        sonuc = await asyncio.gather(*(getir(istemci, u) for u in urller))
    for alan, s in siralar.items():
        print(alan, round(s.bayt / 1_000_000, 2), "MB")
    return sonuc

# Kullanım: asyncio.run(tur(["HEDEF_URL", ...]))

Koddaki iki ayar rotasyonla doğrudan ilgilidir. max_keepalive_connections=0 her isteğin yeni bir bağlantıyla gitmesini sağlar; gateway çıkış IP’sini bağlantı başına atıyorsa her istek farklı bir IP’den çıkar. Bağlantıyı açık tutan bir istemcide aynı bağlantıdan geçen istekler aynı IP’de kalabilir. Ürününüzde rotasyonun istek başına mı oturum başına mı yapılandırıldığını panelde kontrol edin. İkinci ayar num_bytes_downloaded değeridir: yanıtın sıkıştırılmış haliyle indirilen bayt sayısını verir ve GB tahmininizi gerçek ölçüme bağlar. Proxy tarafındaki sayaç istek başlıklarını ve bağlantı kurulumunu da içerebileceği için bu değeri alt sınır kabul edin.

Fiyat izlemede iş yükünün büyük kısmı durumsuzdur: her liste ya da ürün sayfası isteği kendi başına anlamlıdır ve önceki istekle bağı yoktur. Bu tür trafik için istek başına rotasyon en temiz modeldir. Bazı hedeflerde ise fiyat, sayfa açıldıktan sonra bir varyant seçimiyle ya da bölge tercihini tutan bir çerezle belirlenir; bu durumda birkaç isteğin aynı çıkış IP’sinden gitmesi gerekir. RotatingProxy kataloğunda IPv4 Datacenter istek başına veya oturum bazlı rotasyonla, IPv4 Residential ve Mobile sticky ve rotating oturum seçenekleriyle, IPv6 ürünleri ise oturum yapılandırmalı rotasyonla sunulur. Oturumun hangi parametreyle açıldığını ve ne kadar sürdüğünü panelde ve sipariş adımında kontrol edin.

Tablodaki birim maliyet aralıkları paket büyüklüğüne göre değişir. IPv4 Datacenter’da 2 GB’lık karşılama paketi 1 USD, 10 ile 500 GB arası paketler GB başına 0,60 USD, 1.000 GB paketi 0,50 USD’dir. IPv4 Residential’da karşılama paketi 2 GB için 2,5 USD, 1.000 GB paketi 900 USD’dir. Mobile’da fiyatlar 2 GB için 4 USD’den 1.000 GB için 2.100 USD’ye uzanır. Bütün GB bazlı paketler tek seferlik satılır ve süre sınırı yoktur; kota bitene kadar kullanılır.

Karma kullanımda maliyeti residential’e ayrılan trafiğin payı belirler. Büyük katalog hibrit senaryosunda dört hedeften birini residential’e ayırırsanız ve trafik hedeflere eşit dağılıyorsa, ayda yaklaşık 115,4 GB datacenter ve 38,5 GB residential trafik oluşur. 0,60 ve 1,20 USD’lik GB fiyatlarıyla bu, ayda yaklaşık 69,3 ve 46,2 USD, toplamda yaklaşık 115,4 USD eder. Bütün hattı aynı fiyat kademesinde residential’e taşımanın aylık karşılığı ise yaklaşık 184,7 USD’dir. Ürünü hedef bazında seçmek, hattın tamamını en zor hedefe göre fiyatlamaktan kurtarır.

Sınır ötesi satış yapan ya da birden fazla ülkede rakip izleyen ekipler için çıkış ülkesi, verinin kendisinin bir parçasıdır. Aynı ürün sayfası Türkiye’den açıldığında TL ve KDV dahil fiyat, Almanya’dan açıldığında euro ve farklı bir kargo koşulu gösterebilir. RotatingProxy’de IPv4 ürünlerin üçü de 180’den fazla ülkeyi kapsar; öne çıkan 15 ülke arasında Türkiye, Almanya, Birleşik Krallık, ABD, Hollanda, Polonya, Japonya, Hindistan ve Brezilya bulunur. IPv6 Datacenter 8, IPv6 Residential 9 ülkeyle sınırlıdır ve Türkiye iki listede de vardır. Ülkenin nasıl seçildiğini panelde kontrol edin.

Ülke seçimi tek başına yetmez, çünkü site ziyaretçinin pazarını birden fazla sinyalden çıkarır. Çıkış IP’sinin ülkesi, Accept-Language başlığı, önceki ziyaretten kalan bölge çerezi ve adresteki ülke yolu ya da alan adı birbiriyle çelişirse hangi sinyalin kazanacağı siteden siteye değişir. Kural basittir: bir gözlem için bu dört sinyali aynı pazara ayarlayın, çerezleri pazar başına ayrı tutun ve yönlendirme zincirinin sonunda ulaştığınız adresi kayda geçirin. Pazar başına ayrı bir istemci ve çerez deposu, yanlış ülke sürümüne düşen gözlemleri büyük ölçüde önler.

Para birimini tutarın yanındaki simgeden değil, sayfanın yapılandırılmış alanından ya da üç harfli para birimi kodundan okumak daha güvenlidir; aynı simge birden fazla ülkede kullanılır. Tutarları ondalık sayı yerine en küçük birim cinsinden tam sayı olarak saklamak, yuvarlama hatalarını önler ve iki gözlemin karşılaştırmasını basitleştirir. Ülkeler arası karşılaştırma gerekiyorsa kur dönüşümünü toplama katmanında değil raporlama anında yapın; toplanan kayıt, sayfada görülen ham tutarı ve para birimini değiştirmeden taşısın.

Bir fiyat izleme hattının başarısı kaç istek gönderdiğiyle değil, karar verilen anda elinizdeki verinin ne kadar güvenilir olduğuyla ölçülür. Bunu sezgiyle değil, her tur sonunda hesaplanan birkaç göstergeyle izlemek gerekir. Eşik değerlerini pilot ölçümünüzden çıkarın; aşağıdaki tanımlar hangi oranın neyi işaret ettiğini anlatır.

• Kapsam: Tur içinde geçerli fiyat elde edilen gözlem noktalarının planlanan noktalara oranı. Hedef bazında ayrı hesaplanır; tek bir hedefteki düşüş toplam ortalamada kaybolmasın.
• Tazelik: Her gözlem noktası için son geçerli gözlemin yaşı. Sıcak katmandaki bir noktanın son geçerli fiyatı 12 saati geçmişse, o nokta katmanının gerektirdiği tazelikte değildir.
• Ayrıştırma başarısı: 200 yanıtı alınan sayfalardan fiyatın okunabildiklerinin oranı. Ani düşüş çoğunlukla sayfa düzeninin değiştiğini gösterir.
• Teyit oranı: Listede görülen değişimlerden ürün sayfasında doğrulananların oranı. Düşük teyit oranı, liste sayfasında yanlış alanın ya da kupon fiyatının okunduğuna işaret eder.
• Çelişki oranı: Aynı SKU için kısa aralıkla alınan iki gözlemin farklı fiyat verdiği durumların oranı. Önbellek, deneme sürümü ya da yanlış ülke sürümünün işaretidir.

Rotasyon teyit adımını güçlendirir. Bir değişim yalnız bir kez görüldüyse ikinci gözlemi farklı bir çıkış IP’sinden ve aynı ülke ayarıyla yapın. İki gözlem aynı fiyatı verirse değişim kayda geçer; vermezse nokta çelişkili olarak işaretlenir ve bir sonraki turda yeniden kontrol edilir. Bu kural, bazı sitelerin farklı ziyaretçi gruplarına farklı fiyat gösterdiği durumlarda da işe yarar. Bir hedefte çelişki oranı sürekli yüksekse o hedefte tek bir “doğru fiyat” olmayabilir; raporda bunu açıkça belirtmek, yanlış bir otomatik fiyat kararından daha ucuzdur.

Göstergeleri hesaplayabilmek için her gözlemin aynı biçimde kaydedilmesi gerekir. Aşağıdaki kayıt, bu bölümde ve önceki bölümlerde geçen alanların hepsini tek yerde toplar.

{
  "sku": "KLS-2041-SYH",
  "hedef": "rakip-b",
  "pazar": "TR",
  "url": "HEDEF_URL",
  "son_url": "HEDEF_URL",
  "kaynak": "liste_sayfasi",
  "cikis_ip": "203.0.113.48",
  "cikis_ulkesi": "TR",
  "dil": "tr-TR",
  "ham_fiyat": "1.299,90 TL",
  "tutar_en_kucuk_birim": 129990,
  "para_birimi": "TRY",
  "vergi_dahil": true,
  "stok": "stokta",
  "http_kodu": 200,
  "aktarilan_bayt": 342118,
  "gozlem_zamani": "2026-10-14T06:12:09+03:00",
  "teyit": "bekliyor"
}

Kayıtta ham metin ile ayrıştırılmış tutar birlikte durur; bir ayrıştırma hatası sonradan fark edildiğinde geçmiş veriyi yeniden işleyebilirsiniz. Çıkış IP’si, çıkış ülkesi ve son adres, çelişkili gözlemleri incelerken ilk bakılacak alanlardır. aktarilan_bayt alanı ise GB tahminini SKU düzeyine indirir: hangi hedefin, hangi sayfa türünün kotayı tükettiğini bu alanın toplamından görürsünüz. teyit alanı bekliyor, teyitli ve çelişkili değerlerinden birini alır ve takvim kodu yalnız teyitli kayıtlarla beslenir.

Önceki bölümlerdeki hesapların hepsi beş varsayıma dayanıyor. Pilotun amacı bu varsayımları kendi hedeflerinizin gerçek değerleriyle değiştirmektir. IPv4 Datacenter’ın 2 GB’lık karşılama paketi, 200 KB’lık ürün sayfası varsayımıyla yaklaşık 10.000, 350 KB’lık liste sayfası varsayımıyla yaklaşık 5.700 isteğe yeter. Birkaç hedefte bir haftalık ölçüm için bu çoğu zaman yeterlidir; yetmezse 10 GB paketi 6 USD’dir.

1. Örneklem seçin: Her hedeften katalogu temsil eden, farklı kategorilerden gözlem noktaları ve bunları içeren liste sayfalarını seçin. Yalnız en çok satan ürünleri seçmek değişim oranını olduğundan yüksek gösterir.
2. Kuralları kayda geçirin: Her hedefin robots.txt dosyasını ve kullanım koşullarını okuyun; izin verilen yolları ve varsa belirtilen hızı pilot belgesine yazın. Resmi bir ürün akışı sunan hedefi pilota proxy kullanmadan dahil edin.
3. Tempoyu muhafazakâr başlatın: Alan adı başına geniş bir aralıkla başlayın ve pilot boyunca artırmayın. Amaç hızın sınırını bulmak değil, makul bir hızda ne kadar veri aktığını ölçmektir.
4. Sayfa ağırlığını ölçün: Her istek için indirilen bayt sayısını sayfa türüyle birlikte kaydedin; hedef ve sayfa türü başına ortalamayı ve en yüksek değerleri çıkarın.
5. Liste yoğunluğunu ölçün: Her liste sayfasında izlediğiniz ürünlerden kaç tanesinin bulunduğunu sayın. Bu değer 24’ün çok altındaysa hibrit modelin kazancı küçülür; filtreleri daraltmayı deneyin.
6. Değişim oranını ölçün: Pilot süresince her gün kaç noktada teyitli değişim gördüğünüzü kaydedin; hafta içi ve hafta sonu farkını ayrı not edin.
7. Kaliteyi ölçün: Kapsam, ayrıştırma başarısı, teyit ve çelişki oranlarını hedef bazında hesaplayın; kanarya SKU’ların doğru okunduğunu doğrulayın.
8. Planı yeniden hesaplayın: Ölçtüğünüz değerleri GB formülüne ve alan adı bütçesine koyun; paket büyüklüğünü ve ürün karışımını buna göre seçin.

Pilot sonunda elinizde iki sayı olmalıdır: aylık GB ihtiyacı ve hedef başına günlük meşgul süre. İlki paketi, ikincisi takvimin uygulanabilirliğini belirler. Biri bile beklenenin çok üstündeyse paketi büyütmeden önce gözlem birimini ve takvimi yeniden düşünün; çoğu zaman sorun kotada değil, gereğinden sık okunan sayfalardadır.

Fiyat izleme hattındaki sorunların çoğu sessizdir: hat çalışmaya devam eder ama yanlış ya da eksik veri üretir. Aşağıdaki tablo, rotasyonlu bir hatta en sık karşılaşılan belirtilerden yola çıkar.

Tablodaki ilk üç satır doğrudan proxy ile ilgili değildir ama rotasyonlu hatlarda daha sık görünür. İstekler farklı IP’lerden çıktığı için farklı önbellek düğümlerine ve farklı ziyaretçi gruplarına düşme ihtimaliniz artar; aynı sayfanın farklı sürümlerini görmeniz olağandır. Bu yüzden teyit kuralı rotasyonun doğal tamamlayıcısıdır: rotasyon erişimi dağıtır, teyit verinin tutarlılığını korur.

Rotasyon isteklerin hangi IP’den çıktığını değiştirir, hedefin kurallarını değiştirmez; hız sınırı, kullanım koşulları ve robots.txt aynı kalır. Her hedef için kullanım koşullarını ve robots.txt dosyasını okuyun; bu dosyanın biçimi RFC 9309 ile tanımlanmıştır. Otomatik erişime kapalı yolları listeden çıkarın ve hedefin sunduğu resmi bir ürün akışı ya da ortaklık programı varsa onu öncelikli kullanın.

Fiyat izlemeye özgü üç sınır daha vardır. Birincisi, fiyatı görmek için sepete ürün eklemeyin ve sipariş adımlarını otomatikleştirmeyin; bu, hedefin stok ve analitik verisini bozar ve çoğu sitenin koşullarına aykırıdır. Yalnız sepette görünen fiyatlar izleme kapsamının dışında kalır. İkincisi, CAPTCHA, doğrulama sayfası ya da parmak izi kontrolü gibi korumaları aşmaya çalışmayın; bu işaretler, o hedefte temponuzu ya da kapsamınızı yeniden düşünmeniz gerektiğini söyler. Üçüncüsü, toplanan veriyi amaçla sınırlayın: pazar yerlerinde bireysel satıcıların adları ve değerlendirme yazan kullanıcıların bilgileri kişisel veri niteliği taşıyabilir. KVKK’nın amaçla bağlantılı, sınırlı ve ölçülü işleme ilkesi gereği fiyat analizi için bu alanları toplamayın.

Son olarak, izleme verisini otomatik fiyatlamaya bağlıyorsanız kuralları rekabet hukuku açısından da değerlendirin. Rakip fiyatına kendiliğinden tepki veren kurallar, rakiplerle eşgüdüm izlenimi yaratacak biçimde tasarlanmamalıdır. Bu konuda hukuk danışmanınızın görüşünü almak, hattın teknik tasarımı kadar önemlidir.

Aşağıdaki maddelerin her biri, bu sayfada anlatılan bir hatanın önlemidir. İlk tam turu başlatmadan önce listeyi ekip olarak gözden geçirin; işaretlenmeyen her madde, ileride sessiz bir veri hatası olarak geri döner.

• Gözlem noktaları SKU, hedef ve pazar düzeyinde tanımlı; her noktanın katmanı ve son teyitli değişim tarihi tutuluyor.
• Liste sayfaları sabit sıralama ve sabit sayfa boyutuyla isteniyor; liste fiyatı yalnız tetikleyici olarak kullanılıyor.
• Sayfa ağırlığı, liste yoğunluğu ve değişim oranı pilotta ölçüldü; aylık GB ihtiyacı bu değerlerle hesaplandı.
• Paket ve ürün karışımı seçildi; residential ve mobile trafiği yalnız gerçekten gerektiren hedeflere ayrıldı.
• Hız sınırı alan adı başına uygulanıyor ve her hedefte günlük meşgul süre günün içine rahatça sığıyor.
• Rotasyon ayarı doğrulandı: her istek yeni bağlantıyla gidiyor (max_keepalive_connections=0) ve 429 sonrası alan adı Retry-After kadar duruyor; 403 alan hedef turdan çıkıyor.
• Deneme sayısına tavan konuldu; indirilen bayt hedef ve sayfa türü başına kaydediliyor.
• Çıkış ülkesi, dil başlığı, bölge çerezi ve adres aynı pazara ayarlı; son adres ve para birimi her gözlemde doğrulanıyor.
• Tutarlar en küçük birimde tam sayı olarak, ham metinle birlikte saklanıyor.
• Değişimler farklı bir çıkış IP’sinden ikinci gözlemle teyit ediliyor; çelişkili gözlemler ayrı işaretleniyor.
• Kanarya SKU’lar her tur başında kontrol ediliyor; kapsam, tazelik ve ayrıştırma oranları hedef bazında raporlanıyor.
• Kullanım koşulları ve robots.txt incelendi; sepet ve ödeme adımları kapsam dışında; kişisel veri toplanmıyor.

Bu liste tamamlandığında hattınızın maliyeti SKU sayısıyla değil değişim sayısıyla, hedefe bindirdiği yük ise sizin belirlediğiniz alan adı bütçesiyle büyür. Rotating proxy bu yapının erişim katmanıdır; verinin güvenilirliğini ise gözlem birimi, takvim ve teyit disiplini belirler.