データウェアハウスをCDPとして使うべき？

クラウドベースの登場 データウェアハウス (DWH）は、データ駆動型のユースケースに、よりシンプルな展開、より大きなスケール、より優れたパフォーマンスをもたらしています。DWHは、マーテックスタックを含むエンタープライズ技術スタックに広く普及しています。

この場合、必然的に、既存のDWHを採用すべきかどうかが問われることになります。 カスタマーデータプラットフォーム (CDP)ですか？結局のところ、スタック内の既存のコンポーネントを再利用すれば、リソースを節約し、新たなリスクを回避することができるのです。

しかし、話はそれほど単純ではなく、複数のデザインパターンの可能性があります。結局のところ、DWHをCDPとして使用することには賛否両論があるのです。 もっと掘り下げてみましょう。

CDPとしてのDWHは、あなたには向いていないかもしれません。

DWHをCDPとして使用するには、いくつかの固有の問題があります。1つ目は、すべての組織がDWHを導入しているわけではないということです。企業のDWHチームには、顧客中心のユースケースをサポートする時間やリソースがないこともあります。また、CDPを準データウェアハウスとして効果的に導入している企業もあります（すべてのCDPがそうであるわけではありませんが、要点はご理解いただけると思います）。

例えば、顧客データのほとんど、あるいはすべてをDWHに保存しているとします。しかし、多くの企業にとって問題なのは、そのデータがマーケターにとって使いやすい方法でアクセスできないことです。通常、企業のDWHは分析ユースケースをサポートするために構築されており、活性化ユースケースをサポートするものではありません。これは、データのラベル付け、管理、関連付け、内部統制の方法に影響します。

DWHは基本的にストレージとコンピューティングのためのものであり、データはデータベース・テーブルにカラム名を属性として格納されることを意味します。そして、そのデータにアクセスするために、複雑なSQL文を記述します。マーケティング担当者がテーブルとカラム名を覚えて、アクティベーションのためのセグメントを作成するのは非現実的です。言い換えれば、DWHは、ほとんどのCDPのようにマーケターのセルフサービスをサポートしないのが普通です。

これはまた、より広範な構造的な問題にも触れています。DWHは通常、多くのCDPがターゲットとするリアルタイムマーケティングのユースケースをサポートするように設計されていません。DWHは迅速な計算を行うことができ、頻繁な間隔で取り込みと処理を行うようスケジュールすることができますが、それでもリアルタイムではありません。同様に、一部の例外を除き、DWHは生データから行動することを望んでいません。一方、マーケターは生データ（通常はイベント）を使用して特定のアクティベーションをトリガーしたいと考えることがよくあります。

最後に、データとそれにアクセスする能力だけではCDPは作れないということを忘れないでください。ほとんどのCDPは、DWHにはない以下のような付加的な機能を提供しています：

• トリガーによるイベントサブシステム。
• アノニマス アイデンティティ解決.
• セグメンテーションのためのマーケターフレンドリーなインターフェイス。
• コネクタで活性化プロファイルをセグメント化する。
• ポテンシャルテスト、パーソナライゼーション、レコメンデーションサービス。

DWHだけではこれらの機能は提供されないので、別の場所で調達する必要があります。もちろん、DWHベンダーは大規模なパートナー・マーケットプレイスを持っています。しかし、それらはネイティブではないため、統合やサポートの労力が必要になります。

そのため、「コンポーザブルCDP」と、その中でのDWHの役割の可能性について、多くの議論が交わされています。私は以前、「コンポーザブルCDP」とは、以下のようなものだと主張しました。 スペクトルと、ある一定以上の利益を失うようになるのです。

これらの注意点を踏まえた上で、DWHは顧客データスタックの一部として、以下のような役割を果たすことができる：

• DWHから直接起動することで、CDPを不要にする。
• リバースETLプラットフォームでDWHを準CDPとして利用する。
• CDPと共存する。

この3つのデザインパターンを見てみましょう。

1.マーケティングプラットフォームとDWHを直接つなぐ

これはおそらく、私が上で批判した最も極端なケースですが、一部の企業は、特にCDP以前の時代にこれを成功させており、（幅広いエコシステムを持つSnowflakeのような）プラットフォームは、これを解決しようと模索しています。

この考え方は、エンゲージメントプラットフォームがDWHを使用してプッシュプルデータに直接接続することです。多くの成熟したEメールやマーケティングオートメーションのプラットフォームは、バッチプッシュが一般的ではありますが、これを行うためのネイティブな配線が施されています。その後、マーケターはメッセージングプラットフォームを使ってセグメントを作成し、アウトバウンドマーケティングの場合はそのセグメントに対してメッセージを送信します。

別のマーケティングやエンゲージメントのプラットフォーム、パーソナライズされたウェブサイトやeコマースプラットフォームがあるとします。この場合も、DWHからデータを取得し、ウェブアプリケーションプラットフォームを使用して、よりターゲットを絞ったエンゲージメントのための別のセグメントセットを作成します。

もう問題はおわかりでしょうか？セグメンテーションのインターフェースはすでに2セットあるのです。もし、マーケティングプラットフォームが10個あったらどうなるでしょうか？20?あらゆる場所でセグメントを作成し続けることになり、オムニチャネルの約束は消えてしまいます。

最後に、DWHからの直接取り込みに対応していない別のマーケティングプラットフォームを追加する必要があった場合はどうでしょうか。

この方法は、上記の最初のパターンのいくつかの問題を解決するものです。特に注目すべきは、（理論的には）DWHの専門家でなくても、DWHの上に仮想的にユニバーサルセグメントを作成し、複数のプラットフォームを活性化することができることです。変換と優れたコネクターフレームワークを使えば、異なるエンドポイントに異なるラベルマッピングとマーケティングに適したデータ構造を適用することができます。

その仕組みはこうだ。リバースETLプラットフォームは、DWHからデータを取り出し、任意の変換を行った後にマーケティングプラットフォームに送信します。複数の変換を行い、そのデータを複数の送信先に同時に送信することができます。自動化して、あらかじめ定義されたスケジュールで定期的にエクスポートを実行させることもできます。

しかし、データのコピー（またはそのサブセット）は実際にターゲットプラットフォームにコピーされるため、実際にはデータのコピーを1つだけ持っているわけではありません。リバースETLプラットフォームはデータのコピーを持っていないので、必要なセグメントやオーディエンスは常にクエリ時に生成されます（通常はバッチ）。そして、それらを配信先にエクスポートします。

リアルタイムトリガーやイベントに基づく常時キャンペーンを行いたい場合は、この方法は適していません。確かに、高い頻度でエクスポートを自動化することは可能ですが、それはリアルタイムではありません。エクスポートの頻度を上げると、コストは指数関数的に上昇します。

また、リバースETLツールはセグメンテーションのインターフェイスを提供していますが、技術的な傾向が強く、MOpsに特化したものではなく、DataOpsに特化したものとなっています。これをマーケターのセルフサービスに適した「ビジネスに適した」ソリューションと断言する前に、慎重にテストする必要があります。

3.DWHはCDPと共存している

企業のDWHは、CDP（他のエンドポイントも含む）にデータを供給する顧客データ基盤層として機能します。CDPの多くは、SnowflakeをはじめとするDWHプラットフォームから同期する機能を提供しています。

これらのCDPがDWHと共存する方法にはバリエーションがあります。ほとんどのCDPはデータをリポジトリに同期して複製しますが、他のCDP（リバースETLベンダーを含む）は複製を作成しません。しかし、最終的に何が有効かを決定する前に、トレードオフを考慮する必要がある場合もあります。

一般的に、大企業はこのデザインパターンを好む傾向がありますが、顧客のID解決などの重要なサービスが最終的にどこに配置されるかは、大きく異なります。

もっと深く掘り下げる： CDPはマーテックスタックのどこに位置づけられるのか？

まとめ

DWHプラットフォームは、マーテクスタックにおいてますます重要な役割を果たすようになっています。しかし、データエコシステムの中でどのようなサービスを提供するかについては、引き続き複数のアーキテクチャを選択することができます。

CDPを否定するのは時期尚早だと思います。各パターンにはトレードオフがあり、選択肢を評価する際に念頭に置いておく必要があります。