すでにマーケットプレイスのデータを収集しているチームは、Walmartに対してもAmazonと同じやり方で臨みがちですが、その結果出てくる数字は見過ごしやすい形で間違っています。エラーは何も出ません。価格ももっともらしく見えます。ただ、ダラスやタンパの買い物客が実際に目にするものとは一致しておらず、しかもその不一致はランダムではなく体系的なものです。
理由は構造的なものです。Walmartは全国共通のカタログではなく、ウェブサイトを前面に据えた店舗網です。価格と在庫は特定の店舗に対して解決され、その店舗はあなたがコントロールしていないかもしれないシグナルから、あなたの代わりに選ばれます。
店舗こそが真実の単位である
品揃えの大部分において、次の3つは店舗ごとに変動します。
価格。 Rollback、クリアランス、地域別価格設定により、40マイル離れた2つの店舗で同じ商品が異なる価格になることがあります。
在庫。 店舗内在庫は定義上ロケーションごとのものであり、提供される配送・受け取りオプションは、セッションがどの店舗とどのフルフィルメントセンターに紐付いているかに依存します。
品揃え。 一部の商品はそもそも一部の店舗では取り扱われておらず、これは在庫切れではなく商品自体が存在しないという扱いになります。
収集レイヤーが店舗を固定していない場合、サイトはリクエストの見かけ上のロケーションに基づいて店舗をあなたの代わりに選び、それは明日には別の店舗になっているかもしれません。結果として得られる時系列データは、価格変動の一部が本物で、一部はあなたの知らないうちに店舗が入れ替わったことによるものになります。これはデータが欠落しているよりも悪い状態です。なぜならトレンドのように見えてしまうからです。
同じ落とし穴は、地域ごとにフルフィルメントを行う小売業者すべてに当てはまります。この議論の一般的なバージョンは製品の在庫状況の監視にあります。
どの店舗になるかを決める2つのシグナル
あなたのリクエストが由来しているように見えるロケーション、つまりIPアドレスとそのジオロケーションと、セッション内で明示的に選択する店舗またはZIPコードとがあります。これらは異なる仕組みであり、互いに一致している必要があります。
バージニア州のデータセンターIPが、フェニックスの店舗を主張するセッションと組み合わさっているのは、一貫性のない組み合わせです。それでも動くことはありますが、静かに別のものへ解決されることもあり、これはまさに小売業者のアンチボットシステムが重く扱う類のシグナルです。問い合わせている都市圏のレジデンシャルIPを使えば、この組み合わせに一貫性が生まれます。これが要点です。あなたはロケーションを主張しているのではなく、買い物客を再現しているのです。
地理を固定し、そのうえでセッションを固定する
Shifterのゲートウェイでは、ターゲティングは別のAPI呼び出しではなくユーザー名の中に記述します。p.shifter.io:443 を指定し、ロケーションとセッションを認証情報にエンコードします。
customer-USERNAME-country-us-city-dallas-sid-store2354-ttl-600:PASSWORDここで重要な部分は3つです。country-us と city-dallas は出口を正しい都市圏に置きます。sid-store2354 はスティッキーセッションに名前を付け、その識別子でタグ付けされたすべてのリクエストが同じIPから出ていくようにします。ttl-600 はそのIPを10分間保持し、店舗を選択し、カテゴリを巡回し、一連の商品ページを読む間、途中でロケーションが変わらないようにするのに十分な長さです。
ttl は sid と組み合わせて初めて意味を持つ点に注意してください。セッション識別子がなければ維持すべき対象がなく、デフォルトのローテーションが適用されます。
持つべきメンタルモデルは、リクエストごとに1つのセッションではなく、店舗ごとに1つのスティッキーセッションを、その店舗についてチェックする商品全体で使い回すというものです。すべての商品ページの間でローテーションするのはここで最もよくある設定ミスです。なぜなら、それは店舗の解決を絶えず再トリガーし、あなたが排除しようとしていたまさにそのドリフトを生み出すからです。トレードオフについてはスティッキーセッションとローテーティングセッションの比較にまとめられています。
都市名はスペースをアンダースコアに置き換えた小文字表記を使い、国はISO alpha-2コードを使います。フィルタが狭すぎて条件を満たせない場合、ゲートウェイは他の場所の出口を黙って渡すのではなく502を返します。これは、店舗の正確性がすべてを左右する場合に望ましい挙動です。
価格だけでなく店舗も記録する
Walmartのパネルの成否の大半はスキーマで決まります。「商品Xは火曜日に14.98ドルだった」という行は、価格を決定づける要素を欠いているため、使える観測データではありません。
最低限、次を記録してください。
- 商品識別子
- セッションが実際に解決された先の店舗識別子
- 価格、および取り消し線価格や以前の価格があれば別途
- 在庫状態(店舗内、受け取り、配送に分けたもの)
- 出品者(サードパーティ出品はファーストパーティ出品とは異なる挙動をするため)
- リクエストが出ていった国と都市
- UTCでの収集タイムスタンプ
店舗識別子は、リクエストしたものと仮定するのではなく、レスポンスから読み取るべきです。この1つのフィールドだけで、説明のつかない価格の急変が可視化された店舗変更に変わります。これが、防御可能なパネルと謝罪しなければならないチャートとの違いです。
チェックが失敗する4つのパターンを区別する
小売業者の収集では、分離しない限りすべて「データなし」に見える失敗モードが発生します。
ブロックされた。 チャレンジやインタースティシャルを受け取った。観測データは欠落しており、そのアイテムは在庫切れとして記録するのではなく、再試行すべきです。
在庫切れ。 この店舗ではアイテムが利用できないと表示された有効なページ。これは本物のデータであり、系列に含めるべきです。
取り扱いなし。 その店舗の品揃えにアイテムが存在しない。これも本物のデータですが、在庫切れとは別物です。
間違った店舗。 ページはレンダリングされたが、あなたが要求したのではない店舗に対してのものだった。これは危険なパターンです。なぜなら、見た目はきれいだが値が間違っている行を生み出すからです。
再試行が正当化されるのは最初のケースだけです。真ん中の2つを混同すると、本物の品揃えの違いが平坦化されてしまい、4番目を有効なものとして扱うことが、ダッシュボードに悪い数字が届く原因になります。トランスポート側では、407は認証情報または不正な形式のターゲティングフラグを、502は条件に一致する出口がないことを、509は帯域幅の割り当てが尽きたことを意味します。
頻度、そしてなぜそれは地味であるべきか
価格パネルには高頻度化への強い誘惑があります。それには2つの理由から抵抗すべきです。
第一に、小売サイトに対するリクエスト量は、収集パターンが気づかれる最も可能性の高いシグナルであり、解決策はIPを増やすことではなく、一斉スキャンではなく需要らしく見えるスケジュールを組むことです。チェックを一日に分散させ、店舗ごとの同時実行数を控えめにし、エラー時には力任せに続けるのではなく引くべきです。この仕組みについてはレート制限とリクエストスロットリングで扱っています。
第二にコストです。レジデンシャルトラフィックは帯域幅で課金されるため、レバーは1時間あたりのリクエスト数ではなく、1回の観測あたりのバイト数です。画像はスキップし、必要なフィールドを含む最も軽いレスポンスを優先し、3つのアイテムしか必要ないのにカテゴリページ全体を再取得しないようにしてください。より詳しい対処法はプロキシの帯域幅コストを削減するにあります。
ほとんどの小売パネルでは、店舗ごと・アイテムごとに1日1回の読み取りで、重要な変動を検知するのに十分です。より速い頻度は、高価値アイテムの小規模なウォッチリストのために取っておきます。
Walmartパネルのサイジング
帯域幅は、追跡アイテム数、追跡店舗数、1日あたりのチェック数、1回あたりのバイト数という単純な積で決まります。店舗の乗数は人々が忘れがちなものであり、最も急速に増加するものでもあります。5000アイテムのパネルに20の都市圏を追加すると、1パスあたり10万件の観測になるからです。
まず、実際に意思決定を行っている市場を反映した狭い店舗セットから始め、1週間分の実際のチェックあたりバイト数を測定してから拡張してください。実践的な方法は月間レジデンシャルプロキシ帯域幅の見積もりにあり、現在の料金はレジデンシャルプロキシの料金ページにあります。
FAQ
セッション内ですでにZIPコードを選択している場合でも、レジデンシャルIPは必要ですか?
一貫性のためには必要です。別の地域のデータセンター範囲から来ているのにロケーションを選択するのは、一貫性のない組み合わせであり、そのように扱われます。明示的な選択はあなたが何を求めているかをサイトに伝えますが、IPはサイトが信じるものです。
1つのセッションはいくつの店舗をカバーすべきですか?
1つです。スティッキーセッションを1つの店舗のアイテム群にわたって使い回し、次の店舗には新しいセッションを取得してください。1つのセッション内で店舗を混在させることが、帰属エラーを生む原因です。
Walmartのデータ収集はAmazonと異なりますか?
仕組みは重なる部分がありますが、店舗という次元はWalmart特有のものであり、スキーマを変える要因になります。既存のマーケットプレイスのパイプラインを拡張しているのであれば、プロキシを使ったAmazon商品データのスクレイピングが引き継げる部分をカバーしています。
サードパーティのマーケットプレイス出品についてはどうですか?
出品者フィールドを記録し、ファーストパーティとサードパーティの行を別系列として扱ってください。これらを混ぜ合わせると、価格決定とは無関係の理由で急変する価格履歴が生まれます。
結論
Walmartの価格・在庫データは、店舗に紐付けられて初めて意味を持ちます。そして店舗に紐付けるということは、リクエストの見かけ上のロケーションと、それを解決したセッションの持続性の両方をコントロールすることを意味します。ジオターゲティングされたレジデンシャル出口とスティッキーセッションがそのコントロールを与え、解決された店舗を記録することが、それを証明する力を与えます。
この2点を正しく行えば、パイプラインの残りの部分は通常の小売業者データ収集にすぎません。間違えれば、自信満々に、一貫して間違ったダッシュボードを手にすることになります。より広範な小売業のコンテキストはEコマース活動を支えるプロキシと価格インテリジェンスのユースケースにあります。