Speee DEVELOPER BLOG

Speee開発陣による技術情報発信ブログです。 メディア開発・運用、スマートフォンアプリ開発、Webマーケティング、アドテクなどで培った技術ノウハウを発信していきます!

数打ちゃ当たるは的外れ。成果を生み出す「ユーザー中心設計」のABテスト

デジタルトランスフォーメーション(DX)事業本部でPMをしています、九島です。

新卒でSpeeeに入社してから、約5年間グロースに取り組んでいて、中でもLPのABテストを継続してやってきました。この記事では、ABテスト初心者の方に向けて、自分の失敗や試行錯誤の過程をお伝えしながら、今一番上手くいっている「ABテストの型」を紹介します。

「サイトのABテストを任されたけど、どう考えたらいいの?」「ちょっとやってみたけど、もっと成果出すにはどうしたらいい?」 とお考えのEFO担当者の方にとって、一助になれば幸いです。

ABテストとは?

web業界にいる方なら、「ABテスト」という言葉は一度は聞いたことがあるのではないでしょうか。

ABテストとは、

  • A、Bのパターンを用意して結果を比較するテストのやり方
  • どちらがよいか? という結果が明確に出る
  • 様々な要素でA/Bテストを行い、結果のよかったパターンを実装していくことで、最適化していく

といったものです。


メリットは、

  • 同時並行でパターンを試すことができるので、時間による変化を(ほとんど)無視してOK
  • ツールがたくさんあり、コスト低く、フットワーク軽く実施ができる

があり、一方でデメリットは、

  • 短期では最適でも、長期に目を向けるとずれてしまいがち
  • 検証のために、一定の流入数が必要

が挙げられます。


余談ですが、オバマ大統領が利用したのをきっかけに、ABテストは広まりました。(※参考|オバマ大統領が簡単なテストで、6000万ドルもの収益を上げた方法)

1年目:200施策やってCVR上がらない

僕は新卒で入社してすぐ、ABテストのプランナーになりました。

そして10ヶ月間で200施策実行し、ずっとCVRが改善しませんでした。(当時の上司、すみません。)


振り返ると、このような悪い循環にハマり、しばらく抜けられなかったのです。

「施策がなくなってきた」という方は、この循環にハマる兆候かもしれません。

  • はじめは順調だったが、徐々に施策がなくなっていく
  • 「施策数」を気にして、とりあえず施策を実行してしまう
  • ABテストで勝っているのに、事業数字が改善しなくなり、焦る
  • 「施策の改善幅」が高い施策をやろうとリソースを確保し実行するも、工数かかるわりに大外れ
  • やることがなくなる・施策がなくなる

f:id:PoohShinHana:20220214143025p:plain

当時、「自分はできる」「頭がいい」と思っていました。自分が考えた施策は当たるはずと思っていたからこそ、一度上手く進まなくなってからは目の前の数字を上げようと必死になり、空回りしていました。

今になって思うと、こちらの記事でWACULの垣内さんがおっしゃるとおり、ABテスト実施の目的が、「成果を上げること」でなく、 「成果を証明すること」になってしまっていたようです。「ABテスト」という手段にこだわり過ぎて、ユーザーを置いてきぼりにしていたんだと反省しています。

2~3年目:ユーザーニーズを掴むことが糸口に

2年目の途中から新規事業に抜擢されました。(内心、失敗してたのに僕で良いんだろうか、、とは思いました。)


事業として立ち上げたばかりということもあり、まずはユーザーインサイトを掴むため、リスティングの広告文改善から着手しました。

「3種類の広告文を追加し、結果をみて振り返り、次の広告文を追加する」という地道な活動を毎週行い、最初の3ヶ月でユーザーのコアニーズを見つけ、残り3ヶ月で見つけた軸を深堀りました。

細かな表現の違い(「安い」or「最安値」)でも結果が大きく異なり、この経験をとおして、ユーザーニーズに手触り感を持つことができました。


3年目からは、広告文の改善によって理解したユーザーニーズを元に、LPのABテストを開始しました。

大失敗をしているので不安だったのですが、ユーザーニーズに沿って改善を続けた結果、1年目で苦戦したのが嘘のように上手くいき、CVRが開始時の3倍になりました。

f:id:PoohShinHana:20220214143926p:plain
1年間のCVRの推移

当時の上司に勧められ、この一連を振り返って言語化しました。

それによって自信がつき、更にユーザーを意識した改善施策を実施して、成果を出せるようになりました。

f:id:PoohShinHana:20220214144206p:plain
社内wikiに公開しました

4~5年目:行き着いたのは「ユーザー中心設計」のABテスト

4,5年目は、同時に4領域でABテストを実行しました。

立ち上げ期・成長期・安定期と異なるフェーズのLP、異なる種類のユーザーニーズでしたが、同時に実行することで抽象化した学びとなり、自分の中で上手くいくABテストの型が分かってきました。


僕が見つけた型は、

LPやEF(エントリーフォーム)をプロダクトと見たてて、そのプロダクトを磨く手段としてABテストを実施することです。


具体的には、次の3つになります。

 ① ユーザーニーズを定義し、コアの提供価値を決める

 ② 「何をやるか」ではなく「どういう仮説を検証するか」にこだわって、施策をつくる

 ③ 施策数や施策の成功数ではなく、事業の数値を結果責任として持つ

1つずつ説明できればと思います。

①ユーザーニーズを定義し、コアの提供価値を決める

LPやEFをプロダクトとして見立てるのであれば、必要なのは、「誰の・何の課題を解決するためのページなのか?」を決めることです。 ABテストを実施する前に、これを決めます。それによって、施策や判断に方向性が生まれ、局所最適なABテストを防ぐことにつながります。


例えば、このような質問に答えを持っておく必要があります。

  • ページに流入したときの期待値
    • ユーザーが知りたい/やりたいことは何か?
    • それができない(と思っている)構造は何か?
    • このページで何ができると思っているか?
    • そのクオリティはどんなもんだと思っているか?
  • 流入時の期待を上回るためにできること
    • ユーザーが得られるもののクオリティを高められないか?
    • ユーザーが得られるものを、想起しやすくできないか?
    • ユーザーが得るまでの行為を、なめらかにできないか?

f:id:PoohShinHana:20220215152905p:plain
LPについて、ユーザーニーズとコアの価値を定義したときの資料です

②「何をやるか」ではなく「どういう仮説を検証するか」にこだわって、施策をつくる

施策を作ろうとすると、どんな内容にしようか?ということに視点が及んでしまいがちです。改善しやすいフェーズであればよいのですが、その場合はユーザー理解が生まれづらく、施策が枯渇していきやすくなります。


僕は下記のフォーマットで毎回施策を作っています。

見ていただければわかるとおり、「仮説」のところがかなり肉厚で、しっかり設定できるようにしています。

## 施策について
### ざっくり内容

### 仮説
- 〇〇なので
  - (実数値や他の施策の結果)事実として
  - ↑の事実は、ユーザーの気持ちがこう動いているのだろう
- 〇〇することで
- 〇〇するのではないか
  - ユーザーの気持ちがこうなる
  - 結果、何の指標がどうなる

### リリース指標
- 上がってほしい
- 維持してほしい

### 考察にあたっての指標
- 指標①:◯◯
- 指標②:◯◯

このフォーマットで施策を行うと、事前に仮説と指標が設計されていることで、振り返りを通してユーザー理解が深まりやすくなります。

また結果が出たときに、下記のように分岐できるので、施策のネタ切れ状態を起こしづらいです。

f:id:PoohShinHana:20220215154028p:plain
施策後のアクションを決めるツリー

③施策数や施策の成功数ではなく、事業の数値を結果責任として持つ

方針を決めて、ユーザーに向けて施策を実行しても、事業成果を出せないことはあります。ユーザビリティを追求することが必ずしも事業成果に紐付かない例は、いくつか思いつくのではないでしょうか。

そこで、テストのプロセスではなく、実際の事業にまつわる数字を結果責任としてみましょう。営利組織である以上、ユーザーと事業がwin-winになる関係を目指す必要があり、ここは避けては通れません。


また、実は事業全体の数字を見るとユーザー理解が深まります。

というのも、どうしてもABテストの影響ではないところで数字が変動します。そのため、数字の報告責任を果たすには、ページへの流入前・流入後の状況を把握し判断する必要がでてきます。そうすると、不思議と、今まで見ていたのとは違った景色でユーザーを見ることができます。

「責任領域が増えて大変だな、、、」と思うかもしれませんが、責任として持っていると、手段に自由度が高まり、やりたいようにユーザーと向き合うことができます。

f:id:PoohShinHana:20220215210902p:plain
実際の成果報告のフォーマットです

まとめ

僕の5年間のABテストの経験と、上手くいくために自社で取り入れている、「ABテストの型」について紹介させていただきました。

ポイントについて改めて整理すると、

  • 最適化の方向性をコントロールする
  • ユーザーに向き合って施策を回す
  • 事業数字と離れないように、モニタリングする

といったところでしょうか。

f:id:PoohShinHana:20220214144428p:plain

僕はこの考え方をするようになってから、ABテストが好きになりました。

プロダクトとして解釈できるようになり、幅や奥行きが見えるようになってきました。また、フットワーク軽くユーザーの検証を行えるのも魅力的です。

ABテストのもう一つ好きなところは、失敗してもいいことです。仮説さえしっかりしていれば、失敗から学ぶことができ、またチャレンジすることができます。


最近は、後輩にABテストのナレッジと考え方を伝えていく役割を担っています。その過程で言語化が必要となり、正直苦戦しています。 ABテストで学んだように、最初うまくいかなくても、諦めずに取り組み続けたいと思います!


-------------------------------------------—-------------------------------------------—


Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています!

もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください

tech.speee.jp

Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの?」と気になってくれてた方は、こちらチェックしてみてください!もちろんオープンポジション的に上記に限らず積極採用中です!!!