Medición del lado del servidor

Qué se mueve y qué pagas por ello

En la medición del lado del cliente, el navegador del visitante envía el evento directamente al proveedor. En la del lado del servidor, el navegador se lo cuenta a tu backend —o no le cuenta nada, porque tu backend ya sabe que ocurrió— y es tu backend quien lo reenvía. El mismo evento, otro remitente, y el remitente es toda la diferencia.

• Lo que ganas: una extensión no puede tumbar una petición que nunca sale de la máquina del visitante, un envío fallido se puede reintentar, el contenido se valida antes de salir y las claves de API se quedan de tu lado del cable.
• Lo que pierdes: todo lo que sabía el navegador y tu base de datos no — el referente, el tamaño de la ventana, qué elemento se pulsó, cuánto se bajó la página y el identificador anónimo que cosía la sesión.
• Lo que se complica: el momento y la identidad. El navegador sabía que el evento le pasó *a un visitante concreto, en una página concreta, en ese instante*; tu backend sabe que cambió una fila. Reconstruir el resto es el trabajo de verdad.

El problema de identidad del que nadie avisa

Un evento de navegador llega con contexto puesto: qué página, qué referente, qué identificador anónimo, qué etiquetas de campaña había en la URL. Un evento de servidor lleva lo que te acordaste de guardar. Ese es el trabajo real de mudarse al servidor, y no es el envío: es decidir, en el momento en que alguien aterriza, qué hay que copiar a tu propia base de datos porque dentro de cinco minutos ya no existirá.

Los parámetros UTM y los identificadores de clic de anuncios son el caso más filoso, porque existen en una única URL, justo al principio. Si el identificador de clic nunca se guardó junto a la cuenta en el registro, una conversión que subas tres semanas después no tiene a qué agarrarse: habrás protegido con esmero un número que ya no puede responder la pregunta para la que lo construiste. La atribución de marketing es esa pregunta, y se decide en la llegada, no en la conversión.

Lo que aprendimos enviando nuestras propias conversiones desde el servidor

AgentCeres —el AI Growth Officer de agentceres.com— sube conversiones de leads cualificados a una plataforma publicitaria desde su propia base de datos y no desde el navegador de nadie, usando como clave el identificador de clic capturado cuando la persona aterrizó. La sorpresa no fue el envío. Fue que una respuesta HTTP correcta no es un recibo: nuestras subidas volvían con un 200 mientras las filas de dentro estaban siendo rechazadas, y el resultado real solo se veía en una consulta de estado aparte hecha después. El endpoint al que recurrimos primero además resultó estar cerrado a nuevas integraciones, algo que el 200 tampoco mencionaba.

La forma se generaliza. Del lado del navegador, un evento perdido es ruidoso en un sentido concreto: el número simplemente falta, y el hueco se ve. Del lado del servidor, el fallo es una petición que tus propios registros anotan como éxito, así que el hueco parece un dato. Todo lo que muevas al servidor necesita un paso de verificación que le pregunte al proveedor qué guardó de verdad, en vez de fiarse de lo que respondió en su momento. La otra mitad de esta historia, la de la recepción —cuántos datos de navegador se pierden de entrada y por qué el agujero era mayor justo en el público que pagábamos por captar—, está en nuestra página sobre PostHog.

No es una forma de esquivar el consentimiento

La medición del lado del servidor se vende a menudo por derrotar a los bloqueadores de anuncios, cosa que mecánicamente hace. Conviene ser claro sobre lo que eso significa: el bloqueador lo instaló una persona expresando una preferencia, y mover la escritura a tu propio servidor no crea una base legal que no tenías, ni convierte en propio un dato porque haya pasado por tu dominio de camino a otro sitio.

• El consentimiento rige la finalidad, no el transporte. Si un evento necesita consentimiento cuando lo manda un navegador, lo necesita cuando lo manda tu servidor.
• Un proxy en tu propio dominio sigue siendo una cesión cuando el destino es un tercero: descríbelo así en tu aviso de privacidad en lugar de reclasificarlo.
• La versión honesta suele bastar. Casi todo lo que una startup pequeña necesita de verdad en el servidor son sus propios datos de producto —altas, planes, pagos—, que nunca fueron cosa del navegador.