Seguimiento de conversiones en enlaces cortos: identificador de clic, ventanas y eventos de servidor

Todo informe de enlaces tiene un punto en el que se detiene de forma natural, y para casi todos los equipos ese punto es el clic. El panel dice que un enlace se abrió cuatro mil veces el mes pasado, desglosado por país, dispositivo, navegador y fuente, y ahí termina el análisis. Pero cuatro mil clics describen lo que gastaste, no lo que ganaste. Es la mitad barata del embudo, y es además la mitad que mejor queda en una captura de pantalla.

El seguimiento de conversiones cierra ese hueco llevando un identificador desde el momento de la redirección hasta el sistema que acabe registrando el pedido, y devolviéndolo después. La idea es fácil de describir y fácil de estropear de maneras que solo salen a la luz meses más tarde, en forma de informes de ingresos que no cuadran con las facturas. Este artículo cubre el identificador, la ventana de atribución y por qué es una decisión de negocio, la diferencia entre un evento de servidor y uno de navegador, por qué el dinero es un entero, cómo se tratan los duplicados y qué hacer cuando la conversión ocurre en un sistema que no controlas.

Un clic es un coste, no un resultado

Los informes que se quedan en el clic sobreviven porque el clic es la medición fácil. La redirección ocurre en una infraestructura que controlas, así que contarla no exige la colaboración de nadie, mientras que todo lo que viene después ocurre en otra parte. Nuestra guía sobre cómo se miden realmente los clics de un enlace detalla qué puede contener un solo evento de clic, y la versión corta es que sabe que el clic ocurrió y nada de lo que vino detrás.

Esa limitación tiene consecuencias reales. Dos emplazamientos pueden producir volúmenes de clics idénticos mientras uno manda compradores y el otro manda gente que rebota en tres segundos. Un desglose por país que impresiona en clics puede invertirse en ingresos. Las pruebas A/B que se deciden por la tasa de clic eligen una y otra vez la variante con el titular más agresivo y la peor finalización del checkout. Mientras los ingresos no cuelguen de esas mismas dimensiones, cada uno de esos juicios es una suposición disfrazada de métrica.

Colgarlos de ahí requiere una sola cosa: un valor que sobreviva al viaje entre la redirección y el pedido.

El identificador es todo el diseño

En cada redirección el worker emite un token y hace dos cosas con él. Lo añade a la dirección de destino bajo el nombre de parámetro que tú elijas, lp_cid por defecto, y escribe el mismo valor en una cookie propia de tu dominio de redirección, válida durante 90 días.

Existen dos copias porque cualquiera de las dos puede perderse. Hay destinos que eliminan los parámetros de consulta, a veces a propósito para dejar URL limpias, a veces como efecto secundario de una redirección suya. Y un visitante que hace clic hoy y vuelve tres días después escribiendo la dirección ya no tiene ningún parámetro, pero sigue llevando la cookie. Ninguna de las dos copias es fiable por sí sola; juntas cubren casi todos los caminos realistas hasta una compra.

Que la cookie sea propia no es un tecnicismo. La pone tu propio dominio de redirección, el dominio al que el visitante navegó de verdad, que es justo la categoría de cookie que los navegadores no han estado retirando. Por eso un dominio propio deja de ser una preferencia de marca y pasa a ser infraestructura de medición: en un dominio compartido del proveedor, la cookie es del proveedor.

Qué lleva dentro el token

El token va firmado, y la firma cubre más que el clic. Los identificadores de espacio de trabajo y de partner forman parte del payload firmado, así que un token emitido en el enlace de un cliente se rechaza en el espacio de trabajo de otro exactamente igual que una falsificación. Para quien gestiona enlaces de varios clientes, eso mantiene los ingresos de un cliente fuera del informe de otro por construcción, y no por un filtro que alguien se acordó de aplicar.

Lo que el token contiene es deliberadamente escaso: el momento del clic, el enlace, la variante, el país, la clase de dispositivo, la fuente de tráfico y una marca de tráfico sospechoso. Ningún dato personal. Esa lista es además lo que hace útil la columna de ingresos, porque cada uno de esos campos se convierte en una dimensión por la que puedes desglosar los ingresos en analíticas sin un segundo cruce contra nada.

El nombre del parámetro y el interruptor de activación viven en los ajustes del espacio de trabajo, y cambiar cualquiera de los dos reescribe al instante la configuración cacheada de todos los enlaces. Una consecuencia que conviene prever: cuando un plan no incluye conversiones, el redirector deja de emitir identificadores por completo, y activarlas más tarde no crea de forma retroactiva identificadores para los clics que ya ocurrieron.

La ventana de atribución es una decisión de negocio

La ventana es la antigüedad máxima que puede tener un clic para seguir llevándose el crédito de una conversión. Es un ajuste por espacio de trabajo, y es el único número de todo esto que conviene discutir en lugar de aceptar por defecto.

Si la pones demasiado corta, tiras ingresos que produjiste de verdad. Si la pones larguísima, acreditas a los enlaces compras que habrían ocurrido igualmente, y eso es peor que inútil porque se equivoca con aplomo. Elígela midiendo el hueco entre el primer contacto y la compra en pedidos que ya puedes rastrear: una compra impulsiva se cierra en minutos, una compra de consumo meditada tarda días, una compra de empresa con un paso de aprobación tarda semanas.

El modo de fallo que este diseño evita es el rechazo silencioso. Una conversión que llega fuera de la ventana se rechaza con attribution_expired, un código distinto de invalid_click_id. Esas dos situaciones piden arreglos completamente distintos, y una integración que reciba un mismo error genérico para las dos se pasará una semana depurando lo que no era. Registra el código, cuenta las dos por separado y trata una tasa creciente de attribution_expired como la señal de que tu ventana ya no encaja con tu ciclo de venta.

Los dos caminos de entrada tienen además techos distintos. La cookie vive 90 días, así que un reporte desde el navegador que dependa de ella no puede sobrevivir a ese límite. Un reporte desde el servidor guarda el identificador por su cuenta y solo lo acota la ventana del espacio de trabajo.

Dos formas de entrar, un solo conjunto de reglas

Los dos caminos pasan por el mismo servicio, así que la ventana, la deduplicación y el envío hacia fuera se comportan igual. Lo que cambia es a qué sobrevive cada camino y qué te exige cada uno.

El evento de servidor

Tu backend envía el identificador con un objetivo, un identificador de pedido, un importe y una moneda.

curl -X POST https://api.linkprofit.com/v1/conversions \
  -H "Authorization: Bearer lp_live_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-10241" \
  -d '{
    "click_id": "1.eyJ1aWQiOiJ...",
    "goal": "purchase",
    "order_id": "10241",
    "amount_cents": 4999,
    "currency": "usd"
  }'

La clave necesita el permiso conversions:write, lo que significa que este camino te cuesta algo que el del navegador no: una credencial que emitir, guardar y rotar. Mira la autenticación de la API para saber cómo se gestionan las claves con permisos acotados, y mantén esta clave del lado del servidor — una clave con acceso de escritura a tus datos de ingresos no pinta nada en una página.

Lo que obtienes a cambio es un reporte que ningún bloqueador de anuncios, bloqueador de scripts, ajuste de protección contra el rastreo ni error de JavaScript puede suprimir. Se dispara desde tu propia infraestructura en el momento en que tu propio sistema admite que el pedido existe, así que refleja la verdad posterior a las comprobaciones antifraude y no el instante optimista en que se pulsó un botón.

El evento de navegador

El worker sirve un script pequeño desde tu propio dominio de redirección, y la página de gracias lo llama.

<script src="https://go.example.com/cv.js" defer></script>
<script>
  window.lpConversion({ goal: 'purchase', orderId: '10241', amountCents: 4999, currency: 'usd' });
</script>

El script lee el identificador desde la URL o desde la cookie propia, así que no hay que pasarle nada a mano. No hay ningún host de terceros en toda la cadena, y eso importa dos veces: es una propiedad de privacidad y también de marca blanca, porque la página de tu cliente no carga nada que nombre a la plataforma que hay debajo.

El coste es el coste habitual de medir desde el cliente. Los bloqueadores, los modos de privacidad, los scripts que no llegan a cargarse y un visitante que cierra la pestaña medio segundo antes eliminan eventos, y la pérdida no es uniforme. Las audiencias técnicas y las preocupadas por la privacidad suprimen mucho más que las de consumo, así que un montaje solo de navegador no se limita a contar de menos: cuenta de menos de forma desigual según el segmento.

Cómo elegir entre los dos

Usa el camino de servidor siempre que haya un servidor que conozca el pedido, que es casi cualquier sitio donde el dinero cambia de manos. Usa el camino de navegador para resultados que solo existen en el navegador, o allí donde no puedas añadir código de servidor: una página que solo puedes editar a través de un gestor de etiquetas, un alta en una plataforma alojada, la landing de un cliente que no es tuya.

Usar los dos caminos para un mismo resultado es seguro gracias a la deduplicación, pero solo si los dos envían el mismo order_id. Sin eso no estás sumando cobertura: estás contando los ingresos dos veces.

Los objetivos en sí son ligeros. Un objetivo es un resultado con nombre, como purchase, signup o trial, puede llevar un valor y una moneda por defecto para las conversiones que llegan sin importe, y un objetivo al que se hace referencia antes de que exista se crea en su primer uso.

El dinero es un entero

Los importes son unidades mínimas enteras. 4999 significa 49.99 en una moneda de dos decimales, y un importe de 49.99 se rechaza nombrando el campo en lugar de redondearse en silencio.

Esto molesta a la gente durante un día y luego la salva durante años. La coma flotante binaria no puede representar de forma exacta la mayoría de las fracciones decimales, así que la demostración clásica en la que sumar dos importes produce un tercero con un dígito final inesperado no es una curiosidad: es lo que le pasa a cualquier suma de una columna de ingresos a escala. Las monedas sin decimales rompen además cualquier suposición de que dividir entre cien sea universalmente correcto.

Rechazar el decimal en la frontera empuja la única conversión honesta, la que va de un precio legible por humanos a unidades mínimas, a un solo sitio: tu código, una sola vez, donde puedes probarla.

De los duplicados se encarga la base de datos

La deduplicación ocurre como una única inserción atómica, y no como una lectura seguida de una escritura. Entregas repetidas del mismo order_id crean una sola conversión y la devuelven marcada como duplicada.

La distinción suena académica y no lo es. Comprobar y luego insertar deja un hueco entre las dos operaciones, y un webhook reintentado por un emisor impaciente mete dos llamadas dentro de ese hueco. Las dos ven que no hay registro previo y las dos escriben uno. Así es como a un informe de ingresos le crece un diez por ciento fantasma que después nadie es capaz de localizar, porque cada registro individual parece perfectamente legítimo.

La regla práctica es elegir un identificador de pedido que sea estable y único en tu sistema, y no cambiar nunca la forma de derivarlo. Tu propio número de pedido suele ser el acertado; una marca de tiempo o cualquier cosa que se regenere al reintentar es exactamente lo contrario. Combínalo con una cabecera Idempotency-Key, como en la petición de arriba, y una llamada fallida pasa a ser algo que repites en lugar de algo que investigas.

El tráfico sospechoso se etiqueta en lugar de esconderse. El veredicto del clasificador viaja dentro del token, así que una conversión atribuida a un centro de datos o a un proxy queda marcada como sospechosa al registrarse y aparece en los informes como su propio segmento. Doscientas conversiones, y doscientas conversiones con cuarenta desde un mismo rango de hosting en una sola hora, son hechos distintos, y solo uno de los dos merece que lo pagues. Ahí es donde los datos de conversión y el filtrado de tráfico dejan de ser funciones separadas.

Cuando la conversión ocurre en otro sitio

En la práctica, casi toda la dificultad no está en la API. Está en que el momento que merece la pena medir ocurre dentro de una tienda alojada, un CRM o un proveedor de facturación, y tu trabajo consiste en llevar una cadena desde el clic hasta ese sistema y sacarla de vuelta.

Tiendas alojadas. Si la plataforma admite atributos de pedido personalizados o metadatos, esa es la vía limpia: lee el identificador cuando el visitante aterriza, llévalo por el checkout en un campo oculto, guárdalo en el pedido y envía la conversión desde tu servidor cuando el pedido se confirme, y no cuando se pulse el botón. Si la plataforma no admite campos personalizados pero sí permite un script en la página de confirmación, usa en su lugar el camino de navegador. Nuestra página de soluciones para ecommerce entra en más detalle sobre estas opciones.

CRM y ventas asistidas. Captura el identificador como campo oculto del formulario de lead y guárdalo en el registro, y envía después la conversión cuando el trato se marque como ganado. La trampa aquí es el tiempo: un trato que se cierra en siete semanas necesita una ventana que dé cabida a siete semanas, y si tu CRM es el único sitio que conoce el identificador, su retención y su comportamiento de exportación pasan a formar parte de tu arquitectura de atribución. Plantéate enviar un objetivo signup en la captura del lead y un objetivo purchase en el cierre, para que la parte alta del embudo se mida aunque la baja tarde un trimestre.

Facturación y suscripciones. Deja que el disparador sea el webhook del proveedor de facturación. Cuando se paga una factura, tu servidor busca el identificador guardado junto a ese cliente y envía una conversión usando el identificador de la factura como identificador de pedido. Los cargos recurrentes llegan entonces de forma natural como conversiones separadas, y los primeros pagos siguen siendo distinguibles de las renovaciones gracias al objetivo.

En las tres formas el patrón es idéntico: el sistema externo no necesita saber nada de enlaces. Guarda una cadena opaca y te la devuelve.

Adónde viajan los números después es deliberadamente convencional. Se emite un evento firmado conversion.created a través de la maquinaria de webhooks de siempre, y las integraciones publicitarias configuradas reciben la conversión por una cola de envío con una espera creciente documentada y una marca de rendición en lugar de reintentos infinitos. Los planes también pueden topar las conversiones aceptadas por mes natural, contadas en UTC, y superar ese tope responde quota_exceeded y no una restricción de plan, así que «no está en tu plan» y «lo has agotado este mes» se distinguen sin abrir un ticket de soporte.

Hacerlo bien a la primera

1. Activa las conversiones antes de la campaña, no después. Los identificadores se emiten en el momento de la redirección y no se pueden crear de forma retroactiva.
2. Publica los enlaces en tu propio dominio, para que la cookie propia sea tuya.
3. Fija la ventana a partir de tu ciclo de compra medido, y revísala cuando se mueva la tasa de attribution_expired.
4. Prefiere el camino de servidor siempre que haya un servidor que conozca el pedido.
5. Convierte los precios a unidades mínimas enteras en un solo punto de tu código.
6. Usa tu número de pedido real como identificador de pedido, y envíalo idéntico desde todos los caminos.
7. Registra los códigos de rechazo por separado, y después cuadra con facturación una vez por periodo e investiga la diferencia en lugar de disolverla en una media.

La referencia completa de campos vive en la documentación de conversiones, y la página de la función de seguimiento de conversiones explica cómo se comporta la columna de ingresos en los informes que ya lees. Nada de esto sustituye a la contabilidad. Responde a una pregunta más estrecha que la contabilidad no puede responder: qué enlace, qué país, qué destino y qué fuente de tráfico produjeron el dinero.