【事例紹介】独自IDを活用した新規マーケティングプラットフォーム検討支援

毎月数本というペースで新たなサービスを世に送り出している今回のクライアントでは、そのリリース頻度ゆえ、中には十分な磨きこみが行われないままローンチに至るサービスもあり、品質面のばらつきが課題となっていた。

そこで、リリース手順を統一し、サービス品質の高度化・均質化を行うべく、テストマーケティングを実施するための新たなWebプラットフォームの立ち上げ検討を行った。

社内に深く関わる新規プラットフォームということもあり、当初クライアント内では、この取り組みの有効性に対して懐疑的な姿勢を示すサービス管轄部署も存在したが、取り組みとプラットフォームの位置づけを整理することで、円滑な理解促進とプロジェクト推進を行うことができた。そのプロセスをご紹介したい。

社内向けプラットフォームにもマーケットイン視点を

サービスリリースまでのプロセス不統一により発生していた品質面のばらつきを解決するために立ち上がったのが、Web上での効率的なテストマーケティングを可能にするプラットフォームの検討を行う当プロジェクトである。
実際のサービス利用を伴わないアドホックなアンケートによる広範なデータ収集だけでなく、実際にサービスをトライアル利用いただくことで高深度・高精度なデータ収集も可能とすることが、このプラットフォーム構想の大きな特徴だ。
そのため、以下ではこのプラットフォームを「サービストライアルプラットフォーム」と呼ぶこととする。
サービストライアルプラットフォームの構築にあたっては、クライアントが有している2つの既存基盤に白羽の矢が立った。

• ユーザーに対して当クライアントが発行している「独自ID」
• 属性や行動等の様々なユーザーデータを蓄積する「DMP」

サービスのトライアル利用を伴う高精度なテストマーケティングを行おうとする場合、当然サービスを使うユーザー、すなわちモニターが必要となる。そのモニターを上述の「独自ID」取得者の中から募れば、テスト利用の過程で得られた各種データは「独自ID」に紐づいた形で容易に取得できる。また、「独自ID」に対して「DMP」のデータを突合すれば、さらにデータが高解像度なものとなり、属性ごとのきめ細やかな分析が行えるようになり、より効率的で的確なサービス改善が可能となる、という算段である。

かくして検討が始まったサービストライアルプラットフォームだが、ただ単にテストマーケティングが行えるプラットフォームとしてプロダクトアウト的な構築をしたとしても、そのプラットフォーム自体を各サービス管轄部署に利用いただけないのでは意味がない。

そこでまず、実際の各サービス管轄部署において、リリース手順が統一されていないことにより現状どのような課題があるのかを明らかにするため、ヒアリングを行った。
そこで浮かび上がった主な課題は以下のようなものだった。

• リリース手順の不統一のため、サービスの品質にばらつきがある
• 足しげく実施する従来型のフィールド（リアル）でのテストマーケティングでは工数もかさみコスト高となるため、十分な改善が行えない
• リリース前に初期顧客を思うように獲得できない
• リリース後の顧客獲得に行き詰まる

このように、サービス品質面のみならず、顧客獲得といったマーケティング面でも課題感を抱えていたことが判明した。
よって、サービストライアルプラットフォームに求められることは、

• 「サービス企画」「モニターの選定・募集」「市場・ニーズ調査」「トライアル・PoC」「サービス改善・リリース」といったテストマーケティングに必要な一連プロセスをWeb上で実施可能なこと
• サービス改善や顧客獲得に資する各種の施策・機能を備えていること

であることがわかった。

サービス管轄部署との温度差に対するケア

一方、先述のヒアリングの中で、サービストライアルプラットフォームに対して後ろ向きな意見も出た。
というのも、これまで既にフィールド（リアル）でテストマーケティングを行ってきたサービス管轄部署としては、フィールド調査で得られる肉声データに比べ、オンラインで取得するサービストライアルプラットフォームのデータは本当に信頼に足るものか？といった、データの精度に関する懸念の声が上がったのである。また、効率的な調査がしたいのであれば、市場調査会社によるクイック調査で足りるのではないか？というご意見もあった。
こうした懸念に対しては、サービストライアルプラットフォームの性質を整理し、以下の2点を強調することで理解を得た。

1. データはかえって高精度
モニターとなりうる母集団は「独自ID」の取得者である。つまり、リテラシーの高さやクライアントシンパであることがある程度担保された、独特の偏りを持つ母集団である。サービスはそもそもクライアントの顧客を主なターゲットとしているため、リテラシーの高さやシンパといった偏りは、クライアントにおけるサービスのテストマーケティングにはむしろ好都合な偏りであり、データ精度はかえって期待できる。また、実際のサービステスト利用を伴わない市場調査会社によるクイック調査と比較しても、サービストライアルプラットフォームは実際のサービステスト利用を前提とするため、より高深度なフィードバックを得ることができる。

2. 刹那的ではない調査やマーケティングが可能
市場調査会社によるアドホック調査では、単発で刹那的な結果しか得られないが、サービストライアルプラットフォームでは、モニターの行動が「独自ID」に紐づいているため、その後の継続調査やマーケティングへの活用が可能となる。

後日談ではあるが、続くPoCフェーズにおいて多数のサービス管轄部署よりPoCのお申し出をいただくことができたのは、まさにこうした営みによって理解を得られた結果である。

本取り組みにおけるペルソナは「人物像」ではなく…？

続いて、カスタマージャーニーを描き施策と機能の洗い出しを行うのだが、その際のペルソナは「人物像」ではなく「サービス像」すなわち「サービス種」とした。

当然、サービスを磨くのはサービスの管轄部署であるし、サービスをテスト利用いただくのはモニターであるため、ジャーニー内で描かれる各フローは人物主語である。だが、ペルソナについてはあくまでサービス種とし、サービス種切り口でジャーニーをMECEに描いた。そうすることで、SaaSといったサービス種はもとより、一見Webでテストマーケティングを行いづらいように見える物品・端末を伴うサービス種についても、サービストライアルプラットフォームの有効な活用シーンやそのために必要な施策・機能の洗い出しを行うことができた。

そして検討フェーズの終盤はロードマップ定義である。
施策と機能の洗い出し自体は「外部チャネルデータとの連携」「ナレッジの蓄積」といった、単なるテストマーケティングにとどまらないデータ利活用シーンまで想定して行ったが、初期スコープでは、やはりテストマーケティングに不可欠な「サービスのテスト利用」に直接かかわるフロントの施策から実装すべきと考えた。具体的には、主に「モニターを募る」「サービスをテスト利用いただく」「その過程でデータを取得する」「取得したデータを分析しサービス改善の示唆を得る」といった部分に関わる施策である。

同様にバックエンド側のデータ連携面についてもロードマップにて初期スコープの定義を行った。
フロント施策の実現には、それを支える「独自ID」の認証基盤や分析ツール等、複数のシステム間でデータの受け渡しが必要となる。そのため弊社からは、バックエンドのデータ連携についても、初期スコープにあるフロント施策に関わる部分については、同様に初期スコープに含めた形でロードマップの提案を行った。

このバックエンド側の提案については、王道的なロードマップとの評価をいただきつつも、クライアントからは別のご意見が出たのだ。なんでも、初期スコープではシステム同士のデータ連携は行わず疎結合のままにしておき、フロント施策の実現は手動のデータ入出力による運用で行おうというのである。その心は以下の通りであった。

• 「どのようなデータをどう分析することが、何の改善や意思決定に役立つのか」という、データ活用の「型」が決まっていなのであれば、データを連携する意味がない
• （工数はかかるものの）データ活用自体はシステム同士の連携をせずとも手動の入出力で可能

どちらも手戻りを抑える上で重要な観点である。そこで、バックエンド面の初期スコープについては、

• 手動の運用でデータをサイエンスしながら「型」の確立を行うための期間
• 確立したその「型」に必要なデータ連携範囲はどこかを見極めるための期間

という位置づけで、ロードマップの再定義を行った。

以上が今回の取り組みにおける検討フェーズである。

今回のような新規プラットフォーム立ち上げ等の局面においても、ファーストデジタルのPMは大きな推進力となる。とりわけ今回のプロジェクトでは、プロジェクトメンバー・各サービス管轄部署・ユーザーといった数多くのステークホルダーが存在し、また関連するシステムや基盤も多い中で、それらを的確な観点に立ってまとめ上げるロジックに対し、高い評価をいただいた。