技術部データ基盤チームのデータサイエンティストの @zaimy です。今回は、ハンドメイド作品を対象とする EC サービスである minne の注文額を、プロダクト担当者とデータサイエンティストで Prophet を使って予測した事例を、主に運用面から紹介します。
結論ファースト
月ごとの注文額を実績に対して誤差 1% 程度で予測できるようになりました。
背景
これまで minne では、経営計画に基づく年間の注文額の目標があり、それを過去実績に基づいて月割りにし、そこから日数で日割りにする…という流れで計算された、日ごとの注文額の目標を立てていました。
この目標値が予測値として使われているシーンもありましたが、当然、目標値は直近の実績に基づく予測値ではないので、例えば月初の実績値と目標値の差異が大きかったとしても、月の後半の目標値は変わらず堅調な金額が示されます。「この金額は目標値である」と理解している担当者であれば適切にこの値を取り扱うことができますが、「予測値である」と混同してしまうと、目標に対してキャッチアップが必要な状態なのに「月の後半は堅調だから大丈夫」と認識してしまうかもしれません。また、目標値なので、前年と傾向が変わっている時期などは実績との差異が大きくなることもありました。
加えて、キャンペーンや施策の担当者ごとに、個別に短期間の予測が行われているケースはありましたが、根拠がそれぞれ異なるため予測値同士を比較できなかったり、妥当性を検証できなかったりする問題がありました。
そこで、プロダクト担当者から相談をもらって、統一した基準で、継続的に計算可能な、実績に基づく注文額の日ごとの予測を行うことになりました。
時系列予測を行うモデルの選択
時系列予測を行う手法としては、BigQuery ML でも利用できる ARIMA や、LSTM などのディープな種々の手法がありますが、今回は Meta 社が開発した Prophet を用いました。
Prophet は、入力する時系列データの季節性と休日などのイベントに適合するように訓練できる加法モデルで、R と Python の実装が提供されています。特徴として、外れ値や欠損に対して堅牢で、特徴量エンジニアリングが簡単なことが挙げられます。また、Google Colaboratory で簡単に動作させられて軽量なため、ノートブックとして社内で共有・議論しながらプロトタイピングがしやすい理論および実装として選択しました。
モデル式は以下の通りで、イベントには任意の日付やイベントの種別を与えることができます。
y(t) = g(t) + s(t) + h(t) + epsilon(t)
g(t): トレンド項
s(t): 季節性
h(t): イベント項
epsilon(t): 誤差
特徴量の選択と工夫
議論において、経験的に minne の注文額に大きな影響を与える特徴量として、以下のものが挙げられました（ここに記載しているものは一部です）が、このうち周期性と休祝日は Prophet によって自動的に特徴量として組み込むことができます。今回作成するモデルでは、モデルを継続的に運用するにあたって特徴量設計を単純にしたいと考えたため、影響力が大きく、コントロール可能な変数であるキャンペーンの開催のみ追加でモデルに組み込むこととしました。
- 年次, 月次, 週次の周期性
- 休祝日
- キャンペーンの開催
- 台風や寒波など国内の広い範囲に影響のある気象イベント
- 新型コロナウィルス感染症による外出自粛などの社会的な動き
minne では、過去のキャンペーン情報はデータベースに蓄積されていますが、未来に開催するキャンペーンはまだシステムに入力されていないものもあるため、ある程度人力でモデルに入力する必要があります。キャンペーンを Prophet に入力する際は、「どのようなキャンペーンか」を分類して与える必要がありますが、プロダクトを担当するメンバーと一緒に運用しやすいモデルにするために、モデルへの入力が煩雑にならないよう、特徴クロスなどは行わずに「値引き額/率」「開催期間」など案を議論した上でいくつかの分類を試して 1 つだけを採用しました。季節性の周期などのパラメータ調整と、キャンペーンの分類方法の工夫のみによって精度向上を図っています。
モデリングの結果とビジネス的な成果
過去の実績を用いた予測モデルを作ることで、根拠を統一して長い期間の日ごとの予測を常に得られるようになりました。冒頭に述べたとおり、日ごとの注文額を足し上げた月ごとの注文額に関しては実績に対して誤差 1% 程度で予測できています。また、プロダクトを担当しているメンバーが目標に照らして予測を評価することで、差異が大きい場合にキャッチアップなどの手を打ちやすくなったと思います。
更に、今回は当初の要件として Explainable なモデルは求められていませんでしたが、加法モデルである Prophet を選択したことで、トレンドや季節性やイベントによる影響をそれぞれ参照することができるようになりました。これにより、従来「何月は売上が上がる傾向がある」「何曜日は売上が上がる傾向がある」「このキャンペーンはこれくらい注文額に影響がある」のように得られていた経験知を、解像度を上げて定量的な共有知にすることができました。
この記事では minne のデータを示すことはできませんが、例えば下の図は、Prophet の理論を示した論文から引用した、ある時系列のトレンドと週次・年次の季節性を可視化したものです。このような図を見ながら議論することが可能になりました。
Taylor SJ, Letham B. 2017. Forecasting at scale. PeerJ Preprints 5:e3190v2 https://doi.org/10.7287/peerj.preprints.3190v2 より引用
モデルの監視と継続的な改善
日ごとの注文額を足し上げた月ごとの注文額は実績に対して誤差 1% 程度で予測できていますが、日ごとの実績に対する予測の誤差は 1% から、頻度は高くないものの最大 10数% とやや大きくなる日もあります。そこで、誤差が大きく出た日については Slack で報知して、モデルに組み込めていないキャンペーンなどのイベントそのものがなかったか、イベントの分類が適切かなどを関係者で監視・議論して、モデルの改善につなげています。
まとめと今後について
この記事では、EC サービスの注文額の予測について主に運用面からご紹介しました。
今回はまず日ごとの予測モデルを作りましたが、キャンペーンは時間単位で行われているため、時間単位の予測モデルも必要になると考えています。例えばソーシャルゲームの運営において、その日の売上が目標に対して差異が大きければ夕方の時点でキャンペーンを打つ、というように、EC サイトの運営においても、より細かく事業運営出来るようにしていきます。
運用を開始して 2 週間程度ですが、既にプロダクトを担当するメンバーからも「キャンペーンを入力しないケースの予測が知りたい」「予測そのものの時系列変化が知りたい」などフィードバックを幾つももらっていて、予測の活用の可能性を感じています。モデルそのものに加えて、運用・活用方法を継続的に育てていきたいと考えています。