Por lo general, cuando un líder de marketing nos plantea su frustración con la attribution, la conversación empieza por los dashboards. El dashboard de Looker dice que el inbound vino de orgánico. El dashboard de HubSpot dice que el inbound vino de referral. Ambos son técnicamente correctos en su respectiva capa, y el hecho de que no coincidan no es un problema de herramientas, es un problema de unión de sesiones. Las UTM viven en sesiones anónimas, los contactos viven en HubSpot y nadie es responsable del join intermedio. Esa es la brecha de la que trata este artículo.
Por qué importa ahora
En la mayoría de las organizaciones SaaS B2B, ventas y marketing siguen operando con datos desconectados, y ese es el modo de fallo que subyace a casi todas las discusiones sobre attribution. El artículo de Harvard Business Review sobre cómo vincular ventas y marketing lo planteó con claridad: las empresas se ven limitadas por datos de clientes aislados en silos, y un hub digital de clientes, un identificador, un registro, un recorrido, es la solución estructural (hbr.org). Para los equipos SaaS que operan un warehouse junto a HubSpot, la unión entre sesión y contacto es el punto donde ese hub se sostiene o deja de ser confiable sin hacer ruido.
Por qué no basta con capturar la UTM en el envío del formulario
El patrón estándar consiste en capturar los últimos parámetros UTM en el envío del formulario y escribirlos en campos ocultos del contacto: utm_source, utm_medium, utm_campaign. HubSpot lo hace de forma nativa y funciona para el caso más simple: un visitante llega a una URL con UTM, hace clic en un CTA, completa un formulario y se convierte en contacto. Una sesión, un contacto, un conjunto de UTM.
El caso que casi nunca se cumple: un visitante abre el email con UTM el primer día, navega por tres páginas y se va. Dos días después vuelve desde una búsqueda en Google, lee los precios y se va otra vez. Dos días más tarde pega la URL de la página de inicio en el navegador y completa el formulario de demo. La captura de UTM del envío del formulario escribe direct / none en el contacto. La tabla de sesiones del warehouse, en cambio, tiene las tres sesiones y la UTM de origen email que realmente impulsó el recorrido. Dos sistemas, dos verdades, y gana la del dashboard que abra primero el CFO.
El patrón de la propiedad de session token
La solución no es una herramienta de attribution más grande. Es una única propiedad en el registro del contacto, llamémosla session_token, que guarda el mismo identificador que el front-end escribe en su log de sesiones. En la primera carga de página, el front-end genera el token (un UUID, una cookie con hash, cualquier valor estable entre sesiones), lo guarda en una cookie propia (first-party) y etiqueta con él cada evento de página. Cuando el visitante completa un formulario, el mismo token se escribe en un campo oculto y llega al contacto.
A partir de ahí, la attribution deja de ser una suposición y se convierte en un join. El contacto tiene un token; la tabla de sesiones tiene el historial completo de UTM asociado a ese token, incluidas todas las sesiones anónimas previas del mismo navegador. Las propiedades de UTM a nivel de contacto en HubSpot pasan a ser el resumen; el join en el warehouse es la fuente de verdad.
Qué vive dónde
En el contacto: session_token, first_session_utm_source, first_session_utm_medium, first_session_utm_campaign, last_session_utm_source. Son campos de resumen, rellenados por el workflow en el envío del formulario, para que el SDR pueda leer la ficha del contacto sin abrir el warehouse.
Dentro del warehouse: la tabla completa de sesiones, con clave session_token, una fila por página vista con todo el contexto de UTM. El registro del contacto apunta a la tabla de sesiones; la tabla de sesiones no necesita conocer al contacto hasta que se ejecuta el join.
Workflow de backfill: unir sesiones anónimas con contactos convertidos
El envío del formulario captura el session token actual. Por sí solo, no captura las sesiones anónimas previas del mismo navegador. Para eso sirve el workflow de backfill.
La cookie first-party que guarda el token persiste entre sesiones: el mismo UUID en cada visita hasta que la cookie expira o el usuario la borra. La tabla de sesiones del warehouse hereda ese token, de modo que todas las sesiones anónimas de ese navegador ya están asociadas a un único identificador. El registro del contacto solo conoce el token en el momento del envío del formulario. El backfill es el momento en que se recorre ese token hacia atrás en la tabla de sesiones y se incorporan todas las sesiones previas a la vista de attribution del contacto.
En la práctica es un job programado, no un workflow en tiempo real. Cada noche, una consulta de Looker encuentra los contactos nuevos creados en las últimas 24 horas, hace el join por session_token y escribe de vuelta en HubSpot, mediante la API, las UTM consolidadas de primer contacto y de contacto convertidor. El tiempo real es deseable; el nocturno es la versión que realmente se lanza y se mantiene funcionando.
El problema de los dominios de email gratuitos
Alrededor del 40 % de los contactos inbound en la mayoría de los sitios SaaS B2B con los que trabajamos llega con un dominio de email gratuito: gmail, outlook, yahoo. Algunos son compradores reales que usan una dirección personal; muchos son ruido. En cualquier caso, un contacto con email personal es más difícil de vincular a una empresa, y el session token solo ayuda si el navegador y la cookie eran realmente los del comprador. Un portátil compartido, cookies borradas o un envío de formulario en incógnito rompen la cadena del token y el backfill produce una imagen parcial.
No hay una solución limpia a nivel de contacto. Lo que funciona es aceptar la verdad direccional: los contactos con dominio de email gratuito se resuelven bien aproximadamente el 60 % de las veces, y los de dominio de email corporativo cerca del 90 %; el reporte agregado se mantiene honesto si se segmenta por tipo de email. El dashboard que finge que todos los contactos tienen attribution completa es el que le miente en silencio al CMO.
Por un lado, por otro lado
Por un lado, el join por session token da crédito a la campaña de email que realmente impulsó el recorrido, incluso cuando el envío del formulario convertidor dice direct / none. Por otro lado, hay que tomarlo con cautela a nivel de contacto, especialmente en el extremo de los dominios de email gratuitos. En términos direccionales, el join es la solución que se suponía que daría la herramienta de attribution más grande. A nivel de contacto individual, es una señal entre varias. Ambas cosas pueden ser ciertas.
Un patrón visto en el campo
Un equipo SaaS B2B de la región DACH, en Serie A, vino a vernos el trimestre pasado con una queja conocida: el dashboard del warehouse decía que paid social era su mejor canal inbound, mientras que el dashboard de HubSpot a nivel de contacto decía que paid social apenas se registraba. El equipo llevaba dos meses discutiendo qué número poner en el deck del board. El problema real era que el front-end escribía un ID de sesión en el warehouse pero nunca en el contacto, así que HubSpot solo veía las UTM de la sesión convertidora: las cuales, dado el recorrido típico de lectura y regreso del comprador, casi siempre caían en directo u orgánico. Añadimos una propiedad session_token, conectamos el formulario para capturarla, ejecutamos un backfill nocturno sobre el historial de sesiones existente y, en menos de tres semanas, los dashboards empezaron a contar la misma historia: paid social impulsaba el descubrimiento y directo cerraba.
Resolución: el playbook de unión de sesiones
- Genere un session token estable en el front-end. Un UUID por navegador, persistido en una cookie first-party y adjunto a cada evento de página que fluye hacia Looker.
- Añada una propiedad de contacto
session_tokenen HubSpot. Texto de una sola línea, oculta en la ficha del contacto si lo desea, pero rellenada en cada envío de formulario mediante un campo oculto. - Escriba el token en el formulario. El campo oculto del formulario lee la cookie en el momento del envío y escribe el token en el registro del contacto. Es la única pieza que tiene que funcionar en tiempo real.
- Construya la consulta de backfill nocturna. Un job de Looker que hace el join de los contactos nuevos por session_token, consolida las UTM de primer contacto y de contacto convertidor desde la tabla de sesiones y envía el resultado de vuelta a HubSpot mediante la API.
- Segmente sus reportes por tipo de email. Los contactos con dominio de email gratuito tienen una pestaña aparte en el dashboard de attribution. El agregado es honesto solo si deja que el segmento ruidoso sea visiblemente ruidoso.
- Concilie los dos dashboards cada mes. Looker y HubSpot no coincidirán exactamente, porque resumen cosas distintas, pero la historia direccional debería coincidir. Cuando no lo hace, la unión de sesiones se rompió antes que los datos.
- Documente el join. Una nota de una página sobre qué propiedad vive dónde, qué job se ejecuta cuándo y qué revisar primero cuando un número parece incorrecto. El patrón del session token es el tipo de infraestructura que se rompe en silencio si nadie sabe que existe.
Dónde entra Checkpoint
La mayor parte del trabajo de attribution que hacemos en Checkpoint no consiste en construir un modelo nuevo, sino en arreglar la unión de sesiones que el modelo anterior daba por hecha. Si su equipo de marketing operations está lidiando con dos dashboards que no coinciden, el join casi siempre es la capa rota, y una propiedad más una consulta nocturna casi siempre es la solución. Lo combinamos con el trabajo más amplio de revenue operations sobre para qué sirve realmente la attribution en su funnel, y con el trabajo de implementación de HubSpot que conecta las propiedades, los formularios y los workflows para que la unión sobreviva al próximo cambio en el portal. Por eso el mejor punto de partida no es la herramienta de attribution, sino el registro del contacto.
Fuentes
- Sinha, Shastri, Lorimer, sobre cómo vincular ventas y marketing a través de datos de clientes aislados en silos, en Harvard Business Review, noviembre-diciembre de 2024. hbr.org
- Zoltners, Sinha, Lorimer, sobre la planificación ágil de ventas y los ciclos de adaptación continua, en Harvard Business Review, 27 de septiembre de 2021. hbr.org
Noah Charak