見出し画像

noteでのGrowthBookの導入理由と使い方を紹介

EMの佐々木です。

note ではA/Bテストの改善目的でGrowthBookを導入し、まずは先行して一部のチームで利用を開始していました。

▲導入時の記事はこちら

導入したチームからのフィードバックが好評で、従来よりもよりすばやくA/Bテストができるようになったため、全エンジニアに向けて展開することになりました。

今日はGrowthBookの導入方法やアーキテクチャの変化、使い方など基本的なことについて話していきます。

GrowthBookを導入した理由

まずはGrowthBookを導入する計画と目的についてですが、シンプルにA/Bテストをもっと効率的に実施したいというのが始まりです。

noteでは社内製のRubyライブラリを使ってA/Bテストを行っており、画面のA/Bテストをするためには4回デプロイする必要がありました。

そのため、一つの実験をやり切るのにかなりの時間がかかってしまい、効率化が求められていたのです。

そこで、まずはUnleashを検討したのですが、「ネームスペースの設定ができない」ため断念しました。

noteで今まで実施していたA/Bテストでは、違う実験がぶつかり合わないようにネームスペースを切ってユーザーごとに分けていました。今の方針をそのままできるツールであることが前提条件でした。

そこで、機能も豊富なGrowthBookを採用することになりました。GrowthBookは有償版でも細かく権限設定ができるようになりますが、弊社では特に必要なさそうなので無償版で利用しています。

GrowthBookとは?基本機能の紹介

では、ここからGrowthBookについて説明します。

GrowthBookとは、オープンソースのA/Bテストやフィーチャーフラグの管理ツールです。オープンソースのため、コードが公開されておりセルフホスティングも可能です。我々は、セルフホストで利用しています。

A/Bテストの割り当て機能

よく使うの基本機能として、A/Bテストの割合設定があります。どのくらいのユーザーに特定のデザインを見せるかを設定する際の割合を決めることができます。A/Bテストというと通常は2パターンが多いですが、GrowthBookでは3パターン以上のテストも可能です。

Namespace機能

同じページで別の実験が同時に行われているときに、同じユーザーに複数の実験が適用されないように制御するネームスペース機能もあります。

具体的には、「ボタンの色を変える実験」と「価格の文字を赤くする実験」が同時に走っている場合、ネームスペース機能を使わなければ、黄色いボタンと赤い文字が同時に現れる可能性があります。

こうなると、どちらの実験が効果をもたらしたのか分からなくなるので、このような競合を制御する機能があるわけです。

FeatureFlag

テストとしてだけではなく、特定の機能を有効 / 無効にするFeatureFlagだけでも利用可能です。「特定の機能を実験的に公開する」などA/Bテスト以外の使い道も考えられるでしょう。

すべてGUIで設定が可能

これらのすべての設定はGUIを通じて行えるため、エンジニア以外でも簡単に利用することができます。

かなり細かい設定が可能です。ランダムに振り分けるだけでなく、一部のユーザーには固定のデザインを表示することができます。また、社員のユーザーIDを指定して、特定のデザインを表示させることもできます。

GrowthBookの導入でのアーキテクチャとフローの変化

改善前のアーキテクチャとフロー

①noteにアクセスする

現状のフローでは、ユーザーがnoteのウェブサーバーにアクセスすると、A/Bテスト用のAPIサーバーに問い合わせがまず走ります。

②A/Bテスト用のAPIサーバが割り当てを返す

そして、どの実験に割り当てられているかを確認します。「user_id: 1はtreatment_bのデザインを表示する」などのレスポンスが返ってきて、フロントに反映されて表示されます。

③A/Bテストのレスポンスに従って画面を表示し、アクションログを記録

そして、最後にtreatment_bのデザインが表示されたユーザーの行動をアクションログとしてSnowflakeに記録します。そのユーザーのクリックやボタンの操作をログに保存して1週間後に分析するのが基本の流れです。

改善後のアーキテクチャとフロー

GrowthBookを導入した場合でも、①のA/BテストのAPIサーバーに問い合わせる手段は同じです。大きくアーキテクチャを変更する必要はありません。

A/Bテストの取得先サーバーがGrowthBookに変わるだけです。GrowthBookが実験設定を返し、その設定に基づいてどのユーザーにどのデザインが割り当てられるかを決定します。

その後の流れは同じで「user_id: 1はtreatment_bのデザインを表示する」などのレスポンスに従って、フロントのデザインが表示されます。

本番運用では、GrowthBookがダウンしても問題がないように、実験設定をRedisにキャッシュしています。

GrowthBookの使いかた

では、ここからはGrowthBookの詳しい使い方を3つのステップで説明していきます。

①実験を作成
②Variationやネームスペースの設定

まず最初にGUIから実験を追加し、次にcontrolとtreatmentなどのVariation、ネームスペースなどのA/Bテスト用の設定をします。

GrowthBook側で行う基本的な準備はこれだけです。

フロントエンドに実験名を埋め込む

最後に、GrowthBookで設定した実験名をフロントに反映して、リリースします。(※ 上記のgetFeatureValueはnote側で用意した関数)

APIでcontrolやtreatmentなどの情報を取得して、デザインを一部分だけ変更するなどの判断をすることができます。

ここまでの設定が終われば、あとはGrowthBookのGUIからA/Bテストの変更を簡単に行うことができます。

今後について

検証を通して全チームでも利用できることがわかりました。今後のA/Bテストは特別な理由がない限りは、GrowthBookを利用する方向で考えています。

今まで使っていたライブラリを廃止する必要など、まだまだ改善の余地はありますが、GrowthBookの導入でかなりの時間短縮はできました。全社的に使ってもらえるように、働きかけていきたいと思っています。

▼noteの技術記事がもっと読みたい方はこちら


※ この記事は、エンジニアの社内登壇の内容を再編した内容になります