トクバイ テックブログ

株式会社トクバイの技術部メンバーが、テックについてワイワイ語ります。

超速でABテストを回すモバイルアプリ開発 前篇

f:id:hatuyuki4:20190312154113p:plain

こんにちは! @hatuyuki4です。普段はiOSアプリ開発をしているエンジニアです。イカが好きです。

トクバイでは昨年、アプリの新規ユーザ定着率改善のために専用チームを作り、その中で積極的にABテストを使って検証を行ってきました。その中で重視していたのはスピード感です。

行った施策の数は3ヶ月の間に40以上!!

スピード感を出すためには、限られた時間で数多くの検証を行う必要があるのですが、闇雲にアイディアを募ってもすぐに枯渇してしまいますし、見当外れの施策を行ってしまう恐れもあります。そのため、スピード感を持って効果的な施策検証を回すためには以下のことが重要になってきます。

  1. 根拠のある仮説を立てる
  2. 仮説を施策としてアプリに落とし込む
  3. 検証結果を分析し、次の改善に役立てる

今回はこれらの中の(1)と(2)について、チームで行ってきたことを紹介します。

根拠のある仮説を立てる

検証を行ううえで根拠のある仮説を立てるのは重要です。しかし、どのようにすれば根拠のある仮説が立てられるのでしょう。そのためには、どのように仮説を立てるのか、アプローチが重要になってきます。

マジックナンバー分析

マジックナンバー分析とは

マジックナンバー分析とは、アプリの成長に関係する重要なイベントを特定するための分析手法の1つです。有名な事例としては、Twitterが「初日に5人以上フォローしたユーザは定着率が高い」というマジックナンバーを発見し、初回登録時におすすめユーザのレコメンド機能と5人以上のフォローを促すようにした事例などがあります。

マジックナンバーの探し方

マジックナンバーを探していくには、まず、あらゆるユーザイベントと定着率を出していきます。その中から、イベントを行ったユーザ数と定着率が上がっているイベントの上位をマッピングしていきます。

さらに、そのイベントを回数や件数など数量化できるものならば、その数量別の定着率を出していきます(初日のフォローというイベントなら、そのフォロー数など)。そして、数量別の定着率が目標とする指標をoverするラインを見つけ、その数値をマジックナンバーとして定めます。

f:id:hatuyuki4:20190312153858p:plain
ユーザイベントごとの定着率

マジックナンバーの例

チームでマジックナンバーを分析した際、「ユーザは初日にチラシを閲覧していると定着率が高くなる」ということがわかってきました。トクバイは、日頃よく行くお店の特売品や折込チラシをアプリで見られることに価値があります。そのため初回利用時にサービスの価値をちゃんと体験したユーザは定着率も上がるということが言えそうです。

例えば以下のグラフは、初日のチラシ閲覧数と7日後定着率を表したものです。

f:id:hatuyuki4:20190312154113p:plain
PV数と7日後定着率

わかりやすい右肩上がりになっています。初日にチラシを複数枚見るという体験をしたユーザは定着率があがるということがわかります。

マジックナンバーから仮説を立てる

このように、あらゆるユーザイベントと定着率の関係を可視化し、改善したい指標と関係性の高いイベントを探っていきます。関係性の高いイベントが見つかったら、そこから根拠のある仮説を立てていきます。今回の事例なら、初日にチラシを多く閲覧したユーザは定着率が高くなるという仮説が立てられます。

カスタマージャニーマップ(CJM)の作成

カスタマージャニーマップ(CJM)とは

カスタマージャーニーマップとはユーザがサービスを利用する際にユーザが接する様々な段階のタッチポイントと、その時生じる感情の起伏をサービス利用時の流れに沿って視覚化するツール。

wikipedia

マップのスコープ

CJMは同じサービスでも、何を目的とするかによって必要となるマップも粒度も異なってきます。すでに一度CJMを作っていたとしても、ターゲットにするユーザ、改善する機能によって、新たにCJMを作り直すべきか検討する必要があります。

トクバイでもCJMの作成は行っていましたが、それは普段トクバイを使っているユーザに対してのCJMでした。

今回は新規ユーザ定着率改善が目的だったので、アプリインストールから翌日の再訪までの流れを細分化してCJMを新たに作成しました。

感情が大事

CJMでは感情が大事になります。特に感情曲線が下がるようなマイナスな感情です。どんなアプリであろうと、ユーザは何かしらの期待を持ってアプリを使い始めています。その期待に添えられないようながっかりポイントが発生するとしたらどこかということをマップにして可視化できるようにします。

そこから、 がっかりポイントを回避できれば定着率があがるという仮説が立てられます。分析などで数値ばかり追いかけていると忘れがちですが、アプリを使っているのは人間です。感情のままに行動することは人間として正しい生き方であるので、やっぱり感情が大事になります。

共有

以前トクバイでCJMを作成した時には、GoogleDrive上で共有していました。しかしそれだと、自分が目的を持ってCJMのページを見にいかないと、CJMを目にする機会がなく、作ったはいいけど放置されがちになってしまいます。チーム内での認識にもバラツキができます。

そのため、今回チームではホワイトボードの一面にCJMを作成しました。

これにより、MTGや朝会、普段業務をしているときにも目にすることができ、自分たちが今どのポイントを改善しているんだという意識が共有されやすくなりました。

f:id:hatuyuki4:20190312154746j:plain
CJM例

仮説を施策としてアプリに落とし込む

分析やCJMなどによって根拠のある仮説が立てられたら、次はそれをどのようにアプリに落とし込んでいくかが問題になってきます。例えば分析により 初日にチラシを多く閲覧したユーザは定着率が高くなるという仮説がたち、ユーザによりチラシを閲覧してもらおうと思っても、それを実現するためのアイディアは複数あります。

  • アプリのファーストページでチラシへの導線を表示する
  • コーチングでまずチラシを表示してもらうように誘導する
  • ウォークスルー内でチラシを体験させる

などなど、アイディアは複数でてきますが、それを実装するための時間もリソースも限りがあります。

そのためスピード感を出すために、どのようにアイディアを出し、どのようにやる施策とやらない施策を振り分けるのか意思決定を素早く行うことが重要になってきます。

アイディア会

チームではアイディアを出し合い、どのアイディアを実装するかを決定するために、定期的にアイディア会というものを開きました。

個人でアイディアを出す

そのアイディア会ではまず、時間を決めて、各個人が付箋にテーマに沿ったアイディアを書き出します。これは、いきなりテーマにそってどのようなアイディアがいいかブレストを始めると、アイディアが固まっていなかったり、発言するのが苦手だったりする人のアイディアが埋もれてしまいがちです。一度個人で考えを整理して、それを付箋に書きだしていくことでチーム全員がアイディアを出し合える環境にします。

アイディアをまとめる

時間が立ってアイディアがあるていどかけたら、それをホワイトボードに貼り付けていきます。付箋がより重なったものがチームで共通認識が得られます。この段階ではアイディアの種類は気にせず、適当に並べていきます。

アイディアのマッピング

アイディアがまとまったら、それを実装コストと影響度の2軸で並び替えます。二軸で並べると、一番実現可能で、一番効果が高いものが可視化されます。後はそのアイディアをgithubでissue化して、より詳細な仕様を固めて検証を行っていきます。

さらに、付箋にアイディアを書いておくと、その後のタスク管理にも使えるのでおトクです。

f:id:hatuyuki4:20190312154811j:plain
付箋でタスク管理

最後に

今回は 根拠のある仮説を立てる仮説を施策としてアプリに落とし込むという内容を書きましたが、これだけでは施策検証を行えたとは言えません。施策検証を行うためには、どのように施策を実装し、リリースサイクルに乗せていくのか、リリース後にはどのように分析して今後の改善に繋げていけばいいのかというのかが重要になってきます。

特にモバイルアプリ開発はリリースフローが決まっている場合が多いので、スピード感を出すためにはフロー自体を見直す必要があります。それらに関しても色々苦労して工夫した点があるのですが、それはまた次回書きたいと思います。