Lo primero que sorprende al montar un modelo de atribución propio es dónde se va el tiempo. No se va en Markov. Se va en resolver quién es el usuario, en decidir qué es un nodo, en normalizar lo que cada plataforma llama “conversión” y en que negocio se crea el resultado. El reto no va de código; va de lógica de negocio. Esto es lo que hace falta, en el orden en que lo hacemos, con lo que aprendimos montándolo en uno de nuestros clientes.
Requisitos mínimos, sin los cuales ni empezar
- Una recogida de datos de primera parte, sana y completa. Un data collect holístico: cada conversión con usuario y fuente de tráfico. Si esto falla, todo lo demás amplifica el fallo.
- Un data warehouse donde vivan la analítica web y las fuentes publicitarias, o al menos acceso a ellas. Nosotros usamos Google Cloud con el export de GA4 a BigQuery; se podría montar en cualquier otro.
- Un entorno first party que maximice el control sobre la identidad del usuario: qué identificadores hay, cuánto duran, cómo se relacionan.
- Una implementación de privacidad sólida. No por cumplir: porque el consentimiento es la principal fuente de agujeros en las cadenas, y hay que saber exactamente dónde están.
Si falta cualquiera de los cuatro, el proyecto de atribución es en realidad un proyecto de recogida de datos que todavía no se ha hecho.
1. La ingesta antes que el modelo
Asegurar la recogida es previo a planificar ningún modelo matemático. En ese cliente, el modelo de datos era bueno y la navegación estaba bien entendida, pero hubo que corregir problemas de consentimiento que dejaban interacciones sin identidad ni fuente. Cada una de esas interacciones es un punto de contacto que no se puede colgar de ninguna cadena.
El error más caro que vemos está aquí y no parece de data science: un etiquetado UTM incoherente. Se propaga hacia arriba y toda la estadística de encima queda inválida sin que nadie lo note, porque los números siguen saliendo.
2. Identidad: usuarios, no personas
La inmensa mayoría de la navegación ocurre sin identificación: sin user_id, sin email, sin login. Así que conviene fijar el vocabulario desde el principio: cuando el modelo dice “usuario” habla del usuario anónimo de la analítica web, que puede estar representado por varios dispositivos y por varios estados de privacidad a lo largo de su relación con la web.
Se trabaja con identificadores de primera parte: el client_id, el identificador de sesión y los que uno mismo formule. Y se asume el límite: las visitas puntuales sin señal de aceptación son muy difíciles de reconciliar con el resto de la cadena del mismo usuario, porque sus identificadores pueden diferir. No es un problema a resolver; es un problema a medir y a acotar.
3. La tabla de puntos de contacto
Explotar el export de GA4 en bruto no sirve. Hace falta una capa de lógica encima, y en la práctica son varias: distintos estadios de la información cruda en vistas normalizadas que permitan acceder al dato de forma lógica y repetible. Sobre esas capas se construyen los puntos de contacto, estableciendo a lo largo del tiempo tres cosas por usuario:
- su identidad (qué identificadores se consolidan en el mismo usuario);
- los nodos de fuente de tráfico con los que interactúa;
- qué partes del activo digital consume, porque cuándo, cómo y cuánto se relaciona con la web influye después en la ponderación del crédito.
Esta tabla es el 80 % del trabajo y es la parte reutilizable: el reparto que se ponga encima puede cambiar; la tabla, no.
4. Qué es un nodo
Decisión de diseño que condiciona todo lo demás: los nodos son campañas, no clics. El modelo es heurístico y mira la actividad publicitaria en global, así que no necesita click IDs. Cada canal se agrupa en la unidad más pequeña que tenga sentido —idealmente la campaña— y los canales con menos granularidad (orgánico, directo, email, offline) se tratan como nodos más grandes.
Esto resuelve el problema de los canales que no dejan identificador, pero no el de los que no dejan ni visita: hay formatos tan upper funnel que no generan un nodo aguas abajo del que colgar nada. Para ellos hacen falta mecanismos adicionales, y son de los que más cuestan.
5. La ventana no la fija la plataforma
La ventana de atribución no es una línea roja que deban poner las plataformas ni el equipo que desarrolla. Sale del conocimiento del negocio: cuánto dura el ciclo desde que alguien considera el producto hasta que lo adquiere. En un negocio de suscripción ese ciclo es distinto para el cliente que vuelve (corto) y para el nuevo (largo, con comparativa); allí fijamos un máximo de 30 días. En otro negocio será otro número, y se decide con quien conoce el ciclo comercial, no mirando la configuración por defecto de Google Ads.
6. La capa publicitaria: normalizar antes de sumar
Hasta aquí el modelo solo ve lo que ve la analítica. Para integrar la otra mitad se lee el dato de conversiones de cada plataforma y se pasa por una lógica normalizada donde se decide, para cada una:
- qué eventos se leen como conversión;
- en qué ventana;
- de qué naturaleza: post-clic o post-view.
El resultado entra en el modelo como un multiplicador que realimenta las cadenas con la visión publicitaria. Es lo que permite que el reparto final integre las dos versiones de la realidad en vez de elegir una.
Dos avisos de experiencia. Primero: Google Ads y Meta se integran rápido; las plataformas menores, con menos inversión o menos penetración, cuestan mucho más de lo previsto, y en la primera versión es razonable dejar fuera alguna (nosotros dejamos la programática, de inversión puntual, para un evolutivo). Segundo: la configuración de conversiones en plataforma no la controla el equipo de analítica. La hacen los equipos de compra de medios con criterio de activación, no de medición. El modelo tiene que asumirlo como input externo y vigilarlo.
7. El reparto se elige con negocio
Construir los modelos clásicos —lineal, time-decay, posicional, first y last click, Markov— sobre los datos reales y revisarlos con el equipo de negocio es la fase de discovery, y merece la pena hacerla entera antes de decidir. Cada uno cuenta una versión distinta; lo que enseña es qué canales se mueven mucho al cambiar de regla y cuáles no. En nuestro caso, Markov era lo que más se acercaba a la realidad, porque lo relevante no era la posición en la cadena sino su composición y duración, y sobre eso montamos algo propio. Cómo se elige no es un tema matemático: es entender el ciclo comercial y alinearse con negocio. No hay respuesta cerrada; qué se mueve con cada modelo, sí se puede contar.
Y una precisión que conviene tener clara antes de presentar resultados: el modelo reparte crédito, no demuestra incrementalidad.
Sobre Consent Mode: solo dato observable
El modelo trabaja con dato real, observable y reportable. Dejamos fuera el dato modelado de Consent Mode, a sabiendas de que perdemos puntos de contacto. Para reporting compensa y lo defendemos; para alimentar un modelo estadístico es un producto de terceros cuyo funcionamiento no podemos auditar, y meterlo inflaría el volumen de usuarios con hits sin identidad ni fuente que solo añaden ruido. Reporting y advanced analytics merecen dato distinto. Lo que falta se compensa con estadística, no con dato que no se puede explicar.
Producción
Un servicio en Cloud Run consulta las fuentes y ejecuta el modelo en batch diario, a primera hora, en unos 30 segundos: construye las cadenas de los últimos seis meses y reescribe los últimos 30 días de conversiones para todos los nodos del periodo. No es tiempo real; es un modelo vivo.
El consumo importa tanto como el cálculo. El objetivo no era un informe de atribución aparte, sino que el dato fuera un input más del análisis diario: se cargó en los dashboards de Looker Studio que el cliente ya usaba, y se construyó además un reporte específico con dos lectores: marketing y negocio para los resultados, e ingeniería para auditar el comportamiento del propio modelo.
Coste: la infraestructura es despreciable, entra en el mantenimiento como cualquier otra cosa que corra en Google Cloud. El coste es el desarrollo, y no es pequeño: en ese cliente fueron seis semanas —una de discovery, tres de desarrollo hasta tener el modelo estable y validado con el último semestre, dos de productivización.
Qué se vigila cuando ya funciona
Que no se rompa nada no significa que no haya que mirar. Tres cosas:
- Que las fuentes sigan activas, íntegras y al día. Incluye que el negocio no añada plataformas nuevas sin que se integren: una fuente fuera del modelo invalida el reparto sin avisar.
- Que la configuración de conversiones en plataforma no cambie sin que lo sepas. Es input del modelo y no lo controlas tú.
- Que el data collect siga sano. No hay proyecto de advanced analytics sin una recogida sólida y mantenida de primera parte.
Cuándo no montarlo
Con inversión publicitaria moderada, un last click bien medido más la medición de las plataformas da una foto suficiente; el modelo propio se justifica cuando la inversión es alta o hay mucha actividad de encendido, apagado, inventarios nuevos y upper funnel. Y si la recogida no está limpia o no hay warehouse, el proyecto correcto es ese, todavía no este. El recorrido por los cuatro métodos ayuda a situarse.
Qué hacer mañana
- Cuenta cuántas conversiones del último mes no tienen fuente ni usuario. Ese número es tu techo antes de tocar ningún modelo.
- Escribe qué es un nodo para tu negocio y cuánto dura tu ciclo de consideración. Con quien lo sepa, no solo con analítica.
- Lista tus fuentes publicitarias y, para cada una, qué evento, qué ventana y qué naturaleza cuenta como conversión hoy. Lo que no puedas rellenar es lo que va a costar.
Si el dato está limpio y la pregunta es esta, así lo montamos y podemos hablarlo.