Brave Search için Proxy: Bağımsız Dizin, Sorgu Kontrolü ve Ölçüm

Brave Search’ü diğer gizlilik odaklı ön uçlardan ayıran şey, sonuçların büyük bölümünü başka bir motordan devralmak yerine kendi tarama ve dizinleme altyapısından üretmesidir. Katılımcı tarayıcılardan gelen anonim katkılarla beslenen bu dizin, kullanıcı hesabı olmadan çalışır.

Proxy açısından sonuç sade bir tabloya dönüşür: sunucu tarafında sizi tanımlayan kalıcı bir profil yoksa, isteği sınıflandıran sinyaller çıkış adresiniz, bağlantının taşıdığı başlıklar ve adres çubuğundaki parametrelerden ibaret kalır. Üçünü de kontrol edebilirsiniz.

Aşağıdaki bölümler bu üç sinyali tek tek ele alıyor; ardından kurulum, doğrulama ve tempo yönetimi geliyor. Karşılaştırma yapacaksanız her motorun sonucu nereden ürettiğini ayrı ayrı öğrenmek gerekir; sonuç kaynağı değiştikçe proxy kararının ağırlığı da değişir.

Bir sorgu ön uca ulaşana kadar nereden geçer?

İstek tarayıcıdan çıktığında üzerinde üç tür bilgi taşır: hedef adres, bağlantıyı kuran ağ kimliği ve isteğin başlıkları. Proxy yalnızca ikincisini değiştirir. Dil listesi, istemci tanıtım başlıkları (user-agent ve düşük entropili client hints) ve varsa yerel tercihler değişmeden kalır; ekran ölçüsü ise başlıkta değil, sayfadaki betiklerin okuduğu görüntü alanı değerinden anlaşılır. Tarayıcı, görüntü alanı ya da piksel yoğunluğu gibi ipuçlarını istek başlığında ancak site bunları Accept-CH ile açıkça istediğinde taşır; varsayılan durumda taşımaz. Bu yüzden çıkışı değiştirmek tek başına “başka bir kullanıcı” görünümü üretmez.

İkinci durak proxy sunucusudur. HTTPS trafiğinde burada yapılan tek şey CONNECT ile bir tünel açmak ve şifreli baytları taşımaktır; içerik okunmaz. Ön uç, isteğin bu sunucudan geldiğini görür ve adresin ait olduğu ağı sınıflandırabilir. Sınıflandırmanın dayanağı otonom sistem bilgisidir (ASN ve IP itibarı).

Üçüncü durakta sorgu dizinde karşılığını bulur. Kendi dizininden gelen sonuçlarla dış kaynaklardan tamamlanan sonuçlar aynı sayfada birleşebildiği için, iki farklı çıkıştan alınan listeler arasındaki küçük farkları doğrudan “bölgesel fark” diye yorumlamayın. Önce aynı çıkışla iki tur alıp taban gürültüyü ölçün, sonra çıkış değiştirin.

Dar ekran şablonu sonuç kümesini değil yerleşimi değiştirir

Bağımsız bir dizinde sorgunun karşılığı tek bir yerde üretilir; dar ekrana geçtiğinizde değişen şey bu karşılığın kendisi değil, sunulma biçimidir. Dönen alan adları büyük ölçüde aynı kalır, buna karşılık yerleşim sıkışır, yan bloklar listenin içine taşınır ve ilk ekranda görünen satır sayısı düşer. Ayrım pratikte şuraya oturur: ölçtüğünüz büyüklük “kaçıncı sıradaydı” ise iki şablon çoğu turda aynı cevabı verir; “ilk ekranda mıydı” ise cevap doğrudan şablona bağlıdır. Sıra takibini tek seride yürütebilirsiniz, görünürlük takibini yürütemezsiniz.

İkinci ve daha az bilinen mesele, filtre durumunun dar ekranda nasıl taşındığıdır. Bir Goggle ya da güvenli arama seçimi sorgunun bağlantısına iliştirilir; şablon değişse bile bağlantı aynı kaldığı sürece kural uygulanmaya devam eder. Sorun, dar ekranda bağlantının elle kısaltılmasıyla veya arayüzdeki kısayoldan sorgunun yeniden sorulmasıyla ortaya çıkar: kural sessizce düşer, sıralama sade hâline döner ve bu geri dönüşü şablon farkı sanarsınız. Turu kapatmadan önce açık kural adının ekranda hâlâ durduğunu doğrulayın ve tur kaydına yazın.

Şablon tarafı ile ağ tarafı ayrı kararlardır: operatör ağından gelen bir isteğin nasıl karşılandığını ölçmek istiyorsanız konu artık yerleşim değil çıkışın sınıfıdır ve mobil proxy bunun için ayrı bir seri olarak kurulur.

İki seri yürütmeye karar vermeden önce şunu netleştirin: raporunuzda dar ekran çıktısı kendi başına bir satır mı, yoksa geniş ekran sonucunun teyidi mi? Teyit amaçlıysa haftada bir alınan örnek tur yeterlidir ve her turda iki şablonu birden çalıştırmanız gerekmez. Kendi başına bir satırsa iki seriyi baştan ayrı adlandırın; sonradan birleştirilen iki seri, arada şablon değiştiği için geriye dönük olarak ayrıştırılamaz.

Son olarak veri hacmini hesaba katın. Dar ekran şablonu genellikle daha az görsel taşır, ama iki seriyi paralel yürütmek toplam aktarımı ikiye katlar. Kota üzerinden ücretlendirilen bir havuzda bu fark aylık faturada görünür; seri sayısını ihtiyacınıza göre sınırlayın ve kullanılmayan profilleri kapatın.

Operatörler ve Goggles ile sonucu daraltmak

Ölçümde gürültüyü azaltmanın en ucuz yolu, ağ tarafında değil sorgu tarafında çalışmaktır. Tırnak içinde birebir ifade aramak, tek bir alan adıyla sınırlamak için site: kullanmak ya da istenmeyen bir terimi dışarıda bırakmak, iki tur arasındaki farkın kaynağını daraltır. Sorgu ne kadar belirginse, çıkışı değiştirdiğinizde gördüğünüz fark o kadar yorumlanabilir olur.

Brave Search bunun üstüne Goggles adı verilen bir katman koyar: sonuç kümesini yeniden sıralayan, herkese açık kural setleri. Bir Goggle, belirli alan adlarını öne çeker ya da geri iter; sorgu aynı kalırken sıralama ölçütü değişir. Ölçüm yaparken hangi Goggle’ın açık olduğunu kaydetmezseniz, iki tur arasındaki farkı çıkış ülkesine bağlama riskiniz vardır.

Üçüncü değişken arayüzdeki bölge ve dil seçicileridir. Bu seçiciler, çıkış adresinden bağımsız olarak listeyi başka bir pazara çevirebilir. Çıkış ülkesiyle seçici çelişirse ortaya çıkan tablo hiçbir gerçek kullanıcının görünümü değildir; ikisini birlikte ayarlayın ve kayda ikisini birden yazın.

Operatör kullanımının ölçüm dışında bir faydası daha vardır: sonucu daraltmak, gönderdiğiniz istek sayısını da düşürür. Beş geniş sorgu yerine iki keskin sorgu yazmak hem yorumlaması kolay bir çıktı verir hem de çıkışınızdan geçen trafiği azaltır. Kota üzerinden ücretlendirilen havuzlarda bu doğrudan maliyet kalemidir (bant genişliği hesaplama).

• Sorgu setini operatörleriyle birlikte dondurun; sonradan operatör eklemeyin.
• Açık olan Goggle veya filtre adını her turda kaydedin.
• Bölge seçicisini çıkış ülkesiyle aynı yöne ayarlayın.
• Güvenli arama düzeyini sabitleyin; kapalı–açık geçişi kümeyi değiştirir.

Hangi çıkış türü hangi işe oturur?

Çıkış türü seçimi iki eksen üzerinde düşünülür: havuzun ne kadar geniş olduğu ve tek bir adreste ne kadar kalabildiğiniz. Bu iki özellik birbirinin tersine çalışır. Geniş bir havuz sizi tek adrese bağlı kalmaktan kurtarır ama her istekte başka bir adresten çıkmak oturum tutarlılığını bozar.

Uzun süren bir izleme serisinde adreste kalma genellikle ağır basar. Tek bir ISP çıkışı ile aylarca aynı pencereden bakmak, her turda başka bir adresten çıkmaktan daha okunabilir bir seri üretir. Buna karşılık farklı şehirlerin çıktısını yan yana koyacaksanız residential havuzun şehir kırılımı gerekir.

Rotating kurulum ise oturum taşımayan, açık veri okuyan işlerde yükü dağıtmak için uygundur. Her istekte adres değiştiren bir kurulumu sıralama takibinde kullanmak, ölçümün kendisini gürültü kaynağına çevirir: iki tur arasındaki farkın motorun hareketinden mi, yeni çıkıştan mı geldiğini ayıramazsınız.