無料トライアルは固定された少量の帯域幅であり、それをどう使うかによって何かを学べるかどうかが決まる。よくあるやり方は、IPアドレスを返すだけのテスト用エンドポイントにアクセスして、アドレスが変わることを確認し、プロキシが機能していると結論づけることだ。それでは本当に知る必要があることはほとんど分からず、結局は実際に重視しているサイトで期待外れに終わるプランを購入してしまう原因になる。
トライアルが答えるべき問いは一つだけだ。自分のターゲットで、自分の量で、自分の市場で、これは機能するのか。以下は、帯域幅が尽きる前に好奇心が尽きた場合に備えて、価値の高い答えから先に得られる順に並べてある。
始める前に：無駄にしないための準備
準備に2分かけるだけで、トライアルの価値は変わる。
自分の本当のターゲット、プロジェクトが依存している実際のサイトやエンドポイントを書き出し、簡単なものだけでなく最も難しいものも含めること。自分の本当の市場、必要な具体的な国、関連があれば都市も書き出すこと。そして事前に、合格とは何を意味するかを決めておくこと。例えば、2か国からの主要ターゲットで有効な応答が90パーセントといった具合だ。事前に閾値を設定しておけば、後になって平凡な結果を正当化することを防げる。
次に、最初のリクエストを送る前にレスポンスの検証を用意する。これは最も重要な準備段階だ。なぜなら、チャレンジページ、空の結果、切り詰められた一覧、あるいは汎用ページへのリダイレクトは、しばしば200ステータスとともに返ってくるため、ステータスコードだけを数えるテストは何も収集していないのに成功と報告してしまうからだ。本当に良好なページにのみ現れるマーカーを確認すること。期待される要素、妥当なコンテンツ長、JSON内の既知のフィールドなどだ。こうした失敗パターンはdetecting blocked or fake contentにまとめられている。
import requests
PROXY = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"
PROXIES = {"http": PROXY, "https": PROXY}
def is_valid(html):
return "product-price" in html and len(html) > 20_000 # your own marker
ok = 0
for i in range(100): # a small, honest sample
r = requests.get("https://your-real-target.example/item/123",
proxies=PROXIES, timeout=20)
if r.status_code == 200 and is_valid(r.text):
ok += 1
print(f"validated success rate: {ok}%") # not "did it return 200"テスト1：自分のターゲットでの成功率
これは他のすべてを合わせたよりも重要なテストであり、トライアルの大部分をこれに費やすべきだ。
各実ターゲットに対して、100リクエスト程度の意味のあるサンプルを実行し、HTTPの成功率ではなく検証済みの成功率を測定する。最も防御が固いターゲットを含めること。簡単なサイトは処理できても難しいサイトで崩れるプールは、自分の問題を解決するプールではないからだ。現行のセットアップがあるなら、同じサンプルをそこにも通して対照群とし、推測ではなく比較を行う。
実行中に成功率が高い状態から始まり、徐々に低下していくパターンに注意すること。これは通常、プールが悪いのではなく、ターゲットに対して自分のペースが速すぎることを意味する。これは本番環境ではなくトライアル中に学んでおくべきペース配分の教訓だ。
テスト2：地理的な正確性
プロジェクトが位置情報に依存している場合(ほとんどの場合そうだが)、リクエストした国が実際に得られる国であることを確認し、都合の良い一例だけでなく、実際に必要なすべての市場をチェックすること。プールはある地域では優れていても別の地域では薄いことがあり、マーケティングページのグローバルな数値は、実際に収集する特定の場所について何も教えてくれない。
確認する価値のあるレベルは二つある。第一に、出口アドレスがリクエストした国に地理的に一致するかどうかを、不整合を捉えるのに十分な数のリクエストでサンプリングして確認する。第二に、より意味のあることとして、ターゲットサイトが実際にそこにいるかのように振る舞うかどうかだ。正しい通貨、現地価格、地域ごとのカタログ、現地の検索結果などだ。二番目こそが本当のテストである。なぜなら、IPの地理情報データベースとターゲット自身の判断は必ずしも一致せず、料金を支払っているのはターゲット自身の判断に対してだからだ。city-level targetingが必要な場合は、国レベルの正確さから都市レベルの正確さを推測せず、都市の粒度で検証すること。
テスト3：そのプールは謳い通りのものか
出口アドレスをサンプリングし、それが属する組織ごとにグループ分けするために少し帯域幅を使う価値がある。個人向けインターネットプロバイダが見たいものだ。ホスティングやクラウド系の組織が有意な割合を占めているなら、そのプールはデータセンター系のアドレスで薄められていることを意味する。これは重要な問題だ。なぜなら、そうしたアドレスはターゲット側が機械的なトラフィックとして扱うものだからだ。詳しい方法はspotting datacenter IPs sold as residentialにあり、背景となる区別はthe anatomy of a residential IPにある。
ついでに、アドレスの品質はアドレスの種類とは別の軸であることに注意すること。本当にレジデンシャルであるプールでも、乱用されてreputationが悪化していれば、依然としてチャレンジを引き起こす。これはまさにテスト1が外部から測定している内容だ。
テスト4：セッションの挙動
プロジェクトの一部にマルチステップのフロー、ページ送りのある検索、ログイン、設定してから読み取る位置情報コンテキストなどが含まれる場合、トライアル中に二つのことを確認すること。
セッションを指定しない場合にローテーションが実際に機能すること、そしてsticky sessionが必要な期間、実際に一つのアドレスを保持することを確認する。次に、保持したセッションで実際のマルチステップシーケンスの一つをエンドツーエンドで実行すること。プールは単発のリクエストでは問題なく見えても、下でアドレスが変わってしまうとフローが壊れることがあるからだ。同時に多数のIDを保持する必要がある作業なら、並行セッションが独立して動作することを確認すること。
テスト5：パフォーマンスと消費量
記録すべき二つの数値があり、どちらも最終的に購入するプランに影響する。
作業が時間に敏感なら、レイテンシとスループットが重要になるため、速度テスト用のエンドポイントではなく、実際のターゲットでプロキシ経由の応答時間を測定すること。トラフィックがより長い経路を通るため、レジデンシャルは直接接続より遅くなることを想定しておく。重要なのは、データセンターのベンチマークに匹敵するかどうかではなく、自分の作業にとって十分な速さかどうかだ。測定方法はtesting speed, success rate, and location accuracyにある。
次に、リクエストあたりのバイト数を測定する。これがプランの見積もりをプランの意思決定に変える数値だ。測定した平均値に予想される月間リクエスト量を掛ければ、推測ではなく実際の帯域幅の数値が得られる。これがestimating monthly bandwidthへの入力となる。もし結果が思わしくないなら、フルページをレンダリングする代わりにデータエンドポイントを取得することで一段階下のティアに移行できることに気づく瞬間でもある。詳しくはcutting proxy bandwidth costsを参照。
トライアルで無駄にすべきでないこと
いくつかのことは、帯域幅を消費するだけで何も教えてくれない。
IPエコーエンドポイントに対するテストは、プロキシが接続していることを証明するだけであり、30秒の健全性チェックにすぎず、評価ではない。簡単なターゲットだけをテストすることは、プールを実際より良く見せかけ、本当に必要な答えを隠してしまう。一つのターゲットに膨大な量を流すことは品質を測定するものではなく、そのアドレスをブロックされる原因になりかねず、結果としてプールが実際より悪く見えてしまう。そして、わずか数件のリクエストで判断すればノイズしか得られない。5件のサンプルでは、95パーセントのプールと70パーセントのプールを区別できないからだ。
もう一つ。プールサイズの主張だけでプロバイダを評価しないこと。見出しの数値はトライアルで検証できるものではなく、結果を左右するものでもない。重要なのは、自分の国での密度と、自分のターゲットでの成功率だ。
トライアルのチェックリスト
- 準備する：最も難しいものを含む実際のターゲット、実際の市場、合格の閾値、そして最初のリクエストより前に書いておくレスポンスの検証。
- 検証済みの成功率を測定する。ターゲットごとにおよそ100リクエスト、対照群があればそれも使う。
- 必要な市場ごとに地理情報を検証する。出口の位置とターゲット側の挙動の両方を確認する。
- 出口組織をサンプリングし、プールが本当にレジデンシャルであることを確認する。
- スティッキーセッションで実際のマルチステップフローを一つ実行し、セッションなしでのローテーションも確認する。
- リクエストあたりのレイテンシとバイト数を記録し、測定した数値からプランのサイズを決める。
トライアルが自分のターゲットでこの6項目すべてに合格すれば、プランの決定は勘に頼るものではなく算術になる。プランレベルの選択肢の全体像はchoosing the right residential proxy planにある。
まとめ
トライアルとは帯域幅であり、IPエコーエンドポイントに使われた帯域幅は、そもそも持っていなかった問いに答えるだけだ。実際のレスポンス検証を伴う実際のターゲットに使い、実際に必要な市場を検証し、プールが本当にレジデンシャルであることを確認し、作業にセッションフローがあればそれを実行し、リクエストあたりのバイト数を記録して測定に基づいてプランをサイズ決めすること。合格の閾値は始める前に設定すること。それを行えば、そのプロダクトが自分の問題を解決するかどうかを知った上でトライアルを終えられる。それこそがトライアルの唯一の目的だ。
このチェックリストを実行したいなら、free trial of Shifter residential proxiesで試すことができる。国および都市単位のターゲティング、デフォルトでのローテーション、必要なフローのためのスティッキーセッションを備えている。数値が出そろえば、per-GB pricingにより、選ぶプランは推測ではなく測定した帯域幅に基づいたものになる。