Pelotonはアメリカのオンラインフィットネス企業で，フィットネス器具やオンラインコースを提供している会社．多様なコンテンツと個々の会員のニーズに応えるために，パーソナライズが必要で「会員に適切なコンテンツを適切なタイミングで適切な文脈で提供する」ことを常に考えているとのこと．
この記事では，パーソナライゼーションチームがどのようにしてデータ駆動な仮説を持つようになったのかを紹介してくれている．この後編が「How We Built: An Early-Stage Machine Learning Model for Recommendations」で書かれているので，明日はこれを読む予定です．
2019年後半から，ホーム画面のモジュール化によるパーソナライズを進めていた中で，今回紹介している「Daily Picks」といういくつかのクラス提案とそれを提案する短い理由が書かれたモジュールの改善もその1つとのこと．
下記画像にある「For Your Usual」・「 For a Quick Workout」 ・「 For Something New」というカードに対して，3つの段階を経て仮説検証を行ったとのこと．
コンポーネントをモジュール化する方がそれぞれに対してレコメンドエンジンを導入して効果検証できるので，この方法は筋が良いと思うし，確かNetflixやMercari, ZOZOもこのような方法を取ってたはず．
最初の取り組みとしては，機械学習を使うのではなくシンプルなヒューリスティック・セットを選択してメンバーに1セットのクラスを提案した．以下を考慮したもの．
Our first system for serving recommendations, computed based on heuristics
上図は，レコメンデーションをバッチ処理して，API経由でリクエストされた時に提供する初期のシステムを示していて，AWSのマネージドサービスを活用していたとのこと．
何百万人もの会員に対して，レコメンドする必要があったのと，さらに少人数のチームだったというのがあってこの方式を採用したと書いてあり，この辺りはマネージドサービス万々歳．
RDSからGlueでデータ抽出して，S3にデータを保存しておいてGlueでさらに前処理して最終的にはDynamoDBにレコメンドリストを格納してAPIでリクエストしてもらう感じで構築されてる．
この辺はAWSでのバッチレコメンドにおけるレコメンドリスト取得の定番パターンだなと思う．
結果的に，この施策で新しく「Daily Picks」を追加したことで，どれだけの人がこのモジュールからクラスを受講しているかをトラッキングすることができるようになったし，ワークフローなどのインフラが整ったことでより改善を回せるようになっていった．
まずは機械学習を入れずにシンプルな施策を実施することで，ベースラインだったりワークフローを確立して改善サイクルを回せる環境を作るという方針は凄く良いなと思う！こうしておくと，その後の機械学習を使ったレコメンドへの置き換えもある程度しやすくなる．