フィルターとソートがURL内でページの重複を生み出し、パーサーの制限を消費する理由

条件付きの例で計算してみましょう。カテゴリに500のユニークな商品があると仮定しますが、8つのソートオプションと12の人気フィルターの組み合わせのため、URLの正規化なしでパーサーは500ではなく4000-5000ページを回避し、同じカードに再度アクセスします。もし1つのリクエストが居住者プロキシを介して1単位のトラフィックであるなら、単純な回避では、同じ量のユニークデータを取得するために必要な8-10倍のコストを消費します。

さらに悪いことに、同じIPからの類似URLへの再リクエストは、アンチボットシステムにとって典型的なパターンです。リクエストの頻度と均一性が高いほど、保護が迅速に作動します。結果として、閉じたループが形成されます: 重複がリクエストの数を増加させる → プロキシプールへの負荷が増加する → IPがより早く禁止される → プロキシを頻繁に変更し、収集を再起動する必要がある → 最終的なパーシングの時間とコストがさらに増加する。

実際には、セラーはWildberriesで200の競合の価格を1日1回監視したいが、URLがクリーンでないため、彼のスクリプトは2,000ではなく15,000のリクエストを行い、プロキシプールの制限に達し、朝ではなく夕方に不完全なデータを得ることになります。

パーサーを起動する前に重複を検出する方法

収集をスケールアップする前に、ターゲットサイトのURL構造を分析するために1時間を費やす価値があります。以下は実践的な手順です:

1. ブラウザでターゲットカタログを開き、フィルターとソートを手動で確認し、アドレスバーに現れるパラメータを記録します。
2. 出力に影響を与えないパラメータ（例えば、UTMパラメータ）を追加したときにページの内容が変わるか確認します — 内容が同じであれば、このパラメータは収集時に無視する必要があります。
3. ページのソースコードでrel="canonical"を確認します — サイトはしばしば重複するバリエーションの「主要な」URLを示唆します。
4. 100-200のURLからなる小さなテストサンプルを収集し、主要なパラメータに基づいて簡単な重複排除を実行します — リストがどれだけ短縮されるかを確認します。
5. robots.txtを確認します — 時には、パラメータ付きURLに対するDisallowの指示がすでに記載されていることがあり、これも「ゴミ」と見なされるパラメータを示唆します。

URLの正規化: ルールと例

正規化とは、URLを一貫したカノニカル形式に変換することです。その後、回避する必要があるかどうかを判断します。基本的な原則は、「重要な」パラメータ（例えば、ページネーションのページ番号やカテゴリ）を特定し、「重要でない」パラメータ（ソート、UTM、セッション識別子）を除外することです。

Wildberriesのようなカタログに対する正規化ルールの実践的な例:

import urllib.parse as up

IGNORED_PARAMS = {"sort", "utm_source", "utm_medium", "utm_campaign", "clid", "_openstat"}

def normalize_url(url: str) -> str:
    parsed = up.urlparse(url)
    query = up.parse_qsl(parsed.query)
    # 重要なパラメータのみを残し、他は除外
    filtered = [(k, v) for k, v in query if k not in IGNORED_PARAMS]
    filtered.sort()  # パラメータの順序を一貫した形式にする
    new_query = up.urlencode(filtered)
    return up.urlunparse(parsed._replace(query=new_query))
  

正規化後、異なるソートを持つ同じリスティングのすべてのバリエーションが1つのURLに統合されます。プロキシを介してリクエストを送信する前に、パーサーはこの正規化されたアドレスが既に存在したかどうかを確認します — もしそうであれば、スキップします。これは、データの完全性を損なうことなくリクエストの数を減らす最も安価な方法です。

簡単なケースでは、このロジックをコードなしで実装することも可能です — パーシングツールの設定を通じて、「パラメータを無視する」を指定し、リストを列挙するか、URLのクエスチョンマークの後の尾を切り取るための正規表現を指定します。パラメータがあなたのタスクにとって重要な情報を持たない場合。

パーサーをパラメータを無視するように設定する

マーケットプレイスからデータを収集するためのほとんどの既製ソリューションやパーシングツールは、プロジェクト設定のレベルでURLパラメータの除外ルールをサポートしています。最初に確認し、設定するべきことは以下の通りです:

• 無視するパラメータのリスト。 分析段階で見つかったすべてのソート、UTMパラメータ、セッション識別子をここに追加します。
• 正規化されたURLのハッシュによる重複排除。 多くのパーサーは、すでに訪問したアドレスのリストを保持しています — 比較は元の文字列ではなく、正規化されたバージョンで行うことが重要です。
• フィルターの深さ制限。 もしタスクがカテゴリの品揃えを収集することであれば、ソートやフィルターなしで1回の「基本的な」通過で十分であり、すべての組み合わせを再帰的に回避する必要はありません。
• フィルターよりもページネーションを優先。 サイトがページネーションを通じて商品の完全なリストを提供する場合、通常はそれで十分です — 同じリストをフィルターを適用して別々に回避するのは過剰です。

このように設定した後、リクエストの量は通常、ソースサイトのカタログが「パラメータ化」されている程度に応じて3-6倍削減されます。

パーシングのスケーリングにおけるプロキシの役割

URLの正規化が完璧であっても、WildberriesやOzonの大規模なカタログのパーシングには、多数のIPアドレス間でリクエストを分散させる必要があります — さもなければ、アンチボット保護がすぐに1つのソースからの異常なアクティビティを追跡します。ここでは、タスクに適したプロキシのタイプを正しく選択することが重要です。

商品カードの大規模な収集や価格の監視において、ボリュームと速度が重要で、合理的なコストであれば、通常はデータセンターのプロキシで十分です — 彼らは居住者のものよりも速く、安価で、1日に数百万のリクエストを処理する際には重要です。しかし、サイトの保護がデータセンターのIP範囲を積極的に禁止する場合は、居住者プロキシに切り替えるべきです。これらは実際のプロバイダーからの通常のユーザーのように見え、疑いを持たれることが少なくなります。

特定のタスク、例えば特定の地域でモバイルデバイスから特定の商品価格がどのように表示されるかを確認する場合には、モバイルプロキシが役立ちます。これらは携帯電話のオペレーターを介した接続をエミュレートし、ほとんどの場合、大規模にブロックされることはありません。

重要なのは、適切なプロキシの選択はURLの正規化を置き換えるものではなく、それを補完するものであるということです。重複をクリーンアップせずに、最も質の高いIPアドレスプールをより早く消費してしまうことになります。最初に無駄なリクエストの数を減らし、その後、残りをプロキシのローテーションでスケールアップする — この順序が最大のコスト削減をもたらします。

データ収集を開始する前のチェックリスト

パーサーを本格的に起動する前に、短いチェックリストを確認してください:

結論

フィルター、ソート、サービスパラメータは、マーケットプレイスのパーシング時に無駄なトラフィックの主要な源の1つであり、URLの正規化なしでは、パーサーは必要なデータを取得するために必要なリクエストの5-10倍を行う可能性があり、これはプロキシの予算、収集速度、ブロックのリスクに直接影響します。

解決策は簡単に見えますが、準備段階での規律が必要です: ターゲットサイトのURL構造を分析し、どのパラメータがコンテンツに影響を与えるか、どのパラメータが影響を与えないかを特定し、正規化されたアドレスによる重複排除を設定し、その後にプロキシのローテーションを通じて収集をスケールアップします。あなたのタスクがWildberries、Ozon、またはAvitoでの価格と品揃えの安定した監視であれば、最初に居住者プロキシを使用することをお勧めします — これはアンチボットシステムの信頼性と特定のタスクに対する柔軟性の最良のバランスを提供します。