2025.02.21

CDP構築の主な流れ・手順|自社でCDPを構築する場合の懸念点と解消策

CDP構築の主な流れ・手順|自社でCDPを構築する場合の懸念点と解消策

顧客データ活用に向けた、顧客データの収集・統合・加工・連携を行う基盤としてCDPがあります。CDPの構築はベンダーが提供するCDP製品を導入するパターンと、自社で各種クラウドを利用して構築するパターンがあります。

本記事では、自社でCDPを構築するメリットや構築プロジェクトの主な流れ・進め方、自社でCDPを構築する場合の懸念点とその解消策について紹介します。

CDP検討マニュアル|CDPとは?DMP・CRM・DWH・MAとの違い、導入のタイミング

CDPとは

CDPとは「カスタマー データ プラットフォーム:Customer Data Platform」の略称で、企業が持つ顧客データを「実在する個人」に紐付けて統合・管理し、顧客ひとり一人の正確な理解を可能にするプラットフォームです。

integralcore integration

関連:CDPとは?機能や部門・業界別の活用例、今後の動向などをまとめて解説

CDPは主に下記の4つの機能で構成されます。

  • 顧客データの収集
  • 顧客データの統合
  • 顧客データの加工
  • 顧客データの連携

cdp flow

CDPは、オンライン・オフラインを問わず、顧客のあらゆるデータを収集し、名寄せ処理を行うことで、一人の人物として統合的に管理する役割を担います。CDPで統合したデータをもとに顧客理解に向けた分析を行い、顧客視点でのコミュニケーションを実現するためには、BIやMAなどの外部ツールとの連携機能が必要です。

CDPを自社で構築するメリット

CDPの利用を検討する際、CDP製品を導入するか、各種クラウドを利用して自社で構築するかの2つの選択肢があります。CDPを自社で構築するメリットについて、CDP製品を導入するケースと比較しながら紹介します。

柔軟な設計が可能

CDPを自社で構築するメリットの1つに、自社のビジネス要件やシステム要件に適した設計がしやすい点が挙げられます。

CDP以外の製品も含め、どのようなSaaS製品でも、その製品で提供される標準のデータモデルに合わせた設計が求められます。そのため、業界特有のデータや企業独自のデータを管理する際に、適切なデータ構造を持てない場合があります。特に、標準モデルが「顧客単位」の管理を前提にしている場合、顧客以外の情報(所有品・契約・履歴データなど)を適切に管理するのが難しくなります。

CDP製品では、顧客単位のデータに関しては、管理画面上で簡単に操作できる各種機能を提供しています。しかし、所有品データや複数のエンティティ(顧客以外のデータ構造)を扱う場合、それらの機能をそのまま適用できないことがあります。

例えば、カメラや車などの耐久消費財メーカーでは、下記のようなデータを統合・管理する必要があります。

  • 顧客単位のデータ(一般的な顧客情報 + webトラッキング・サービス利用履歴・購入履歴 など)
  • 所有品のデータ(製造番号をもとにした商品情報 + 製品の利用履歴・修理履歴 など)

これらのデータをCDP製品で管理する場合、所有品のデータを顧客データに紐付けて扱うことになります。製品の利用履歴や修理履歴を顧客の行動データと同じ形で管理する要件であれば、CDP製品の標準機能で対応可能です。しかし、次のような要件がある場合、CDP製品では対応が難しくなることがあります。

  • 所有者が変更された際にも、製品の履歴情報を適切に引き継ぎたい
  • 顧客ごとではなく、製品ごとにデータを管理し、複数商品の関係をわかりやすく持ちたい

CDP製品は顧客単位のデータ統合を主目的としているため、所有品や製品単位のデータ管理を柔軟に行うには、自社構築の方が適している場合があります。特に、製品ごとの履歴管理や顧客との関係性を動的に変更できる仕組みを持ち、かつそれを管理画面上で柔軟に行いたい場合、自社でカスタマイズ可能なデータ基盤を構築して管理画面も作り込むことでより最適なデータ管理が可能となります。

運用費用の軽減

設計次第で、運用費用を抑えられる点も自社でCDPを構築するメリットです。

CDP製品の場合、価格はインフラ費用だけでなく各種提供機能の価値を含めて設定されています。しかし、自社の要件に合わない機能が多いほど、費用対効果は低くなります。

自社でCDPを構築する場合、下記のような方法でコストを最適化できます。

  • 必要な機能のみを実装し、不要な機能の開発・運用を省略
  • 最適なクラウド環境・リソースを選択し、データ処理の負荷に応じてスケール調整
  • バッチ処理を活用し、リアルタイム処理が不要な部分のリソース消費を削減

例えば、マーケティング用途で毎日一回バッチ処理を実行するだけでよい企業の場合、リアルタイム処理基盤を維持する必要がなく、大幅なコスト削減が可能です。

もちろん、CDPをゼロから構築するには初期開発費用がかかり、運用・保守を担当する人員も必要です。しかし、運用段階に入った後は、システムのランニングコスト(サーバー・ストレージ・ネットワーク費用など)を最小限に抑える設計が可能であり、長期的な視点ではコストを抑えられる可能性があります。

セキュリティの強化

自社でCDPを構築することで、自社のセキュリティポリシーに完全に適合した環境を構築できます。

一般的なCDP製品では、データの保存場所や管理方法がベンダーによって決められているため、自社の厳格なセキュリティ基準と完全には一致しないことがあります。

例えば、金融業界や医療業界では、各業界のガイドラインに基づいたシステム構築が求められます。これらの業界では、CDP製品やクラウド型ソリューションが要件に適合しない可能性がありますが、自社構築であれば企業のガイドラインに完全に適合したCDPを構築することが可能です。

CDP構築の主な流れ・手順

CDPの構築は、一般的なシステム開発の流れと同様に、以下のステップで進めていきます。

  1. 要求・要件定義
  2. 設計・開発
  3. テスト・リリース
  4. 運用

CDP構築において重要なポイントや、ビジネスサイドが大枠として理解しておくべきことを中心に説明します。

1.要求・要件定義

1.1 要求定義

要求定義は、CDPを利用するビジネスサイドが中心として進めていくステップで、下記のような点を整理します。

具体的な内容
CDPを導入する目的の整理 「ECと店舗の購買データを統合し、オムニチャネルの顧客分析を可能にする」といった目的を決定する
活用シナリオの整理 「web行動データを活かして、メール配信のセグメントを細かくする」といった、どのようなデータをどのようなシーンで利用するか整理する
KPIの設計 CDP導入の成果を測るために、目的の達成度を測るためのKPIや、活用シナリオごとの評価をするための中間KPIなどを設定する
既存システムとの関係の整理 活用シナリオにおいて必要となるデータが存在するシステムとの連携、また分析や施策を実施するBIツールやCRMツールへの連携方法について整理する

1.2 要件定義

要件定義は、要求定義で整理した内容をもとにエンジニアとすり合わせを行うステップで、次のような点を整理します。

具体的な内容
統合すべきデータの定義 要求定義で整理したシステムにおいて、どこに・どのような形でデータが存在しているか、また活用シナリオからリアルタイムで必要なデータとバッチ処理で十分なデータを分類し、適切な連携方式を決める
ID統合のルールの整理 複数のツール・システムから収集したデータをどのように統合するかを整理したうえで定義する
プライバシー・ガバナンスの定義 個人情報を扱うため、アクセス権限・データ保持ルール・セキュリティ対策の定義付けを行う

プライバシー・ガバナンスの定義付けを行う際は、マーケティングや分析チームがどの範囲のデータにアクセスできるのかを明確にし、不要な情報の取り扱いを制限することが重要です。

2.設計・開発

設計・開発は、主にエンジニアが中心として進めるステップですが、ビジネスサイドでも大枠のデータの流れを理解しておくことで、設計に対するフィードバックや運用時の依頼などを行いやすくなります。

CDPの設計・開発では、要求定義・要件定義で整理した内容をもとに、データをどのように処理し、活用するのかを具体化します。ここでは、データの流れに沿って、設計・開発のポイントを整理します。

2.1 データの収集

CDPの基盤となるデータを各システムから取得し、統合する仕組みを作ります。ビジネスサイドでは、どのデータが必要か優先度を決めたり、どのくらいの頻度で更新が必要かを判断します。

店舗とECを展開している事業を例にすると、収集するデータとしては下記のようなものがあります。

  • 会員情報(CRM・EC・店舗POS)
  • 購買履歴(EC・店舗POS)
  • web行動データ(サイト閲覧履歴、広告クリック履歴)
  • 問合せ履歴(カスタマーサポート、FAQ検索履歴)

データの収集方法としては、下記のような方法があります。

  • リアルタイム連携(webサイトの閲覧データ、広告クリック)
  • バッチ処理(POSデータ、CRMデータの1日1回更新)

要件定義ですべて明らかになっていればほとんど論点がありませんが、設計にあたり具体的に調査を進めた結果として実現可否が明らかになると、データ収集方法の再検討が必要となる場合があります。

2.2 データの統合(DWH構築)

収集したデータを整理し、統合するデータウェアハウス(DWH)を構築します。データの統合において、どのデータを統合し、どの粒度で管理するかの整理や、データ統合のルールが活用に適しているかの確認などをビジネスサイドで行う必要があります。

データの統合では、各システムからのデータを一元管理し、データの形式を統一して分析や施策で利用しやすい形に整えることを目的として、DWHを構築します。

DWH構築の際に、データの標準化を行います。具体的には、データクレンジング(表記ゆれ・重複の削除など)やID統合を実施します。ID統合は要件定義で整理したルールをもとに行いますが、具体的なデータを見ると要件定義で整理できていない論点が出てくる可能性があり、ビジネスサイドとしてはそれらの判断が必要です。

2.3 分析・施策用のデータ作成(データマート構築)

BIツールやMAツール、CRMツールに連携するためのデータとして、必要に応じてデータマートを構築します。ビジネスサイドでは、必要なセグメントや分析データの要件を決めたり、使いやすい形になっているかを判断します。

BIツールへの連携では、分析用のダッシュボード構築に必要な形のデータマートを構築します。DWHのデータを直接参照して分析が行える場合もありますが、特定のレポートに合わせた集計を行ったデータマートが必要なケース、表示速度を担保するために集計を行ったデータマートが必要なケースがあります。

MAツールやCRMツールへの連携では、ツールのデータの持ち方に合わせてデータマートを構築する必要があり、データの形としては主に3つの種類があります。

マスター(横持ち、属性データ など) 一人の顧客に対して1レコードで持つ形
トランザクション(縦持ち、イベントデータ、行動データ など) 顧客の購買などに対して1レコードで持つ形。一人の顧客に対して複数のレコードがある
オーディエンス(ユーザーリスト など) メールアドレスや各ツールのIDをリスト化した形

連携するツールによって、対応しているデータの持ち方や連携できる項目(カラム)数の上限などがあるため、調査を進めていく中でさまざまな論点が出てくるケースがあります。

2.4 データの連携(コネクタ作成)

CDPの製品ではコネクタとも呼ばれる、各種連携先のツール・システムとのデータの連携のための仕組みを作ります。ビジネスサイドでは、活用方法に合わせた優先度の判断や、項目単位で必要なデータが連携できる状態にあるかの確認を行います。

各ツールによって提供しているAPIや連携方式が異なるため、それらを確認したうえでコネクタを作成する必要があります。

BIツールでは、DWHのテーブルやデータマートのテーブルを直接参照するケースが多いです。しかし、データを転送できるツールもあるため、それぞれのメリット・デメリットを見て判断します。

MAツールやCRMツールでは、提供されているAPIによりますが、該当のツールのAPIを実行して、データを同期したり定期連携するといったコネクタの開発が必要です。

3.テスト・リリース

誤ったデータが作成されていて、そのデータをもとに施策を実行した場合、個人情報の漏えいなどの大きなリスクが生じることがあるため、丁寧なテストと段階的なリリースを行います。

3.1 テスト

テストでは、データが正しく収集・統合・連携できているかを重点的に確認します。

まずは、データの収集・統合の観点で、DWHに統合されている顧客データに対して、正しいデータが紐づいているかを確認する必要があります。また、顧客が重複していないかという観点での確認も必要です。

連携の観点では、主に分析や施策が問題なく行える形でデータ連携が行われているかを確認します。

3.2 リリース

リリースでは、多段階のリリースが推奨されます。

初期リリースでは、一部のユーザーがCDPのデータを利用して分析を行うことから始め、段階的にデータの利用範囲やユーザー数を拡大することでリスクを低減できます。

4.運用

収集するデータや分析や施策で利用するデータの変化に対応するためのメンテナンス、社内でのデータ活用の促進を行います。

4.1 データのメンテナンス

新たなデータの追加や、各種処理の変更、データマートの改修や追加など、データ活用を推進する中で、さまざまな変更が必要となります。

構築のみ外部のベンダーに依頼して、運用のリソースを依頼していない場合、運用のリソース不足がデータ活用推進の障害となる可能性が非常に大きいです。

運用時において、社内でデータのメンテナンスが行えるエンジニアリソースを確保するか、構築をしたベンダーなど外部のリソースを確保しておく必要があります。

4.2 データ活用の推進

構築したCDPを利用し、データを使った分析や施策の実施、改善を行います。

施策に関しては、マーケティングチームにて施策の実施と振り返り、改善が行える体制を整える必要があります。

分析に関しては、分析結果をもとにPDCAを回すことが重要です。

顧客データを一元管理するCDPを構築し分析を行うことで、顧客理解が進み新たなインサイトを掴めます。しかし、分析した結果を施策に反映しなければ、初期段階で設定したCDP構築のビジネス要件を達成できません。そのような事態が続いていくうちにCDPの利用価値が下がり、利用頻度も減っていき、結果的に利用されなくなることも多いです。

分析結果をもとに、どのような施策を行うことでビジネス要件を達成できるのかを検討し、実行していきましょう。

また、分析結果を単にBIのダッシュボードやレポートを社内展開するのみでは、データを見るのみになってしまう可能性があります。そのため、必要に応じてデータ活用推進のための社内のデータ分析スキル向上を目的とした勉強会の実施などを実施します。

関連:CDP導入が失敗する6つの原因。成功企業に共通するポイントとは

自社でCDPを構築する場合の解消点とその解消策

自社でCDPを構築することにはメリットがありますが、プロジェクトを進める前に理解しておいてほしい懸念点もあります。懸念点の解消策の1つとして、ベンダーが提供するCDP製品の導入があり、2つの選択肢を比較したうえで自社にとっての最適な方法を選択することが重要です。

CDP構築の最大の懸念点は、要件定義から設計・開発において専門的な知識を持ったエンジニアの膨大なリソースが必要になることです。

例えば、CDP構築過程で各データソースからデータを取り込む際、最適な連携方法をそれぞれ1から設計・開発する必要があります。CDP製品の多くは、データを取り込む機能・コネクターが標準で装備されています。また、スコアリングやセグメント作成といった分析・施策の実行に必要な機能を備えているため、DWHやデータマートの構築における設計・開発のリソースを大幅に削減できます。

加えて、自社でCDPを構築する場合は運用保守の負担も大きく、トラブル対応やセキュリティ対策で適宜追加で担当者のリソースを割くことになります。外部のパートナーに依頼する場合でも、開発・運用保守の費用が別途発生します。

ベンダーが提供するCDP製品を導入する場合、専門的知識を持ったベンダーに開発や運用保守を依頼でき、自社のエンジニアのリソースの削減に繋がります。導入後の活用シーンでも、データ活用やマーケティングの専門知識を持ったベンダー担当者に相談しながら、顧客データの活用方法や効果的な施策の実行などが可能です。

  • 独自の要件が多く既存のCDPではカバーしきれない
  • 社内、パートナーに技術力のあるエンジニアチームがいて長期のコスト効率を重視する

このような特別な要件がない限り、製品化されたCDPを利用することが企業にとってのベストソリューションとなりえます。

CDP製品の導入を検討する際に知っておきたいポイントについて、詳しくは下記の無料資料をご覧ください。各業界で収集できるデータの例やほかのツールとの違いなどについても紹介しています。

無料資料:CDP検討マニュアル|CDPとは?DMP・CRM・DWH・MAとの違い、導入のタイミング

CDP検討マニュアル|CDPとは?DMP・CRM・DWH・MAとの違い、導入のタイミング

また、ベンダーが提供するCDP製品を比較する際確認すべき点について、詳しくは下記の記事をご覧ください。

関連:CDPの比較|人気のCDPタイプ・比較時に確認するべき12のこと

Related Post

関連記事