Cómo transferir los datos de un evento B2B al CRM

Esquema de transferencia de datos de un evento B2B a la CRM: entidades, ID, estados, campos, consentimientos, duplicados y verificación del registro recibido.

Los datos de los eventos para empresas (B2B, business-to-business) a menudo pierden su sentido entre el recinto y la CRM, el sistema de gestión de relaciones con clientes. En el formulario hay nombre y email, en la acreditación aparece un número, el escáner registra una acción, y en el sistema de destino queda un nuevo contacto sin un evento, sesión, reunión o fuente de invitación claros.

En Aventura empezamos por el otro lado: describimos los hechos que deben llegar al sistema del cliente y acordamos cómo la CRM confirmará su recepción. Este contrato es necesario antes de abrir el registro. Más adelante, cambiar los identificadores (ID), los estados y la finalidad de los campos resulta notablemente más difícil: los datos ya llegan desde varios puntos a la vez.

Si está preparando un evento de negocios y quiere vincular de antemano el registro, la marca de llegada (check-in) y las actividades en el recinto con el sistema del cliente, solicite una reunión de trabajo sobre el proyecto. Le ayudaremos a describir el esquema de datos del evento y los requisitos para la prueba conjunta. La configuración y la administración de la CRM siguen siendo responsabilidad del equipo especializado del cliente.

¿Qué datos deben llegar al CRM?

Transmita solo aquellos datos que respaldan una acción concreta en el CRM. Para cada campo y dato, defina de antemano el objetivo, el propietario y el destinatario. Si el equipo no puede explicar quién utiliza el valor y qué hace después, es mejor eliminar el campo del formulario o del intercambio.

Las fuentes de un evento B2B son varias. La invitación aporta la campaña y el canal de acceso. El registro indica quién solicitó participar.

La marca de llegada confirma la presencia. La sesión, la reunión o la acción en el stand añaden un nuevo dato. El CRM debe recibir estas partes con un contexto común, pero no está obligado a almacenarlas en un solo objeto.

La pregunta mínima para cada fuente es la siguiente:

Las etiquetas UTM (Urchin Tracking Module) ayudan a distinguir la fuente, el canal y la campaña de acceso. Pertenecen al contexto del registro y no sustituyen el identificador de la persona o de la solicitud. El número de la acreditación tampoco debe convertirse en una clave universal: su función está limitada a un proyecto concreto y a un método de acceso.

Un artículo aparte sobre el registro y los requisitos de la Ley Federal No. 152-FZ analiza el aspecto jurídico y organizativo del formulario. Aquí mantenemos un límite más estrecho: qué entidades y campos recorren el camino hasta el registro aceptado en el CRM.

Cinco entidades en lugar de un único contacto sobrecargado

La persona, la empresa, el registro, la asistencia y la actividad responden a preguntas distintas. Si se agrupan en la ficha de un contacto y se reescriben los campos constantemente, el sistema perderá el historial. Los registros vinculados conservan el orden de los hechos y permiten verificar cada transferencia por separado. Así, el equipo ve no solo el estado actual del contacto, sino también el recorrido del participante por un evento concreto.

Persona (Person): el registro maestro del participante. En el registro maestro se encuentran los datos de contacto estables y los identificadores aceptados. Una persona puede participar en varios eventos, registrarse varias veces y realizar distintas acciones.

Empresa (Company): la organización. La empresa no equivale al dominio del correo electrónico en todos los casos, por lo que debe aprobarse la regla de vinculación. Un dominio corporativo puede ser una señal sólida. El correo público, una filial o un consultor requieren otra decisión y, en ocasiones, una verificación manual.

Registro (Registration): la solicitud de una persona para un evento concreto. Tiene su propio ID, event ID, origen, fecha de creación y estado. La participación repetida de la misma persona en otro evento genera un nuevo registro, no una nueva persona.

Asistencia (Attendance): el hecho de la presencia. El registro no demuestra la visita. Microsoft Customer Insights también separa el event registration y el check-in, y el check-in puede referirse a todo el evento o a una sesión concreta. Por ello, los campos «registrado» y «asistió» no pueden considerarse sinónimos.

Actividad (Activity): una acción concreta: asistencia a una sesión, reunión, escaneo de un material, visita al stand u otro hecho acordado. La actividad guarda su propio ID, tipo, hora y contexto. HubSpot Meetings API sigue la misma lógica: la reunión existe como una actividad de CRM independiente y se vincula con contactos y empresas.

Este modelo no exige la misma estructura en todos los CRM. En un sistema, el registro será un objeto independiente; en otro, una participación en una campaña, y la actividad, una entrada en el feed de acciones. El sentido debe conservarse sea cual sea la representación técnica.

Sistema de identificadores para todo el recorrido

Cada objeto y hecho debe tener un ID estable propio. La fuente emite el identificador una sola vez y los sistemas siguientes lo transmiten sin recrearlo. Así, una entrega repetida se reconoce como duplicado y el equipo puede encontrar el mismo registro en el formulario, el registro de intercambio y el CRM.

El conjunto de trabajo puede incluir:

1. event_id - el evento concreto.
2. person_id - el registro maestro de la persona en el entorno acordado.
3. company_id - la organización en el sistema del cliente o en el directorio de intercambio.
4. registration_id - la solicitud de la persona para este evento.
5. attendance_id - el hecho concreto de check-in.
6. activity_id - la sesión, reunión, stand u otra acción.
7. source_system - el sistema que creó el hecho.
8. schema_version - la versión del contrato de datos.

El estándar RFC describe el UUID, un identificador universalmente único de 128 bits que puede emitirse sin registro central. Esto resulta útil cuando el formulario, la aplicación móvil y el equipamiento del recinto son atendidos por sistemas distintos. UUIDv7 además admite el orden temporal, pero la versión concreta es secundaria. Lo crítico es otra cosa: un equipo asigna las reglas de emisión y todos los participantes conservan el valor.

La especificación CloudEvents define un modelo útil de transmisión de eventos. El par source + id determina un evento concreto, y un hecho reenviado puede conservar el mismo ID. El receptor entonces reconoce el duplicado sin conjeturas por nombre, email y hora.

Importante. El identificador del hecho transmitido no es igual al identificador de la persona ni al event_id del evento. El modelo de eventos Adobe XDM ExperienceEvent separa directamente el _id del registro de evento y la identidad de la persona. Un participante puede generar muchas actividades, y cada una recibe su propio identificador.

En una conferencia o foro este enfoque resulta especialmente útil: el registro, la entrada general, la asistencia a los tracks y las reuniones asignadas provienen de distintas partes del proyecto, pero se agrupan en torno a event_id y person_id comunes. Así el equipo puede verificar el recorrido de cada hecho sin mezclar entidades distintas en la ficha del contacto.

Es necesario acordar el esquema de datos del evento antes de que los proveedores configuren los formularios, las acreditaciones y los escáneres. Solicite una consulta sobre el esquema de datos y un presupuesto preliminar. Vincularemos los puntos de contacto del evento en un único pliego de condiciones y realizaremos la prueba junto con el responsable del CRM por parte del cliente.

¿Cómo acordar los estados?

Un estado debe tener un código, una definición, un propietario y transiciones permitidas. El texto libre como «llegó», «participó» o «mostró interés» pierde rápidamente su significado. El catálogo fija qué hecho cambia el estado y qué recibe el CRM. Diccionarios separados para el registro, la asistencia y las reuniones evitan que una misma palabra designe eventos distintos.

Empiece por diccionarios separados. Los estados de registro no deben mezclarse con los estados de presencia ni con los resultados de la reunión.

Los nombres de la tabla sirven como ejemplo de estructura. Los códigos finales los elige el equipo del cliente. Si el CRM ya tiene un catálogo, el emisor se adapta a él mediante un mapa explícito. Si el emisor usa su propio diccionario, el mapa debe mostrar cada correspondencia y el comportamiento para un valor desconocido.

Para cada estado, registre cuatro reglas:

1. Qué hecho observable lo establece.
2. Quién tiene derecho a cambiar el valor.
3. Si se puede volver al estado anterior.
4. Qué ocurre ante un evento tardío o repetido.

Por ejemplo, checked_in aparece tras un escaneo aceptado en la entrada. Un nuevo escaneo del mismo attendance ID no crea una segunda asistencia. Una cancelación tardía del registro no elimina el hecho de presencia ya confirmado, si la política del cliente exige conservar el historial.

No cambie el valor de un código existente durante la campaña. Añada una nueva versión del esquema y acuerde la transición. De lo contrario, el mismo status=confirmed antes y después del cambio significará cosas distintas.

¿Cómo elaborar un mapa de campos y contexto?

El mapa de campos vincula el origen y el CRM a nivel de nombre, tipo, obligatoriedad, transformación y comportamiento ante errores. Una simple lista de columnas no es suficiente. El destinatario debe entender de dónde proviene el valor y a qué entidad pertenece. Para los campos controvertidos se fijan de inmediato el catálogo, la versión del esquema, el responsable de la decisión y la respuesta del sistema ante un valor incorrecto.

HubSpot Properties API muestra bien la diferencia entre el tipo de dato y la interfaz del campo. Cadena, fecha, número y enumeración se almacenan de forma distinta. Para el catálogo de estados es adecuado un conjunto limitado de valores, no un campo de texto. El ID externo propio puede ubicarse en un campo con requisito de unicidad, si el CRM de destino admite ese modo.

El mapa de campos mínimo tiene este aspecto:

El contexto es especialmente importante para el stand. Transmitir solo badge_number=1842 no comunica nada al destinatario. Se necesitan event ID, activity ID, tipo de acción, hora, origen del escaneo y person o registration ID. Si el participante solicitó un material concreto, el código del material se transmite en un campo aparte solo si el destinatario dispone de una acción acordada.

Para la participación en la exposición, el mapa debe abarcar no solo el registro general. En él aparecen zonas, stands, escáneres y distintos propietarios de datos. Cuantas más fuentes haya, más importante será un source_system unificado, la versión del esquema y el registro de entradas rechazadas.

Es útil conservar el valor original junto al transformado, si las reglas de minimización lo permiten. Así se puede analizar un estado controvertido sin volver a consultar al recinto. El plazo de conservación de este rastro técnico lo determina el cliente.

Minimización de datos y consentimientos

El formulario y el intercambio deben recoger el conjunto mínimo necesario para el fin declarado. Cada campo adicional aumenta el volumen de verificación, el número de errores y la carga jurídica. El W3C WAI recomienda preguntar solo lo necesario para completar el proceso, así como ofrecer etiquetas, instrucciones y mensajes de error claros.

Utilizamos un filtro sencillo de campos:

1. ¿Qué tarea resuelve el campo en el evento o en el CRM?
2. ¿Quién es el propietario del valor?
3. ¿Qué acción se derivará tras su obtención?
4. ¿Se necesita precisión ya en el registro?
5. ¿Se puede obtener el valor más adelante desde el sistema maestro?
6. ¿Qué ocurrirá si el participante no rellena el campo?

Un campo sin respuesta a las tres primeras preguntas normalmente se elimina. Por ejemplo, un perfil sectorial detallado puede ser útil para el programa, pero no conviene recogerlo si nadie utiliza la segmentación y los datos no influyen en el recorrido del participante.

El consentimiento y otra base del tratamiento se diseñan por finalidades. El Comité Europeo de Protección de Datos (EDPB), en su guía sobre el Reglamento General de Protección de Datos (GDPR), exige un consentimiento específico, informado e inequívoco, así como la posibilidad de demostrar cómo y cuándo se obtuvo. Este documento no sustituye la verificación jurídica rusa, pero aporta un principio útil: la participación en el evento y las comunicaciones de marketing posteriores no deben ocultarse en un único campo indistinguible.

Si el tratamiento se basa en el consentimiento, en el contrato de datos pueden ser necesarios:

• la finalidad;
• la versión del texto;
• la hora;
• la fuente de la interfaz;
• el resultado de la elección;
• el método para modificar o retirar el consentimiento en el sistema del cliente.

El servicio Google Customer Match muestra otro límite más. La plataforma publicitaria trabaja con los datos online y offline propios de la empresa y, para las cargas de datos de usuarios del Espacio Económico Europeo procedentes de socios, exige señales de consentimiento. La transferencia operativa del registro al CRM no implica por sí misma la autorización para cualquier activación publicitaria. Esta finalidad, la composición de los campos y la base las acuerda el cliente por separado.

¿Cómo evitar crear duplicados?

La deduplicación implica buscar un registro similar y decidir por separado qué hacer con él. Una coincidencia exacta de un ID externo estable puede procesarse automáticamente. Una coincidencia probable por nombre, empresa, email o teléfono requiere reglas, prioridades y, en ocasiones, una revisión manual. Antes del lanzamiento, el equipo define qué indicios se consideran exactos y cuáles solo envían el registro a revisión.

Salesforce separa las reglas de búsqueda de coincidencias (matching rules) y las reglas de gestión de duplicados (duplicate rules). Las primeras encuentran candidatos; las segundas determinan la acción: advertir, permitir o bloquear la creación. Esta lógica resulta útil fuera de una plataforma concreta.

Orden de trabajo:

1. Buscar el registro por external_person_id, si ya se conoce.
2. Comprobar el email normalizado exacto, si la política del cliente lo admite como clave de búsqueda.
3. Comprobar otros identificadores confirmados.
4. Generar candidatos por la combinación de indicios más débiles.
5. No fusionar automáticamente ante un resultado ambiguo.
6. Crear un nuevo registro maestro solo tras superar las reglas.
7. Vincular a él el nuevo registro o la nueva actividad, sin sobrescribir el historial.

La normalización se realiza de forma idéntica en el emisor y en el receptor. El teléfono se lleva a un formato acordado. El email se limpia de espacios y se comprueba según la regla de mayúsculas y minúsculas adoptada. El nombre de la empresa no debe usarse como única clave: las variantes de escritura y la estructura del grupo de empresas generan falsas coincidencias.

Una tarea aparte es la idempotencia, es decir, el reenvío seguro. Si la red se interrumpió después de la escritura, el emisor puede no conocer el resultado y repetir la solicitud. Un mismo registration_id, attendance_id o activity_id debe actualizar o confirmar el objeto existente, no crear un segundo.

Compruebe al menos cuatro casos:

Un registro maestro no significa una sola fila para todo. El maestro se refiere a la persona. Los registros, las asistencias y las actividades siguen siendo un historial aparte en torno a ella.

Responsables del envío, la recepción y los errores

El intercambio debe tener dos responsables designados: uno por parte del emisor y otro por parte del receptor. El primero responde por la integridad, el formato y el reenvío. El segundo, por el esquema del CRM, las reglas de aceptación, las relaciones y la lectura de control del registro. Sin este par, los equipos no saben quién corrige un error y quién confirma la recepción repetida.

La distribución puede fijarse así:

Se necesita un registro de errores con record_id, hora, versión del esquema, código de motivo y estado del reprocesamiento. Los datos personales en el registro se reducen al mínimo necesario. Al equipo le suele bastar con el ID técnico y una referencia al registro protegido.

En Aventura no implementamos el CRM del cliente ni definimos reglas dentro de él. Podemos describir las fuentes de datos del evento, acordar el formato de transmisión con el equipo especializado y comprobar que el escenario del recinto aporta los datos esperados. El responsable del modelo de recepción y de los derechos de acceso es el propietario del CRM del cliente.

¿Cómo comprobar el recorrido hasta la apertura del registro?

La prueba de extremo a extremo comienza con la acción del participante y termina con la lectura de control del registro en el CRM. Entre estos puntos, el equipo verifica por separado el origen, la transmisión y el procesamiento de los datos. La respuesta de la interfaz de programación o la aparición de un archivo en la carpeta solo confirma un paso intermedio. El registro se considera aceptado cuando en el sistema de destino se han verificado los campos clave, las relaciones, el propietario y el estado.

Prepare un evento de prueba independiente y un conjunto de registros sintéticos sin datos de personas reales. Después, ejecute los escenarios en orden.

1. Registro normal. Rellene el formulario, guarde el contexto UTM y compruebe el registration ID.
2. Persona conocida. Repita el registro con el person ID de un registro maestro de prueba existente.
3. Check-in. Escanee una acreditación de prueba y compruebe el attendance ID independiente.
4. Sesión o stand. Cree activity_id con event_id, tipo de acción, hora occurred_at y sistema de origen source_system.
5. Reunión. Transmita la hora, el propietario, el resultado y las relaciones con la persona y la empresa.
6. Reenvío. Envíe de nuevo el mismo identificador de registro y asegúrese de que no se crea un duplicado.
7. Error de catálogo. Transmita un estado desconocido y compruebe que el sistema rechazó el registro según la regla acordada.
8. Campo obligatorio omitido. Asegúrese de que la causa del error es comprensible para el remitente.
9. Lectura de control. Lea el registro del CRM y compare los valores, las relaciones y el propietario con lo esperado.
10. Corrección. Repita el registro tras la corrección sin perder el ID original ni el historial.

Para cada comprobación, guarde el resultado esperado y el real. Toda discrepancia debe tener un propietario, un plazo de corrección y una nueva ejecución del mismo escenario.

La prueba de carga del registro y del check-in resuelve una tarea paralela: si el circuito soportará el flujo previsto y qué ocurrirá en caso de fallo. Sus escenarios se recogen en el artículo sobre el ensayo de carga del registro y el check-in. Aquí el criterio de aceptación se limita al sentido y la integridad de un único registro en todo el recorrido.

Tras la prueba, ambas partes firman la versión del mapa de campos, el diccionario de estados y los resultados de las pruebas. Cualquier cambio en uno de estos documentos exige volver a comprobar los escenarios afectados.

Lista de verificación de preparación para el lanzamiento

El circuito está listo cuando los participantes del proyecto entienden de la misma manera las entidades, los campos y el criterio de registro aceptado. Esta lista de verificación se puede utilizar en la sesión conjunta final antes de abrir el formulario. No repite todo el mapa de campos, sino que fija las decisiones sin las cuales al equipo le resulta difícil controlar los duplicados y los estados controvertidos.

1. El evento tiene un event_id estable, y el registro, la visita y la actividad tienen identificadores propios.
2. La persona, la empresa, el registro, la visita y la actividad están separados por su significado.
3. Los estados tienen códigos, definiciones, responsables y versión del diccionario.
4. El mapa de campos fija los tipos, la obligatoriedad, las transformaciones, la campaña y los errores.
5. Las reglas de búsqueda de coincidencias, de reenvío y de tratamiento de duplicados se acuerdan por separado.
6. Se nombran los responsables del envío, la recepción y la corrección de errores.
7. La prueba de extremo a extremo incluye un registro normal, una persona conocida, un duplicado, un error y una lectura de control.
8. El responsable de la CRM confirmó las relaciones y la versión del esquema antes de abrir el registro.

Esta preparación no sustituye el trabajo posterior con los datos. La relación general de los eventos con el sistema comercial se analiza en el material sobre event-led growth y el embudo. El orden de transmisión de las acciones a marketing y ventas después del evento se expone en el artículo sobre SLA follow-up. El circuito actual termina en el momento en que la CRM ha aceptado un registro verificable con las relaciones y el responsable correctos.

En Aventura podemos reunir los puntos de datos del evento en un único pliego de condiciones técnico, recorrer el camino del invitado y realizar una prueba conjunta con el equipo del cliente. Solicite una conversación sobre el proyecto y un presupuesto preliminar. En la reunión definiremos las fuentes de datos del evento, los límites de nuestro trabajo y los participantes en la aceptación por parte del CRM.

Fuentes

• European Data Protection Board - Guidelines 05/2020 on consent
• CloudEvents specification 1.0.2
• HubSpot - CRM Properties API Guide
• HubSpot - Meetings API Guide
• Google Analytics - URL builders and UTM parameters
• IETF - RFC 9562: Universally Unique IDentifiers
• Microsoft Learn - View and manage event attendance
• Salesforce Trailhead - Resolve and Prevent Duplicate Data
• Adobe Experience Platform - XDM ExperienceEvent class
• W3C WAI - Forms Tutorial
• Google Ads - About Customer Match