Dönen IPv4 residential ağ ile esnek erişim

Bir residential IP’nin değeri, hedef sitenin onu hangi ülkeye yerleştirdiğiyle başlar. Fiyat, stok, arama sırası, reklam ve hatta sayfanın hangi dilde açılacağı bu yerleştirmeye bağlıdır. Bu yüzden Rotating IPv4 paketini kurarken ilk soru “kaç GB lazım?” değil, “hangi pazarların verisini, hangi doğrulukla istiyorum?” olmalıdır. Bütçe, doğrulama ve raporlama bu sorunun cevabından türer; GB hesabı en sona kalır.

Bu rehberde pazar, tek bir ülke kodunun etrafında toplanan iş paketi anlamına gelir: o ülkeden çıkan istekler, o ülkeye özgü sayfa listesi, beklenen dil ve para birimi, kabul edilebilir hata payı ve ayrılmış GB bütçesi. Her isteğin hangi pazara ait olduğu baştan bellidir; kayıt, rapor ve maliyet aynı etiketle tutulur. Ülke etiketi olmadan toplanmış bir satır, ne kadar temiz görünürse görünsün, yorumlanamaz.

Pazar düzeyinde düşünmenin üç pratik sonucu vardır. Birincisi, bir pazarda çıkan sorun diğerlerini kirletmez; Japonya kuyruğunda zaman aşımı artarsa yalnız o kuyruk yavaşlar. İkincisi, GB tüketimi pazar bazında izlendiği için hangi ülkenin bütçeyi beklenenden hızlı tükettiği hemen görülür. Üçüncüsü, oturum isteyen bir adım çıktığında yalnız o pazar için static IPv4 düşünülür; bütün düzeni baştan kurmanız gerekmez.

Pratikte her pazarı küçük bir “pazar kartı” ile tanımlamak işe yarar. Kart, ekibin ve kodun aynı varsayımlarla çalışmasını sağlar; ölçüm sonradan tartışıldığında hangi ayarla yapıldığı da kayıtlıdır. Aşağıdaki örnekte alan adları ve değerler yer tutucudur; kendi işinize göre doldurun.

# Pazar kartı: her ülke için ayrı bir dosya ya da blok
pazar: de
cikis_ulkesi: DE                        # paneldeki ülke seçimiyle aynı olmalı
baglanti: KULLANICI:ŞİFRE@GATEWAY:PORT  # ülke ayarının yazımı panelde
beklenen:
  html_lang: de
  para_birimi: EUR
  saat_dilimi: Europe/Berlin
yerel_sayfalar:
  - HEDEF_URL                           # pazarın yerel adresleri
gunluk_sayfa: 600
zaman_asimi_sn: 40                      # uzak pazarlarda daha uzun
kabul_edilen_ulke_hatasi: 0.02          # yüzde 2 üstü uyarı üretir
cerez_onayi: reddedildi                 # her ölçümde aynı durum
oturum_gerektiren_adim: yok             # varsa: aynı ülkenin static IPv4 IP’si
aylik_gb_payi: 2.8
kurallar: robots.txt ve kullanım koşulları kontrol edildi

Kartın en sık atlanan iki alanı kabul edilen ülke hatası ve çerez onayı durumudur. İlki, doğrulama adımının hangi oranda alarm üreteceğini belirler. İkincisi, Avrupa pazarlarında sayfa içeriğini ve ağırlığını değiştiren onay penceresinin her ölçümde aynı durumda tutulmasını sağlar. İkisi de ilerleyen bölümlerde ayrıntılı olarak ele alınıyor.

Rotating IPv4 ürününün katalog kaydında iki ayrı kapsam bilgisi bulunur. Ürün sayfasında öne çıkan ülke listesi 15 ülkeden oluşur: Amerika Birleşik Devletleri, Birleşik Krallık, Almanya, Fransa, Türkiye, Hollanda, Kanada, Brezilya, Avustralya, Japonya, Hindistan, Polonya, Avusturya, Portekiz ve İspanya. Bunun yanında “180+ lokasyon” şeklinde bir kapsam notu yer alır. İkisi aynı şeyi söylemez: liste, sayfada adıyla doğrulanmış ülkeleri gösterir; kapsam notu ise ağın bu listeden daha geniş bir lokasyon yelpazesine ulaştığını belirtir.

Bu ayrımın planlamadaki karşılığı nettir. Pazarınız 15 ülkelik listedeyse paket kararını doğrudan verebilirsiniz. Listede olmayan bir ülke için kapsam notu umut verir ama tek başına güvence değildir; o ülkenin seçilebildiğini ve trafiğin gerçekten oradan çıktığını satın almadan önce panelde ya da destek kanalında doğrulayın, ardından küçük bir doğrulama turu çalıştırın. Katalogdaki GB paketlerinin ülke alanı yoktur, yani paketler ülkeye göre ayrı fiyatlanmaz. Pazar eklemenin maliyeti fiyat farkından değil, eklenen trafikten doğar.

Oturum isteyen adımları ileride static IPv4’e taşıyacaksanız, aynı ülkenin static tarafta da bulunup bulunmadığını baştan bilmeniz gerekir. Aşağıdaki tablo, 15 ülkelik listeyi static IPv4 kataloğuyla yan yana koyar. Static fiyatlar aylıktır ve IP adedine göre paketlenir; en küçük paket ülkeye göre değişir.

Tablodan çıkan sonuç şudur: 15 pazarın 11’inde ölçümü dönen havuzla, oturum isteyen adımları ise aynı ülkenin static IP’siyle yürütmek mümkündür. İspanya, Avustralya, Japonya ve Hindistan’da bu ikili düzen katalog üzerinden kurulamaz; bu pazarlarda oturumlu adımları ürünün sticky oturum desteğiyle kısa tutmanız ya da ölçüm kapsamından çıkarmanız gerekir. Türkiye ise static tarafta tek IP’lik paketi olan tek ülkedir; küçük bir oturum ihtiyacı için beş IP almak zorunda kalmazsınız.

Türkiye pazarı için bir seçenek daha vardır. Hedef IPv6 kabul ediyorsa, katalogda yalnız Türkiye lokasyonuyla yayınlanan ve port bazlı aylık faturalanan Rotating IPv6 ürünü de değerlendirilebilir. Hedefin IPv6 davranışını doğrulamadan bu ürüne geçmeyin; çok pazarlı bir düzende IPv4 tarafı ortak dil olarak kalır.

Çıkış IP’sinin doğru ülkeden gelmesi, hedef sitenin size o ülkenin içeriğini göstereceği anlamına gelmez. Siteler konumu birden fazla sinyalden çıkarır ve bu sinyallere farklı öncelik verir. Ölçüm tasarımında hangi sinyalin baskın olduğunu bilmek, ülke seçiminin gerçekten işe yarayıp yaramadığını belirler.

Tablonun ilk satırı en sık gözden kaçan noktadır. Birçok uluslararası site, ziyaretçinin açıkça seçtiği ülke yolunu IP’nin önüne koyar. Almanya’dan çıkan bir istekle sitenin Türkiye yoluna giderseniz büyük olasılıkla Türkiye içeriğini görürsünüz. Bu durumda ülke hedefleme ölçüme hiçbir şey katmamış, yalnızca residential trafik harcanmış olur. Tersine, ülke yolu bulunmayan ve içeriği yalnız IP’ye göre değiştiren sitelerde ülke seçimi her şeydir; tek bir hatalı çıkış doğrudan yanlış veri üretir.

Konum veritabanları da birbirinin aynısı değildir. Bir IP bağımsız bir sorgu servisinde Hollanda görünürken hedefin kullandığı veritabanında Belçika ya da Almanya olarak işaretlenmiş olabilir; sınır bölgelerinde ve yakın zamanda el değiştirmiş adres bloklarında bu fark daha sık görülür. Bu yüzden doğrulamanın ikinci katmanı her zaman hedefin kendi sayfasından gelmelidir: gösterilen para birimi, ülke seçicisinin varsayılan değeri, sayfanın dil kodu ya da kargo bilgisinde yazan ülke.

Hedefi tanımak için küçük bir deney yeterlidir. Aynı ürün sayfasını önce genel adresinden, sonra ülke yolundan, iki farklı ülkenin çıkışıyla açın ve dört sonucu karşılaştırın. İçerik yalnız adrese göre değişiyorsa bu hedefte ülke seçimi ölçüme katkı sağlamaz; residential GB’ı içeriği IP’ye göre değiştiren hedeflere ayırın. İçerik yalnız IP’ye göre değişiyorsa ülke hedefleme şarttır. İkisine birden bağlıysa pazar kartında hem yerel adres hem de aynı ülkenin çıkışı birlikte tanımlanmalıdır; ikisinden biri eksik kaldığında sonuç iki pazarın karışımı olabilir.

Ülke hatalarının tehlikesi, nadiren hata mesajı üretmeleridir. Yanıt başarılı döner, sayfa eksiksiz yüklenir, ayrıştırıcı aradığı alanları bulur ve satır veritabanına yazılır. Sorun çoğu zaman haftalar sonra, bir pazarda açıklanamayan bir dalgalanma görüldüğünde fark edilir. Aşağıdaki dört bozulma tipi, bu sessiz hataların en sık rastlanan biçimleridir.

Doğrulamanın amacı her isteği ikinci kez yapmak değildir; her pazarın her çalışmasından küçük bir örnek alıp ülke hatası oranını ölçmektir. Birinci katman çıkış IP’sinin hangi ülkeye ait göründüğünü, ikinci katman hedef sitenin sizi hangi pazara yerleştirdiğini kontrol eder. İki katman birlikte geçerse o çalışmanın satırları güvenilir sayılır. Aşağıdaki betik bu mantığı üç pazar için gösterir; bağlantı bilgisini ve ülke ayarının yazımını panelden alın.

# İki katmanlı ülke doğrulaması (Python 3, requests)
# Her pazar için panelde verilen, ülke ayarı yapılmış bağlantı bilgisini yazın.
import re
import requests

PAZARLAR = {
    'tr': {'proxy': 'http://KULLANICI:ŞİFRE@GATEWAY:PORT', 'lang': 'tr', 'para': 'TRY'},
    'de': {'proxy': 'http://KULLANICI:ŞİFRE@GATEWAY:PORT', 'lang': 'de', 'para': 'EUR'},
    'pl': {'proxy': 'http://KULLANICI:ŞİFRE@GATEWAY:PORT', 'lang': 'pl', 'para': 'PLN'},
}
KONUM_SORGUSU = 'HEDEF_URL'  # düz metin ülke kodu döndüren bir servis
YEREL_SAYFA = 'HEDEF_URL'    # pazarın yerel sayfası (pazar kartından)


def katman_1(proxy):
    yanit = requests.get(KONUM_SORGUSU, proxies={'http': proxy, 'https': proxy}, timeout=(10, 20))
    return yanit.text.strip().lower()[:2]


def katman_2(proxy, beklenen):
    yanit = requests.get(YEREL_SAYFA, proxies={'http': proxy, 'https': proxy}, timeout=(10, 40))
    dil = re.search(r'<html[^>]*lang="([a-zA-Z-]+)"', yanit.text)
    dil_tamam = bool(dil) and dil.group(1).lower().startswith(beklenen['lang'])
    para_tamam = beklenen['para'] in yanit.text
    return dil_tamam and para_tamam


for kod, ayar in PAZARLAR.items():
    hatali = 0
    for _ in range(5):
        # katman_1 tutmazsa sayfa hiç indirilmez (kota korunur)
        if katman_1(ayar['proxy']) != kod or not katman_2(ayar['proxy'], ayar):
            hatali += 1
    print(f'{kod}: 5 örnekte {hatali} hatalı')

# Örnek çıktı biçimi:
# tr: 5 örnekte 0 hatalı
# de: 5 örnekte 1 hatalı
# pl: 5 örnekte 0 hatalı

Betik bilinçli olarak sade tutuldu; zaman aşımı, tekrar ve kayıt mantığını kendi altyapınıza göre ekleyin. Üretimde her pazarın her çalışmasından birkaç örnek yeterlidir. Hata oranı pazar kartındaki eşiği aşarsa o pazarın o günkü verisini “şüpheli” olarak işaretleyin ve nedenini bulmadan rapora almayın.

Dönen modda bilinmesi gereken bir ayrıntı vardır: iki katmanın istekleri farklı çıkış IP’lerinden gidebilir. Bu durumda birinci katman tek bir IP’yi değil, ülke ayarının o çalışmada genel olarak uygulandığını gösterir. İki katmanı aynı IP üzerinde birlikte doğrulamak istiyorsanız örnek çiftini ürünün sticky oturumuyla gönderin; sticky ayarının nasıl yazıldığını ve ne kadar sürdüğünü panelde kontrol edin.

Doğrulamanın maliyeti bütçede yuvarlama hatası kadar yer tutar. Varsayım olarak konum sorgusu başına 2 KB aktarım alalım: beş pazarda günde 20 sorgu, ayda 5 × 20 × 2 × 30 = 6.000 KB, yani yaklaşık 0,006 GB eder. 1,20 USD/GB kademesinde bu, ayda bir sentin altındadır. İkinci katman sayfa indirdiği için daha pahalıdır; onu yalnız birinci katmandan geçen örneklerde çalıştırmak bu yüzden önemlidir.

Rotating IPv4 paketleri tek seferlik ödenir ve GB bazlıdır. Katalogdaki beş paketin GB başına fiyatı ve pazar planlamasındaki tipik yeri şöyledir:

10 GB’tan 100 GB’a kadar GB başına fiyat 1,20 USD’de sabit kalır. Pazar sayısı arttıkça büyük paket almak birim fiyatı düşürmez; paket boyutunu tüketim hızınız ve kotanın bitmesinin işinizi ne kadar aksatacağı belirler. Kalan kotanın geçerlilik koşullarını sipariş adımında okuyun.

Örnek olarak Türkiye merkezli bir ev tekstili markasının e-ihracat ekibini düşünelim. Ekip, kendi ürünlerinin ve kamuya açık rakip fiyatlarının beş pazardaki görünümünü her gün izliyor: Türkiye, Almanya, Hollanda, Polonya ve Japonya. Pazarların sayfa sayısı ve sayfa ağırlığı birbirinden farklıdır. Aşağıdaki değerlerin tamamı varsayımdır ve pilotta ölçeceğiniz gerçek değerlerle değiştirilmelidir:

• —Sıkıştırılmış aktarım üzerinden ortalama sayfa ağırlığı: Türkiye 90 KB, Almanya 140 KB, Hollanda 130 KB, Polonya 120 KB, Japonya 180 KB.
• —Almanya ve Hollanda’daki fazlalık çerez onayı katmanından, Japonya’daki fazlalık büyük yazı tipi dosyalarından gelir.
• —Tekrar payı pazara göre değişir: Türkiye yüzde 5, Almanya, Hollanda ve Polonya yüzde 8, Japonya yüzde 15. Japonya’daki yüksek pay, uzak çıkışta zaman aşımı kaynaklı tekrarları temsil eder.
• —Ay 30 gün, 1 GB ise 1.000.000 KB kabul edilir; doğrulama trafiği önemsiz olduğu için hesaba katılmaz.

Tablonun en öğretici satırı Almanya’dır: Türkiye’den daha az sayfa okunmasına rağmen bütçenin en büyük payını alır, çünkü sayfaları daha ağırdır. Japonya ise Polonya’nın üçte ikisi kadar sayfayla ondan daha fazla GB tüketir; yüksek sayfa ağırlığı ile yüksek tekrar payı birlikte bu sonucu doğurur. Bütçeyi sayfa sayısına göre paylaştırsaydınız Japonya’yı yaklaşık yüzde 37, Almanya’yı yaklaşık yüzde 13 eksik, Türkiye’yi ise yaklaşık yüzde 39 fazla planlamış olurdunuz.

Paket kararı bu tablodan kolayca çıkar. Ayda 8,66 GB ile 10 GB’lık paket yaklaşık 34 gün, 20 GB’lık paket yaklaşık 69 gün, 50 GB’lık paket ise beş buçuk aydan biraz fazla yeter. Birim fiyat aynı olduğu için seçim nakit akışı ve satın alma sıklığı tercihine kalır. Pazar eklemenin marjinal maliyeti de hesaplanabilir: Hollanda ile aynı varsayımları taşıyan altıncı bir pazar, örneğin Brezilya, ayda yaklaşık 1,26 GB ve 1,52 USD ekler.

Residential çıkışlarda yavaşlık ile kota tüketimi çoğu zaman aynı sorunun iki yüzüdür. Zaman aşımına uğrayan bir istekte kesilme anına kadar aktarılan veri de kotaya yansıyabilir; ardından gelen tekrar aynı sayfayı baştan indirir. Yavaş bir pazar bu yüzden aynı zamanda pahalı bir pazardır. Çözüme geçmeden önce yavaşlığın nerede oluştuğunu ayırın: ağ geçidine bağlanırken mi, hedefe tünel kurulurken mi, hedefin ilk baytı göndermesinde mi, yoksa indirmenin kendisinde mi?

# Pazar bazında süre ve boyut dökümü (bash, curl)
# PROXY satırını her pazar için panelde verilen ülke ayarlı bağlantı bilgisiyle değiştirin.
BICIM='baglanti=%{time_connect} tunel=%{time_appconnect} ilk_bayt=%{time_starttransfer} toplam=%{time_total} boyut=%{size_download}'

for PAZAR in tr de jp; do
  PROXY='http://KULLANICI:ŞİFRE@GATEWAY:PORT'
  printf '%s ' "$PAZAR"
  curl -s -o /dev/null -x "$PROXY" --compressed --connect-timeout 10 --max-time 60 -w "$BICIM" 'HEDEF_URL'
  echo
done

# Çıktı biçimi (değerler sizin ölçümünüzden gelir):
# tr baglanti=... tunel=... ilk_bayt=... toplam=... boyut=...

Çıktıyı aşamalara bölerek okuyun. Bağlantı süresi yüksekse sorun istemci sunucunuz ile ağ geçidi arasındadır ve hedefle ilgisi yoktur. Tünel süresi ile bağlantı süresi arasındaki fark büyükse çıkış noktası ile hedef arasındaki yol ve şifreli bağlantının kurulması zaman alıyordur. İlk bayt süresi ile tünel süresi arasındaki fark, hedefin yanıtı üretmek için harcadığı süredir. Toplam süre ile ilk bayt arasındaki fark ise indirmedir; sayfa ağırlığı ve çıkış bağlantısının o anki hızı burada görünür. Ölçümü her pazarda günün farklı saatlerinde birkaç kez tekrarlayın; tek bir ölçüm residential çıkışların doğal değişkenliğini yansıtmaz.

Dönen havuzun gücü, birbirinden bağımsız istekleri farklı çıkışlara dağıtmasından gelir. Bazı adımlar ise aynı kimliği ister: kendi pazar yeri satıcı panelinizde ürünlerinizin yerel listelenmesini kontrol etmek, bir posta koduyla kargo ücreti hesaplatmak ya da kendi müşteri hesabınızla oturum açıp kişiselleştirilmiş fiyatı görmek. Katalog, Rotating IPv4’ün sticky oturum senaryolarına da uyduğunu belirtir; sticky süresi panelde kontrol edilmelidir; kısa akışlar için yeterli olabilir (varsayım). Aynı kimliğin günlerce korunması gerektiğinde ise doğru araç aynı ülkenin static IPv4 IP’sidir. Ürün kaydı da tek IP ile uzun süreli hesap oturumunu ve sabit kurumsal kimlik gerektiren panelleri bu ürünün uygun olmadığı işler arasında sayar.

Maliyet tarafı farklı birimlerle hesaplanır. Static IPv4 aylık ve IP adedine göre, Rotating IPv4 ise GB başına faturalanır. İki birimi karşılaştırmak için static paketin aylık bedelini 1,20 USD/GB’ye bölebilirsiniz: Türkiye’deki 1 IP’lik paketin 2,25 USD’si yaklaşık 1,9 GB, diğer ülkelerdeki 5 IP’lik paketin 17,5 USD’si yaklaşık 14,6 GB dönen trafiğe denk gelir. Bu eşdeğerlik bir tercih kuralı değildir; oturum gerektiren adım için static, maliyetinden bağımsız olarak doğru araçtır. Ama aynı pazarda hem dönen hem static kullanacaksanız aylık toplamı doğru görmenizi sağlar.

Örnek senaryoya dönelim. Ekip, Almanya ve Hollanda’daki kendi satıcı panellerini her sabah kontrol etmek istesin. İki ülkede de en küçük static paket 5 IP ve aylık 17,5 USD’dir; iki ülke 35 USD eder ve dönen tarafın 10,39 USD’lik aylık bütçesiyle toplam 45,39 USD’ye çıkar. Türkiye’deki panel için 1 IP’lik paket yeterlidir ve toplamı 47,64 USD yapar. Japonya’daki panel için katalogda static seçenek olmadığından ekip ya kısa sticky oturumlarla yetinir ya da o kontrolü ölçüm düzeninin dışında, insan eliyle yapar.

Beş IP’lik paketlerde dört IP boşta kalabilir. Bunları aynı ülkede yedek çıkış ya da birbirinden bağımsız kendi hesaplarınız için planlayın. Platformun kullanım koşullarının izin vermediği çoklu hesap düzenlerine bu IP’leri kullanmayın; static IP’nin değeri, meşru bir hesabın her gün aynı ülkeden ve aynı adresten tutarlı biçimde açılmasıdır.

Aşağıdaki sıra, yeni bir çok pazarlı düzeni ilk günden ölçülebilir kurmak için tasarlandı. Adımların her biri bir önceki adımın çıktısını kullanır; sırayı değiştirmek genellikle tahminle verilmiş kararlar demektir.

1. 01Ölçmek istediğiniz pazarları yazın ve her birini katalogdaki 15 ülkelik listeyle eşleştirin. Listede olmayan pazarlar için kapsamı satın almadan önce panelde ya da destek kanalında doğrulayın.
2. 02Her hedefin konum sinyallerini çözün: aynı sayfayı genel ve yerel adresten, iki farklı ülke çıkışıyla açarak içeriğin IP’ye mi, adrese mi, yoksa ikisine birden mi bağlı olduğunu belirleyin.
3. 03Pazar kartlarını doldurun: yerel adresler, beklenen dil ve para birimi, saat dilimi, günlük sayfa sayısı, zaman aşımı, kabul edilen ülke hatası ve çerez onayı durumu.
4. 042 GB’lık paketi pilot olarak kullanın. Her pazardan 300 sayfalık bir örnek, ortalama 130 KB varsayımıyla beş pazarda yaklaşık 0,2 GB tutar; paketin geri kalanı ilk üretim günlerine kalır.
5. 05Pilotta pazar bazında ortalama aktarımı, tekrar oranını ve süre dökümünü kaydedin; uzak pazarlar için ayrı zaman aşımı değerleri belirleyin.
6. 06İki katmanlı doğrulamayı her pazarda çalıştırın ve ölçülen ülke hatası oranını pazar kartındaki eşikle karşılaştırın; eşiği aşan pazarı üretime almadan önce düzeltin.
7. 07Ölçülen değerlerle aylık GB’ı pazar bazında hesaplayın, bütçe paylarını ve günlük harcama sınırlarını yazın, paket boyutunu tüketim hızına göre seçin.
8. 08Oturum gerektiren adımları ayırın; static IPv4 seçeneği olan pazarlarda bu adımları aynı ülkenin static IP’sine taşıyın, olmayanlarda sticky oturumu ya da kapsam dışı bırakmayı yazılı olarak karara bağlayın.
9. 09Taramaları her pazarın yerel saatine göre zamanlayın; fiyat veya stok güncelleme saatini biliyorsanız ölçümü bu saatin hep aynı tarafına koyun.
10. 10İlk iki haftanın sonunda pazar bazlı tüketimi, ülke hatası oranını ve tekrar oranını gözden geçirin; pazar kartlarındaki varsayımları ölçülen değerlerle değiştirin.

Pilotun en değerli çıktısı tek bir toplam GB rakamı değil, pazarlar arasındaki farktır. Sayfa ağırlığı, tekrar oranı ve ülke hatası oranı pazardan pazara değişir; bu farkları ilk iki haftada görmek, sonraki ayların bütçesini tahminden ölçüme taşır.

Ülke hedefleme çoğu zaman aynı markanın farklı ülke alan adlarına gitmek demektir. Her alan adının robots.txt dosyası, kullanım koşulları ve hız sınırları ayrı olabilir; Türkiye sitesinde açık olan bir yol Almanya sitesinde kapalı olabilir. Bu kontrolü pazar bazında yapın, sonucunu pazar kartına yazın ve kuralları her pazarda ayrı uygulayın.

Kişisel veri tarafında da pazar önemlidir. Türkiye’de KVKK, Avrupa Birliği ülkelerinde GDPR, diğer ülkelerde yerel düzenlemeler geçerlidir. Bu rehberde anlatılan ölçümler kamuya açık fiyat, stok, sıra ve içerik verisi içindir. Yorumlardaki kullanıcı adları, profil bilgileri ya da iletişim verileri gibi kişisel verileri toplamayın; indirilen sayfalarda bu tür veri bulunuyorsa ayrıştırma aşamasında atın ve saklamayın.

Çerez onayı pencerelerini bir ölçüm ayarı olarak ele alın. Onayı otomatik olarak kabul etmek, kullanıcı adına izin vermek anlamına gelir; zorunlu olmayan çerezleri reddetmek ya da pencereyi olduğu gibi bırakmak hem daha temkinli hem de daha tutarlı bir yaklaşımdır. Hangi durumu seçerseniz seçin, her ölçümde aynı durumu koruyun ki pazarlar ve günler arasındaki karşılaştırma bozulmasın.

Son olarak, ülke hedefleme bir erişim kısıtını aşmak için kullanılmamalıdır. Bir içerik belirli ülkelerde lisans ya da yasal nedenlerle sunulmuyorsa veya hedef site otomatik erişimi kapatıyorsa, doğru yanıt ölçümü o pazarda durdurmaktır. CAPTCHA ya da benzeri doğrulama adımlarıyla karşılaştığınızda bunları aşmaya çalışmayın; isteği durdurun, tempoyu ve kuralları gözden geçirin. ResidentialProxy ürünlerini yalnız meşru ve hedef sitenin koşullarına uygun işlerde kullanın.

Üretim trafiğini açmadan önce her pazar için aşağıdaki maddeleri tek tek işaretleyin. Bir maddeyi atlamanın bedeli genellikle hata mesajı değil, sessizce yanlışlaşan bir rapordur.

• —Her pazar 15 ülkelik listede ya da kapsamı panelde doğrulanmış; şehir düzeyinde sonuç gerekiyorsa bu ayrıca doğrulandı.
• —Pazar kartları dolu: yerel adresler, dil, para birimi, saat dilimi, günlük sayfa sayısı, zaman aşımı, ülke hatası eşiği ve çerez onayı durumu.
• —Hedeflerin konum sinyalleri çözüldü; içerik adrese bağlıysa yerel adres, IP’ye bağlıysa ülke çıkışı, ikisine bağlıysa ikisi birden tanımlı.
• —Her çalışma kısa bir konum sorgusuyla başlıyor; çıkış ülkesi tutmadığında büyük indirme hiç başlamıyor.
• —İkinci katman doğrulama hedefin kendi sayfasından yapılıyor ve ülke hatası oranı pazar bazında kaydediliyor.
• —Doğrulamadan geçmeyen satırlar rapora girmiyor; “şüpheli” işaretli günler ayrı tutuluyor.
• —Kayıtlarda pazar etiketi, çıkış ülkesi, nihai adres, zaman damgası ve aktarım boyutu birlikte saklanıyor.
• —Aylık GB pazar bazında, ölçülmüş sayfa ağırlığı ve tekrar oranıyla hesaplandı; bütçe sayfa sayısına göre paylaştırılmadı.
• —Her pazarın günlük harcama sınırı ve kalan kota için eşik uyarısı tanımlı.
• —Zaman aşımı değerleri pazar bazında ayarlandı; uzak pazarlar için süre dökümü alındı.
• —Oturum gerektiren adımlar ayrıldı; static IPv4 olan pazarlarda aynı ülkenin static IP’sine taşındı, olmayanlarda karar yazılı.
• —Taramalar pazarların yerel saatine göre planlandı ve fiyat güncelleme saatleriyle çakışmıyor.
• —Her ülke alan adının robots.txt dosyası, kullanım koşulları ve hız sınırları ayrı ayrı gözden geçirildi; kişisel veri toplanmıyor.