グロースの逆説 : メルカリで分析とサービスグロースをやる前に知りたかったこと

樫田光 | Hikaru Kashida

この記事ではメルカリという会社で4年ほどプロダクトやマーケティングの分析、グロースなどをやっていた僕（ hik0107 / hikaru ）がそこで得た学びをまとめておこうと思います。

特に「こうやったらうまく行った」というよくある成功談ではなく、

「これをわかってなかったために時間を浪費した」
「結局の所、これが一番大事という当たり前の結論に達した」

などという"知っていれば手間をショートカットできたこと"をメインテーマに書いていこうと思います。

そういう知見は一見当たり前で何も言ってないように見えて、一番役に立ったりするんですよね。

大通りを大事にしろ

色んな所で細かい改善を打つのもよいのだが、結局の所はそのサービスに置いての「一番の大通り」に施策を打つのが最も効果が良いと言うのがメルカリでの施策を通して得た学びだ。

全ユーザの10%しか使っていない場所を2倍良くするよりも、95%のユーザが使っている場所を1.1倍改善するほうが遥かに結果が出やすい。

これは意外と見落とされがちな事実かもしれない。大通りの漸進的な改善というのは非常に地味で、多くの人はマニアックな場所だとしても2倍の改善や機能追加をしたがる。しかしそういったモノづくり魂みたいなモチベーションは使い手側には関係がない。

人はたまにしかいかない裏道のクリスマスツリーよりも、毎日通る通学路の舗装やゴミのなさに100倍興味があるんです。

人通りの多いメイン通りをきっちりと舗装して、石を払いのけること。メイン通りに面したお店の出入り口を掃き清めることを何より大事にすること。

小さな改善では数字はさほど動かない

上の学びの逆ですが、大通りでないところへの施策、特に小さな改善では数字がわかりやすく動くことはほぼありません。大体の場合はびっくりするくらい何のKPIも変化しません。

これは数字を見る経験が浅い人からすると本当にびっくり（というがガッカリ）してしまうと思います。

ちょっとした変化ではユーザは全く気づかなかったり、体験がさほど変わらなかったり、好きな人と嫌いな人それぞれのポジネガにオフセットされて全体としてはかき消されてしまったり、何にせよ無風に終わることが多い。

特に気をつけたいのが、最初は野心的で大きな変更や改善を志していたのに、所々の理由（実装の難易度だったり、テストであっても大胆な変更に否定的なUX警察だったり）によって骨抜きになり、気づいてみたらスコープが当初の構想の10%くらいの小さなものに圧縮されてしまうケース。

結果、リリースしても何も計数上の変化が起きず「ここは掘っても無駄」となってしまう。初期のスコープで大胆にやれば結果は違った可能性はあるにも関わらず...

逆に、小さな改善は頑張ってA/Bテストで計測しすぎると数値の動かなさにチームのモチベーションが下がる原因にもなりかねないので、効果測定は諦め施策の正しさを信じてサクサクとリリースしていったほうが精神衛生上いいのかもしれません。

何でもかんでも分析すればいいってもんじゃない。

復帰に期待するな

それなりの期間運営してるサービスで、ユーザを「新規」「アクティブ」「休眠」などにセグメンテーションしてボリュームを分析すると「休眠」層の多さに目が行くことが多いだろう。

この休眠顧客のうち10%でも復帰してくれればかなりのMAUのカサ増しになる...と誰でも考えたくなる。僕も一時期はこの罠に嵌った。

結論から言うと、休眠顧客を復帰させるための試みはうまく行かないことが多い。「かつては顧客だった」という甘えから、なにか手を講じれば簡単に復帰してくれるように思えてしまうが、大抵の場合復帰に掛かるCPAは安くなはい。実際はもう一度「新規」として獲得し直すような気持ちで努力する必要がある。

また、この手の議論は「何を持って休眠というか」という定義、言いかえれば「いつのタイミングで復帰施策を仕掛けるのがベストか」という、細かくかつ難しい（が、頑張れば答えが出せそうな）議論に発展しがちだ。

実はこれは無駄とは言わないがあまり生産的な結果にならないことが多い。経験則的に行って休眠復帰にはあまり期待しないほうが良いし、時間もかけすぎないことが大事だと今は思っている。

理由なんてわからない

また、顧客の休眠に目を向けると「なぜこの人は離反したのか」が気になってくる。サービスを数字で見すぎて視野狭窄に陥ると、データから離反の理由を突き止めようと躍起になってしまうことがある。

例えば「離反者の最後の取引に共通点はないか」「Bad UXと離反に相関があるのでは」などの仮説を持ちその検証に血道を上げることになったりする。

これも無駄とは言いたくないが、現実世界では「離脱の理由は色々ありすぎてデータでわかるケースは極稀」だと思ったほうがいい。

引っ越しや結婚などの生活の変化、競合と併用していてたまたま競合側に全振りした、端末を変えた際になんとなくアンインストールした、長期旅行などに行ったら使う習慣が消えた、恋人と同棲を始めたら金銭感覚が変わった、などなど、

サービスを使ったり使わなくなったりする理由は星の数ほどあり、ほとんどの理由はサービス提供者には捕捉するどころかその尻尾の片鱗さえも掴めない。

これらは理由がわかりえないどころか、N1などで理由を突き止めたとしても手の打ちようが無いことが大多数だったりするものだ。

わからないことはわからないし、わからないこともたくさんある。これを前向きに認めることは実はとっても大事で、その諦めのおかげで無駄に時間を浪費しなくてすむ。その時間で別の「わかること」「なんとかできること」にフォーカスして価値を作る努力をしよう。

最適なタイミングより早めの一手

メルカリで「登録後○日間で購入がなかったらxxする」といういわゆるCRM的な施策の最適化を行っていた時がある。

わかりやすいものとしては、7日目に初購買を促すためのクーポン、のようなものだ。このときに「最適化」という名目で「何日目がアクションを起こすのにベストか」という議論が持ち上がる。

面白いことに多くの人はこの手の議論が好きで、僕も例に漏れず好きだった。細かく日付を変えてABテストを繰り返したり、投資対効果の比較のGoogle Sheetを作ったりした。

それを自分の身で行う過程は楽しかったし、とても重要だったと思う。しかし結論から言うと、この最適化というコンセプトにはあまり意味がなく、実は最初から結論はほぼ出ている。早ければ早いほどいいのだ。

例えば、見購買者に対して「登録後2日目にクーポン」と「登録後14日目にクーポン」でそれぞれ得るもの・失うものは真逆でトレードオフの関係にある。

ユーザは登録から時間が経つほどサービスに興味を失うので、早めにアクションを打ったほうがコンバージョン数のボリュームは大きくなる。一方で、別にクーポンがなくても買う気だった多くのユーザにも値引きを提供することになるため、投資効果は悪化する。遅めのアクションはその逆で、投資効果は良いが、ボリュームが小さくなる。

実際に計算すればわかることだが、それなりに継続率があるサービスであれば、投資効果が多少悪くても新規顧客を多く作ったほうが長期的な収益は大きくなる。また、ネットワーク効果があるような、規模がものをいうエコシステムであればなおさら、顧客数のボリュームが正義になる。

「効果的な施策のタイミング」を考える岐路に立ったら、迷わずまずはボリュームを最大化する選択肢を第一に考えるのが良いと思う。

人は投資対効果のよいものが好きだが、頑張ってそれに抗おう。

燃費の良い軽自動車で4人運ぶよりも、ガソリンは食ってもジャンボジェットをチャーターして一気に300人を高速で運びさるほうがむしろ得なんだ、というバブリーな価値観が時には求められる。

それがウェブサービスだということを覚えておこう。

継続率は放っておけ

LTVの向上のために、インストール後の7dayのRetention（継続率）を事業のKPIにおいて日々トラックをしていた。

なんならslackに最新の7day-RR%が毎日流れるようにしていた。

それはそれでチームの意識を上げるという意味では良かったのだが、継続率というのはサービス全体のUXやその他非常に様々な要素を背景として発露するもので、数字としてそんなに簡単に上がったり下がったりするものではない。

それにDailyのレベルで一喜一憂すると疲れてしまうデメリットのほうが大きい。もっと長期的に腰を据えて取り組むもの、かつ細かい改善とは別に大味な手を打たないと継続率はドラスティックには改善しない。

過去の経験でも、継続率が重要なフェーズのサービスのユーザ規模感だと、7day RRなどは週次で見てもこれくらいは上下する。

画像1

Business Intelligence in mercari (2017) より抜粋

中期で振り返ると確かに上がっていた、という話なのだが、短期的に見すぎると船酔いしてしまいそうだ。

継続率は「結果的に上がっていったら嬉しい」「個別の施策との結びつきを意識しすぎない」くらいの構えでいたほうが良い説が濃厚。

探るよりバカになって寄り添え

人は何故か「当てっこゲーム」が好きだ。箱の中に隠されているものを当てようと躍起になる。ウェブ業界の人間は、放っておくとすぐに「これまでの情報からこのユーザの好きなものを推定」しようとする。

AとBとCという商品を見ているユーザは何に興味があるだろうか。

AとBとCに類似度が高いDという商品を推薦すればいいのでは？類似度は商品ベースの特徴のコサイン類似度で取ればいいのか？.... 

などと考えるのは悪い癖の始まりだ。実はこのゲームには必勝法がある。

AとBとCという商品を見ているユーザは「AとBとCに興味がある」
これが必勝法だ。

推定したDをレコメンドするより前に、もっとやることがある。A,B,Cのうちまだ何も買っていないようなら、その中にユーザが本当に欲しい物がある可能性は低くない。

ユーザが「気になっている」ものを「まだ買っていない」理由はたくさん考えられるが、実は単にまだ決めきれてないだけ、ということが往々にしてよくある（時限式のクーポンやセールの最終日で売上がやたらと伸びるのはここに理由がある。）。

ユーザが商品A,B,Cを見ていたなら、無理やり勝手に推定した商品Dを進める前に、A,B,Cに未練がないのかをきっちりと探ろう。そして、そっと背中を押してあげよう。

あれやこれやと賢ぶって勝手に推測して探りを入れるヤツはモテない。
そんなことより、バカになってわかりやすくユーザから発されているシグ　ナルに寄り添ってあげよう。

メルカリは「いいねした商品」「検索した内容」「見たことがある商品」などにかなりUIの上でいい場所を与えてますよね。

事業計画とKPIは一心同体

プロダクトが好きだとユーザの体験やUI、機能に関わる数値やKPIに重心をおいてしまいがちになる場合がある。行動系のKPIや登録後の継続率、といったユーザを軸にした数値や分析に目が行きがちになる。

しかし、どんな会社でも基本的には「ユーザの体験」だけを焦点に当てて事業運営をしていくのは難しい。遅かれ早かれ"ビジネスとしての良し悪し"という判断軸が社内の意思決定の優先度の階段を駆け上がり、やがては頂上に陣取る。

僕のデータ分析のキャリアにおける、最大の気付きのひとつは、

「ビジネスの判断軸と顧客体験を含むユーザKPIを調和し共存する形でモデルを組むことで事業は大きな力を発揮する」ということだ。

これの実現方法はいくつかあるのだと思うが、僕の視点で話す場合は「プロダクトのKPIを設計するデータアナリストが、事業計画のモデルと予算の策定を担う」という言い方になると思う。

これがうまくいくと格段にいろんなことがやりやすくなる。
自分はメルカリで程なくこのことを突き止め、優秀な事業リーダーのもとに事業計画に関わる機会に恵まれた。が、もっと早く気づけておけたら、といまでも思っている。




いつも読んでくださってありがとうございます。 サポートいただいたお代は、執筆時に使っている近所のお気に入りのカフェへのお布施にさせていただきます。