Medición en servidor.
La conversión sale de tu servidor en vez del móvil del comprador. Recupera parte de lo que bloquean navegadores y extensiones, y lo que recupera solo se sabe midiendo antes y después.
La medición en servidor, o server-side tracking, es la técnica de enviar los eventos de conversión a las plataformas de anuncios desde tu propio servidor en vez de desde el navegador del usuario. Recupera parte de las conversiones que se pierden cuando un bloqueador, una extensión o el propio navegador impiden que el script de la plataforma se cargue o se ejecute.
También: server-side tracking · medición server side · conversions api · capi
Agencia Snowball, Barcelona · Revisado el
El mismo aviso, enviado por otro remitente.
Cada venta que tus campañas usan para aprender llega a la plataforma de anuncios como un aviso: un evento de conversión que dice “esto se ha comprado, por este importe, en este momento”. Lo normal es que ese aviso lo mande el navegador del comprador, mediante un script que se carga en su móvil cuando termina de pagar.
La medición en servidor cambia el remitente y nada más. El aviso lo manda tu servidor, que es el que ya sabe que el pedido existe porque lo ha cobrado. No es un modelo de atribución distinto, no es una herramienta que se compra y no mide cosas nuevas: es la misma conversión saliendo por otro camino.
El malentendido que resuelve es de los caros: “el píxel está instalado, así que está todo medido”. Instalado no es lo mismo que entregado. En la ruta del navegador, tres de los cuatro pasos que hay entre la compra y la plataforma ocurren en un dispositivo que no es tuyo, con extensiones que no has elegido y bajo reglas de privacidad que cambian sin consultarte. En la ruta del servidor solo queda un paso fuera de tu control, y es el último: que la plataforma acepte el evento y sepa a qué anuncio pertenece.
El móvil del comprador
3 de 4pasos fuera de tu control
- 1
El comprador paga
El pedido existe. Esto pasa en tu web y lo sabes con certeza.
- 2
Su navegador tiene que descargar el script de la plataforma
Si un bloqueador, una extensión o el propio navegador lo cortan, el script no llega y no hay nada que enviar.
- 3
El script tiene que ejecutarse en su dispositivo
Un móvil lento, una pestaña que se cierra antes de la página de gracias o un error de otro script de la web y no se ejecuta.
- 4
Su navegador tiene que enviar el aviso a la plataforma
El envío sale de una red que no controlas y bajo las reglas de privacidad de un navegador que cambia sin avisarte.
La máquina que ya cobró el pedido
1 de 4pasos fuera de tu control
- 1
El comprador paga
Mismo punto de partida. La diferencia empieza en el paso siguiente.
- 2
Tu sistema registra el pedido cobrado
Es el registro con el que facturas. No depende de que se cargue ningún script.
- 3
Tu servidor llama a la plataforma y le pasa el evento
Una máquina tuya hablando con una API. Ni bloqueadores, ni extensiones, ni pestañas cerradas.
- 4
La plataforma acepta el evento y lo casa con un anuncio
Este paso sigue siendo suyo: si el identificador que mandas no le sirve, el evento entra pero no se atribuye.
Dos cosas que la técnica no cambia, porque se confunden a diario. Lo que viaja sigue siendo tu propio dato, tus datos de origen propio: enviarlos desde tu servidor no los convierte en información nueva, los convierte en información que llega. Y el permiso del usuario sigue mandando igual —el servidor no es una puerta de atrás para medir a quien te ha dicho que no—, con lo que la conversación sobre el consentimiento es exactamente la misma antes y después de montarlo.
Tres piezas, y una cuenta para saber si sirvió.
Montarlo es un trabajo de stack técnico, no de configuración en un panel. Se resume en tres piezas, y ninguna de las tres es opcional.
El evento
Sale de donde está la verdad, que es tu registro de pedidos cobrados: qué se ha comprado, por cuánto, en qué moneda y cuándo. Ese registro es el mismo con el que facturas, así que no discute contigo.
El identificador
Es lo que permite a la plataforma reconocer que esa compra es de alguien a quien le enseñó un anuncio. Sin identificador el evento entra, se suma al total y no se atribuye a nada: has recuperado el recuento y has perdido la atribución.
La deduplicación
Casi nadie apaga el navegador de golpe: durante un tiempo la conversión se manda por los dos caminos. Para que la plataforma no la cuente dos veces, las dos copias viajan con el mismo identificador de evento y ella tira la repetida. Si ese identificador no está, no tienes medición mejor: tienes el doble de conversiones inventadas.
La cuenta que importa viene después de montarlo, y es una división: cobertura = eventos que registra la plataforma ÷ pedidos que has cobrado en ese mismo periodo. Pongamos 100 pedidos cobrados en un mes. Si la plataforma registra 71, tu cobertura es 0,71 y hay 29 ventas de las que tus campañas nunca han sabido nada. Con el envío desde el servidor pasa a registrar 84: cobertura 0,84, y 13 pedidos más de los que aprender.
Y ahora lo que no entra en esa cuenta, porque es donde se pierden los proyectos. La medición en servidor no arregla un UTM mal puesto: si el enlace venía sin etiquetar, el evento llega perfectamente y sigue sin canal. No arregla lo que ves en GA4, que cuenta sesiones y no pedidos y tiene sus propias reglas. No cambia la ventana de atribución con la que la plataforma decide qué se lleva el mérito. Y no toca el sistema de atribución entero: aporta una pieza de ese sistema, la de la recogida, que es exactamente una de las tres o cuatro que hacen falta para que un informe de canal se sostenga.
No es “sí o no”: es a cambio de qué.
Esto tiene coste. Alguien lo monta, alguien lo mantiene y el día que cambies el checkout o la pasarela hay que volver a tocarlo. Por eso la decisión no se toma con una promesa de porcentaje: se toma con dos preguntas y con una medición.
La primera pregunta es si el hueco te está cambiando alguna decisión. Que falten conversiones no es lo mismo que estar decidiendo mal. Si con la cobertura que tienes ya sabes qué canal escalas y cuál matas, y ese veredicto no cambiaría con veinte pedidos más de registro, montarlo es un proyecto técnico sin consecuencia. El caso claro es el contrario: cuando el hueco es tan grande que un canal parece malo por lo que no llega y no por lo que vende, y no eres capaz de decidir el presupuesto del mes que viene sin discutir de dónde salen los números.
La segunda es si puedes medir el resultado. Y aquí está la única regla dura de esta ficha: lo que recupera solo se sabe midiendo antes y después. Se elige un tramo, se apunta la cobertura, se enciende el envío desde el servidor y se vuelve a medir el mismo número de días con el mismo mix de canales. Si no tienes el antes apuntado, el después no significa nada: cualquier subida se la puede haber llevado la temporada, una campaña nueva o el cambio de mezcla.
Con la diferencia medida delante, el veredicto se lee solo. Si has recuperado registro y con ese registro cambia el orden de tus canales, el trabajo se ha pagado. Si has recuperado registro y el orden es el mismo, tienes un panel más bonito y la misma decisión: no lo amplíes, mantenlo y vete al problema siguiente.
Un último aviso, y es el que se salta todo el mundo el primer mes: recuperar conversiones registradas no es vender más. La facturación del mes siguiente puede ser idéntica y aun así el informe subirá, porque lo que ha cambiado es cuántas de tus ventas la plataforma sabe que existen. Si lo que quieres saber es si el canal genera ventas que no habrías tenido, eso es incrementalidad y se mide apagando y encendiendo, no enviando eventos. Y si lo que te trajo aquí es que Meta, la analítica y tu facturación no cuadran, la técnica ayuda pero no es la respuesta completa: el descuadre entero se aborda en la discrepancia de plataforma, que es donde están las otras piezas.
Cuatro formas de montarlo y no ganar nada.
Encenderlo sin apuntar el antes
Es el error de origen y no tiene arreglo hacia atrás: el día que enciendes el envío desde el servidor, la cobertura anterior deja de poder medirse. Sin ese número, la conversación de dentro de tres meses sobre si el proyecto sirvió se resuelve por opinión.
Mandar por los dos caminos sin identificador de evento
La conversión se cuenta dos veces, el ROAS del panel se infla y la decisión que sale de ese panel es peor que la que tenías antes de mejorar la medición. Duplicar conversiones no es un fallo de configuración menor: es fabricar rentabilidad que no existe.
Esperar que arregle la atribución
La ruta mejora la recogida. El reparto del mérito lo siguen decidiendo la ventana y el modelo de la plataforma, y si el problema era que todo se lo lleva el último clic, seguirá llevándoselo con los eventos llegando mejor que nunca.
Usarlo para esquivar el permiso
Enviar desde tu servidor los datos de quien ha rechazado que le midan no es una solución técnica ingeniosa, es el mismo incumplimiento por otra puerta. El permiso viaja con el dato: si no lo hay, el evento no sale.
Lo que se pregunta sobre medición en servidor.
¿Qué es la medición en servidor?
Es enviar los eventos de conversión a la plataforma de anuncios desde tu propio servidor y no desde el navegador del comprador. El aviso es el mismo; lo que cambia es el remitente. En la ruta del navegador hay tres pasos que ocurren en un dispositivo que no controlas —descargar el script, ejecutarlo y enviar el aviso—; en la del servidor solo depende de otro que la plataforma acepte el evento.
¿Qué diferencia hay entre el píxel del navegador y la medición en servidor?
El píxel depende de que el navegador del usuario cargue y ejecute un script y luego mande el aviso; un bloqueador, una extensión o una pestaña cerrada antes de tiempo lo cortan. La medición en servidor sale de tu registro de pedidos cobrados, que ya existe porque has facturado. Miden lo mismo por caminos distintos, y por eso dan números distintos.
¿La medición en servidor duplica las conversiones?
Solo si se monta mal. Mientras conviven las dos rutas, cada conversión tiene que viajar con el mismo identificador de evento por las dos para que la plataforma descarte la copia. Sin ese identificador acabas con la misma venta contada dos veces, el ROAS del panel inflado y decisiones peores que antes de tocar nada.
¿Merece la pena montar la medición en servidor?
Depende de dos cosas, y ninguna es un porcentaje prometido. Primero, si el hueco de conversiones te está cambiando alguna decisión: si ya sabes qué canal escalas y qué canal matas, y ese veredicto no cambiaría con más registro, es un proyecto técnico sin consecuencia. Segundo, si puedes medirlo: se apunta la cobertura de un tramo, se enciende el envío y se compara con el mismo número de días y el mismo mix de canales. Sin el antes, el después no significa nada.
Los que hacen falta para usar este.
Saber de dónde viene cada venta y poder demostrarlo cuando alguien lo discuta.
Saber de dónde viene cada venta. Sin esto, cualquier decisión de inversión es el cuento de la vieja.
El tráfico por el que pagas de forma directa. Su precio lo fija una subasta contra tu competencia, así que se encarece solo cuando lo usas más.
Vender producto por internet con catálogo, cesta y checkout. Los números que lo gobiernan no son los del embudo B2B: mandan el ticket, el margen por referencia y cuántas veces vuelve el mismo cliente.
Lo que el usuario te deja medir. Hoy decide qué porcentaje de tus datos existe, y ningún arreglo técnico se lo salta.
Los datos que tienes porque te los dio tu cliente. El único activo de medición que no depende de una plataforma ajena.
Meta dice 40, Analytics dice 35 y tu facturación dice 52. Por qué pasa siempre y a cuál se le hace caso.
