El mito del conector CDP

En una demostración reciente de CDP a la que asistí, un cliente nervioso le preguntó al proveedor si tenía un conector para Salesforce Sales Cloud. El vendedor respondió afirmativamente y el cliente respiró aliviado. Pero la verdad es que la mayoría de los proveedores de Customer Data Platform (CDP) tienen conectores empaquetados decepcionantes. Siga leyendo para averiguar por qué y qué puede hacer al respecto.

Un poco de historia: la carrera de los 'portlets' empresariales

Este encuentro me recordó la era del "Enterprise Portal". Permítanme mirar hacia atrás, a fines de la década de 2000 y principios de la de 2010, una época que a la mayoría de los clientes y proveedores les gustaría olvidar, pero que todavía ofrece lecciones hoy.

Los portales empresariales deben proporcionar una interfaz única y conveniente para una gama potencialmente amplia de aplicaciones empresariales, presentadas como bloques separados en una pantalla en un tema de tablero. La tecnología detrás de estos bloques separados ha tenido muchos nombres, pero ahora se llama cmlet "Portlets". "

Rápidamente se hizo evidente que los programas de portal eran, en el fondo, proyectos de integración muy complejos, por lo que las empresas naturalmente buscaron aprovechar el código de conector preempaquetado. Los proveedores respondieron con catálogos de portlets y se produjo una carrera armamentista.

Estos portlets diferían drásticamente en términos de procedencia, soporte, facilidad de uso, rendimiento, seguridad y (crucialmente) fundamentos técnicos. Por lo general, un "portlet" era una instancia de referencia de código Java o C# que alguien había escrito para la implementación de un solo cliente. La mayoría de las veces, el código tenía que volver a trabajarse, a veces desde cero.

Los proveedores respondieron, no sin razón, que los problemas a menudo radican más en la configuración de los sistemas remotos que en la plataforma del portal en sí. Tal vez sea así, pero las empresas finalmente se cansaron de los portlets.

La nueva carrera de conectores CDP

Avance rápido hasta hoy, y el mundo entiende los CDP (entre otras cosas) como entornos de integración. Cada equipo de selección de CDP con el que trabajamos se esfuerza por encontrar proveedores con conectores prediseñados que puedan competir con sus plataformas establecidas. La implementación de CDP da como resultado que los desarrolladores costosos modifiquen o reescriban significativamente esos conectores.

Los proveedores de CDP parecen sucumbir a la presión bajo la que se encuentran sus hermanos del portal. Si los clientes valoran un catálogo diverso de conectores, entonces, como proveedor de CDP, debe mostrar muchos de ellos, listos o no. En las demostraciones de CDP, los conectores aparecen en la pantalla como bloques ordenados (con el logotipo de la plataforma conectada claramente visible) que puede arrastrar, ¡casi como portlets!

Bueno, no tan rápido. Al igual que los portlets, los conectores de proveedores de CDP pueden resultar simplemente de la salida de una sola implementación. Más importante aún, en algunos casos, un solo conector no puede manejar la complejidad de la plataforma martech en el otro extremo.

Considere la nube de ventas de Salesforce mencionada anteriormente. La plataforma sufre de un modelo de objeto problemático que la mayoría de los licenciatarios distorsionan o amplían en gran medida. Puede ser como conectarse con un pulpo muy enojado. Y Salesforce no está solo aquí. En tales situaciones, un conector de proveedor de CDP solo puede proporcionar el marco básico y dejar el resto a un desarrollador.

somos el enemigo

Los portales se extinguieron por otra razón. Si los ojos eran ventanas al alma, los portales eran ventanas a las entrañas de la empresa. Un portal era tan útil como las aplicaciones subyacentes. A menudo, estas aplicaciones eran caóticas, carecían de contenido común y modelos de acceso a metadatos, y participaban en regímenes de control, exhibían diferentes modelos UX y, a veces, exponían datos de baja calidad.

En mi empresa, vemos un fenómeno similar con los CDP. Dependiendo de cómo elija un esfuerzo de CDP (y aquí surgen diferentes patrones), el CDP puede revelar la inmadurez de su sistema de gestión de datos de clientes más amplio, razón de más para adaptar cualquier CDP potencial a su arquitectura de datos más amplia.

Profundice más: Cómo identificar y organizar datos con un nuevo CDP

Tenga cuidado con los proveedores de CDP que afirman tener diferentes catálogos de conectores

Como siempre, se recomienda precaución. Primero, considere sobrevalorar a un proveedor que afirma tener catálogos de conectores que se ajustan bien a su pila. Entre otras cosas, muchos casos de uso (no en tiempo real) se pueden resolver simplemente moviendo archivos CSV. Necesitan conectores integrados, la experiencia de integración específica se vuelve útil, pero no constituye automáticamente una protección contra desarrollos significativos en su futuro. La clave es para saber cuánto desarrollo se requiere.

Es de esperar que sigan un proceso de selección de CDP ágil que termine con un concurso competitivo y una prueba de concepto (PoC) más técnica con uno o dos finalistas. Un PoC es un excelente entorno para probar algunos conectores importantes. Entonces entenderé cuánto esfuerzo se requiere para adelantarlo, y eso puede ser a menudo.

Al igual que sus predecesores de proveedores de portales, los proveedores de CDP prometen paquetes de "inicio rápido" para acelerar una implementación inicial. No lo crea. Una vez más, pueden surgir algunos retrasos debido al tiempo que le lleva poner en orden su propia casa de datos. Pero puedo también garantice que alguien esté desarrollando el conector y que el trabajo se mida en trimestres, no en meses, así que presupueste sus recursos en consecuencia.

¡Consigue Aprendermarketing! Entregado diariamente a su bandeja de entrada de forma gratuita.

Las opiniones expresadas en este artículo son las del autor invitado y no necesariamente las de Aprendermarketing. Los autores del personal se enumeran aquí.