3/17 読んだ記事と感想

マーケットプレイスの作り方（5）：サプライとデマンド、どちらが伸び悩んでいるかをどう判断するべきか？

マーケットプレイスの作り方（5）：サプライとデマンド、どちらが伸び悩んでいるかをどう判断するべきか？ | TechCrunch Japan

マーケットプレイス型の事業を行っているため、グロースのさせ方の記事を最近は読んでいる。全8回ある特集の5回はサプライとデマンドの優先順位の変化のポイント。記事では40%の事業が常にサプライ側が足りていない、40%が事例や地域によってサプライとデマンドのどちらが足りていないかは異なるといった回答だったようだ。マーケ戦略とは違った軸の話なので、ここを深掘るのは趣旨と異なるが、自分が携わる事業ではサプライが常に足りていない。マッチングしたいとしてもサプライ側の希望を満たせるデマンドがないのである。Open Tableで「市場の何店舗と何パーセントのレストランを取れたのかをグラフ化」とあるが、まさしくすべきことである。マッチング数が特定の域になるまでとにかく同じ市場を育てることを重要だと解釈した。サプライ側のニーズを満たすにはユーザーが検索した時に満足の行くレコメンドが何件くるのを期待しているのかを見極めることが重要そう。

マーケットプレイスの作り方(6)：スケール時に効果的だった8つのグロース戦略

マーケットプレイスの作り方(6)：スケール時に効果的だった8つのグロース戦略 | TechCrunch Japan

上位3つの広告・SEO・CVR改善は既にやっており地域拡大は時期を見て検討することができている。サプライ側とデマンド側の双方で弱いのが口コミ戦略である。こちらは社内にノウハウがない？状態で有効な施策として上がってこない。重要な戦略にはなりうる気がするので今読んでいる本とセットで別コミュニティのマーケターに話を聞いてみたい。

マーケットプレイスの作り方（7）：クオリティー担保戦略

マーケットプレイスの作り方（7）：クオリティー担保戦略 | TechCrunch Japan

スケールした時にサービスのクオリティをどう担保していくかとう記事。有効だなと思ったのはサービスのミニマムスタンダードを定義すること。例えばサービス提供を受ける人のマッチングプラットフォームの場合、デマンド側はキャンセル規定の設定、サプライ側は初回対応のプロセスタイムの規定を設定するなどしてクオリティを保てるようにするなど。また、オンボーディングも非常に重要な観点。もう少しサプライ側へのオンボーディングを厚くしたほうがいいのではと思うことは多々ある。今行なっているサービスはグロースに重きを起きすぎていて、実際に使われていないサービスがあったり成約に障害が生まれる構造になっていたりと改善の余地ありなので、優先順位を決めてしっかりと取り組んでいきたい。

マーケットプレイスの作り方（8）：もう一度やり直すとしたらどうする？

マーケットプレイスの作り方（8）：もう一度やり直すとしたらどうする？ | TechCrunch Japan

この記事に関して言うと、背景が記載されておらずなぜ「もう一度やり直したいか」が分からなかったためあまり有効ではなかった。1つ、Task Rabbitのスケールする前にPMFを達成することはとても重要。特にユーザーがサービスに失望してしまった場合、2回目も同じサービスを使おうとはなかなかならない。機能は最小限でもいいが、正しくユーザーが使いたいと思っているサービスにできているかは吟味する必要がある。読んでいて、自分たちが手詰まりになった時に取りこぼしている観点はないかのチェックリストとして使うことは有用そうだった。

マッチングアプリ"with"から学ぶビジネスモデル・カテゴリを横断したユーザー体験設計・グロース施策まとめ

印象に残ったのは被いいね数の廃止について。いいね数を消すことで特定のユーザーにCTRが偏るリスクを低減できる。マッチングアプリに置いては評価観点が多様なのはその通りで、いいね数を評価観点に用いるかどうかはアプリの思想を反映すると言える
ただ、実際に何をリスティングロジックと置くかも非常に重要で最終的なマッチングの質を意識するのであれば、プロフ欄の記入度をリスティングロジックに組み入れるのはある種妥当な判断だと言える。
〇〇促進機能も非常に良い。

（補足）
昨日の記事で抜け漏れていた学びが1つ。デマンド側の方がサプライ側よりも平均施策数が多い。デマンド側により多くのチャネルを投資している。