banner
Maison / Nouvelles / Le mythe du connecteur CDP
Nouvelles

Le mythe du connecteur CDP

Jan 28, 2024Jan 28, 2024

MarTech » Plateforme de données client (CDP) » Le mythe du connecteur CDP

Lors d'une récente démonstration CDP à laquelle j'ai assisté, un client nerveux a demandé au fournisseur s'il disposait d'un connecteur vers Salesforce Sales Cloud. Le vendeur a répondu par l'affirmative et le client a poussé un soupir de soulagement. Mais la vérité est que la plupart des fournisseurs de plateformes de données client (CDP) ont des connecteurs packagés décevants. Lisez la suite pour savoir pourquoi et ce que vous pouvez faire à ce sujet.

Cette rencontre m'a rappelé l'époque du "portail d'entreprise". S'il vous plaît, faites-moi plaisir pendant que je repense à la fin des années 2000 et au début des années 2010 - une époque que la plupart des clients et des fournisseurs voudraient oublier, mais qui porte encore des leçons aujourd'hui.

Les portails d'entreprise étaient censés fournir une interface unique et pratique dans un éventail potentiellement large d'applications d'entreprise, affichées sous forme de blocs séparés sur un écran dans un motif de tableau de bord. La technologie sous-jacente à ces blocs individuels portait de nombreux noms, mais pour l'instant, appelons-les "portlets".

Il est rapidement devenu clair que les programmes de portail étaient fondamentalement des projets d'intégration très complexes, de sorte que les entreprises ont naturellement cherché à tirer parti du code de connecteur préfabriqué. Les vendeurs ont répondu avec des catalogues de portlets et une course aux armements s'est ensuivie. "Nous avons 250 portlets", se vantait un vendeur.

Ces portlets varieraient considérablement en termes de provenance, de prise en charge, de convivialité, de performances, de sécurité et (essentiellement) de fondements techniques. Un "portlet" était généralement une instance de référence d'un code Java ou C # écrit par quelqu'un pour une implémentation client unique. Le plus souvent, le code devait être remanié, parfois à partir de zéro.

Les fournisseurs ont rétorqué – non injustement – ​​que les problèmes provenaient souvent de la configuration des systèmes distants plutôt que de la plate-forme du portail elle-même. Peut-être que oui, mais les entreprises ont fini par se lasser des portlets. Au milieu d'autres changements technologiques et commerciaux dans le monde numérique, la technologie des plates-formes de portail est progressivement passée de mode.

Avance rapide jusqu'à aujourd'hui, et le monde en vient à comprendre les CDP comme des environnements d'intégration (entre autres). Chaque équipe de sélection CDP avec laquelle nous travaillons s'efforce de trouver des fournisseurs avec des connecteurs pré-construits pour correspondre à leurs plates-formes en place. Pourtant, presque toutes les implémentations CDP trouvent des développeurs coûteux modifiant ou réécrivant considérablement ces connecteurs.

Les fournisseurs de CDP succombent apparemment aux pressions que leurs frères de portail ont endurées. Si les clients apprécient un catalogue diversifié de connecteurs, alors en tant que fournisseur CDP, vous devez en afficher un grand nombre, prêts ou non. Dans les démos CDP, les connecteurs apparaissent à l'écran sous forme de blocs ordonnés (avec le logo de la plate-forme connectée apparaissant bien en évidence) que vous pouvez faire glisser — presque comme des portlets !

Eh bien, pas si vite. Comme les portlets, les connecteurs de fournisseur CDP peuvent résulter simplement de la sortie d'une seule implémentation. Plus important encore, dans certains cas, un seul connecteur ne peut éventuellement pas répondre à la complexité de la plate-forme martech à l'autre extrémité.

Considérez Salesforce Sales Cloud, mentionné ci-dessus. La plate-forme souffre d'un modèle d'objet problématique que la plupart des titulaires de licence tordent ou étendent fortement. Cela peut être comme se connecter à une pieuvre très en colère. Et Salesforce n'est en aucun cas seul ici. Dans de telles situations, le connecteur d'un fournisseur CDP ne peut fournir que l'échafaudage de base et laisser le reste à un développeur.

Les portails ont disparu pour une autre raison. Si les yeux sont des fenêtres sur l'âme, les portails étaient des fenêtres sur les intestins de l'entreprise. Un portail n'était aussi utile que les applications sous-jacentes. Souvent, ces applications étaient désordonnées, manquaient de modèles de contenu et de métadonnées communs, utilisaient divers régimes de contrôle d'accès, présentaient différents modèles UX et exposaient parfois des données de mauvaise qualité.

Dans mon entreprise, on observe un phénomène similaire avec les CDP. Selon la façon dont vous étendez un effort CDP (et différents modèles émergent ici), le CDP peut exposer l'immaturité de votre régime plus large de gestion des données client - raison de plus pour faire correspondre tout CDP potentiel à votre architecture de données plus large.

Approfondir : comment identifier et organiser les données avec un nouveau CDP

Comme toujours, prévenu est prévenu. Tout d'abord, envisagez de surpondérer un fournisseur qui prétend avoir des catalogues de connecteurs qui correspondent bien à votre pile. Entre autres raisons, le simple fait de déplacer des fichiers CSV peut résoudre de nombreux cas d'utilisation (non en temps réel). Lorsque vous avez besoin de connecteurs packagés, une expérience d'intégration spécifique devient utile mais ne protège pas intrinsèquement contre un développement substantiel dans votre avenir. La clé est de savoir combien de développement.

J'espère que vous suivez un processus de sélection CDP agile qui se termine par une préparation compétitive et une preuve de concept (PoC) plus technique avec un ou deux finalistes. Un PoC est un environnement idéal pour tester quelques connecteurs essentiels. Vous comprendrez alors le niveau d'effort nécessaire pour réviser si nécessaire - et cela peut être souvent.

À l'instar de leurs prédécesseurs, les fournisseurs de portails, les fournisseurs de CDP promettent des packages de "démarrage rapide" pour accélérer une mise en œuvre initiale. Ne le croyez pas. Encore une fois, certains retards peuvent provenir du temps dont vous aurez besoin pour mettre de l'ordre dans votre propre data house, mais aussi, je peux vous garantir que quelqu'un se chargera du développement des connecteurs, et ce travail se mesure en trimestres, pas en mois. Budgétisez vos ressources en conséquence.

Obtenez MarTech ! Quotidien. Gratuit. Dans votre boîte de réception.

Voir conditions.

Les opinions exprimées dans cet article sont celles de l'auteur invité et pas nécessairement celles de MarTech. Les auteurs du personnel sont répertoriés ici.

Histoires liées

Nouveau sur MarTech

A propos de l'auteur

Rubriques connexes

Approfondir : comment identifier et organiser les données avec un nouveau CDP Tony Byrne