競合のプロモーションを追跡したいと考えているほとんどのチームは、すでに価格モニタリングを導入しており、それがこの問いに答えてくれないことに驚くことになる。
理由は構造的なものだ。価格モニタリングが記録するのは水準、つまり「見た時点でこの商品がいくらだったか」である。プロモーションはイベントだ。それは開始し、何らかの仕組みと値引き幅を持ち、一定期間続き、終了する。水準の連なりはイベントを示唆することはできても、プロモーションがいつ始まったのか、どのくらいの期間を想定していたのか、何がきっかけだったのかを教えてはくれない。そしてサンプリング間隔がプロモーションの期間より長ければ、あなたのデータにとってそのイベントは起きなかったことになる。
価格の連続データが見誤ること
失敗のパターンは主に2つある。
プロモーションがサンプリング間隔より短い場合。 1日1回のスナップショットでは、6時間のフラッシュセールは何も捉えられない。値引き幅が浅く見えるのではなく、まったく何も見えないのだ。あなたのデータ上では、競合の顧客がセールを目にしている間、競合は価格を維持していたことになる。
プロモーションがサンプリング間隔より長いが、両端しか見えていない場合。 3日間のプロモーションのさなかにたまたま当たった週1回のスナップショットは、それを1週間全体の通常価格として記録してしまう。この一つの読み違いが、その上に構築されるすべての平均値を歪めることになる。
どちらも一見きれいなデータを生む。どちらもエラーを出さない。だからこそ、プロモーション追跡は価格テーブルに対するレポートとして扱うのではなく、それ自体の設計が必要になる。
プロモーションは価格フィールドには現れない
2つ目の構造的な問題は、値引きがあってもパーサーが読み取る数値が変わらないことが多いという点だ。
価格モニタリングが日常的に見逃す仕組みには、次のようなものがある。
- カート段階の割引。 商品価格は変わらず、値引きはチェックアウト時に表示される。
- クーポンコード。 カートで適用され、ページ上にバナーとして表示されることもあれば、メールでのみ配布されることもある。
- バンドルとまとめ買い。 2個購入で単価が下がる。表示されている単価自体は変わらない。
- 条件付き適用対象。 会員価格、初回注文割引、地域限定オファー、ロイヤルティ階層。
- 配送料の閾値。 実質的には割引だが、価格フィールドには一切現れない。
したがって収集は数値以上のものを捉える必要がある。最低限、表示価格、取り消し線付きの参照価格の有無、プロモーションバッジのテキスト、バナーのテキスト、表示されていれば明記された終了時刻を捉えるべきだ。カウントダウンタイマーは特に解析する価値がある。なぜならそこだけが、競合が意図した終了日を教えてくれる場所だからだ。
小売全般の収集の仕組みはresidential proxies for price monitoringに、店舗特化版の問題はWalmart price and inventory monitoringにある。
観測ではなくイベントを記録する
以降のすべてを機能させる設計上の決定は、観測データからプロモーションのイベントを導出し、それ自体を独立したレコードとして保存することだ。
イベントには開始観測、終了観測、そしてそれを記述するフィールドが必要になる。
| フィールド | 重要な理由 |
|---|---|
| 基準価格 | 割引を測る基準であり、先週の価格ではない |
| プロモ価格 | イベント期間中の実効価格 |
| メカニズム | パーセンテージ、固定額、バンドル、クーポン、カート段階、配送料 |
| 値引き幅 | 基準価格とプロモ価格から算出し、再計算せず保存する |
| 開始・終了観測 | タイムスタンプ付きで、期間を測定可能にする |
| 明記された終了時刻 | 競合が公表していれば、カウントダウンやバナーから |
| 市場 | 観測元の国、関連する場合は地域 |
| 信頼度 | 境界が実際に観測されたものか、サンプリング間隔による制約を受けているか |
最後のフィールドが正直なところだ。6時間おきにサンプリングしているなら、プロモーションが6時間の窓のどこかで始まったことは分かるが、正確にいつ始まったかは分からない。この不確実性を記録しておけば、実際には持っていない精度があるかのように装うのではなく、期間分析でそれを考慮に入れることができる。
サンプリング頻度は見たい対象より短くなければならない
このルールは扱いにくいが単純だ。サンプリング間隔より短いプロモーションは検出できず、その間隔より高い精度で期間を測定することもできない。
すべてを一律に高頻度化するのではなく、階層化するとよい。最も攻撃的な競合の高価値商品を集めた小規模なウォッチリストであれば、短い間隔を正当化できる。ロングテールは1日1回でよい。さらにイベント駆動型の層を加える。ある競合の1商品が動いたら、その競合の間隔を一定期間タイトにする。プロモーションはまとまって発生する傾向があるからだ。
小売業の年間カレンダーも、部分的にはこれを予測可能にする。既知のセール時期の前後の週は、あらかじめ設定した高頻度が必要だ。その時期はプロモーションの頻度も深さも変化するからである。
プロモーションは地域ごとに異なる
競合のプロモーションカレンダーは通常、単一のカレンダーではない。オファーは市場ごとに実施され、同じ商品ページでも、ある国では割引が表示され、同じ日に別の国では通常価格ということがある。
単一の視点から収集すると、ある1市場のカレンダーを競合の戦略だと誤って捉えてしまうことになる。複数市場で販売しているなら、収集はそれぞれの市場から行う必要がある。国指定が可能なResidential proxiesがあれば、その視点を実現できる。Shifterのゲートウェイでは、ターゲティングとセッションはp.shifter.io:443に対する認証情報の中に指定する。
customer-USERNAME-country-fr-sid-promo-fr-01-ttl-600:PASSWORDcountry-frは市場を設定し、sid-promo-fr-01はカテゴリ巡回の間、一つの出口を保持することで読み取る価格の内部整合性を保ち、ttl-600はそれを10分間維持する。クロール途中でローテーションすると、1つのレコードの中で2つの市場の価格を比較してしまうことになる。
同時実行数は控えめに保ち、エラーが出てもリトライを繰り返すのではなく引き下げること。詳細はrate limiting and request throttlingを参照。製品ビューはe-commerce data collectionページにある。
イベントデータが実際に教えてくれること
プロモーションをイベントとして扱うようになると、分析は単純で本当に意思決定に役立つものになる。
競合ごとの頻度。 どのくらいの頻度でプロモーションを行うか、そしてその間隔が予測できるほど規則的かどうか。競合の中には、隔週の見抜けるリズムを持つものもある。
値引き幅の分布。 典型的な割引幅、最大割引幅、そしてどのカテゴリが大幅値引きの対象になるか。これこそ自社の価格戦略委員会が本当に欲しがっている数字だ。
期間。 オファーがどのくらい続くか。これにより、本物の在庫処分と、取り消し線価格が実際には適用されたことのない恒常的な偽セールとを見分けられる。
先行か追随か。 競合が一貫してあなたより先に動くか後に動くか。これはイベントを順序付けられるだけの精度のタイムスタンプがあって初めて見えるものであり、サンプリング間隔の規律を守るべきもう一つの根拠となる。
カレンダー上の集中。 どの週に活動が集中するかが分かれば、自社の計画も後手に回らずに済む。
FAQ
フラッシュセールを捉えるにはどのくらいの頻度で収集する必要がありますか。
フラッシュセールより短い頻度が必要だ。数時間単位が重要なウォッチリストであれば、それは全カタログではなく少数の商品に対して1時間おき、あるいはそれ以上の頻度を意味する。ウォッチリストの規模をどう設定するかが本当の判断どころだ。
基準価格はどう確立すればよいですか。
直前の観測値を使うのではなく、別のゆっくり動く系列として追跡すること。先週の価格を基準として使うと、2回連続の割引が割引なしのように見えてしまう。
カート段階のオファーを捉えるために、カートに商品を追加する必要がありますか。
カートでしか現れない仕組みについては、何らかのチェックアウト段階での観測がそれを見る唯一の方法だ。それは小規模で意図的な範囲にとどめ、サイトの利用規約を尊重し、決して取引を完了させないこと。
取り消し線価格は基準として信頼できますか。
必ずしもそうではない。一部の小売業者は、最近実際にその価格で売れたことのない参照価格を表示する。自社で観測した基準価格を彼らの価格と並行して保持し、両者が食い違う場合はそれを記録しておくこと。その差異自体が一つの発見だからだ。
結論
プロモーション追跡は、価格履歴に対するクエリとして扱われると失敗する。プロモーションはメカニズム、値引き幅、期間、市場を持つイベントであり、その情報のほとんどは価格フィールドには存在しない。
バッジ、取り消し線、明記された終了時刻を価格と併せて捉え、境界に関する明示的な信頼度を伴うイベントを導出し、それを正当化できる商品については関心のあるプロモーションより速くサンプリングし、販売しているすべての市場から収集すること。料金はpricing pageに掲載されている。