Qué arregla de verdad la API de Conversiones, y qué no

Todos me dicen que instale la API de Conversiones. ¿Qué arregla de verdad, y qué va a seguir roto después?

Una API de Conversiones manda tus eventos de compra a una plataforma de anuncios desde tu servidor en vez de desde el navegador del comprador. Ése es el mecanismo completo, y casi todo lo que se escribe al respecto o exagera lo que se sigue de él o es lo bastante vago como para insinuar más. Vale la pena ser preciso, porque en la distancia entre lo que arregla y lo que la gente espera que arregle es donde vive la decepción.

Qué arregla de verdad

El navegador es un narrador poco confiable. Una extensión puede bloquear la petición de plano. La protección de rastreo de Safari acorta o descarta las cookies que la plataforma usa para reconocer a alguien. Un checkout que se pinta en el dominio de la pasarela no corre ni una línea de tu código. Un comprador que cierra la pestaña en la pantalla de confirmación mata el evento antes de que se dispare.

Cada uno de esos casos pierde una venta que sí ocurrió. Tu servidor sabe de todos ellos, porque tu servidor es donde existe la orden. Mandar el evento desde ahí recupera exactamente esa población, y por eso la parte recuperada varía tanto entre tiendas: sigue qué tan cuidadosa con su privacidad es tu audiencia y cómo está construido tu checkout, no qué tan buena es tu implementación.

Lo segundo que arregla es la calidad de emparejamiento. Un evento de navegador lleva lo que tiene el navegador. Un evento de servidor puede llevar lo que tiene la orden: un correo hasheado, un teléfono hasheado, un nombre, una dirección. Más identificadores significa que la plataforma reconoce a más de los compradores que le mandas.

Tres cosas deciden si funciona, y el orden importa

**Un ID de evento compartido.** En cuanto mandas compras desde el navegador y desde el servidor, la plataforma recibe dos eventos por una venta. Los colapsa en uno solo si los dos llevan el mismo ID de evento, y Meta solo deduplica dentro de su ventana documentada a partir del primer evento con ese ID. Si los dos lados generan sus IDs por separado, o uno lo omite, no construiste redundancia. Construiste doble conteo, y se ve como crecimiento.

**Identificadores hasheados como la plataforma los espera, exactamente.** Meta empareja SHA-256 plano de un valor normalizado. Es fácil hashear con una función con llave en su lugar, porque un hash con llave es la elección correcta casi en cualquier otro lugar de un sistema que maneja datos personales. Meta lo va a aceptar. Lo va a contar como recibido. Lo va a emparejar con nadie, para siempre, y nada en la respuesta lo dice. Esta falla es silenciosa por construcción, y por eso la calidad de emparejamiento hay que leerla en vez de suponerla.

**Un candado de idempotencia de tu lado.** Los webhooks de orden reintentan. Una plataforma vuelve a notificar en cada cambio de estado. Sin un registro que diga que esta orden ya se mandó a esta plataforma, una venta sale varias veces, y en Google no hay red de ID de evento que la atrape.

Qué no arregla

No vuelve verificable el reclamo de la plataforma. Mejor dato de entrada significa un reclamo mejor informado de salida, y el reclamo sigue siendo la versión que la plataforma da de su propia contribución, medida en su propia ventana, sin forma de que tú audites una venta individual dentro de él.

No cambia el modelo de atribución. Una ventana de 7 días de clic es una ventana de 7 días de clic llegue el evento del navegador o del servidor.

No reconcilia nada con tu tienda. La tabla de órdenes y el conteo de conversiones de la plataforma siguen siendo dos números distintos sobre dos bases distintas, y la API de Conversiones acerca uno al otro sin volver ninguno comprobable contra el otro.

Y no evita que pagues por volver a adquirir gente que ya es tu cliente. Éste vale la pena decirlo con todas sus letras porque se da por hecho muy seguido. El dato de eventos le enseña al optimizador cómo se ve un buen resultado. Nunca saca a nadie de la subasta. Excluir clientes existentes requiere un público cableado como exclusión, que es otro mecanismo y una decisión que depende del propósito de la campaña.

Cómo comprobarlo sin creerle a nadie

Las plataformas exponen diagnósticos para esto y son más útiles que el panel del proveedor que va encima. Lee la calidad de emparejamiento por evento, no el promedio de la cuenta, porque un buen promedio de PageView esconde un mal puntaje de Purchase. Lee la retroalimentación de deduplicación, que te dice qué fracción de los eventos se colapsó de verdad y sobre cuál llave: eso es la plataforma confirmando que tu ID de evento está haciendo su trabajo, en vez de que tú lo supongas.

Después haz la aritmética que ningún diagnóstico va a hacer por ti. Compara cuántos eventos de compra recibió la plataforma en una ventana contra cuántas órdenes liquidó tu tienda en la misma ventana. No van a coincidir, y la dirección de la diferencia te dice cuál problema tienes.

La advertencia que nadie pone en la presentación de ventas

Cuando entra una API de Conversiones, las conversiones reportadas suben. Ése es el efecto buscado y es algo bueno: ventas que siempre estaban ocurriendo ahora son visibles para la plataforma que influyó en ellas.

Tampoco es más ingreso, y los reportes no distinguen esas dos cosas. Si el ROAS reportado mejora el día del cambio, nada del negocio cambió. Lo que cambió es cuánto del mismo ingreso puede ver y reclamar la plataforma. Un comercio que lea eso como crecimiento va a subir la inversión contra un número que se movió por una razón de medición, y la corrección llega después, en la cuenta de banco y no en el panel.

La protección contra esto es la misma que responde casi todas las preguntas de este blog. Conserva las órdenes liquidadas de tu tienda como ancla, trata cada número de plataforma como un reclamo sobre esa lista, y verifica los reclamos contra ella. Una plataforma puede resolver legítimamente a un comprador que tú nunca viste, pero ninguna plataforma puede resolver una orden que no existe.