Analyst がCRM領域で価値を出すために心がけた3つのこと
はじめまして。メルカリ Growth Analytics チームで、CRM領域*の分析テーマを担当している岩田です(@iwachi_55)。この記事では、CRM施策を分析する際に直面した課題と、それを解決するため Analyst として何を行い、どのような成果を出したかをまとめました。
* Customer Relationship Management : 一般的に、お客さまとサービスの接点に関する情報の管理・分析を通じ、お客さまに合った最適なコミュニケーションを提供することでロイヤリティ向上を目指すマーケティング領域
こちらの記事は、先日の Retty さんとメルカリのイベント「Retty ✕ Mercari Analyst Talk Night!」に登壇した際の内容に、イベントではお伝えできなかった具体の内容を含めて加筆・アップデートしたものです（資料 / 動画）。
さて本題ですが、私がこの記事でお伝えしたい事は3つです。
1) Analyst は、CRM方針だけでなく、その後の実行計画の策定まで行おう
2) 計画は検証すべき仮説の重要度を踏まえ、最短で重要論点に答えが出せるように作ろう
3) Analyst が意思決定を推進するためには、PDCA 全体に関わっていこう
それでは早速、続きの文章で追って説明します。
CRM領域における Marketer と Analyst の役割 （当時）
まず、この記事の話の前提として、CRM領域において Marketer と Analyst がどのように協働しているかを簡単に紹介します。メルカリのCRM領域における取り組みの全体像を、PDCAの4つで整理すると下記のようになります。どういった観点で仕事をしているかイメージを持ちやすくするために、それぞれの局面で Marketer / Analyst が主に考慮している点も記載しました。
P) 作戦・施策方針の策定
・事業上の目標に関連して、何を達成すべきか
・どういったお客さまを狙うべきか
・何を訴求し、どういった行動を促していくべきか
・どのように施策を行うべきか
D) 施策の実行・施策効果のモニタリング
・作戦に応じた施策を実行できているか
・施策効果を、正しく、タイムリーに評価する体制ができているか
C) 施策の評価・インサイト抽出
・狙ったKPIの目標水準に対して、結果はどうだったか
・作戦で描いていた仮説どおりの結果だったか、想定と違った場合はなぜか
・施策効果を、正しく、タイムリーに評価する体制ができているか
A) 次回施策・作戦へのインサイトの反映
・施策の結果、わかったインサイトをどのように次の施策に組み込むか
・施策の結果から、作戦をどのようにアップデートすべきか
この中でAnalyst が特に注力していた領域は、P) 作戦・施策方針の策定と、C) 施策の評価・インサイト抽出です。作戦立案のための分析や、インサイト抽出のための施策分析を、Marketer と協働しながら遂行することを主な活動としていました。
一方で、Marketer と一緒に作戦を立てたあとの D) 実行局面については、モニタリング体制を整えること以外に踏み込んだサポートはせず、Marketer の方々に一任する役割分担がなされていました。
当時の課題：実行計画の不備で、検証したい仮説に答えが出せない
このような役割分担をしつつも、Marketer / Analyst の連携を深めていく中で、見えてきた課題があります。
良い作戦を立てることが成果を出すために必要であることは真ですが、良い作戦を立てるだけで成果が出るわけではないこともまた真です。実行を通じてその作戦を評価すること、さらにその評価を踏まえて次なる作戦を立案し、またそれを実行して評価する。これらを繰り返し、事業上の成果の最大化を図る必要があります。私がCRM領域の Analyst となった当時は、「実行を通じてその作戦を評価する」という目的に照らして、施策設計や実行計画が適切に策定されていないことが課題でした。具体的には、「当初の作戦のどこが良くて、どこをどのように改善すべきなのか、あるいは方針を変えるべきなのか」という問いに、答えを出しづらい、あるいは答えを出せたとして時間がかかる施策設計と実行計画になっていたのです。どういうことなのか、以下で実際に起きていたことを元に、便宜的にデフォルメした例を使って解説します。
例1：仮説が正しかったかどうか、答えられない施策の設計になっている
前提として、購入はするが出品はしたことがないお客さまに対して、出品を促していく方針だったと想定してください。その方針の中、 Marketer が、下記の2つの施策改善の仮説を検討したとします。
仮説1：訴求タイミング
購入体験のタイミングに合わせて、購入に絡めた訴求をすると出品してくださるのではないか。具体的には、購入する手前の検索の時に、「出品すればXXX円分のお買い物がお得！」といった訴求をすれば、単にアプリを訪問した時に訴求するより良いのではないか？
仮説2：キャンペーン期間設計
お客さまは、「いつでもできる」というより状態より、「今しないと損をする」という気持ちになった方が行動するのではないか。具体的には、出品キャンペーンの期限を今より短くして、「今しかない」といった訴求をするの方が良いのではないか？
さて、この2つの仮説を検証するにあたって、実際の施策は下記のA、B のような設計になりました。この設計で実行して、私が分析をする際に困った点はなんでしょうか。
正解は、こちらのパターン数の施策だけでは、仮説1の効果がよかったのか、仮説2の効果がよかったのか、切り分けて評価ができない点です。パターンBは、パターンAと訴求タイミングとキャンペーン期間の両方が異なっており、どちらの仮説が当たったのか、どちらの仮説が効果により寄与したのかが、単純に比較するだけでは分からない設計になっています。当時のCRMでは、このような設計の不備で、仮説の評価に関する知見が積み上がらない状態が問題でした。
なお、こちらの仮説 1、2を検証したい場合の設計例は下記が考えられます。A vs B で 仮説1を検証し、B vs C で仮説2を検証するという設計です。
例2：同じ論点の仮説を異なる時期に検証しており、最短で答えを出せない
もう一つの例は、先ほどの例と同じで、購入したことはあるが出品したことはないお客さまの出品促進の話です。施策の体験全体に係る重要な問いに、「購入体験にのせた訴求タイミングは、どこが最も効果が高いか？」というものがありました。
この問いに対する検証したい仮説として、下記の3つがありました。
仮説1：検索のタイミングで訴求することがベスト
仮説2：いいねのタイミングで訴求することがベスト
仮説3：商品を閲覧しているタイミングで訴求することがベスト
そして当時、この仮説を検証する施策の実行日程は下記のようになっていました。これのどこが問題だったのでしょうか。
検証1：20xx / 8 / 14
検証2：20xx / 9 / 1
こちらの実行日程で困ることとしては、施策方針においてどのタイミングで施策を発動させるかというのは、体験全体を踏まえてまず最初に決定しておきたい重要な論点である中、2回の時期が異なる検証を待たないと、その論点に対する答えが出せない点です。また、施策の実行時期が分かれることの別のリスクとしては、実行時期によって別の要因（e.g. 季節トレンド、別のプロモーション施策影響など）が絡み、それぞれの時期の Control郡と施策郡のKPI水準が単純比較できないことがあります。そういった余計な観点を増やさないためにも、重要な論点に関しては、いくつかの仮説を同じタイミングで検証して、期の早い段階で答えを出し切ることが望ましいです。具体例として、下記のようなものです。
検証1：20xx / 8 / 14
実行計画不備の背景にある課題
さて、ここまでの記載で、実行計画や施策設計に不備があった事例を解説しました。では、これらの事例の背景にある課題は何だったのでしょうか。
当時の課題は、下記の2つだと考えていました。
1) 仮説に対して施策を適切に設計するための運用が確立されていなかった
（よって、設計に不備があっても施策が実行されうる状態になっていた）
2) 体験全体に影響がある幹となる重要仮説と、枝葉の仮説が区別されず、実行計画の検証順序に反映されていなかった
（よって、同一論点の仮説検証がバラバラの時期に実施されるようなことが起きていた）
次の章では、これら2つの課題に対して、どのような取り組みを行ったかを紹介します。
課題への取り組み：検証設計のフレームワーク策定・仮説の重要度の計画への反映
前章で述べた2つの課題に対して、それぞれ実行した対策を共有します。
1) 検証設計のフレームワーク策定、レビュー体制の確立
施策設計の不備によって、仮説の答え合わせができない事例の防止に関して、Analyst とMarketer で、施策実施前に施策設計のレビューをする会議を運用の中に設けました。
レビュー会では、下記の施策設計のフレームワークでポイントを確認し、仮説の評価に問題が生じない設計に施策を落とし込んでいきました。
CRM施策 検証設計のフレームワーク
A) 仮説の確認
・この施策では何の仮説を検証しようとしているか？仮説は複数あるか？
B) 検証設計の確認
・仮説に応じた適切な施策設計になっているか？施策の結果指標を見て、その仮説の評価ができるか？
・複数の仮説を検証する場合、施策パターン数は十分に用意できているか？
C) サンプルサイズの確認
・施策パターン数が多い場合、サンプルサイズは十分に確保できるか？
ここで少し留意が必要な点が、全ての仮説の数に応じて施策パターンを機械的に増やすことが必ずしもベストではないことです。施策パターンが増えれば検証に係る工数も増えるため、事前にほぼ自明に考えられる点については、施策パターンを無闇に増やさず、あくまで重要かつ確かめるべき価値がある仮説のみ、検証のエラーがないように設計することがゴールです。
（例えば、インセンティブ額が増えればより多くのお客さまが反応することは自明のため、他に検証すべき体験上の重要な仮説があればそちらを優先し、インセ額で複数パターンをあえて用意することはありません。※あくまで例であり、投資対効果でどの程度の額がROIが良いか、という論点ならインセ額は重要な変数なのでこの限りではない）
施策設計のレビュー会はシンプルな対策ではありましたが、ノウハウ共有と蓄積の効果が高く、今では Analyst が関与せずとも、設計エラーによって仮説が評価できないということは起きなくなっています。
2) 仮説の重要度の提示、優先順序を考慮した実行計画への落とし込み
重要な仮説が効率的に検証できる計画となっていなかった課題に対しては、毎四半期末にAnalyst と Marketer で、次の期で検証すべき仮説を洗い出し、優先度を整理して計画に反映させていく取り組みを実施しました。この取り組みを行う前は、四半期の中で施策を実行しながら仮説を考えていくというような動きでしたが、期初までに仮説を洗い出し、それらの検証の優先順序を最初から計画に反映して実行することで、最短かつ最小の施策数で、重要な仮説に答えを出す運用を定着させることができました。
例えば、登録直後のオンボーディング段階において、どのようにすればお客さまに購入と出品を両方、経験していただけるか？というテーマがあったとします。
その際、仮説としてさまざまなアイデアが出ることが想定されますが、優先順序をつける判断軸は、体験全体に影響がある仮説なのか、それともその仮説が検証されたとしても体験の一部にしか影響がないものなのか、という点です。洗い出した仮説がどちらに整理されるのかを考え、まずは体験全体に影響がある仮説を優先するように留意します。
例えば、下記のように、購入と出品の訴求順序に関する仮説と、購入促進のためのクーポン配布設計に関する仮説があった場合を考えてみます。
仮説1：購入と出品の訴求順序
・購入と出品を両方経験いただくには、まず購入を促すコミュニケーションをした方が良い
・購入は出品に比べ手間が少なく、まずメルカリ内の取引に慣れていただいてから出品を促した方が、結果として購入と出品を両方経験していただけるのではないか
仮説2：購入促進クーポンの配布設計
・購入を促すためには、期限の長いお得なクーポンを1度に配るよりも、期限の短いクーポンを、購入していただくまで何回かに分けて配る方が良い
・期限の短いクーポンで、「今買わないともったいない」という状態にしつつ、期限が短いことによる機会損失を配布回数でカバーすることで、購入するお客さまを最大化できるのではないか
この場合、1つ目の訴求順序に係る仮説を先に検証するように計画します。最初に訴求すべき行動が購入なのか、出品なのかを明らかにしておくことで、その後はその勝ちパターンに基づいた施策を改善することに集中できるからです。また仮に、出品を先に注力するべきという結果になった場合、2つめの購入促進に関する検証の優先度を下げて、出品促進に関する別の仮説の検証を優先するという判断もできます。もし、2つめの購入促進の仮説を先に検証した後、出品に注力すべきということが分かると、出品に関する貴重な検証機会を1度逃すことになり得ます。そのような機会損失を避けるためにも、まず体験全体に係る重要な論点が検証できるように計画を策定することを留意しています。
結果：より精度の高い仮説検証で、より早く Next Action を決められるようになった
上記で述べた取り組みによって、得られた結果としては2つあります
1) 重要論点に早い段階で答えを出し、より早くインパクト最大化を狙える
重要論点を早い段階で検証し、体験の勝ちパターンを見つけられると、その後の検証を勝ちパターンの改善に関するものだけに限定することができます。検証で早く答えを出せると、最も効果が高いものにより早く注力できるため、ビジネスインパクト最大化にも貢献します。
2) A / B テストの分析だけで仮説検証が完結するため、PDCAが高速化する
また、検証を事前に正しく設計しておくと、A / B テストの結果指標を可視化するだけで仮説に答えが出せるようようになり、施策を評価して次回施策に反映するスピードが高速化されました。設計のエラーによって必要となる補填的な分析や、検証のやり直しの工数も減り、以前より少ない施策数で知見を蓄積・反映することができるようになっています。
まとめ：CRM領域で Analyst が価値を出すには
ここまでの話を踏まえて、私が Analyst として価値を出すために心がけたことを、冒頭で書いた結論を再度引用する形で述べさせてください。
1) Analyst は、CRM方針だけでなく、その後の実行計画の策定まで行おう
方針と実行が噛み合わないと、実際の施策評価がままならず、成果に結びつけるための正しい軌道修正が効きません。Analyst が実行計画の策定フェーズまで関与し、方針を正しく実行することを担保する動きをすれば、成果により結びつく貢献ができると考えています。
2) 計画は検証すべき仮説の重要度を踏まえ、最短で重要論点に答えが出せるように作ろう
毎期の施策実行において、全ての仮説を検証できればいいですが、現実はそう上手くいくことは少ないです。事業計画の目標数値達成のため、その時点での最善施策を全展開するべき局面があり、四半期の中で検証に挑戦できる期間は限られているからです。そのため、どの仮説がお客さまの体験に最も影響し、ビジネスインパクトに繋がるか、という点で重要な仮説を提示し、その仮説に最も早く答えが出せるよう計画を策定していくことがAnalyst として大事な貢献ポイントだと考えています。
3) Analyst が意思決定を推進するためには、PDCA全体に関わっていこう
1) , 2) の話からも分かるように、Analyst というのは仕事の1つの側面を切り取った名称でしかないと考えています。本質的には、課題解決のために関係チームと志を一つにして、計画・実行・振り返りの推進に貢献すべき、ということが、私がこの記事を通して伝えたい最後の主張です。
（もちろん私として全く完璧にできている訳ではないので、自戒を込めて）
このような仕事の捉え方に関連して、Analyst がどのようなマインドを持つべきかという期待が、メルカリ Analytics チームのVision Statement に表現されています。私自身、この Vision Statement に共感しますし、とても好きな言葉なので、最後にそちらを紹介して、この章の結びとしたいと思います。
Be the brain that drives the growth of Mercari
メルカリの成長を主導するブレインになる
Marketing 課題解決に貢献したい Analyst を募集しています！
ここまで読んでくださりありがとうございます、いかがでしたでしょうか。
少しでも皆さんにとって有益な示唆があれば幸いです。
メルカリは未だに成長を続けている会社のため、上記で例にあげたCRM施策プログラムだけでなく、大型プロモーションキャンペーン施策、広告による獲得マーケティング施策など、さまざまなマーケティング施策領域で課題がまだ多くあります。メルカリの Analytics チームでは、それらの課題解決に貢献する取り組みを All For One で推進していますが、仲間がまだまだ足りていません。課題解決のために分析をして、実際に戦略・戦術の意思決定に貢献していく仕事に興味がある、この記事を読んでいらっしゃるあなた！
ぜひ、カジュアル面談でお話させてください。ご連絡お待ちしております！
▼採用情報サイト・関連記事はこちらから
この記事が気に入ったらサポートをしてみませんか？