GrowthBookでA/Bテストの工数削減し、誰でもテストができる環境になった話
UX改善チームの甲斐です。
私たちのチームでは、A/Bテストを実行しながらUX改善を行い、クリエイターの売上を伸ばすことを目標としています。
今までnoteでは社内製のA/Bテストツールを使っていたのですが、工数が大きくかかってしまうことが悩みでした。
そこで、テストツールであるGrowthBookを導入し、より効率的で柔軟なABテストができるような環境を目指しました。導入したことで、UIから誰でもテストを実行できるようになり、工数も削減することができました。
この記事では、導入の背景や他ツールとの比較、導入時のTipsやメリットなどについて、詳しく話していきます。
GrowthBook導入の背景と課題
noteでは社内製のRubyライブラリを使ってA/Bテストを行ってきました。
しかし、テストを行うためにコードを変更してリリースしなければいけない状態でした。計測してみたらテスト完了までに10日ほどかかっていたことがわかりました。また、コードを触る必要があるため、エンジニアしかテストを実行できない課題もありました。
そこで、今年の1月からA/Bテストのツールを導入する検討を始めることになりました。
UnleashとGrowthBookの比較
noteで今まで実施していたA/Bテストでは、違う実験がぶつかり合わないようにネームスペースを切ってユーザーごとに分けていました。今の方針をそのままできるツールであることが前提条件でした。
最初に候補にあがったのは、Unleashでした。使いやすかったですし、機能としても充分でした。ただ、先ほどあげたネームスペース機能がUnleashにはなかったため、導入を断念しました。
他のテストツールも検討しましたが、高機能なものはあまりありませんでした。基本的には、Googleアナリティクスのようにランディングページをテストするようなツールが多い印象です。
色々と調査と検証を重ねた結果、機能の充実さとネームスペースが利用できることからGrowthBookを導入することになりました。また、GrowthBookはRuby向けのSDKも用意されていて、noteと連携しやすい相性の良さもありました。
UnleashとGrowthBookの差はほとんどなく、ネームスペースが使えるかどうかという点のみが決定打となりました。
GrowthBook導入時のTips
導入は特に大変なことはありませんでした。
工夫した点を強いてあげるとすれば、GrowthBookから実験データを取ってくる際に、キャッシュを入れた点でしょうか。
キャッシュを設けずに実験データを取得する場合、ユーザがnoteにアクセスする度にGrowthBookのサーバから実験データを取得することになります。そのため、GrowthBookのサーバーに大量の負荷がかかるため、RedisでデータをキャッシュしてSDKに渡すようにしました。
独自で開発をしたのはこのくらいで、あとはドキュメント通りにすんなりと進めることができました。
GrowthBookを導入したメリット
UIでA/Bテストが設定可能
GrowthBookはセグメントやグループなどの条件をまとめることができ、特定のユーザーだけにテストを行うことができます。
これらのテストがUIで実行ができるため、PMでもデザイナーでもA/Bテストを実行できるようになりました。実際にチームのPMに触ってもらったのですが、特に違和感なくすぐに取り組むことができていました。
工数の削減
サーバーサイドの変更が不要になったため、開発の工数が大幅に削減されました。
また、今まではテストで問題が発生したときには、切り戻すために緊急リリースをする必要がありました。しかし、GrowthBookを導入したことでUI上でオンオフが実行できるようになったため、すぐにテストを中止することが可能になりました。
運用コストが低い
GrowthBookはオープンソースであるため、セルフホストできるのも大きなポイントです。
noteのサービスを稼働させているKubernetesクラスタ(EKS)上で動かしているため、運用コストがほとんどかからないこともメリットの1つだと感じています。
今後の課題
UIの複雑さ
GrowthBookはできることが多いので、初めて触るとUIに戸惑ってしまうことがあります。
また、UIで操作をする必要があるので、ポチポチと押していかなければならない部分も多く、少しめんどくさく感じる人もいるかもしれません。
このあたりはドキュメントを整備して、誰でも使えるような準備はしたいと思っています。
現行ツールの移行
今、使用しているツールを徐々にGrowthBookに移行していきたいと思っています。現行ツールとGrowthBookのネームスペースは別々なため、実験がぶつかってしまうことも考えられます。今年中には完全に移行を完了させる予定です。
まとめ
ツールは導入してからが始まりだと考えています。これからチームメンバーに使ってもらい、使い心地などを見て、足りないところを改善したりしていく予定です。
他のチームに無理にGrowthBookの使用をお願いする必要はあまりないと考えています。まずは自分たちのチームでブラッシュアップしていき、そこから徐々に展開していこうと考えています。
A/Bテストがすばやくできるようになったことで、noteへの改善スピードもあがったはずです。これからますますUXの改善に取り組んでいきたいと思います。
noteのA/Bテストをさらに詳しく知りたい方は、上記の記事もぜひご覧ください。
※ この記事はエンジニアのインタビュー内容をもとにライターが再編しました
▼noteの技術記事をもっと読みたい方はこちら