1,110 測定値

データ駆動型製品開発のための実験環境のセットアップ方法

に Victor Semin10m2023/04/04

長すぎる; 読むには

製品の所有者は、オプション A とオプション B のどちらに進むかという問題に直面することがよくあります。このような決定は、個人的な判断に基づいて行われるか、競合他社のアプローチを模倣して行われます。比較的労力がかからない単純な実験環境を設定することで、このような落とし穴を回避できます。この記事では、これを実現する方法について説明します。

featured image - データ駆動型製品開発のための実験環境のセットアップ方法

製品所有者として、オプション A とオプション B のどちらに進むべきかという質問に直面するのはよくあることです。または、より良い結果を得るには、どちらのバージョンの画面を実装する必要がありますか?このような決定を下すことは、特に限られたリソースで締め切りが迫っている場合は困難な場合があります。さらに、そのような決定は、個人的な判断または競合他社のアプローチの模倣に基づいて行われ、最適ではない結果につながる可能性があります。

幸いなことに、比較的労力がかからない単純な実験環境を設定することで、このような落とし穴を回避できます。この記事では、これを実現する方法について説明します。

実験環境の設定が重要な理由

実験環境のセットアップは、次の 2 つの理由から重要です。

まず、新しい機能を実装したら、データ駆動型のアプローチに基づいて最適なオプションを選択できるようになります。
次に、「現状」と仮想の「将来」のオプションを比較し、「もしも」分析を行うことで、製品の既存の機能を継続的に改善できます。

神話

アプローチに進む前に、通常、製品所有者を誤解させるいくつかの誤解を正しましょう。

実験や A/B テストを実行できる複雑な環境をセットアップするには、多くのリソースが必要です

誤り: 記述されたアプローチは、ソフトウェアエンジニアのリソースを 1 週間も使わない。

十分に確立されたデータ収集プロセスと詳細なイベント追跡が必要です

間違った例: 製品のメインエンティティのライフサイクルに関する情報を格納する既存のデータベースに依存できます。たとえば、配送サービスの場合は注文ステータスです。

毎日私のリクエストを処理してくれるアナリストの専任チームが必要です

間違った例: 実験のアプローチと指標を理解したら、簡単なSQL クエリを使用して定期的に自分でデータを取得できます。

アプローチ

実験環境をセットアップするには、次の手順に従うことをお勧めします。

1. 今後の実験の目標を定義し、オプションを理解し、指標を選択する

プロダクトデザイナーに連絡する前に、実験の一環として測定する目標と指標を定義します。古典的な「オプション A またはオプション B」の質問の場合、通常、変更を実装することによって達成したいことは単純明快です。たとえば、目標到達プロセスの特定の部分に対処している可能性があります。

説明のために、あなたが配送会社で働いていて、現在注文作成フォームに焦点を当てていると仮定しましょう。配送先住所を提供し、配送方法を選択する比較的低い割合のユーザーに対応したいと考えています。また、ジャーニーの 2 つの新しいバージョンがあるとします。

現在のバージョン: 1 つの画面で住所を入力し、提供された住所に基づいてピンで地図を表示する必要があります。次の画面では、提供された住所に基づいて配送方法を選択できます。
新バージョン: 一画面で住所入力と配送方法選択ができるようになりました。

目標は、住所を提供し、配送方法を選択したユーザーの割合が高くなるオプションを決定することです。メトリクスはかなり単純です。住所を提供し、配送方法を選択したユーザーの割合です。

実際、そのようなデータを測定する方法は 2 つあります。

バックエンドの設計によってすでに利用可能なデータに基づいています。たとえば、注文のライフサイクルに関する情報を持つデータベースを考えてみましょう。注文には、次のような状態またはステータスがあります。
1. 下書きを作成しました
2. 発送方法を検索してみる
3. 配送オプションが見つかりました/配送オプションが見つかりませんでした
イベントトラッキング- これはすぐに使用できるものではないため、実装には余分な労力が必要です。ただし、イベント追跡により、より詳細な分析が可能になります。たとえば、デバイスのタイプとブラウザー名をイベントのパラメーターとして渡すことができます。

この記事の次のセクションでは、最初のアプローチ、つまり、イベント追跡のない既存のデータアーキテクチャに焦点を当てます。

2. 実験環境のアーキテクチャを設計する

テストフロー内で 2 つの主な手順を完了する必要があります。

選択したパラメーターで実験を作成する
ユーザーをいずれかのグループに割り当てる必要があるユーザージャーニーの段階を定義し、結果として関連する UI が表示されるようにします。

実験の作成:

アイデアは、軽量のA/B テストフレームワークを考え出すことです。このフレームワークは、できるだけシンプルで、次のパラメーターを使用して実験を作成できるようにする必要があります。

実験 ID
最大サンプル
各グループの番号と名前
各グループに入る確率

これらのパラメーターを構成できるため、サンプル制限を設定し、目的のサンプルサイズに達するまで実験の候補をランダムに選択できます。

これにはクライアントとサーバーの両方に変更が必要です。サーバーは実験ごとに候補の数を追跡する必要があり、バックエンドは現在のユーザーが実験に参加するかどうかを決定します。バックエンドは、現在のサンプルサイズと一定の確率に基づいて、認証されたユーザーを実験に参加させるかどうかを決定します。さらに、バックエンドは、ユーザーに一貫したエクスペリエンスを提供し、実験結果を適切に計算するために、特定の実験の一部であるユーザーのコレクションを維持する必要があります。

実験の構成のエンドポイントは次のようになります。

POST /api/your-service/experiment-create

リクエスト：

 { experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e", maximum_sample_size: 250, groups: { { group_name: "old_journey", probability_of_falling_in: 0.5 }, { group_name: "new_journey", probability_of_falling_in: 0.5 },}

応答：

{

200,

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

ユーザーをいつどのように実験グループに割り当てるかを決定する:

特定のユーザーを実験および対応するグループに割り当てる役割を担う別のエンドポイントが必要になります。これをexperiment-enrollmentsと呼びましょう。

環境全体を設計する際には、ユーザージャーニーexperiment-enrollmentsエンドポイントのどの段階で呼び出す必要があるかを明確に理解する必要があります。また、すべてのユーザーが実験に参加できるとは限らない場合があります。そのため、エンドポイントにもユーザー認証トークンを提供すると便利です。

この例では、最初の注文を行っている新規ユーザーのみに注目したい場合、user-auth を使用して、そのユーザーのタイプと、そのユーザーを実験に登録する必要があるかどうかを判断できます。また、エンドポイントが呼び出されたら、必要なすべての情報が利用可能であり、ジャーニーとライフサイクルの詳細を考慮していることを確認してください。

experiment-enrollmentsエンドポイントについては、以下で説明します。特定のタイプのユーザー (例: まだ住所を提供していない新規ユーザーのみ) のために、旅の特定の段階 (例: 配送先住所を要求する画面に到達する前) で呼び出すことができ、現在のユーザーが参加する必要があるかどうかを計算します。特定の実験でかどうか:

POST /api/your-service/experiment-enrollments 、ユーザー認証トークンが必要です

リクエスト：

\ {

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

応答：

 {200, enrolled: true/false, group_name: group_1,}

理論的なデータフローがどのように見えるかを説明するために、配送会社での注文作成フローの同じ例を想定します。注文作成画面の 2 つのオプションから選択しています。

次のエンドポイントは、次の図に記載されています。

/create-order-draft (ステップ 3)
/find-shipping-method (ステップ 16)
/submit-order (ステップ 20)

実例をサポートするために提供されており、実験環境の必須部分ではありません

また、データベースの例示的で単純化されたアーキテクチャを以下に示します。

3 つのメインテーブルがあります。

Experiments set - 以前に作成したすべての実験が含まれています。 /experiment-createエンドポイントを呼び出すたびに、データベースが更新されます。
Experiments database - 特定のユーザーの各登録に関連付けられたすべてのレコードが含まれています。データベースは、 experiment-enrollmentsエンドポイントを呼び出すたびに更新されます
Order lifecycle database - 実験関連データの保存方法の例をサポートするために提供されます。ポイントは、このテーブル (または製品の仕様に対応する同様のテーブル) を使用すると、実験グループの 1 つに登録されている特定のユーザーのエントリ (注文の作成など) が成功したかどうかを確認できることです。設定しました。この例では、ユーザーが配送の詳細を正常に提供し、提案された配送方法のいずれかを選択したと結論付けるために、配送方法が選択されたステータスに依存できます。

設計および実装アプローチの概要

長所：

結果のサンプルは不均一です
サンプルサイズは事前にわかっています
固定のサンプリング確率に応じて、結果をすばやく計算できます

短所：

フロントエンドとバックエンドの両方の変更が必要
結果の計算はいくつかのデータベースに依存しますが、その一部は最初は分析目的で設計できませんでした

タスクと目安の見積もり:

[ ]未定義[バックエンド]モデルを作成し、フェッチカウンターエンドポイントを公開: ~2 ストーリーポイント
[ ]未定義[バックエンド]インクリメントカウンターのエンドポイントを公開: ~2 ストーリーポイント
[ ]未定義[バックエンド]エンドポイントをフェッチしてカウンタをインクリメントするように公開: ~1 ストーリーポイント
[ ]未定義[フロントエンド]サインアップフローを切り替えるためのカウンターエンドポイントの呼び出し: ~3 ストーリーポイント

バックエンドを設計したら、フロントエンドチームが情報を受け取るための最良の方法と、フローのどの段階であるかについて調整します。

主な依存関係を念頭に置いて軽減します。

フロントエンド部分をバックエンドと並行して実装できるように、チームが事前に契約について調整していることを確認してください。
バックエンド全体が完了するまで、フロントエンドがブロックされないようにしてください
実験環境に関係なく、すべての UI オプションをとにかく実装する必要があります

3. 結果の分析と解釈

実験が十分な時間実行されたら、結果を分析して解釈し、意味のある結論を導き出すことが重要です。

以前に焦点を当てることにしたメトリックへの影響を計算するために必要なフィールドのリストを定義します。

上記の例から、データソースは 2 つのテーブルになります。

Experiments database :
- 入力: 結果を探している実験 ID
- 出力: 特定の実験の参加者であるすべてのユーザー ID のリスト、各ユーザーが割り当てられたグループ、およびユーザーが割り当てられたときのタイムスタンプ
Order lifecycle database
- 入力: 実験の範囲内にあるユーザーのリストと、実験に登録されたときのタイムスタンプ
- 出力: これらのユーザーに関連付けられ、ユーザーが実験に登録された後に処理されたすべての注文の最終ステータス

このデータに基づいて、各実験グループの正常に作成された注文の割合を計算できます。

結果を分析するときは、生の数値だけにとどまらないことが重要です。また、統計的有意性を調べて、テストグループ間で観察された違いが単なる偶然によるものではないことを確認する必要があります。このトピックに関連する多くの記事を、このトピックや他のオンラインリソースで既に目にしているため、この部分にはあまり焦点を当てません。とにかく、ここでは過度の知識は必要ありません。私の意見では、 Z 検定または T 検定を適用して、2 つのグループ間の差の有意性を確認できれば十分です。

それでも、結果が統計的に有意であると判断したら、製品のどのオプションがより優れたパフォーマンスを発揮したかについて結論を導き出すことができます。

4. 優先オプションのスケールアップ

実験を正常に実行し、最適なオプションに関して十分な信頼を得たら、次のステップは製品全体に変更を拡大することです。いくつかのアプローチがあります。

最も簡単な方法は、テストの構成を調整して、 100% のユーザーがより良い結果を示すグループに分類されるようにすることです。 UI のこの特定の部分の表示が実験環境とは無関係になるように、将来的にコードをクリーンアップするための時間を確保する必要があります。
単純ではないのは、製品が複数のプラットフォームで利用できる場合です。 Web フローでの実験の結果がモバイルアプリフローに適用される (またはその逆) と想定する場合は、特に注意してください。申し訳ありませんが、別のプラットフォームで同様の方法で別の実験を実行するよりも、安全を確保する方がよい場合があります。