CDP コネクタの神話

Jan 28, 2024

MarTech » 顧客データプラットフォーム (CDP) » CDP コネクタの神話

私が参加した最近の CDP デモでは、緊張したクライアントがベンダーに、Salesforce Sales Cloud へのコネクタがあるかどうか尋ねました。ベンダーは肯定的に答え、クライアントは安堵のため息をつきました。しかし真実は、ほとんどの顧客データプラットフォーム (CDP) ベンダーが残念なパッケージコネクタを持っているということです。その理由とそれに対して何ができるかを読んでください。

この出会いで私は「エンタープライズポータル」の時代を思い出しました。 2000 年代後半から 2010 年代初頭のことを振り返ってみてください。ほとんどの顧客やベンダーが忘れたいと思っている時代ですが、この時代は今も教訓として残っています。

エンタープライズポータルは、ダッシュボードモチーフの画面上に個別のブロックとして表示される、潜在的に広範なエンタープライズアプリケーションへの単一の便利なインターフェイスを提供することになっていました。これらの個々のブロックを支えるテクノロジーにはさまざまな名前が付けられていますが、ここではそれらを「ポートレット」と呼ぶことにします。

ポータルプログラムは基本的に非常に複雑な統合プロジェクトであることがすぐに明らかになったため、企業は当然プレハブコネクタコードを活用しようとしました。ベンダーはポートレットカタログで応じ、軍拡競争が起こった。「当社には 250 のポートレットがあります」とベンダーは自慢するでしょう。

これらのポートレットは、来歴、サポート、使いやすさ、パフォーマンス、セキュリティ、および (重要な) 技術的基盤の点で大きく異なります。「ポートレット」は通常、単一のクライアント実装用に誰かが作成した Java または C# コードの参照インスタンスでした。多くの場合、コードを徹底的に見直す必要があり、場合によっては最初から見直す必要がありました。

ベンダーは、不公平ではなく、問題はポータルプラットフォーム自体ではなく、リモートシステムの構成方法に起因することが多いと反論しました。そうかもしれませんが、企業は最終的にポートレットにうんざりしてしまいました。デジタル世界での他のテクノロジーやビジネスの変化の中で、ポータルプラットフォームテクノロジーは徐々に時代遅れになっていきました。

今日に目を向けると、世界は CDP を (とりわけ) 統合環境として理解するようになりつつあります。私たちが協力するすべての CDP 選択チームは、既存のプラットフォームに適合する事前構築済みのコネクタを備えたベンダーを見つけるよう努めています。しかし、ほぼすべての CDP 実装では、開発者が費用をかけてコネクタを大幅に変更または書き換えていることがわかります。

CDP ベンダーは、ポータルの同胞たちが耐えてきた圧力に屈しているようです。顧客がコネクタの多様なカタログを重視する場合、CDP ベンダーとして、準備ができているかどうかにかかわらず、コネクタの多くを展示する必要があります。 CDP デモでは、コネクタは画面上にきちんとしたブロックとして表示され (接続されたプラットフォームのロゴが目立つように表示されます)、ドラッグして移動できます。まるでポートレットです。

まあ、それほど速くはありません。ポートレットと同様に、CDP ベンダーコネクタは、単に単一の実装の出力から得られる場合があります。さらに重要なことは、場合によっては、単一のコネクタでは相手側のマーテックプラットフォームの複雑さに対処できない可能性があることです。

前述した Salesforce Sales Cloud について考えてみましょう。このプラットフォームは、ほとんどのライセンシーが曲解したり大幅に拡張したりする問題のあるオブジェクトモデルに悩まされています。それは、非常に怒っているタコとつながっているようなものかもしれません。そして、ここでは Salesforce だけが存在するわけではありません。このような状況では、CDP ベンダーのコネクタは基本的な足場のみを提供し、残りは開発者に任せることができます。

ポータルは別の理由で消滅しました。目が魂への窓だとすれば、ポータルは企業の腸への窓でした。ポータルは、基礎となるアプリケーションと同じくらい役に立ちました。多くの場合、これらのアプリケーションは乱雑で、共通のコンテンツとメタデータモデルが欠如し、多様なアクセス制御体制を採用し、異なる UX モデルを示し、場合によっては低品質のデータが公開されていました。

私の会社でも、CDP に関して同様の現象が見られます。 CDP の取り組みの範囲をどのように設定するかによっては (そしてここではさまざまなパターンが出現しています)、CDP は広範な顧客データ管理体制の未熟さを露呈する可能性があります。だからこそ、将来の CDP を広範なデータアーキテクチャに適合させる必要があるのです。

さらに深く掘り下げる: 新しい CDP を使用してデータを識別し、整理する方法

いつものように、事前警告は事前準備です。まず、自社のスタックに適合するコネクタカタログを持っていると主張するベンダーを過大評価することを再考してください。理由としては、特に CSV ファイルを移動するだけで、多くの (非リアルタイムの) ユースケースを解決できる可能性があります。パッケージ化されたコネクタが必要な場合、特定の統合エクスペリエンスは役に立ちますが、本質的に将来の大幅な開発を防ぐことはできません。重要なのは、どの程度の開発が行われるかを知ることです。

うまくいけば、あなたは、競争力のあるベイクオフと、1 人または 2 人の最終候補者によるより技術的な概念実証 (PoC) で終わる、アジャイルな CDP 選択プロセスに従っていることを願っています。 PoC は、いくつかの重要なコネクタをテストするのに最適な環境です。そうすれば、必要に応じてオーバーホールするための努力のレベルが理解できるようになります。それは頻繁に行われる可能性があります。

前任者のポータルベンダーと同様に、CDP ベンダーは初期実装を加速する「クイックスタート」パッケージを約束します。信じないでください。繰り返しになりますが、独自のデータハウスを整備する必要があるため、遅延が発生する可能性がありますが、誰かがコネクタ開発を行うことも保証できます。また、この作業は数か月ではなく四半期単位で測定されます。それに応じてリソースの予算を立てます。

マーテックを手に入れましょう！毎日。無料。受信箱にあります。

規約を参照してください。

この記事で表明された意見はゲスト著者の意見であり、必ずしも MarTech とは限りません。スタッフの著者はここにリストされています。

マーテックの新機能

著者について