競合他社の価格監視をプロキシを通じて行う: セラーのためのガイド

マーケットプレイスで販売していて、価格を手動で週に一度変更している場合、価格が毎時更新される競合があなたの販売を奪ってしまいます。独自の監視システムがこの問題を解決しますが、マーケットプレイスや競合のウェブサイトはボット、IPアドレス、データセンターのサブネットを積極的に禁止しています。この記事では、ブロックなしでデータを収集するための作業スキームを、適切なプロキシ、ツール、リクエストの頻度を選ぶ方法と共に解説します。

なぜ独自の競合監視システムが必要なのか

既存の価格監視サービス（市場には数十のサービスがあります）は、月額数千ルーブルからで、通常は商品数やデータ更新の頻度に制限があります。500〜5000 SKUのカタログを持ち、Wildberries、Ozon、Avitoで同時に販売している場合、3つの異なるサービスにサブスクリプションをする方が独自のシステムよりも高くなり、柔軟性も不足します: 価格の再計算のカスタムロジックを設定したり、競合の非標準サイトの監視を追加したりすることはできません。

独自のシステムには3つの具体的な利点があります。第一に、収集の頻度を制御できること — トップ競合の価格を15分ごとに確認し、他の競合は1日1回確認することができます。第二に、価格だけでなく、在庫、評価、レビュー数、検索結果での位置など、あなたのビジネスに重要な任意のパラメータを収集できます。第三に、データはあなたのものとして残ります: 内部のマージン分析と組み合わせて、価格を自動的に再計算し、赤字にならないようにすることができます。

競合の監視に基づいて自動的に価格を再計算したセラーは、平均してカテゴリーのトップ10のポジションの購入率を15〜25%向上させています。これは、価格が手動よりも市場の変化に迅速に反応するためです。これは特に競争が激しいカテゴリー（衣料品、電子機器、家庭用品）では重要です。

なぜウェブサイトやマーケットプレイスはパースを禁止するのか

Wildberries、Ozon、そしてほとんどのオンラインストアは、リクエストの挙動を分析するアンチボットシステムを使用しています。もし1つのIPから200リクエストが1分間に送信され、間隔がなく、ブラウザの特徴的なヘッダーがなく、JavaScriptが実行されていない場合 — これは瞬時にボットとしてマークされます。その後、システムはキャプチャを要求するか、意図的に不正確なデータ（偽の価格）を提供するか、数時間の間IPを禁止します。

別の問題は、データセンターのサブネットです。Amazon AWS、Google Cloud、DigitalOceanなどのプロバイダーに属するIPアドレスは、最初のリクエストを行う前にほとんどのアンチボットシステムのブラックリストに載っています。マーケットプレイスはプロバイダーのASN（自律システム番号）を確認し、たとえ1時間に1リクエストを送信しても、全範囲をブロックします。

そのため、マーケットプレイスの監視において、従来のサーバープロキシは効果が薄いのです: 速くて安価ですが、IPの評判レベルでバレてしまいます。回避するためには、通常のユーザーのように見えるIPが必要です — これが私たちが次に説明するスキームの鍵となるアイデアです。

システムのアーキテクチャ: 何から構成されているか

競合監視の作業システムは5つのブロックで構成されており、各ブロックは深いプログラミングスキルなしで構築できます — 既存のノーコードおよびローコードツールを使用して。

ターゲットリスト — 監視する競合の商品カードへのリンクを含むテーブル。通常はGoogleスプレッドシートやExcelで、列は: URL、マーケットプレイス、あなたのSKU、希望するチェック頻度です。
データ収集ツール（スクレイパー） — ページを開いて価格、在庫、評価を取得するプログラムまたはサービス。ノーコードのパーサーやPythonのスクリプトである可能性があります。
プロキシレイヤー — スクレイパーのすべてのリクエストが通過する層で、IPがマーケットプレイスによって禁止されないようにします。
データストレージ — 各通過の結果をタイムスタンプ付きで保存するデータベースまたはテーブル。
反応ロジック — システムがあなたに通知するルール（Telegramやメールで）またはマーケットプレイスのAPIを通じて自動的に価格を変更するルール。

スタートするには、Googleスプレッドシート + ノーコードパーサー（例えば、Make/Zapierや専門のパーシングサービスに基づく） + プロキシ + 通知用のTelegramボットの組み合わせで十分です。これをコードを書くことなく1日で構築できます。より大規模なスケール（数千SKU）には、requests/BeautifulSoupやSeleniumのライブラリを使用したPythonスクリプトが必要で、サーバー上でスケジュールに従って実行されます。

監視用のプロキシはどれを選ぶべきか

プロキシの選択は、システム全体の成功の70%を占めます。3つのタイプとそれぞれの適切な使用時期を見ていきましょう。

プロキシの種類	使用するタイミング	ブロックのリスク
データセンタープロキシ	アンチボットがない簡単なウェブサイト、小規模なオンラインストアの低頻度監視	マーケットプレイスでは高い、通常のサイトでは低い
レジデンシャルプロキシ	Wildberries、Ozon、Avito — マーケットプレイス監視の主なツール	適切なローテーションで低い
モバイルプロキシ	ボットからの強力な保護があるカードのポイントチェック、手動チェックでのキャプチャ回避	最小限だが運用コストが高い

WildberriesとOzonでの数千のカードの毎日の監視には、レジデンシャルプロキシが最適な選択です。なぜなら、これらのIPは実際の家庭用プロバイダーに属し、データセンターのブラックリストには載っていないからです。サーバープロキシよりも高価ですが、ブロックやキャプチャを回避する時間を節約でき、結果的にシステムの所有コストを削減します。

モバイルプロキシは、レジデンシャルIPがキャプチャを受ける場合のために予備として保持する価値があります — 例えば、強化された保護がある特定の難しい商品カテゴリーを監視する場合です。モバイルオペレーターのサーバーはCGNAT（数千の加入者に共通のIP）を使用しているため、そのIPの禁止は実際のユーザーにも影響を与え、プラットフォームは非常に慎重に扱います。

データ収集ツール

プログラマーでない場合、コードなしでシステムを構築する方法はいくつかあります。第一に、ノーコードのパーシングおよび価格監視サービスは、商品カードのURLを指定し、視覚的インターフェースを通じて価格のCSSセレクターを選択することを可能にします — ページの必要なブロックをマウスでクリックするだけです。第二に、Googleスプレッドシートと、スケジュールに従ってページをチェックし、結果をテーブルに記録するブラウザ拡張機能を組み合わせることができます。

チームに基本的な技術スキルを持つ人がいる場合、Pythonでのシステムは最大の柔軟性を提供します。最小限のスクリプトは次のようになります:

import requests
from bs4 import BeautifulSoup

proxies = {
    "http": "http://login:password@proxy_host:port",
    "https": "http://login:password@proxy_host:port",
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}

url = "https://example-shop.ru/product/12345"
response = requests.get(url, proxies=proxies, headers=headers, timeout=15)
soup = BeautifulSoup(response.text, "html.parser")

price = soup.select_one(".product-price").get_text(strip=True)
print(f"現在の価格: {price}")

価格をJavaScript経由で読み込むページ（WildberriesやOzonに特有）には、通常のrequestsは機能しません — SeleniumやPlaywrightに基づくヘッドレスブラウザが必要で、通常のユーザーのようにページを完全にレンダリングします。このアプローチは遅いですが、動的コンテンツでも正確なデータを提供します。

ローテーションとリクエストの頻度の設定

質の高いプロキシを使用していても、リクエストがあまりにも頻繁で均一である場合、システムは禁止される可能性があります。マーケットプレイスのアンチボットアルゴリズムは、IPだけでなく、リクエスト間の間隔、ページへのアクセス順序、ヘッダーの繰り返しを分析します。

ブロックのリスクを減少させるための効果的なローテーションルールは次のとおりです:

各リクエストごとにIPを変更するか、5〜10リクエストごとに変更します — ほとんどのレジデンシャルプロキシプロバイダーは、タイマーまたはリクエストに基づく自動ローテーションをサポートしています。
リクエスト間に3〜15秒のランダムな遅延を追加し、固定の間隔を避けます。
実際のブラウザのリストからUser-Agentを交互に使用します — 数千のリクエストに対して同じヘッダーを使用しないでください。
時間帯に応じて負荷を分散します: 00:00に全カタログを一度にチェックせず、数時間にわたってチェックを分散させます。
地理的に関連するIPを使用します — 競合がロシアで販売している場合、プロキシはロシアのジオロケーションでなければならず、さもなければ価格や在庫があなたの地域の実際のものと異なる可能性があります。

1,000〜3,000カードを1日で監視するには、数十の同時IPのプールが5〜10分ごとにローテーションするだけで十分です。より大規模なスケール（数万のチェック）には、大規模なレジデンシャルIPプールを持ち、データ収集スクリプトに直接IP変更を統合するためのAPIローテーションをサポートするプロバイダーが必要です。

Wildberries、Ozon、Avitoの監視の特徴

各プラットフォームには独自の保護の特性があり、スキームをそれに適応させる必要があります。

Wildberriesは、内部APIを介して価格と在庫のデータを提供します。これは直接呼び出すことができ、HTMLのパースを必要とせずにJSONレスポンスを取得できます。これは、ブラウザでページをレンダリングするよりも速く安定していますが、このAPIには1つのIPからのリクエスト頻度に制限があるため、1時間に50〜100商品以上を監視する場合はプロキシのローテーションが必須です。

Ozonは、JavaScriptレンダリングを積極的に使用し、マウスの動きやスクロール速度のチェックを含むボットに対するより攻撃的な保護を提供しています。Ozonを安定して監視するには、通常、実際のユーザーの行動をエミュレートするヘッドレスブラウザが必要であり、単なるHTTPリクエストでは不十分です。

Avitoは、主に1つのIPからのリクエスト頻度と広告検索パターンを監視しています。競合の広告を監視する（例えば、あなたのニッチでの新しい広告や価格の変更を追跡する）ためには、リクエストの頻度を低く保つことが重要です — 1つのIPから広告ごとに10〜15分ごとに1リクエストを超えないようにしないと、アカウントやIPがシャドウバンされ、明示的なエラーなしに不正確なデータが提供されます。

多くのSMMスペシャリストやアービトラージャーは、同様のタスクのためにDolphin Anty、AdsPower、Multiloginなどのアンチデテクトブラウザを使用しています — これらのツールは、競合のカードの手動チェックにも適しており、自動収集が疑わしいデータを示す場合に、別のプロファイルを介して手動で確認するために使用できます。

データの保存とダッシュボード

収集したデータは、便利な分析方法がなければ無意味です。小規模なカタログ（500 SKUまで）には、日付ごとの価格履歴を持つGoogleスプレッドシートで十分であり、競合の価格変更を赤または緑でハイライトする条件付き書式を使用します。より大規模なボリュームには、PostgreSQLやSQLiteなどのデータベースが必要です。システムが1つのサーバーで動作する場合はSQLiteでも適しています。

収集したデータに基づいて、Google Data Studio（Looker Studio）やPower BIでシンプルなダッシュボードを構築するのが便利です。ここでは、競合の価格の過去30日間の動向、あなたのポジションに対する価格の差、各競合の価格変更の頻度が表示されます。この視覚化は、パターンを把握するのに役立ちます — 例えば、競合が毎週月曜日の朝に価格を変更する場合、あなたはそのサイクルに合わせて戦略を調整できます。

現在の価格だけでなく、すべての変更履歴をタイムスタンプ付きで保存することが重要です。これにより、後で季節性を分析し、セール前のダンピングを特定し、次の類似の期間（例えば、11.11やブラックフライデーの前）に競合の行動を予測することができます。

システム構築時のよくある誤り

実際には、ほとんどの自作の監視システムは、事前に簡単に回避できるいくつかの典型的なエラーのために壊れてしまいます。

監視全体で1つのIPを使用する。 質の高いプロキシでも、ローテーションなしで何千ものリクエストが行われると、早かれ遅かれ禁止されます。
ブラウザのヘッダーを無視する。 User-Agentなしのリクエストや古いヘッダーを使用することは、アンチボットシステムに対する瞬時の信号です。
チェックの頻度が高すぎる。 毎分の監視は、5〜10の主要な競合に対してのみ意味があります。他のカタログには数時間ごとのチェックで十分です。
エラー処理がない。 サイトがキャプチャを返すか、一時的に利用できない場合、システムはそれを認識し、後で再試行する必要があります。空の値や誤った値を現在の価格としてデータベースに記録してはいけません。
マーケットプレイス用にデータセンタープロキシを使用する。 プロキシの種類を節約すると、常に禁止され、毎日手動でIPを変更する必要が生じます — 結局、システムは必要以上に手動作業を要求します。

結論

マーケットプレイスでの競合監視の独自システムは、一度きりの設定ではなく、正しいアーキテクチャを必要とする作業ツールです: ターゲットリスト、スクレイパー、プロキシレイヤー、データストレージ、変化に対する反応ロジック。全体の安定性を左右する重要な要素はプロキシです。サーバーIPはWildberriesやOzonのアンチボットシステムによって迅速に禁止されるため、定期的なマーケットプレイスの監視には、ローテーションを伴う質の高いIPを予算に組み込むべきです。

Wildberries、Ozon、またはAvitoでの競合の価格監視を計画している場合は、レジデンシャルプロキシから始めてください — これにより、収集したデータの信頼性が高まり、適切なローテーションを行えばブロックのリスクが最小限に抑えられます。最も保護されたカードのポイントチェックには、モバイルプロキシを予備として保持し、より保護されていないサイトでの補助的なタスクには、より予算に優しいデータセンタープロキシも適しています。