El píxel y la API de conversiones miden lo mismo por caminos distintos
El píxel vive en el navegador de quien visita la web y depende de que ese navegador lo deje trabajar. La API de conversiones sale del servidor de la web hacia Meta sin pasar por el navegador, así que sobrevive a lo que el píxel no sobrevive: extensiones que bloquean, restricciones del propio navegador y sesiones que se cierran antes de que el evento llegue a salir.
Montar los dos no es redundancia defensiva, es la forma normal de medir hoy. Cada uno aporta algo que el otro no tiene. El píxel ve el comportamiento en la página —qué se visitó antes, hasta dónde se bajó— y el servidor ve el hecho consumado, incluido el que ocurre más tarde, cuando el contacto se confirma por teléfono o el pedido se cobra de verdad.
Lo que no se puede hacer es montarlos y dar por bueno lo que llegue. Dos caminos hacia el mismo destino producen, por defecto, el doble de llegadas.
La deduplicación es el paso que casi nadie comprueba
Si el mismo formulario envía su evento por el píxel y por el servidor sin nada que los relacione, Meta cuenta dos contactos donde hubo uno. El panel se ve mejor de lo que fue, la campaña optimiza hacia lo que cree que funciona, y cualquier decisión de presupuesto tomada encima de ese dato es la equivocada.
La deduplicación consiste en que los dos envíos lleven el mismo nombre de evento y el mismo identificador de evento, generado una sola vez para esa acción concreta. Con eso la plataforma reconoce que son el mismo hecho contado dos veces y se queda con uno.
Los fallos típicos son tres y ninguno avisa: que el identificador se genere de nuevo en cada envío en vez de compartirse, que el evento se llame de una forma en el navegador y de otra en el servidor, o que cada camino dispare en un momento distinto —uno al pulsar el botón y otro al confirmarse el envío—, con lo que no hay nada que emparejar.
Decidir qué cuenta como conversión antes de medirla
Un formulario enviado no es una venta, y una llamada iniciada no es una llamada atendida. Medir todo lo que se puede medir no sale gratis: la campaña optimiza hacia el evento que se le señale, y si ese evento es fácil de conseguir, la plataforma lo conseguirá en abundancia sin traer negocio.
Por eso la conversación previa no es técnica. Es qué acción del visitante representa una oportunidad comercial real para este negocio, cuánto vale aproximadamente, y qué eventos intermedios sirven para diagnosticar aunque no se optimice sobre ellos.
Hay además una decisión de volumen que conviene tomar a la vez. El evento sobre el que se optimiza tiene que ocurrir con cierta frecuencia; si es tan raro que la cuenta apenas lo registra, lo razonable es optimizar sobre un paso anterior y vigilar el evento final como resultado, no como objetivo de campaña.
Por qué la plataforma y la analítica nunca dicen lo mismo
Es la primera discusión de casi toda cuenta nueva: Meta declara más contactos de los que aparecen en la analítica de la web o en el buzón del negocio. Casi nunca es un fallo de configuración; es que cada sistema cuenta cosas distintas y las dos cuentas pueden estar bien.
Meta atribuye el contacto a la campaña dentro de una ventana que incluye a quien hizo clic y, si está activada, también a quien solo vio el anuncio y llegó después por su cuenta. La analítica de la web suele atribuir al último canal que trajo la visita y no sabe nada de las impresiones. Los dos números pueden ser correctos y no coincidir jamás.
Lo práctico es decidir antes de empezar cuál manda para qué. La plataforma manda para optimizar, porque es la que toma las decisiones de reparto. El recuento propio del negocio —los contactos que llegan, los presupuestos enviados, lo que se cobra— manda para saber si la inversión compensa. Mezclar los dos papeles es lo que produce esas reuniones en las que nadie se pone de acuerdo sobre lo que pasó el mes pasado.
La fase de aprendizaje empieza con los datos que encuentre
Cada conjunto de anuncios nuevo pasa por un tramo inicial en el que la plataforma está averiguando a quién enseñar el anuncio, y en el que los resultados son más caros e inestables. Ese tramo termina cuando acumula suficientes eventos del tipo sobre el que se está optimizando.
De ahí se siguen dos consecuencias que condicionan el calendario entero de una puesta en marcha. La primera: si la medición no está lista, ese aprendizaje se hace igualmente, pero sobre una señal equivocada, y lo aprendido no se borra el día que se arregla el píxel. La segunda: cada edición relevante del conjunto —cambiar el evento de optimización, el público o la creatividad, añadir un anuncio, pausarlo una semana o más, o mover mucho el presupuesto— lo devuelve a ese tramo.
Por eso los cambios se agrupan en vez de tocar la cuenta a diario, y por eso la medición no es una tarea paralela que pueda ir un poco por detrás del lanzamiento. Va antes.
La comprobación se hace con un envío real
La configuración se da por buena cuando una persona rellena el formulario de verdad y ese envío aparece en la plataforma como el evento que tenía que aparecer, una sola vez, con el valor correcto y en la cuenta correcta. No cuando la herramienta de depuración dice que la conexión está activa.
Es un trámite de minutos que cambia todo lo que viene después: a partir de ahí, cada lectura de la cuenta se apoya en un dato que alguien ha visto llegar con sus propios ojos.
Qué se pierde cuando la medición llega después
Nada de esto se puede reconstruir hacia atrás. Los eventos que no se enviaron no existen, el histórico con el que la plataforma decide se formó con lo que hubiera, y el tramo de inversión gastado mientras tanto no vuelve.
Con la medición montada al final se puede arreglar lo que venga, pero el diagnóstico de lo ya ocurrido se queda para siempre en suposiciones. Es la razón por la que en una puesta en marcha el orden es este y no el inverso: medir, comprobar, y solo entonces encender.