O mito do conector CDP

Jan 28, 2024

MarTech » Plataforma de dados do cliente (CDP) » O mito do conector CDP

Em uma demonstração recente do CDP da qual participei, um cliente nervoso perguntou ao fornecedor se ele tinha um conector para o Salesforce Sales Cloud. O vendedor respondeu afirmativamente, e o cliente deu um suspiro de alívio. Mas a verdade é que a maioria dos fornecedores de plataforma de dados do cliente (CDP) tem conectores empacotados decepcionantes. Leia sobre por que isso acontece e o que você pode fazer sobre isso.

Esse encontro me lembrou a era do "portal empresarial". Por favor, permita-me enquanto olho para o final dos anos 2000 e início dos anos 2010 - uma época que a maioria dos clientes e fornecedores gostaria de esquecer, mas que ainda traz lições hoje.

Os portais corporativos deveriam fornecer uma interface única e conveniente para uma variedade potencialmente ampla de aplicativos corporativos, exibidos como blocos separados em uma tela em um motivo de painel. A tecnologia subjacente a esses blocos individuais tinha muitos nomes, mas, por enquanto, vamos chamá-los de "portlets".

Rapidamente ficou claro que os programas de portal eram fundamentalmente projetos de integração altamente complexos, então as empresas buscaram naturalmente alavancar o código do conector pré-fabricado. Os fornecedores responderam com catálogos de portlets, e uma corrida armamentista começou. "Temos 250 portlets", gabava-se um fornecedor.

Esses portlets variam drasticamente em proveniência, suporte, usabilidade, desempenho, segurança e (crucialmente) fundamentos técnicos. Um "portlet" geralmente era uma instância de referência de algum código Java ou C# que alguém escreveu para uma implementação de cliente único. Na maioria das vezes, o código precisava ser revisado, às vezes do zero.

Os fornecedores responderam - não injustamente - que os problemas geralmente se originavam em como os sistemas remotos eram configurados, e não na própria plataforma do portal. Talvez sim, mas as empresas acabaram se cansando dos portlets. Em meio a outras mudanças de tecnologia e negócios no mundo digital, a tecnologia de plataforma de portal gradualmente saiu de moda.

Avançando para hoje, o mundo está começando a entender os CDPs como ambientes de integração (entre outras coisas). Todas as equipes de seleção de CDP com as quais trabalhamos se esforçam para encontrar fornecedores com conectores pré-construídos para corresponder às suas plataformas incumbentes. No entanto, quase todas as implementações de CDP encontram desenvolvedores caros modificando ou reescrevendo significativamente esses conectores.

Os fornecedores de CDP aparentemente estão sucumbindo às pressões que seus irmãos de portais sofreram. Se os clientes valorizam um catálogo diversificado de conectores, então, como fornecedor de CDP, você deve exibir muitos deles, prontos ou não. Nas demos do CDP, os conectores aparecem na tela como blocos organizados (com o logotipo da plataforma conectada aparecendo de forma proeminente) que você pode arrastar — quase como portlets!

Bem, não tão rápido. Assim como os portlets, os conectores do fornecedor CDP podem resultar simplesmente da saída de uma única implementação. Mais importante, em alguns casos, um único conector não pode abordar a complexidade da plataforma martech na outra extremidade.

Considere o Salesforce Sales Cloud, mencionado acima. A plataforma sofre de um modelo de objeto problemático que a maioria dos licenciados distorce ou estende fortemente. Pode ser como conectar-se a um polvo muito zangado. E o Salesforce não está sozinho aqui. Em tais situações, o conector de um fornecedor de CDP pode fornecer apenas a estrutura básica e deixar o restante para o desenvolvedor.

Os portais desapareceram por outro motivo. Se os olhos são as janelas da alma, os portais eram as janelas das entranhas da empresa. Um portal era tão útil quanto os aplicativos subjacentes. Freqüentemente, esses aplicativos eram confusos, careciam de modelos comuns de conteúdo e metadados, empregavam diversos regimes de controle de acesso, exibiam diferentes modelos de UX e, às vezes, expunham dados de baixa qualidade.

Na minha empresa, vemos um fenômeno semelhante com os CDPs. Dependendo de como você define o escopo de um esforço de CDP (e diferentes padrões estão surgindo aqui), o CDP pode expor a imaturidade de seu regime mais amplo de gerenciamento de dados do cliente — mais uma razão para combinar qualquer CDP potencial com sua arquitetura de dados mais ampla.