TL;DR
こんにちは、メルカリでCRE (Customer Reliability Engineering) に所属している @umechan です。
今回は、チームメンバーの@shidoと一緒に、以下のような試みを行ったのでその結果を共有します。
- お問合せだけでは把握できない悪い体験の継続率を可視化したところ、Goodmanの法則[1]と同様に、不満を持ちながら苦情を申し立てないお客さまの継続率が悪いことが分かった
- 可視化した継続率をもとに、対策の優先度づけする方法を提案した
背景
ご存知のように、メルカリは個人が簡単にモノの売り買いを楽しめるフリマアプリで、買い手はもちろん売り手も個人となるC2Cサービスになります。おかげで、誰もが簡単にモノの売り買いを楽しむことができ、個人のエンパワーメントを実現する一端を手助けをできていると考えています。
しかし、売り手も個人であることで、一般的なB2Cサービスでは起きないような問題も発生します。例えば、売り手の商品の記述が十分でなく誤解を与えたり、取引のやりとりが不親切で相手に悪い印象を与えたりなどすることもあります。このように、個人間同士で取引を行うことによる新たな問題があり、メルカリはよりお客さまをサポートしていく必要があります。
そのため、メルカリにはCustomer Reliability Engineering (CRE : 顧客信頼性エンジニアリング) というチームがあり、「お客さまが使い続けたくなるような信頼できるプラットフォームを構築する」というミッションのもと日々改善を続けています。その中の具体的な指針として、お客さまの体験を向上し継続的にメルカリを使っていただく仕組みをつくる、というものがあります。
日々、メルカリにはお問合せが届いており、お客さまの体験が報告されています。そのような報告に対し、カスタマーサポートにより問題の解決の手助けをしたり、分析やプロダクト改善をすることで根本的な改善を行ったりしています。
課題
お客さまの悪い体験を把握するために、メルカリは主にお客さまからのお問合せを用いています。しかし、実はこれはお客さまの悪い体験全体のほんの一部にしかすぎません。佐藤知恭氏の調査[1]によると、不満を持った顧客のうち、苦情を申し立てる顧客は4%、残り96%は申し立てをせずその大半は無言で去ってしまうそうです。メルカリでも同様の事象が起きていると考えられ、お問合せだけでは把握できない悪い体験をしたお客さまを把握していく必要があります。
また、お問合せだけでは把握できない悪い体験をしたお客さまを把握することで、それをもとに能動的なカスタマーサポートやプロダクト改善をおこなったり、その施策の評価を行うことができると考えています。上記のような課題を踏まえ、まずはこれに該当するお客さまの可視化をすることが必要だと考えました。
要件
「何か」を可視化をするためには、それを指標として定義し、ダッシュボード等で定常的にモニタリングできるようにしなければなりません。また、「何か」を改善するには、その指標を定義し、それをもとに効果検証を行わなければなりません。
今回の場合も同様で、「お問合せだけでは把握できない悪い体験」を可視化・改善したいなら、それを指標として定義し、定常的にモニタリング・効果検証を行う必要があります。それを実現するためには、今回の場合は以下のようなプロセスが必要になります。
- 「お問合せだけでは把握できない悪い体験をしたお客さま」のセグメントを定義する
- 上記で定義したセグメントごとに、そのお客さま体験を指標化する
上記を行うことで、それぞれの悪い体験ごとにその体験を指標化することができます。
解決方法
「お問合せだけでは把握できない悪い体験をしたお客さま」のセグメントの定義
お問合せだけでは把握できない悪い体験をしたお客さまのセグメントを定義するにはいくつかの方法が挙げられると思います。
- 悪い体験をログデータで定義し、その定義にあったお客さまをセグメントに使う
- 悪い体験をしたお客さまを定義し、そのお客さまと類似の行動ログを持つお客さまをセグメントに使う
今回は前者の「悪い体験をログデータで定義し、その定義にあったお客さまをセグメントに使う」にスコープを絞って可視化を行いました。例えば、以下のような悪い体験の可視化を行いました。
- 取引後に悪い評価を受けたお客さま
- 取引後に評価をされないお客さま
- 取引中にキャンセルした/されたお客さま
- 購入後に配送が遅れたお客さま
上記のような体験の場合、その体験をしたかどうかをログデータを用いて定義できます。そのため、実際にお問合せをしていなくても、悪い体験をしたお客さまを把握することができます。
お客さま体験の指標化
計測できないものは改善できないとはよく言われますが、お客さま体験を計測するためにはいくつかの一般的な指標[2]が存在します。例えば、以下のような指標があります。
- ネット・プロモーター・スコア（NPS）
- 顧客満足度 (CSAT)
- 解約率 (Churn Rate)
- 継続率 (Retention Rate) など
今回使用する指標をとしては「継続率」を選択しました。まず、継続率を定義するためには継続利用を定義する必要があります。ECビジネスにおいて、n日以内にある「行動」をしたら継続、しなかったら離脱と定義することができます。例えば、お客さまが1ヶ月ごとにログインすることが重要であると考えた場合、28日以内にログインしたお客さまを継続ユーザーとみなすことができます。次に、その定義に基づいて、継続率を定義します。一般的に、継続率の定義は、「ある期間の始まりの時点の継続ユーザーのうち、ある期間の終わりの時点の継続ユーザーの割合」になります。なので、28日以内にログインしたお客さまを継続ユーザーとみなした場合、継続率は「ある期間の始まりの時点で28日以内にログインした人のうち、ある期間の終わりの時点で28日以内にログインした人数の割合」と定義できます。期間として月(28日)を用いた場合、
28日間継続率=29〜56日にログインした、かつ1〜28日前にログインした人 / 29〜56日前にログインした人
と計算できます。
メルカリは、フリマアプリということで以下のような行動が例として挙げることができます。
- ログイン
- 購入
- 出品
- 売却
継続率を選択した理由としては、以下の観点が挙げられます。
- 全てのお客さまで得られるデータから算出できる、なぜならサンプリングを用いると全数を把握できないから。
- 計測頻度が短いほうが良い、なぜならより頻繁に数値を比較することができるから。
- インパクトが反映されるまでの遅延が短い、なぜなら改善効果をより早く検証できるから。
特に1は重要で、今回の目的は悪い体験をしているお客さまの全数を把握することです。NPSやCSATはサンプリング計測を行うため、これを満たしません。2に関しても、サーベイを利用する指標だと毎日必要十分なサンプルを集めることが難しいです。3に関しては、n日間継続率だと効果が測定できるまでn日かかってしまいます。ただ、これは他の指標でもそれだけ遅延は発生してしまうのでやむを得ないと判断しました。また、解約率を使用しなかった理由としては、メルカリはサブスクリプション形式のサービスではないため、明確に解約するお客さまよりもアプリを使用しなくなるお客さまの方が多いからです。
結果
上記のように、「お問合せだけでは把握できない悪い体験をしたお客さま」のセグメントを定義し、そのセグメントごとお客さま体験を継続率で指標化した後、その推移をグラフで可視化しました。以下は、試しに取引後に悪い評価を受けたお客さまセグメントに対して可視化を行ったものです。x軸が悪い体験をした日付で、y軸が継続率です。ただ、実際の値を変更したり、軸の値を消したり、スケールを変える等して元の値自体はわからないようにしています。
上記を見ると、悪い体験をしなかったお客さまと比べて、悪い体験をしたお客さまの継続率が低いことがわかります。また、お問合せをしたお客さまの継続率は悪い体験をしなかったお客さまと同等、もしくはそれ以上であることもわかります。この結果自体には、お問い合わせをする人ほどメルカリを使用している等のバイアスが含まれているかもしれませんが、お問合せ対応の効果を示している可能性があり、Goodmanの法則[1]と同様の結果を示しています。
次のグラフは、それぞれの人数の推移を示したグラフになります。これに関しても具体的な値をお見せすることはできないですが、だいたいの数を示すと、悪い体験をしたお客さまは悪い体験をしなかったお客さまの0.1~1%程度、お問い合わせをしたお客さまは悪い体験をしたお客さまの5%程度でした。特に後者の値は佐藤知恭氏の調査結果[1]に近い値だったのは驚きでした。
これらの値の推移を見ることで、それぞれの悪い体験の影響を見守ることができます。
将来の展望
悪い体験の定義に基づいてお客さまの継続率の可視化の試みとその結果を説明しました。しかし、それだけでは現状把握ができただけであり、改善にはなりません。
ここでは、可視化した継続率を用いて、どの悪い体験を改善すればよいかを優先度付けする方法を説明します。
可視化した継続率による対策の優先度づけ
それぞれの悪い体験をしたお客さま \(n_1\)人とその継続率\(r_1\)と、しなかったお客さま \(n_2\)人とその継続率\(r_2\)を実数で把握できたことにより、それをCLTV(Customer Lifetime Value: 顧客生涯価値)[3]という金銭的な数値に置き換えることができるようになります。CLTVは、単純化すると以下の式で書けます。
\(CLTV=\frac{M}{1-r}\)
Mは各期間の利益、\(r\)が継続率です。例えば、\(r\)に28日間ログイン継続率を用いた場合、\(M\)は28日間ログイン継続に該当するお客さまによるその期間の平均利益を近似的に用いることができます。また、この時、CLTVによって計算される値は、28日間ログイン継続に該当するセグメントのCLTVになります。
上記CLTVをその期間に悪い体験をしたお客さまとしなかったお客さまの項に分けて書くと以下のようになります。この時、\(\alpha = \frac{n_1}{n_1 + n_2}\)で該当する全お客さまに対する悪い体験をしたお客さまの割合です。
\(CLTV(r_1,r_2,\alpha)=\alpha \frac{M}{1-r_1} + (1-\alpha)\frac{M}{1-r_2}\)
例えば、悪い体験をしたお客さまの継続率\(r_1\)を\(\Delta r\)改善したときの効果は以下のように求められます。
\(\Delta CLTV(r_1,r_2,\alpha) = CLTV(r_1 + \Delta r,r_2,\alpha) - CLTV(r_1,r_2,\alpha) \\ = \alpha M \frac{\Delta r}{(1-r_1-\Delta r)(1-r_1)}\)
ここで、改善量を割合で出すために、\(\alpha \approx 0\)と仮定して、\(CLTV(r_1,r_2,\alpha) \approx \frac{M}{1-r_2}\)で割ってみると以下のようになります。
\(\frac{\Delta CLTV(r_1,r_2,\alpha)}{CLTV(r_1,r_2,\alpha)} \approx \alpha \frac{\Delta r (1-r_2)}{(1-r_1-\Delta r)(1-r_1)}\)
\(\Delta r = 0.01\)として1%継続率を改善した場合、\(\frac{\Delta CLTV(r_1,r_2,\alpha)}{CLTV(r_1,r_2,\alpha)} \approx 0.01 \alpha \frac{(1-r_2)}{(1-r_1)^2}\)となり、該当する全お客さまに対する悪い体験をしたお客さまの割合\(\alpha\)に比例して効果がでて、\(1 - r_1\)の2乗に反比例して効果が出ることがわかります。つまり、もし1%継続率を改善するなら悪い体験をしたお客さまの割合が多い、かつ継続率が高い体験から改善したほうが良いことがわかります。
また、\(\alpha = 0.01\)とした時、改善率は以下となります。
\(\frac{\Delta CLTV(r_1,r_2,\alpha)}{CLTV(r_1,r_2,\alpha)} \approx 0.01 \frac{\Delta r (1-r_2)}{(1-r_1-\Delta r)(1-r_1)}\)
試しにいくつかのパターンで計算してみると以下のようになります。
Δr=0.1, r1=0.3, r2=0.4の時、該当するセグメントのCLTVが0.14%改善
Δr=0.1, r1=0.5, r2=0.6の時、該当するセグメントのCLTVが0.20%改善
Δr=0.1, r1=0.8, r2=0.9の時、該当するセグメントのCLTVが0.50%改善
また、施策によってそもそも悪い体験をする人を削減したい場合は以下によってその効果を推定できます。
\(CLTV(r_1,r_2,\alpha - \Delta \alpha) - CLTV(r_1,r_2,\alpha)\)
これに対しても、上記で行ったような分析を行うことで施策の優先度を判断できます。
さらなる応用
上記は、取り組むべき悪い体験の優先度付けの方法を説明したものですが、この方法は以下のようなことにも応用できると考えています。
- CLTVを用いて施策の効果をABテストで評価する
- 「お問合せだけでは把握できない悪い体験をしたお客さま」のセグメントの定義に機械学習を用いる
今回説明した方法を用いて、お客さまの悪い体験に優先度付けを行い、いくつかの対策を検討して実施しています。次の機会では、それらの対策の結果と今回説明した優先度付けの有効性ついて、報告したいと考えています。
Reference
- Goodmanの法則ーグッドマンの法則ー
- 6 Most Popular Customer Experience Metrics and KPIs Explained Simply
- Data-Driven Marketing: The 15 Metrics Everyone in Marketing Should Know
