Der CDP-Connector-Mythos

Bei einer kürzlich von mir besuchten CDP-Demo fragte ein nervöser Kunde den Anbieter, ob er einen Konnektor zu Salesforce Sales Cloud habe. Der Verkäufer bejahte dies und der Kunde atmete erleichtert auf. Aber die Wahrheit ist – die meisten Anbieter von Kundendatenplattformen (CDP) haben enttäuschende verpackte Konnektoren. Lesen Sie weiter, warum das so ist und was Sie dagegen tun können.

Ein bisschen Geschichte: Das Rennen der Unternehmens-'Portlets'

Diese Begegnung erinnerte mich an die „Enterprise Portal“-Ära. Verwöhnen Sie mich bitte, während ich auf die späten 2000er und frühen 2010er Jahre zurückblicke – eine Zeit, die die meisten Kunden und Verkäufer gerne vergessen würden, die aber auch heute noch Lehren enthält.

Unternehmensportale sollten eine einzige, bequeme Schnittstelle zu einer potenziell breiten Palette von Unternehmensanwendungen bieten, die als separate Blöcke auf einem Bildschirm in einem Dashboard-Motiv angezeigt werden. Die Technologie, die diesen einzelnen Blöcken zugrunde liegt, hatte viele Namen, aber nennen wir sie vorerst „Portlets“.

Es wurde schnell klar, dass Portalprogramme im Grunde hochkomplexe Integrationsprojekte waren, sodass Unternehmen natürlich versuchten, vorgefertigten Connector-Code zu nutzen. Die Anbieter reagierten mit Portlet-Katalogen, und ein Wettrüsten entbrannte. „Wir haben 250 Portlets“, prahlte ein Anbieter.

Diese Portlets würden sich in Bezug auf Herkunft, Support, Benutzerfreundlichkeit, Leistung, Sicherheit und (entscheidend) technische Grundlagen stark unterscheiden. Ein „Portlet“ war in der Regel eine Referenzinstanz von Java- oder C#-Code, den jemand für eine einzelne Client-Implementierung geschrieben hatte. Meistens musste der Code überarbeitet werden, manchmal von Grund auf neu.

Anbieter entgegneten – nicht zu Unrecht – dass Probleme oft eher in der Konfiguration von Remote-Systemen als in der Portalplattform selbst lägen. Vielleicht ja, aber Unternehmen wurden schließlich von Portlets abgestumpft. Inmitten anderer technologischer und geschäftlicher Veränderungen in der digitalen Welt geriet die Portalplattformtechnologie allmählich aus der Mode.

Das neue CDP-Konnektor-Rennen

Schneller Vorlauf bis heute, und die Welt beginnt, CDPs (unter anderem) als Integrationsumgebungen zu verstehen. Jedes CDP-Auswahlteam, mit dem wir zusammenarbeiten, ist bestrebt, Anbieter mit vorgefertigten Konnektoren zu finden, die mit ihren etablierten Plattformen mithalten können. Bei fast jeder CDP-Implementierung werden diese Konnektoren jedoch von teuren Entwicklern erheblich modifiziert oder neu geschrieben.

CDP-Anbieter erliegen anscheinend dem Druck, dem ihre Portal-Brüder ausgesetzt waren. Wenn Kunden Wert auf einen vielfältigen Katalog von Konnektoren legen, müssen Sie als CDP-Anbieter viele davon anzeigen, fertig oder nicht. In CDP-Demos erscheinen Konnektoren auf dem Bildschirm als ordentliche Blöcke (mit dem Logo der verbundenen Plattform, das deutlich sichtbar ist), die Sie herumziehen können – fast wie Portlets!

Nun, nicht so schnell. Wie Portlets können CDP-Anbieter-Konnektoren einfach aus der Ausgabe einer einzelnen Implementierung resultieren. Noch wichtiger ist, dass in einigen Fällen ein einzelner Konnektor unmöglich die Komplexität der Martech-Plattform am anderen Ende bewältigen kann.

Betrachten Sie die oben erwähnte Salesforce Sales Cloud. Die Plattform leidet unter einem problematischen Objektmodell, das die meisten Lizenznehmer verzerren oder stark erweitern. Es kann so sein, als würde man sich mit einem sehr wütenden Oktopus verbinden. Und Salesforce ist hier keineswegs allein. In solchen Situationen kann der Konnektor eines CDP-Anbieters nur das grundlegende Gerüst bereitstellen und den Rest einem Entwickler überlassen.

Sind wir der Feind?

Portale starben aus einem anderen Grund. Wenn Augen Fenster zur Seele sind, waren Portale Fenster in Unternehmensdärme. Ein Portal war nur so nützlich wie die zugrunde liegenden Anwendungen. Oft waren diese Anwendungen chaotisch, hatten keine gemeinsamen Inhalts- und Metadatenmodelle, verwendeten unterschiedliche Zugriffskontrollregime, zeigten unterschiedliche UX-Modelle und zeigten manchmal Daten von geringer Qualität.

In meiner Firma sehen wir ein ähnliches Phänomen bei CDPs. Je nachdem, wie Sie eine CDP-Bemühung ausrichten (und hier zeigen sich unterschiedliche Muster), kann die CDP die Unreife Ihres umfassenderen Kundendatenverwaltungssystems aufdecken – ein Grund mehr, jede potenzielle CDP an Ihre umfassendere Datenarchitektur anzupassen.

Tiefer graben: So identifizieren und organisieren Sie Daten mit einem neuen CDP

Achten Sie auf CDP-Anbieter, die behaupten, verschiedene Connector-Kataloge zu haben

Vorgewarnt ist wie immer gewappnet. Überdenken Sie zunächst die Übergewichtung eines Anbieters, der behauptet, über Konnektorkataloge zu verfügen, die gut zu Ihrem Stack passen. Unter anderem kann das einfache Verschieben von CSV-Dateien viele (Nicht-Echtzeit-)Anwendungsfälle lösen. Wenn Sie gebündelte Konnektoren benötigen, ist spezifische Integrationserfahrung nützlich, schützt jedoch nicht automatisch vor erheblichen Entwicklungen in Ihrer Zukunft. Der Schlüssel ist, herauszufinden, wie viel Entwicklung.

Hoffentlich folgen Sie einem agilen CDP-Auswahlverfahren, das mit einem wettbewerbsfähigen Bake-off und einem eher technischen Proof of Concept (PoC) mit einem oder zwei Finalisten endet. Ein PoC ist eine großartige Umgebung, um einige wichtige Anschlüsse zu testen. Sie werden dann verstehen, wie viel Aufwand erforderlich ist, um bei Bedarf zu überholen – und das kann oft sein.

Wie ihre Portalanbieter-Vorgänger werden CDP-Anbieter „Schnellstart“-Pakete versprechen, um eine Erstimplementierung zu beschleunigen. Glauben Sie es nicht. Auch hier können einige Verzögerungen auf die Zeit zurückzuführen sein, die Sie benötigen, um Ihr eigenes Datenhaus in Ordnung zu bringen, aber ich kann Ihnen auch garantieren, dass jemand die Connector-Entwicklung übernimmt, und diese Arbeit wird in Quartalen und nicht in Monaten gemessen. Budgetieren Sie Ihre Ressourcen entsprechend.