Índice del artículo
La medición server-side consiste en que las conversiones de tu clínica salgan hacia Google y Meta desde un servidor o un CRM que controlas tú, y no solo desde el navegador del paciente. Recupera lo que se pierde por bloqueadores, por los límites de Safari a las cookies y por citas que se cierran en recepción. Lo que no hace es saltarse el consentimiento.
Si un paciente rechaza las cookies de publicidad, no se le mide para publicidad, lo envíes desde donde lo envíes. Con esa regla clara, te explicamos qué se pierde hoy, qué piezas existen, en qué orden implantarlas y cómo comprobar que funcionan.
Dónde se pierden hoy tus conversiones
Son las 22:15 y una paciente rellena desde su iPhone el formulario de tu landing de ortodoncia. El píxel de Meta y la etiqueta de Google tienen que cargarse en su navegador, leer sus cookies y enviar la conversión antes de que cierre la pestaña. Por el camino pueden fallar varias cosas, y en el informe solo verás que esa campaña «convierte poco».
El rechazo de cookies
Es la pérdida más grande y la única que no tiene arreglo técnico, porque no debe tenerlo. La guía sobre el uso de las cookies de la AEPD, actualizada en mayo de 2024, exige que la opción de rechazar se ofrezca al mismo tiempo, al mismo nivel y con la misma visibilidad que la de aceptar. Si tu banner cumple, una parte de tus visitas rechazará, y esas visitas no deben alimentar tus campañas con cookies publicitarias.
Bloqueadores y navegadores con protección
Las extensiones bloqueadoras y algunos navegadores impiden que se carguen los scripts de terceros conocidos, entre ellos los de las plataformas publicitarias. El paciente envía el formulario, la clínica recibe el lead, pero Meta y Google no se enteran.
Safari y sus límites a las cookies
Desde la versión 2.1 de su prevención inteligente de rastreo, documentada en el blog de WebKit, Safari limita a siete días la duración de las cookies que se crean con JavaScript, que son justo las que crean el píxel y la etiqueta de Google en la web. Para una tienda online, siete días bastan. Para una clínica, no: el paciente de implantes que vio tu anuncio, se lo pensó y vuelve a los doce días a pedir cita ya no es reconocido, y esa cita se queda sin atribuir.
Además, Safari elimina de los enlaces algunos identificadores de clic conocidos en la navegación privada y en enlaces abiertos desde Mail y Mensajes. Sobre si esta eliminación se ha ampliado a la navegación normal en las versiones de 2025 hay informes contradictorios; lo prudente es probarlo con un iPhone actualizado antes de dar nada por hecho. Y en iPhone, las apps tienen que pedir permiso para rastrear la actividad en webs y apps de terceros, lo que también reduce lo que Meta puede relacionar.
Lo que el navegador nunca ve
Una llamada, un WhatsApp, una cita confirmada por teléfono, una primera visita, un presupuesto aceptado. Nada de eso pasa en tu web. Si solo mides con el navegador, tus campañas aprenden de formularios y nunca de pacientes. Es el motivo de fondo por el que existen la API de conversiones de Meta y las conversiones offline de Google Ads.
Fugas de andar por casa
Formularios de software de citas incrustados en un iframe donde el píxel no dispara, redirecciones que pierden el gclid o el fbclid por el camino, páginas de gracias que cargan tan despacio que el paciente cierra antes. No son exóticas: las encontramos en muchas webs de clínicas, y más de una se arregla sin tocar ningún servidor. Si tu web tiene problemas de base, empieza por por qué tu web frena la captación.
Qué arregla la medición server-side y qué no
| Causa de la pérdida | ¿Lo arregla enviar desde el servidor? | Qué hacer |
|---|---|---|
| El paciente rechaza las cookies publicitarias | No, y no debe | Respetarlo. Banner correcto y modo de consentimiento |
| Bloqueador de anuncios | En parte | Enviar el lead desde el servidor cuando hay base legal para hacerlo |
| Cookies de Safari que caducan a los siete días | En buena parte | Guardar los identificadores en el CRM y enviar los eventos desde allí |
| Identificador de clic perdido en una redirección | No por sí solo | Corregir la web y capturar el identificador al llegar |
| Llamadas, WhatsApp, citas y asistencias | Sí | Eventos desde el CRM por API o importación |
| Formulario en un iframe de terceros | Sí, si el software avisa a tu servidor | Integración del software de citas con tu CRM |
Las piezas, explicadas sin tecnicismos
Piensa en el píxel como un mensajero que vive en el móvil del paciente: si el móvil le cierra la puerta, el mensaje no sale. La medición server-side pone un segundo mensajero en tu casa, que solo envía lo que tú decides y cuando tú decides. Ese segundo mensajero puede tomar tres formas, y no todas las clínicas necesitan las tres.
API de conversiones de Meta
Envía eventos a Meta desde tu servidor o tu CRM: el formulario, y después el lead cualificado, la cita y la asistencia. Se usa a la vez que el píxel, con un identificador de evento común para no contar dos veces. Es la pieza que más señal devuelve en una clínica. Ojo con lo que envías: en salud hay restricciones serias, que repasamos en qué puede enviar una clínica a Meta.
Conversiones mejoradas e importación en Google
Las conversiones mejoradas para leads permiten que Google relacione un lead con el clic usando el correo o el teléfono cifrados, sin depender de que la cookie siga viva. Después, desde el CRM, importas las etapas que importan. Lo tienes paso a paso en conversiones mejoradas para leads.
Contenedor de servidor
Es un servidor intermedio, normalmente con Google Tag Manager en su versión de servidor, que se aloja en un subdominio tuyo (por ejemplo, medicion.tuclinica.es). El navegador le manda los datos una sola vez y el contenedor los reparte a Google, Meta o TikTok, filtrando lo que no debe salir. Tiene dos ventajas: las cookies las fija tu propio servidor, no un script, y tú controlas cada campo que se reenvía. Tiene un coste: hay que alojarlo, mantenerlo y configurarlo bien, porque Safari también limita las cookies que fijan servidores de terceros disfrazados de subdominio propio.
Nuestro criterio: para una clínica con una o dos sedes, lo primero es la API de conversiones conectada al CRM y las conversiones mejoradas. El contenedor de servidor tiene sentido cuando ya hay volumen, varias plataformas o una web con mucho tráfico. Montarlo antes de tener el CRM bien llevado es empezar la casa por el tejado.
El modo de consentimiento de Google, en 2026
El modo de consentimiento es la forma de decirle a las etiquetas de Google qué ha aceptado cada visitante. Su segunda versión añadió dos señales a las de almacenamiento: ad_user_data (si el usuario acepta que se envíen sus datos a Google con fines publicitarios) y ad_personalization (si acepta publicidad personalizada), junto a ad_storage y analytics_storage. Para seguir usando las funciones de medición y remarketing con usuarios del Espacio Económico Europeo, Google pide que le transmitas ese consentimiento, y el modo de consentimiento es la vía que propone.
Según la ayuda de Google sobre el modo de consentimiento, hay dos formas de implantarlo:
- Básica: las etiquetas de Google no se cargan hasta que el visitante acepta. Si rechaza, no se envía nada, y Google estima las conversiones que faltan con un modelo general.
- Avanzada: las etiquetas se cargan con el consentimiento denegado por defecto y, si el visitante rechaza, envían avisos sin cookies (con datos como la hora o el navegador) que Google usa para modelar conversiones con un modelo específico de tu cuenta.
La avanzada recupera más señal, pero hay debate sobre su encaje con la normativa española cuando el visitante ha rechazado. No te vamos a dar una respuesta legal: es una decisión para tomar con tu delegado de protección de datos. Si hay dudas, la básica es la opción conservadora.
El modo de consentimiento no es un banner. No pregunta nada al paciente: solo transmite a Google lo que el banner ha recogido. Si el banner no cumple la guía de la AEPD, el modo de consentimiento no lo arregla.
Lo que la medición server-side no te permite hacer
Aquí vemos los peores errores, casi siempre de proveedores que venden el servidor como «la forma de medir al 100 %». La Ley de Servicios de la Sociedad de la Información exige consentimiento para almacenar o leer información en el dispositivo del usuario con fines no necesarios, y el Reglamento General de Protección de Datos exige base legal para enviar datos personales a Google o Meta. Mover el envío al servidor no cambia ninguna de las dos cosas.
- Si el visitante rechaza las cookies publicitarias, el servidor no debe reenviar a las plataformas sus identificadores ni sus visitas con fines publicitarios.
- El estado del consentimiento tiene que viajar con cada evento hasta el servidor, y el servidor tiene que respetarlo.
- Los eventos posteriores del CRM, como la cita o la asistencia, necesitan su propia base legal e información clara en el formulario y en la política de privacidad. Lo vemos en protección de datos de los leads.
- Los datos de salud no se envían, ni desde el navegador ni desde el servidor.
Dicho de otra forma: la medición server-side recupera lo que se perdía por motivos técnicos. Lo que se pierde porque el paciente ha dicho que no, se queda perdido.
Cómo implantarlo, paso a paso
- Mide el agujero. Compara, mes a mes y por canal, los leads de tu CRM con las conversiones que ven Google y Meta. La diferencia es lo que se pierde (o lo que el CRM no recoge, que también pasa).
- Arregla el banner y el consentimiento. Rechazar al mismo nivel que aceptar, y el modo de consentimiento conectado al banner.
- Captura los identificadores al llegar. Campos ocultos en los formularios para el
gclidy elfbclid, y lectura de la cookie_fbpal enviar. Todo eso viaja al CRM con el lead. - Envía el lead por la API de conversiones con el mismo
event_idque el píxel, el correo y el teléfono cifrados y el estado del consentimiento. - Activa las conversiones mejoradas para leads en Google Ads.
- Conecta el CRM. Cada cambio de etapa (cualificado, cita, asistencia, presupuesto aceptado) sale hacia Meta por la API y hacia Google por importación, con nombres genéricos.
- Valora el contenedor de servidor cuando tengas volumen o varias plataformas, alojado en un subdominio propio y con el filtrado de campos documentado.
- Vuelve a medir el agujero a las cuatro semanas, con el mismo método del paso 1.
Cómo comprobar que funciona
No te fíes de que «ya está instalado». Comprueba:
- En el administrador de eventos de Meta, que el evento de lead llega por navegador y por servidor y que Meta indica que los deduplica. Y que la calidad de la coincidencia de los eventos del CRM no está por los suelos.
- En Google Ads, el diagnóstico de las conversiones mejoradas y el porcentaje de coincidencias de cada importación.
- Con la herramienta de vista previa del gestor de etiquetas, que con el banner rechazado no sale ninguna etiqueta publicitaria con cookies.
- En tu hoja mensual, que la diferencia entre leads del CRM y conversiones de cada plataforma se ha reducido.
Pongamos un ejemplo con números redondos. Una clínica estética en Majadahonda registra en su CRM 100 leads al mes que vienen de Meta, y Meta solo cuenta 65. Tras enviar el lead por la API con deduplicación, Meta pasa a contar 85; los 15 restantes son, en buena parte, visitantes que rechazaron las cookies, y así debe ser. Es un ejemplo, no una promesa: cuánto se recupera depende de cuántos visitantes usan Safari o bloqueadores y de cómo esté montada la web. Pero lo más valioso no son esos 20 leads, sino que las citas y asistencias empiezan a llegar a Meta, y eso cambia lo que aprende la campaña. Para cruzarlo con el resto de canales, tienes atribución de leads en clínicas.
Checklist de medición server-side para tu clínica
| Comprobación | Dónde se mira | Está bien si… |
|---|---|---|
| Botón de rechazar | Banner de cookies | Aparece en la primera capa, al mismo nivel que aceptar |
| Modo de consentimiento | Vista previa del gestor de etiquetas | Las cuatro señales cambian al aceptar o rechazar |
| Identificadores de clic | Ficha del lead en el CRM | Los leads de anuncios llevan gclid o fbc |
| Deduplicación en Meta | Administrador de eventos | El lead llega por navegador y servidor y se cuenta una vez |
| Conversiones mejoradas | Diagnóstico de Google Ads | Sin avisos y con coincidencias |
| Eventos del CRM | Meta y Google | Cualificado, cita y asistencia llegan el mismo día o al siguiente |
| Datos sensibles | Eventos de prueba | Ni nombres, ni URLs, ni parámetros nombran tratamientos |
| Agujero de medición | Hoja mensual | La diferencia CRM frente a plataforma baja respecto al mes de partida |
En nuestro Método C.I.T.A. esto es la A, Asistencia: la última pieza, y la que hace que las campañas aprendan de pacientes y no de formularios. Pero solo funciona si las anteriores están en su sitio, porque un servidor perfecto no tiene nada que enviar si recepción no marca las citas.
Si quieres saber cuántas conversiones está perdiendo tu clínica y qué se puede recuperar dentro de la ley, pide una consulta. Y si el problema empieza en la propia web, lo trabajamos en diseño web para clínicas.
Preguntas frecuentes
¿Qué es la medición server-side?
Es enviar las conversiones a Google, Meta u otras plataformas desde un servidor que controla la clínica, y no solo desde el navegador del visitante. Así no dependen de bloqueadores, de la duración de las cookies en Safari ni de que el paciente cierre la página, y permiten enviar lo que pasa fuera de la web, como una cita.
¿La medición server-side permite medir a quien rechaza las cookies?
No debe. La LSSI exige consentimiento para las cookies no necesarias y el RGPD exige base legal para enviar datos personales a las plataformas. Enviar desde el servidor no cambia esas obligaciones: si el visitante rechaza las cookies publicitarias, no se le mide con fines publicitarios.
¿Necesito Google Tag Manager de servidor?
No siempre. Para muchas clínicas basta con la API de conversiones de Meta conectada al CRM y las conversiones mejoradas de Google. El contenedor de servidor compensa cuando hay volumen, varias plataformas o una web con mucho tráfico, porque supone alojarlo y mantenerlo.
¿Qué es el modo de consentimiento v2 de Google?
Es la forma de transmitir a las etiquetas de Google lo que cada visitante ha aceptado en el banner, con cuatro señales: almacenamiento publicitario, almacenamiento analítico, uso de datos para publicidad y personalización de anuncios. Google lo pide para mantener sus funciones de medición y remarketing con usuarios del Espacio Económico Europeo.
