Founderz utiliza HubSpot Marketing Events para gestionar sus workshops online, centralizando la planificación y el registro de asistentes en una única fuente de la verdad. Sin embargo, existía una limitación crítica: no podían medir el impacto real de los eventos en revenue.
El problema no era de configuración, sino estructural. HubSpot gestiona los eventos como elementos operativos, pero no como unidades directamente vinculadas a generación de ingresos. Esto impide responder a una pregunta clave para cualquier equipo de Revenue:
¿Qué eventos están generando negocio real?
Además, el comportamiento de los usuarios añadía complejidad. Un mismo contacto podía registrarse en múltiples webinars a lo largo del tiempo, a través de distintos canales, y cerrar una venta semanas después. Sin una visión completa del recorrido, cualquier modelo de atribución resultaba incompleto o directamente engañoso.
A esto se sumaba otra limitación: la falta de visibilidad sobre el origen de cada registro. Sin capturar correctamente los parámetros de adquisición en cada inscripción, BASOLS no podía identificar qué canales estaban impulsando los registros de mayor calidad.
El modelo de atribución estándar de HubSpot no puede responder estas preguntas con precisión porque no tiene visibilidad sobre el historial completo de registros de un contacto en eventos, ni sobre los parámetros de captación de cada uno de esos registros.
Construimos una aplicación en Firebase que actúa como intermediario entre HubSpot y BigQuery. Cada vez que un contacto se registra en un evento, HubSpot envía a esta aplicación todos los datos del registro: identificador del contacto, identificador del evento, timestamp, y la totalidad de los parámetros UTM asociados a ese registro — source, medium, campaign, content, term.
Esto resuelve el primer problema: tener un registro exhaustivo, cronológico y con contexto de captación de cada interacción de cada contacto con cada webinar. Algo que HubSpot, por diseño, no almacena de esta forma.
Firebase inserta cada registro en una base de datos en GCP. En Bigquery construimos una tabla de hechos que contiene, para cada contacto, el historial completo de sus inscripciones a webinars, ordenadas cronológicamente, con el canal de captación de cada una.
Sobre esta tabla construimos el modelo de atribución. Las reglas se definen en SQL, son auditables, y pueden modificarse sin tocar los sistemas operativos.
Con el historial completo disponible, diseñamos las reglas de atribución. La lógica central: cuando un contacto genera un deal cerrado, se identifica el último webinar en el que se registró dentro de una ventana temporal previa al cierre. Ese webinar recibe la atribución del revenue.
Esta regla es intencionalmente simple. No porque no sea posible construir algo más sofisticado, sino porque un modelo que el equipo no puede explicar y auditar no genera confianza, y sin confianza no cambia el comportamiento de decisión.
Los resultados del modelo se visualizan en cuatro vistas en Microsoft Power BI, cada una orientada a una pregunta de negocio específica: rentabilidad por workshop, rendimiento por canal de captación, tasa de conversión por tipo de tráfico, y ROI comparado por unidad económica.
La implementación de esta solución no produce un único resultado puntual. Produce un conjunto de capacidades analíticas permanentes que cambian cómo el equipo toma decisiones sobre cada workshop.