はじめに
こんにちは。検索基盤部の岩崎です。検索基盤部ではZOZOTOWNの検索機能の改善に日々取り組んでいます。ZOZOTOWNのおすすめ順検索のプロジェクトでは、機械学習モデルを活用した検索結果の並び順の改善に取り組んでおり、全ての施策はA/Bテストで検証しています。なお、最近の並び順精度改善の取り組みについては以下の記事をご参照ください。
本記事におけるA/Bテストとは、特定期間中ランダムに振り分けたユーザーに対してそれぞれ別の施策を提示し、その成果の差を検定するテストのことを指します。A/Bテストは施策の効果を検証するための優れた手段として広く知られており、おすすめ順検索改善のリリース判断には欠かせない存在となっています。ZOZOではA/Bテスト基盤の整備を進めており、おすすめ順検索以外にもさまざまな施策でA/Bテスト基盤を用いた運用がされています。
しかし、おすすめ順検索のプロジェクトではA/Bテストを重ねていくうちにデータ分析の工程が徐々に複雑化してしまい、その手動作業が分析者の負担となっていました。ダッシュボードに表示する指標もどんどん増え、修正作業の難しい状態となっていました。本記事ではA/Bテストのデータ分析工程に関して、従来の課題とその改善策について焦点をあて、取り組みを紹介していきます。A/Bテストのデータ分析工程に関して類似した課題を抱えている方の一助となれば幸いです。
目次
従来の運用
A/Bテスト導入当初はスプレッドシートのカスタムクエリの機能を用いて集計処理が行われていました。以下は実際に当初運用していたクエリの編集画面になります。なお具体的なクエリの内容については加工処理をしています。
この集計結果をもとに、A/Bテスト期間中の各施策の指標を比較できるダッシュボードをスプレッドシート内に作成していました。A/Bテスト期間中は定期的にカスタムクエリを実行し、指標の速報値をプロジェクトメンバー内で共有し、もし指標値の急激な悪化が見られた場合は早期に切り戻しする、といった運用をしていました。A/Bテスト期間後に発生する後続の分析調査についても同じスプレッドシート内に追加していくことで運用されていました。
そして、A/Bテストが行われるたびに上記の集計クエリやダッシュボードが格納されたスプレッドシートを複製し、クエリ編集画面にあるパラメータやクエリ内容を次のA/Bテストの設定に修正していました。以上が従来の運用方法になります。
この運用は、比較的軽量な作業で運用可能な状態を作り上げられるというメリットがあります。一方で、コードの管理体制が十分でないことやスプレッドシート自体の制約により、運用を継続していく上で多くの課題が生じました。以降にその課題と改善の取り組みを説明していきます。
改善1. 集計のワークフローをVertex AI Pipelinesで自動化する
従来の運用では、集計クエリのコードがスプレッドシート内に存在しており、その内容を直接バージョン管理できていませんでした。レビュー体制も構築できておらず、クエリ修正作業の属人化が進行していました。また、集計クエリがダッシュボードに依存しているという課題もありました。これによりA/Bテストが行われるたびに集計クエリが複製されるため、さらに差分を追いづらい状態になっていました。ダッシュボードを他のツールに移行することも難しく、ツール再選定の余地がない状態になっていました。
加えて、カスタムクエリのタイムアウトは通常のクエリのタイムアウトよりも短く設定されていることが一般的です。このため、カスタムクエリの集計期間によってはタイムアウトになることもありました。これを防ぐために、通常のクエリ実行で集計した結果を一時的なテーブルとして保存しておき、カスタムクエリでその結果を取得する、といった暫定対応なども必要になりました。こういった手動作業の複雑化についても課題となっていました。
これらの課題により、A/Bテストのたびに行う分析者の手動作業が多く、分析者のリソースが逼迫していました。人的ミスの入り込む可能性も高く、クエリ修正作業の属人化も進行していました。これらの課題の解決のために、集計クエリの実行の自動化に取り組みました。
集計クエリの自動化には、Google Cloud Platform(GCP)のサービスであるVertex AI Pipelinesを利用しました。選定理由は以下の3点です。
1点目の選定理由は、条件分岐やループをもつワークフローを簡単に記述できる点です。これにより、「A/Bテスト期間中のみ速報値を日次で出力したい」といった要件や「複数のA/Bテストが同時期に行われることも想定したい」といった要件に対しても柔軟に対応できます。
2点目の選定理由は、Vertex AI Pipelinesがおすすめ順検索の開発者にとって馴染みのあるサービスであるという点です。Vertex AI Pipelinesは一般的には機械学習のワークフローを管理するサービスであり、おすすめ順検索の機械学習モデルの開発時にも活用しています。そのため、習得すべき技術項目を増やすことなく分析工程の改善にも取り組むことができます。なお、おすすめ順検索の機械学習モデルの開発からデプロイまでのワークフローの自動化については以下の記事をご覧ください。
3点目の選定理由は、社内にVertex AI PipelinesのCI/CD、監視、スクリプト類のまとまったテンプレートリポジトリがある点です。このリポジトリはCloud SchedulerとCloud FunctionsによるVertex AI Pipelinesの定期実行も簡単に実装できるようになっています。こちらを活用することにより、今回目指している集計クエリの自動化がより容易に実現できます。以下の記事でVertex AI Pipelinesの導入事例やテンプレートリポジトリを紹介しているので併せてご参照ください。
以上の理由から、Vertex AI Pipelinesを採用して、集計クエリの自動化を行いました。
実際に運用している集計のワークフローを以下に示します。この図はVertex AI Pipelinesのコンソール画面から確認できるワークフロー全体像となっています。
簡単にこのワークフローを説明すると、以下のとおりです。このワークフローが日次で実行されることにより、集計の自動化が実現できています。
- 集計の基準日を取得する（デフォルトではワークフロー実行日となる）
- 前段で取得した基準日に行われているA/Bテストがいくつなのか、A/Bテスト名などの情報とあわせて取得する
- 前段で取得したA/Bテストそれぞれについて、指標算出のための集計クエリを実行し、結果をBigQueryに出力する
なお、移行にあたっては、特定のA/Bテストについて従来の運用と新規の運用を並走させて同一の結果を出力することを確認する、という方針で安全に行いました。
この取り組みにより、集計クエリとダッシュボードとの依存関係を軽減でき、ダッシュボードのツールを再選定しやすい状態になりました。現状のダッシュボードは習熟コストの低さを優先してスプレッドシートを引き続き採用していますが、今後のツール選定の余地を残したまま運用できています。
また、GitHub上で管理されたSQLファイルを直接実行する仕組みとなったため、取得する指標の変更に応じてレビューが適切に行われるようになりました。加えて、SQLのLinterであるSQLFluffをGitHub Actionsに導入することでコードの品質も保つことができるようになりました。
改善2. 指標の再整理
従来の運用では、これまでのA/Bテストで作成された指標がそのまま次のA/Bテストのダッシュボードに引き継がれていく仕組みとなっていました。A/Bテスト期間後の事後分析用のクエリも引き継いでいるため、徐々にダッシュボードが複雑になっていき、「集計しているが数値の確認はしていない」といった状態の指標が発生していました。またレビュー体制が整っていないこともあり、「A/Bテストの判断に必要な指標」と「事後分析などの追加調査のための指標」という別の目的をもった集計が単一クエリに混在している状態でした。以上のことから、クエリやダッシュボードも必要以上の複雑さになっており、修正作業の属人化が進行していました。
この状態の解決のために、現在算出している指標とその算出に必要なカラムを全て洗い出し、指標を分類する取り組みを行いました。関係者と議論して「A/Bテストの判断に必要な指標」とそうでない指標を分類し、前者のみを自動化の対象とし、その算出に必要なカラムのみを抽出するように集計クエリを作り直しました。
これらの対処の結果、追加調査は別クエリとして切り出されるようになり、集計クエリのコードの肥大化防止につながりました。追加調査もより気軽に、他の集計を気にせず行える仕組みとなりました。指標数やクエリのコード量は従来の1/5程度に抑えられ、クエリ修正作業の属人化の解消にもつながりました。ダッシュボードもシンプルになり、KGIやKPI、A/Bテストが正しく行われているかの指標を信頼区間つきで端的に示されることで、リリース可否の判断もしやすくなりました。
以下は改善後のダッシュボード例になります。数値はダミーの値に加工しています。
この図から、新規施策が多くの指標で上回っており、そのうち2つの指標についてその差が統計的に有意であることが読み取れます。
まとめ
今回の取り組みにより手動作業の多くは自動化され、分析者はA/Bテスト期間中でも他の分析へ注力できるようになりました。クエリの簡単化とレビュー体制の構築により、属人化の問題を解消できました。さらに、これらの仕組み改善のおかげで、Sample Ratio Mismatchの検知や信頼区間の導入など、リリース判断にとって重要な取り組みを実施できるようになりました。
今回の取り組みによって分析工程の自動化をある程度進めることができた一方、A/Bテストの実施工程の全体を見つめ直すとまだまだ自動化できる要素がたくさん残っています。現状はリリースフロー上関係部署と多くのやり取りをする必要があるため、協調して仕組みを自動化できればと考えております。日々の運用を改善していき、大量のA/Bテストを負担なく実行できるような体制につなげられればと思います。
おわりに
ZOZOでは一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！
