Pazar Araştırması için Datacenter Proxy

E-ticarette rekabet her gün değişen üç bilgi üzerinden yürür: fiyat, stok ve ürünün nasıl sunulduğu. Bir rakibin kampanyaya girdiğini, bir ürünü stoktan çıkardığını ya da ürün başlığını yeniden yazdığını ne kadar erken görürseniz, kendi fiyatlandırma ve içerik kararlarınızı o kadar sağlam verirsiniz. Bu bilgilerin büyük kısmı rakiplerin herkese açık ürün sayfalarında durur. Sorun, yüzlerce ya da binlerce sayfayı düzenli aralıklarla, doğru ülkeden ve tutarlı biçimde kontrol etmektir.

Datacenter proxy bu işin erişim katmanıdır. Fiyat izleme ve stok takibi yapan bir toplama hattı, istekleri ölçülen pazarın ülkesinden çıkarır, yükü birden fazla IP’ye yayar ve trafiği öngörülebilir bir maliyetle taşır. Veri merkezlerinde barındırılan çıkışlar, bağlantı süresi ve kapasite açısından çoğu durumda istikrarlıdır; bu da her gün aynı saatte tamamlanması gereken tarama işleri için önemlidir.

Topladığınız veriyi baştan sınırlamak, hem maliyeti hem riski azaltır. Pazar araştırmasında genellikle şu alanlar yeterlidir: ürün kimliği (SKU, barkod ya da sitenin kendi ürün numarası), liste fiyatı, indirimli fiyat, para birimi, stok durumu, kargo bilgisi, ürün başlığı, kategori yolu ve, gerekiyorsa, açıklama metninin özeti ya da sürüm imzası. Kullanıcı yorumlarındaki kişi adları, satıcı iletişim bilgileri gibi kişisel nitelikli alanlar rakip analizi için gerekli değildir ve toplanmamalıdır.

Her sayfayı her saat kontrol etmek hem gereksiz trafik üretir hem de hedef sitelere yük bindirir. Doğru yaklaşım, veri türüne göre bir izleme takvimi kurmaktır. Fiyat, kampanya dönemlerinde gün içinde değişebilir; ürün açıklaması ise haftalarca aynı kalır. Takvimi veri türüne göre ayırdığınızda istek sayısı, dolayısıyla GB tüketimi ve hız sınırı riski belirgin biçimde düşer.

Tablodaki “stok durumunu fiyatla aynı turda oku” önerisi küçük görünür ama toplam isteği ciddi biçimde azaltır. Aynı ürün sayfası hem fiyatı hem stok durumunu taşıyorsa, iki ayrı tarama yapmak trafiği ikiye katlar. Benzer biçimde, yeni ürün keşfi için kategori sayfalarını derinlemesine taramak yerine sitenin yayımladığı site haritası dosyalarını okumak hem hedefe daha az yük bindirir hem de daha eksiksiz bir liste verir.

Pazar araştırması işleri, erişim ihtiyacı açısından üç profile ayrılır. Hangi profilde olduğunuzu bilmek, DatacenterProxy kataloğundaki dört ürün ailesinden hangisinin işinize yarayacağını belirler.

Lokasyon seçiminin genel kuralları ayrı bir konudur; pazar araştırmasında bilmeniz gereken, ülkenin üç farklı şeyi etkileyebileceğidir. Birincisi gösterilen fiyattır: bazı siteler ziyaretçinin ülkesine göre farklı para birimi, farklı vergi gösterimi ya da farklı kampanya sunabilir. İkincisi ürün kapsamıdır: bir ürün bir ülkede satışta görünürken başka bir ülkede gönderim dışı olabilir. Üçüncüsü yönlendirmedir: site, ziyaretçiyi ülke alt alan adına ya da dil sürümüne yönlendirebilir. Bu nedenle izlediğiniz pazarın ülkesinden ölçüm almak, verinin doğruluğu için ön koşuldur.

Datacenter tarafında gecikme ise toplama işinin süresini belirler. Tarama sunucunuz ile proxy çıkışı arasındaki mesafe her istekte gidiş dönüş süresi ekler; binlerce istekte bu, turun bitiş saatini kaydırır. Günlük fiyat raporunun sabah toplantısına yetişmesi gerekiyorsa, tarama sunucusunu mümkün olduğunca izlenen pazara yakın konumlandırmak ve zaman aşımı değerlerini ülkeye göre ayrı ayarlamak, paralel bağlantı sayısını artırmaktan daha güvenli bir hızlandırma yöntemidir.

Aşağıdaki adımlar, sıfırdan bir fiyat izleme ve stok takibi hattı kuran ekip için yazıldı. Hazır bir izleme aracı kullanıyorsanız da adımların çoğu geçerlidir; yalnız ayrıştırma ve zamanlama aracın içinde olur.

1. Ürün eşleştirme tablosunu kurun: Kendi ürünlerinizi rakip URL’lerle eşleştirin. Barkod ya da üretici kodu varsa eşleştirmeyi onunla yapın; yalnız başlık benzerliğine dayanan eşleştirme yanlış karşılaştırma üretir.
2. URL’leri katmanlara ayırın: Kritik ürünler sık, uzun kuyruk seyrek izlenir. Her URL’nin katmanı, ülkesi ve sahibi tabloda yer alsın.
3. Hedeflerin kurallarını inceleyin: Her rakip sitenin kullanım koşullarını ve robots.txt dosyasını okuyun; taranmasına izin verilmeyen yolları listeden çıkarın. Resmi ürün akışı ya da ortaklık veri kaynağı sunuluyorsa onu tercih edin.
4. İstek bütçesini hesaplayın: URL sayısı × aylık kontrol sayısı × yüzde 10–15 tekrar payı. Bu sayı, proxy paketini ve hız sınırını belirler.
5. Ürünü seçin ve pilotu başlatın: Rotating IPv4’ün 2 GB’lık hoş geldin paketi ya da 10 GB paketiyle, gerçek URL listesinin küçük bir örneğinde deneme yapın.
6. Alan adı başına hız sınırı koyun: Her hedef site için iki istek arasında en az bekleme süresi ve saatlik tavan belirleyin. Sınırı IP başına değil alan adı başına tutun; aynı siteye farklı IP’lerden aynı anda yüklenmek hız sınırının amacını boşa çıkarır.
7. Koşullu istek kullanın: Sunucu ETag ya da Last-Modified başlığı veriyorsa sonraki isteklerde bunları gönderin. Sayfa değişmediyse kısa bir 304 yanıtı gelir ve GB tüketimi düşer.
8. Yapılandırılmış veriyi önceliklendirin: Ürün sayfasında schema.org Product işaretlemesi varsa fiyatı ve stok durumunu oradan okuyun; görsel düzen değişse bile bu alanlar daha kararlıdır.
9. Geçerlilik kurallarını yazın: Fiyat boş, para birimi beklenmedik ya da sayfa bir doğrulama sayfasıysa satırı geçersiz işaretleyin ve turu o alan adı için durdurun.
10. Pilot sonrası bütçeyi güncelleyin: Bir haftalık pilotta ölçtüğünüz istek başına veri miktarıyla aylık GB ihtiyacını yeniden hesaplayın, paketi buna göre seçin.

Yedinci ve sekizinci adımlar, maliyet ve bakım yükü üzerinde en büyük etkiye sahip olanlardır. Koşullu istek, değişmeyen sayfalar için tam HTML indirmeyi önler; yapılandırılmış veri ise sitenin tasarımı her değiştiğinde ayrıştırıcıyı yeniden yazma zorunluluğunu azaltır. İkisi birlikte, aynı bütçeyle daha fazla ürün izlemenizi sağlar.

Aşağıdaki iki Python parçası, yukarıdaki adımların çekirdeğini gösterir. İlki bir URL listesini alan adı başına hız sınırıyla dolaşır, koşullu istek gönderir, sayfadaki schema.org Product verisinden fiyat ve stok durumunu okur ve sonucu CSV dosyasına ekler. İkincisi, iki günün CSV dosyasını karşılaştırarak fiyat ve stok değişimlerini listeler. Hedef adresler dosyadan okunur; kodda gerçek bir site adresi yoktur.

import csv
import json
import random
import re
import time
from datetime import datetime, timezone
from urllib.parse import urlparse

import requests

PROXY = "http://KULLANICI:ŞİFRE@PROXY_HOST:PORT"
PROXIES = {"http": PROXY, "https": PROXY}
MIN_ARALIK = 6.0   # aynı alan adına iki istek arası en az saniye (varsayım)
SAPMA = 3.0
ZAMAN_ASIMI = (5, 25)

son_istek = {}     # alan adı -> son istek zamanı
onbellek = {}      # url -> (etag, last_modified, son_kayit)
durdurulan = set() # doğrulama sayfası görülen alan adları


def bekle(alan):
    gecen = time.monotonic() - son_istek.get(alan, 0)
    hedef = MIN_ARALIK + random.uniform(0, SAPMA)
    if gecen < hedef:
        time.sleep(hedef - gecen)
    son_istek[alan] = time.monotonic()


def urun_verisi(html):
    # Sayfadaki JSON-LD bloklarında Product / Offer alanlarını arar.
    for blok in re.findall(r'<script[^>]+ld\+json[^>]*>(.*?)</script>', html, re.S):
        try:
            veri = json.loads(blok)
        except ValueError:
            continue
        for oge in veri if isinstance(veri, list) else [veri]:
            if isinstance(oge, dict) and oge.get("@type") == "Product":
                teklif = oge.get("offers") or {}
                if isinstance(teklif, list):
                    teklif = teklif[0] if teklif else {}
                return (teklif.get("price"), teklif.get("priceCurrency"),
                        str(teklif.get("availability", "")).rsplit("/", 1)[-1])
    return None, None, None


def kontrol_et(url, oturum, yazici):
    alan = urlparse(url).netloc
    if alan in durdurulan:
        return
    bekle(alan)
    basliklar = {}
    etag, degisim, onceki = onbellek.get(url, (None, None, None))
    if etag:
        basliklar["If-None-Match"] = etag
    if degisim:
        basliklar["If-Modified-Since"] = degisim
    try:
        r = oturum.get(url, headers=basliklar, proxies=PROXIES, timeout=ZAMAN_ASIMI)
    except requests.RequestException as hata:
        yazici.writerow([zaman(), url, "", "", "", "hata", type(hata).__name__])
        return
    if r.status_code == 304 and onceki:
        yazici.writerow([zaman(), url, *onceki, "degismedi", 304])
        return
    if r.status_code == 429:
        time.sleep(int(r.headers.get("Retry-After", 120)))
        yazici.writerow([zaman(), url, "", "", "", "ertelendi", 429])
        return
    fiyat, para, stok = urun_verisi(r.text) if r.status_code == 200 else (None, None, None)
    if fiyat is None:
        if r.status_code in (403, 503):
            durdurulan.add(alan)
        yazici.writerow([zaman(), url, "", "", "", "gecersiz", r.status_code])
        return
    kayit = (fiyat, para, stok)
    onbellek[url] = (r.headers.get("ETag"), r.headers.get("Last-Modified"), kayit)
    yazici.writerow([zaman(), url, *kayit, "ok", r.status_code])


def zaman():
    return datetime.now(timezone.utc).isoformat()


def calistir(url_dosyasi, cikti="fiyatlar.csv"):
    oturum = requests.Session()
    oturum.headers["Accept-Encoding"] = "gzip, deflate"
    with open(url_dosyasi, encoding="utf-8") as f:
        urller = [s.strip() for s in f if s.strip()]
    with open(cikti, "a", newline="", encoding="utf-8") as f:
        yazici = csv.writer(f)
        for url in urller:
            kontrol_et(url, oturum, yazici)
            f.flush()

import csv
from decimal import Decimal, InvalidOperation

ESIK = Decimal("0.02")  # yüzde 2 ve üzeri fiyat değişimini raporla (varsayım)


def oku(dosya):
    sonuc = {}
    with open(dosya, encoding="utf-8") as f:
        for zaman, url, fiyat, para, stok, durum, kod in csv.reader(f):
            if durum in ("ok", "degismedi") and fiyat:
                sonuc[url] = (fiyat, para, stok)  # günün son geçerli kaydı
    return sonuc


def sayi(deger):
    try:
        return Decimal(str(deger).replace(",", "."))
    except InvalidOperation:
        return None


def karsilastir(dun_dosyasi, bugun_dosyasi, rapor="degisimler.csv"):
    dun, bugun = oku(dun_dosyasi), oku(bugun_dosyasi)
    with open(rapor, "w", newline="", encoding="utf-8") as f:
        yazici = csv.writer(f)
        yazici.writerow(["url", "eski_fiyat", "yeni_fiyat", "degisim", "eski_stok", "yeni_stok"])
        for url, (fiyat, para, stok) in bugun.items():
            if url not in dun:
                continue
            eski_fiyat, eski_para, eski_stok = dun[url]
            if para != eski_para:
                continue  # para birimi değişti: ayrı incele, oran hesaplama
            a, b = sayi(eski_fiyat), sayi(fiyat)
            if not a or b is None:
                continue
            oran = (b - a) / a
            if abs(oran) >= ESIK or stok != eski_stok:
                yazici.writerow([url, a, b, f"{oran:.2%}", eski_stok, stok])

Birinci parçadaki önemli karar, hız sınırının alan adı başına tutulmasıdır. Rotating bir proxy ile her istek farklı IP’den çıksa bile, aynı siteye saniyede onlarca istek göndermek o sitenin altyapısına yük bindirir ve kurallarına aykırıdır. İkinci önemli karar, 403 ve 503 gibi engelleme işareti olabilecek yanıtlarda o alan adının tur boyunca durdurulmasıdır; hatayı farklı IP’lerle zorlamak yerine bir sonraki turu daha düşük hızla planlarsınız. İkinci parçada ise para birimi değiştiğinde oran hesaplanmaz; aksi halde bir para birimi değişimi yüzde yüzlerce “fiyat artışı” gibi görünür.

Türkiye pazarında satış yapan orta ölçekli bir elektronik perakendecisini düşünelim. Analiz ekibi beş rakibin toplam 4.000 ürün sayfasını izlemek istiyor. Fiyatlar DatacenterProxy kataloğundandır; URL sayısı, kontrol sıklığı, sayfa ağırlığı ve koşullu istek oranı ise varsayımdır ve pilot ölçümle güncellenmelidir. Türkiye çıkışı gerektiği için hesap rotating IPv4 üzerinden yapılır.

• Varsayım 1: 1.000 kritik ürün günde 4 kez, 3.000 uzun kuyruk ürün günde 1 kez kontrol edilir; ay 30 gün kabul edilir.
• Varsayım 2: Sıkıştırılmış tam bir ürün sayfası yanıtı ortalama 180 KB veri aktarır. Görseller ve betikler yalın HTTP istemcisinde indirilmez.
• Varsayım 3: Tekrar denemeler için yüzde 10 pay eklenir. 1 GB = 1.000.000 KB alınır.
• Varsayım 4 (iyileştirilmiş senaryo): Kritik ürün kontrollerinin yarısında sunucu koşullu isteğe 304 yanıtı verir ve bu yanıtların veri aktarımı hesapta ihmal edilir.

Temel senaryoda istek sayısı şöyledir: kritik ürünler için 1.000 × 4 × 30 = 120.000, uzun kuyruk için 3.000 × 30 = 90.000; toplam 210.000 istek. Veri aktarımı 210.000 × 180 KB = 37,8 GB, yüzde 10 payla yaklaşık 41,6 GB eder. İyileştirilmiş senaryoda kritik ürün isteklerinin yarısı, yani 60.000 istek, 304 yanıtıyla döner; tam sayfa aktarılan istek sayısı 150.000’e iner. 150.000 × 180 KB = 27 GB, yüzde 10 payla 29,7 GB olur.

Hesaptaki birim fiyat, rotating IPv4’ün 10, 20, 50 ve 100 GB paketlerinin ortak GB fiyatından gelir (örneğin 30 USD / 50 GB = 0,60 USD). Paketler tek seferliktir; geçerlilik ve kullanım koşulları sipariş adımında görünür. Senaryonun asıl mesajı, koşullu istek gibi küçük bir teknik iyileştirmenin aylık trafiği yaklaşık üçte bir oranında azaltabilmesidir. Bu oran tamamen varsayıma dayanır; hedef sitelerin ETag ve Last-Modified desteğine göre sizin değeriniz daha yüksek ya da sıfır olabilir.

Ham fiyat verisi doğrudan karşılaştırmaya uygun değildir. İki rakipten toplanan iki fiyat, aynı ürünü farklı paket boyutunda, farklı vergi gösterimiyle ya da farklı kargo koşuluyla temsil edebilir. Rakip analizi raporunun güvenilirliği, toplama işinden çok bu adımın titizliğine bağlıdır. Aşağıdaki kurallar en sık karşılaşılan farkları kapsar.

• Sayı biçimi: Türkçe sayfalarda binlik ayıracı nokta, ondalık ayıracı virgüldür; yapılandırılmış veride ise genellikle nokta ondalıktır. Fiyatı hangi kaynaktan okuduğunuzu kaydedin ve dönüşümü kaynağa göre yapın.
• Para birimi: Her satırda para birimi kodu saklansın. Kur dönüşümü gerekiyorsa kullanılan kur ve tarihini ayrı sütunda tutun; geçmiş raporlar sonradan yeniden hesaplanabilsin.
• Vergi gösterimi: Bazı siteler vergi dahil, bazı B2B portalları vergi hariç fiyat gösterir. Karşılaştırmadan önce tek bir esasa çevirin ve hangi esası kullandığınızı raporda belirtin.
• Liste fiyatı ve indirimli fiyat: İkisini ayrı alanlarda tutun. Sepette uygulanan ya da üyelikle açılan indirimler herkese açık sayfada görünmeyebilir; bunları toplanan verinin kapsamı dışında sayın.
• Varyantlar: Renk, beden ya da kapasite varyantlarının fiyatı farklı olabilir. Ürün eşleştirmesini varyant düzeyinde yapın; ana ürün fiyatını varyantlarla karıştırmayın.
• Birim fiyat: Paket boyutu farklı ürünlerde kilogram, litre ya da adet başına fiyat hesaplayın.
• Kargo: Ücretsiz kargo eşiği ve kargo ücreti nihai maliyeti değiştirir. Toplanabiliyorsa ayrı alanda saklayın.
• Stok sinyali: Yapılandırılmış verideki stok durumu değerlerini kendi kısa kodlarınıza eşleyin (stokta, tükendi, ön sipariş). Sayfa metnindeki “son birkaç ürün” gibi ifadeleri kesin stok adedi olarak yorumlamayın.

Bir başka sık sorun, eşleştirme hatasının fiyat değişimi gibi görünmesidir. Rakip bir ürün sayfasının URL’sini başka bir ürüne yönlendirdiğinde, toplama hattı sorunsuz çalışır ama yanlış ürünün fiyatını kaydeder. Bunu yakalamak için ürün kimliğini (SKU ya da barkod) fiyatla birlikte okuyun ve eşleştirme tablosundaki değerle karşılaştırın. Kimlik eşleşmiyorsa satırı geçersiz işaretleyin; büyük bir fiyat sıçramasından önce bu kontrolü yapmak, yanlış alarm sayısını ciddi biçimde azaltır.

Fiyat izleme hattında karşılaşılan sorunların bir kısmı proxy bağlantısıyla, bir kısmı hedefin davranışıyla, önemli bir kısmı da veri hazırlamayla ilgilidir. Aşağıdaki tablo belirtiden yola çıkar.

Datacenter IP’lerine özgü bir not: bazı siteler trafiği tek tek IP’ye değil, IP’nin ait olduğu ağa bakarak değerlendirebilir. Böyle bir hedefte IP değiştirmek kalıcı çözüm değildir. Bu durumda doğru yol, o hedef için istek hacmini düşürmek, izin verilen bir veri kaynağı aramak ya da o rakibi izleme kapsamından çıkarmaktır.

Herkese açık fiyat bilgisini izlemek yaygın bir rekabet analizi yöntemidir; ancak yöntemin sınırları vardır ve bu sınırlar her site için ayrıdır. Her hedefin kullanım koşulları ve robots.txt dosyası, hangi alanların otomatik araçlarla erişime açık olduğunu ve hangi koşullarda erişileceğini belirtir. Bu kurallara uymak, hız sınırlarına saygı göstermek ve sitenin altyapısına zarar verecek yükten kaçınmak, toplama hattını kuran ekibin sorumluluğundadır. Proxy kullanımı bu sorumluluğu ortadan kaldırmaz.

Pratikte üç ilke çoğu durumu kapsar. Birincisi, oturum açma ya da ödeme gerektiren alanlara yalnız yetkili olduğunuz hesaplarla ve o hesabın koşulları çerçevesinde erişin; başkasının erişim kontrolünü aşmaya çalışmayın. İkincisi, toplanan veriyi amaçla sınırlayın: fiyat, stok ve ürün içeriği yeterliyken kullanıcı yorumları, profil bilgileri ya da iletişim bilgileri gibi kişisel verileri toplamayın. KVKK dahil kişisel verilerin korunmasına ilişkin düzenlemeler, verinin amaçla bağlantılı, sınırlı ve ölçülü işlenmesini temel ilke olarak benimser. Üçüncüsü, rakip içeriğini kopyalayıp yayımlamayın; analiz için topladığınız metinler kendi sitenizde kullanılacak içerik değildir.

Ekip içinde, hangi sitelerin hangi sıklıkla izlendiğini, hangi hız sınırlarının uygulandığını ve verinin ne kadar süre saklandığını gösteren kısa bir belge tutun. Bir hedef siteden itiraz ya da engelleme geldiğinde ne yapılacağını da bu belgeye yazın. Bu, hem hukuki riski azaltır hem de ekip değiştiğinde toplama hattının sorumlu biçimde işletilmeye devam etmesini sağlar.

Aşağıdaki maddelerin her biri, bu sayfada anlatılan bir sorunun önlemidir. Yeni bir fiyat izleme ya da stok takibi projesini günlük çalışmaya bağlamadan önce listeyi ekip olarak gözden geçirin.

• Ürün eşleştirmesi barkod, üretici kodu ya da SKU üzerinden ve varyant düzeyinde yapıldı.
• Her URL’nin katmanı, ülkesi ve kontrol sıklığı tanımlı; stok bilgisi fiyatla aynı turda okunuyor.
• Her hedefin kullanım koşulları ve robots.txt dosyası incelendi; izin verilmeyen yollar listeden çıkarıldı.
• Ürün seçimi ülke kapsamına göre doğrulandı; Türkiye pazarı için rotating IPv4 ya da IPv6 erişilebilir hedeflerde static IPv6 planlandı.
• IPv6 ürünü seçildiyse hedeflerin IPv6 erişilebilirliği IPv6 Destek Kontrolü aracıyla test edildi.
• Hız sınırı alan adı başına uygulanıyor; rastgele sapma ve saatlik tavan tanımlı.
• 429 yanıtında Retry-After süresine uyuluyor; doğrulama sayfası ve 403 yanıtında alan adı tur boyunca durduruluyor.
• Koşullu istek ve sıkıştırma etkin; GB tüketimi pilotta ölçüldü ve paket buna göre seçildi.
• Fiyat, para birimi, vergi esası, liste ve indirimli fiyat ayrı alanlarda saklanıyor.
• Eşik üstü fiyat değişimleri ikinci bir kontrol turuyla doğrulanıyor.
• Çıkış IP’si ve ülkesi her turun başında kayda geçiyor.
• Kişisel veri toplanmıyor; saklama süresi ve itiraz süreci yazılı.

Bu listenin tamamlanması, pazar araştırması verinizin hem güvenilir hem de sürdürülebilir olduğunu gösterir. Datacenter proxy bu yapının hızlı ve maliyeti öngörülebilir erişim katmanıdır; rakip analizi kararlarının kalitesini ise eşleştirme, normalizasyon ve doğrulama disiplini belirler.