データ ウェアハウスを 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 は生データに基づいて行動したくないのに対し、マーケターはしばしば生データ (通常はイベント) を使用して特定のアクティベーションをトリガーしたいと考えています。

最後に、データとそれにアクセスする機能だけでは CDP にはならないことを覚えておいてください。 ほとんどの CDP は、次のような DWH にはない追加機能のサブセットを提供します。

• トリガー付きのイベント サブシステム。
• 匿名の ID 解決。
• セグメンテーションのためのマーケティング担当者向けのインターフェイス。
• アクティベーション プロファイルをコネクタでセグメント化します。
• テスト、パーソナライゼーション、推奨サービスの可能性。

DWH だけではこれらの機能は提供されないため、他の場所でこれらを入手する必要があります。 もちろん、DWH ベンダーにはかなりの規模のパートナー市場があります。 多くの代替手段を見つけることができますが、それらはネイティブではなく、統合とサポートの作業が必要になります。

当然のことながら、「コンポーザブル CDP」と、そのコンテキストにおける DWH の潜在的な役割について、多くの話題があります。 コンポーザビリティはスペクトルであり、特定のポイントを超えると利点が失われ始めると以前に主張しました。

これらすべての注意事項を発行した後、DWH は次のような顧客データ スタックの一部として役割を果たすことができます。

• DWH から直接アクティブ化することで、CDP を廃止します。
• リバース ETL プラットフォームで DWH を準 CDP として使用する。
• CDP との共存。

これらの 3 つの設計パターンを見てみましょう。

1. マーケティング プラットフォームを DWH に直接接続する

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

ここでの考え方は、エンゲージメント プラットフォームが DWH を使用してプッシュプル データに直接接続するというものです。 多くの成熟した電子メールおよびマーケティング自動化プラットフォームは、通常はバッチ プッシュを使用しますが、これを行うためにネイティブに配線されています。 その後、マーケティング担当者はメッセージング プラットフォームを使用してセグメントを作成し、アウトバウンド マーケティングの場合はそれらのセグメントにメッセージを送信します。

別のマーケティングまたはエンゲージメント プラットフォーム、パーソナライズされた Web サイトまたは e コマース プラットフォームがあると想像してください。 再び DWH からデータを取得し、Web アプリケーション プラットフォームを使用して、よりターゲットを絞ったエンゲージメントのための別のセグメント セットを作成します。

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

最後に、DWH からの直接取り込みをサポートしていない別のマーケティング プラットフォームを追加する必要があるとしたら?

2. リバース ETL ツールで DWH を採用する

このアプローチは、上記の最初のパターンのいくつかの問題を解決します。 特に、(理論的には) 非 DWH スペシャリストが仮想的に DWH の上にユニバーサル セグメントを作成し、複数のプラットフォームを有効にすることができます。 変換とより優れたコネクタ フレームワークにより、さまざまなラベル マッピングとマーケターにとって使いやすいデータ構造をさまざまなエンドポイントに適用できます。

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

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

これは、イベントに基づいてリアルタイムのトリガーや常時キャンペーンを行いたい場合には適切なアプローチではありません。 確かに、高頻度でエクスポートを自動化できますが、それはリアルタイムではありません。 エクスポートの頻度を増やすと、コストが指数関数的に増加します。

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

3. DWH と CDP の共存

エンタープライズ DWH は、(他のエンドポイントの中でも) CDP にデータを提供する顧客データ インフラストラクチャ レイヤーとして機能します。 ほとんどではないにしても、多くの CDP が、DWH プラットフォーム、特に Snowflake から同期する機能を提供するようになりました。

これらの CDP が DWH と共存できる方法にはさまざまなバリエーションがあります。 ほとんどの CDP はデータをリポジトリに同期して複製しますが、他のもの (リバース ETL ベンダーを含む) はコピーを作成しません。 ただし、自分に合ったものを最終決定する前に、考慮しなければならないトレードオフが存在する可能性があります。

一般に、大企業はこの設計パターンを好む傾向がありますが、顧客 ID 解決などの重要なサービスが最終的に存在する場所には大きなばらつきがあります。

より深く掘り下げる: CDP はマーテック スタックのどこに収まるべきか?

要約

DWH プラットフォームは、マーテック スタックにおいてますます重要な役割を果たしています。 ただし、データ エコシステム内でレンダリングするサービスについては、引き続き複数のアーキテクチャの選択肢があります。

将来的に CDP を除外するのは時期尚早だと思います。 各パターンには、オプションを評価する際に留意すべきトレードオフがあります。