DecisaDocumentación
Volver a la documentación

Documentación · Metodología

Cómo Decisa atribuye los ingresos.

La atribución parece sencilla hasta que tienes que defender un número ante una junta directiva. Esta página expone el cálculo exacto para que puedas hacerlo, incluidas las partes que aún hacemos mal.

01

La cadena canónica

Cada evento de ingresos en Decisa recorre la misma cadena:

UtmLink  →  Click  →  Session  →  Order  →  AttributedConversion

UtmLink son metadatos que te pertenecen. Click lo captura pixel.js cuando un visitante llega. Session une varios clics bajo una sola cookie propia dcs_vid. Order se crea cuando tu backend hace un POST a /v1/conversions. AttributedConversion es la fila de unión que registra qué clic(s) reciben el crédito por qué pedido, bajo qué modelo y en qué momento.

02

Reglas de ventana y deduplicación

  • Ventana de clic → conversión: 30 días por defecto. Configurable por workspace.
  • Identidad del visitante: cookie propia dcs_vid, vencimiento renovable de 12 meses, actualizada en cada clic reconocido.
  • Deduplicación de pedidos: unicidad en (workspace_id, external_id). Los reenvíos del mismo webhook nunca crean un pedido duplicado.
  • Deduplicación de conversiones (para el pushback de CAPI): unicidad de event_id por plataforma + workspace. Cada pusher revisa el registro saliente antes de enviar.

03

Modelos de atribución

Los modelos son entidades de primera clase: cambiar de modelo no reescribe la historia. La instantánea de atribución anterior sigue siendo consultable para garantizar la reproducibilidad.

Último clic (por defecto)

El 100 % de los ingresos del pedido se asigna al clic más reciente que califique dentro de la ventana. Esto es lo que Meta y Google muestran por defecto. Empezamos aquí porque es el número más fácil de conciliar para un equipo de finanzas.

Lineal

Los ingresos se dividen en partes iguales entre cada clic que califique en la sesión. Útil para descubrir qué fuentes de la parte alta del embudo cargan en silencio con el trabajo del héroe del último clic.

Basado en posición (40/20/40)

El primer clic recibe el 40 %, el último clic recibe el 40 %, y los clics intermedios se reparten el 20 % restante en partes iguales. Estándar para recorridos donde tanto la introducción como el momento de decisión importan.

Decaimiento temporal (vida media de 7 días)

El peso por clic = 2^(-age_days / 7), normalizado para que los créditos entre puntos de contacto sumen 1. Un clic 7 días antes de la conversión tiene la mitad del peso de un clic en el día de la conversión. Bueno para ventanas de consideración cortas; oculta las inversiones de marca/relaciones públicas de combustión lenta cuyo impacto se acumula durante semanas.

04

Versionado

Cada fila de AttributedConversion lleva el nombre y la versión del modelo de atribución con el que se calculó. Si alguna vez cambiamos el cálculo (lo haremos), las filas más antiguas permanecen intactas y se escribe una nueva versión junto a ellas. Puedes fijar los reportes a una versión del modelo cuando defiendas un número ante la dirección seis meses después.

05

Lo que deliberadamente no hacemos

  • No hacemos fingerprinting de visitantes. Sin hashing de canvas, sin sondeo de fuentes, sin emparejamiento de IP+UA. Solo dcs_vid.
  • No almacenamos correos electrónicos sin procesar ni IPs completas. A los correos se les aplica hash SHA256; a las IPs se les aplica hash con un salt por workspace.
  • No inventamos atribución para clics que nunca vimos. Si el pixel no estaba instalado cuando ocurrió un clic, ese pedido se marca como sin atribuir. Nunca se reasigna en silencio a otra fuente.
  • No comparamos contra las conversiones reportadas por las plataformas. Nuestro número es independiente. Mostramos la brecha; nunca la disimulamos.

06

Limitaciones conocidas

  • Los navegadores integrados en apps de iOS borran las cookies de forma agresiva. Algunos clics pierden continuidad al pasar de la app al navegador. Estamos midiendo la brecha; todavía no la cerramos.
  • Los recorridos entre dispositivos requieren que el usuario se identifique en ambos dispositivos (p. ej. un checkout con sesión iniciada). Sin eso, las dos sesiones permanecen independientes.
  • Los correos renderizados en el servidor con parámetros utm no se unen actualmente al grafo de sesiones. Próximamente en una versión posterior.

¿Quieres ver la cadena en acción con una instalación funcionando? Comienza en Primeros pasos o lee la referencia de la API.