カスタマーコンサルティングチームの坂本 登です。
Treasure Data CDPは、あらゆるチャネルより多種多様なデータを収集、統合し、それらを分析や活用のために出力することに優れたツールです。前回のブログでは統合した顧客データの可視化の具体的な事例(① 営業支援における活用例 | 任意の顧客に特定した指標での可視化、② 広告最適化のための活用(オンオフを連携した顧客データでの可視化))をご紹介させていただきました。今回はそのような統合データを用いたプロジェクトマネジメントのポイントについて解説できればと思います。
- ダッシュボードの構築プロセス
- 可視化要件の種類
- データソースの 連携頻度 / タイミング
ダッシュボードの構築プロセス
プロジェクトマネジメントにおいては、各タスクの内容や想定されるスケジュールを把握しておくことが非常に重要であります。こういったBIツールを使用した可視化ダッシュボード構築においては、以下の図のようなタスクが設定されます。(弊社池田の記事を参考)
各タスクは、サーバー構築やデータ連携周りのエンジニアリング要件に近いタスクと、ダッシュボードの要件やデザインの設計など、ビジネス要件に近いタスクが並行して進むことも多いです。特に、新しくBIツール自体を構築する、また新しいデータソースを使用する場合などは、そういったケースが多々あります。
そのため、プロジェクトを運営する際はエンジニアリング要件及びビジネス要件の部分を広く理解した上で、進める必要があります。例えば、ダッシュボード要件で取得するべき指標や、軸を決める際には、エンジニアリング要件側でどういったデータが入ってくるのか、足りないデータは何か、どのくらいの頻度でいつのデータから入ってくるのかを把握した上で、設定をする必要があります。
また、ダッシュボードのデザインの際には、一旦エクセルやスライドで作りイメージを検討するなどはありますが、見た目 / データ自体が具体的なほうが実際にダッシュボードを実装した際に、イメージがずれることがなくなるため、実データを用いて、可能であれば使用予定のBIツールにてモックを設計することをお勧めします。そのため、デザイン設計の段階では、実データが連携されている状況であることがベターです。
更に、データマート設計/実装は、ダッシュボード設計を元に構築されるためダッシュボードデザイン設計時点で綿密に設計することをお勧めします。ここで設計が曖昧にすると、ダッシュボード実装後に、データマート自体を見直す必要が出てくるなど、手戻りが発生する可能性があります。
可視化ダッシュボード構築要件の種類
CDP上のデータを用いて、重要指標を可視化ツールを用いて企画・実装するにあたっては、いくつかの種類があり、それらを3つに区分にしてご説明をします。
まず、1つ目は、移管と定義したものです。こちらはすでにある任意のデータを用いて可視化しているが、別の可視化ツールにて移管して表示するようなものです。基本的にはすでに活用目的や要件が決まっていることが多いため、構築が比較的容易であり、構築にあたってのスケジュールも短く済むことが多いです。移管にあたってはCDPを通じて実施することによって、後の新規データソースとの統合や、データの活用が容易になります。
2つ目は、統合と定義したものです。CDPの性質上、一つのデータソースではなく、複数のデータソースからデータを収集し、統合をすることが多いですが、CDP導入以前に、データソース毎に、すでに指標を可視化しているケースも多いです。例えば、GA単体でウェブ上のデータを統計的に可視化して活用していた。また、広告配信データを可視化して、広告アロケーションしてきた。そして別途、オフライン上での営業 / 成約データを可視化していたケースなどです。
こういった場合において、それぞれで可視化した指標を、CDPでデータを統合することで統合した指標としてBIツールに可視化する場合を移管と定義します。この場合、活用目的や設計の流用は可能ですが、データを統合するため、エンジニアリング要件のデータ周りの検証やデータマート構築等で工数がかかる可能性が高いです。
最後に、3つ目は、新規と定義したものです。こちらは元々、指標の定義及びそれらを用いた可視化をしていない場合にゼロベースでダッシュボードを構築するケースです。例えば、これの場合、前項であげたダッシュボードの構築プロセスを全て実施する場合が多く、特にダッシュボードの要件や見た目も、決まっていない状態がからプロジェクトをスタートをするため、最も難易度が高く、時間もかかります。
データソースの 連携頻度 / タイミング
CDPを活用したダッシュボードを構築する場合、CDPの性質上、様々なデータソースからのデータを統合し、ダッシュボード用に作成したデータマートを用いることが多いです。そういった場合、定常的に運用する際には、どの出力データが、どのタイミングで、どれくらいの頻度で連携されていくのかを理解しながら、運用フローを設定する必要があります。
上記の図では、データソースから一連のデータが入ってくるタイミングを記載しておりますが、このようにダッシュボードを運用する際はこういったフローが全体として、誰しもがわかる図を用意しておくことをお勧めします。そうすることで、プロジェクトメンバー全体がどのタイミングでどのデータがダッシュボードに反映されているかを理解できますし、認識の齟齬がなくなります。
例えば、データの出力に関する情報を理解していないと、ダッシュボード上に表示されているデータがいつからいつまでのものなのかが分からず、指標を見ることによって正しい判断ができないなどのリスクにもつながります。
まとめ
今回あげたポイントについてですが、以下を留意しながら進めていただくと、より良い統合データを用いた可視化ダッシュボードが構築できるかと思います。
- ダッシュボードの構築プロセス
- 可視化要件の種類
- データソースの 連携頻度 / タイミング
構築プロセスは、エンジニアリング/ビジネス要件が必要なプロセスが並行して発生する。各プロセスの関連性及び重要な点を理解した上で、プロジェクトを推進する。
大きく分けて3つの要件がある。自身のプロジェクトがどれに当てはまるかを理解し、難易度やスケジュール、構築プロセス上どこがポイントになるかを理解する。
今後の運用を見越して、各データソースの収集タイミング/頻度を理解した上で、データマート及びダッシュボードへの反映タイミングを決定し、運営をする。また、その情報はプロジェクトメンバーが理解できるように全体図を共有しておく。
ぜひご参照ください。