プライシングエンジンに送信する前に商品データを検証する方法

Scrapeless Agent Browser はストアフロントのオファーをレンダリングして抽出し、Scrapeless Residential Proxies はオファー収集のために市場別のネットワークルーティングを提供します。

パイプライン概要

商品データ検証は、比較可能なオファーを特定し、そのディシジョン契約を満たす観測だけを許可することでプライシングエンジンを保護します。まずページ状態と出所を取得します。次に形状を検証し、フィールドを正規化し、ID を確認し、鮮度をチェックして、ディスポジションを割り当てます。プライシングエンジンは、承認済み観測値のみを狭いインターフェース経由で受け取ります。別のワークフローが、判断を再現できるだけのコンテキスト付きで例外を処理します。

セール金額が選択された色に対して表示されるが、サイズを選ぶと価格が変わるランニングシューズのページを考えます。コレクターは、正しい数値の価格を含む整形式の JSON を返せても、それを誤ったサイズに紐づけてしまうことがあります。形状検証だけではその不具合を見逃します。自動化で利用する前に、厳密なバリアントまたは選択済みディメンションを要求し、同一状態内で価格を裏付けてください。

倉庫全体とイベントストリームでポリシー語彙を安定させておきます。 価格・通貨・在庫状況のためのオファー語彙 は、ソースフィールドに名前を付ける際に有用です。受け入れるスキーマはそれより狭くして構いません。送料を含まない公開価格と、送料込みの総コストは、別々の金額タイプを持つべきです。顧客セグメント、必要購入数量、クーポン適格性は、ソースが明示している場合には価格の横に位置付けます。

ステージ 1. キャプチャコンテキストを契約に含める

観測契約は、ソース、バリアント、オファー、市場を識別します。ソースドメイン、要求 URL、最終 URL、ローカルな商品またはバリアント ID、販売者 ID（存在する場合）、表示された生の金額、金額タイプ、通貨、在庫状況、キャプチャ時刻を含めます。診断のためにアダプターバージョンとソースタイプを追加します。どのフィールドが null 許容かを指定し、欠落フィールドと、そのオファーが使用していないフィールドを区別します。

生のアーティファクトは不変に保ち、後続コードが同じ入力で観測を再解釈できるようにします。正準イベントには安定した ID とバージョンが必要です。組織が重複排除のためにシリアライズした JSON をハッシュする場合は、ハッシュを計算する前に決定的シリアライゼーションに合意します。 JSON Canonicalization Scheme は、サポートされる JSON 値に対する定義済み表現を提供します。ハッシュは意思決定に使われたペイロードを識別しますが、意味ベースの重複排除には依然としてビジネスキーとキャプチャウィンドウルールが必要です。

ブラウザーアダプターは、同じレンダリング状態からオファーと選択済みバリアントを取得できます。非同期更新やコントロールを持つページには Agent Browser を使用し、新しい状態が表示可能になったら Agent Browser automation workflow を適用して有用なチェックポイントをキャプチャします。ストアの挙動が地域によって変わる場合は Residential Proxies を使用し、市場ラベルを付与する前に、レンダリングされたロケールと通貨を確認します。ジョブリクエスト上の意図された国は試行の来歴であり、観測されたストアフロントコンテキストは検証のための証拠です。

ステージ 2. 推測なしで金額と在庫状況をパースする

正規化された金額フィールドは、通貨と 10 進数の金額、または構成された通貨単位での整数を記録すべきです。元の表示文字列は保持します。句読点はロケールに依存します。通貨記号だけではあいまいになることがあり、金額の前後のテキストが分割払い条件、旧リスト価格、別の購入数量に対する価格を示す場合があります。意味が不明瞭な場合は、レビュー用にそのあいまいさを記録します。

在庫状況は別々に正規化します。在庫あり、在庫なし、予約、不明は異なる状態を表します。たとえストアが価格を隠していても、在庫切れの観測はプライシングチームにとって価値があります。検証済みの在庫なしオファーに対しては、価格欠如を明示的に許容する契約を与えます。空のテキストや、まだレンダリングされていないボタンは、不明を出力すべきです。

ステージ 3. アイデンティティと商業コンテキストを比較する

近い価格でも間違った商品ではもっともらしく見えてしまうため、レンジチェックに先立ってアイデンティティチェックを行うべきです。利用可能な識別子と属性を検証した後にのみ、観測値を社内のバリアントに結合します。価格ポリシーに関係する場合は、パッケージ、コンディション、地域、販売者の役割を確認します。1 つの出品に 2 人のマーチャントが両方とも表現できるよう、オファーキーをプロダクトキーとは区別しておきます。

フィールドをまたぐルールは明示的な述語として記述します。市場固有のオファーは、期待される通貨か、文書化された代替通貨を示すべきです。会員階層向けに有効な価格には、その制限が必要です。表示価格と埋め込まれた価格が一致しない場合は、そのバリアント、市場、金額タイプを比較します。不一致はトリアージのために保持しておきます。サーバーが出力する構造化レコードは、顧客が更新された選択肢を見ている場合でも、デフォルトのオファーを記述している可能性があります。

直近の履歴からの乖離をレビューのシグナルとして扱います。通常の販売価格が EUR 89 前後で、コレクターが EUR 8.90 を出力したとします。この金額は、プロモーション、小数点の誤り、月額支払いのいずれかを表している可能性があります。生の文字列、選択されたバリアント、商業的な修飾子を比較します。レンジルールによって、自動利用を防ぎつつ、レビュアーが証拠を確認できるようにします。分析のために基礎となる観測値を保持しておきます。

ステージ 4. 鮮度と重複配信を評価する

観測値の年齢は、実際にオファーが観測された時点から始まります。キャプチャ時刻、検証時刻、取り込み時刻を別々に保存し、その際には RFC 3339 タイムスタンプを使用します。キャプチャ時刻を、そのオファーのコホートに定義された鮮度しきい値と比較します。輸送が今届いたばかりでも、遅延したエクスポートには古い価格が含まれている可能性があります。キューが複数の受理された更新を受け取る場合は、そのキャプチャ順序を比較し、同順の場合の決定性あるルールを適用します。

イベント処理は冪等にします。同じ観測値がバッチエクスポートとイベントストリームの両方に出現することがあります。安定したイベント ID を使用して、エンジンがその効果を 1 回だけ適用するようにします。鮮度が重要な場合は、同じ表示金額に対する後続の観測値を保持します。繰り返された価格は、その現在の状態について新たな証拠を提供します。イベントの重複と、同じビジネス事実の再キャプチャを区別します。

ステージ 5. 例外をルーティングし、リプレイが安全であることを証明する

隔離キューには、ルール名、生の証拠、影響を受けるオファーキーとオーナーを含めるべきです。レビューの優先度はビジネスインパクトで設定します。プロモーションコホートに対する誤った通貨は、価格に影響しない説明フィールドの欠落よりも迅速な対応が必要です。レビュアーがソースマッピングを解消できるようにしつつ、元の決定と、それを下したルールバージョンは保持します。

パーサーやルールを変更したら、限定された集合をリプレイします。どのレコードが新たに受理され、どれが受理集合から外れ、どの正規化フィールドが変化したかを比較します。ラベル付きサンプルと差分を照合し終えるまでは、新しい受理ビューを公開しないでください。取り消し不能な再価格設定アクションは、エンジン自身の権限・マージン・承認ルールの背後に置きます。データ受理は、入力が契約を満たしていることを確立します。価格承認は、別個のビジネス判断を適用します。

原因が誤った通貨や市場にある場合には regional price monitoring を使ってコンテキストを切り分け、より広いコレクション設計には competitive pricing pipeline を使用します。ブラウザを伴う検証レイヤーの規模を決める前に、実際のキャプチャ量と例外量を Scrapeless pricing に持ち込みます。レビュアーが視覚的な証拠を必要とするケースにのみスクリーンショットを予約し、保存したアーティファクトには保管期間を設定します。

まずは小さな受理フィードを配信する

1 つのカテゴリと 1 つの市場を選び、各ディスポジション向けのフィクスチャを作成し、読み取り専用の価格シミュレーションに受理フィードを送信します。自動アクションを有効にする前に、欠落・陳腐化・競合するオファーが決定にどう影響するかを検査します。同じレビュー出力により、コレクションチームは、拒否された各行をそれを決定したルールと証拠までトレースできるようにすべきです。