Si tu Snap Pixel carga pero PURCHASE nunca aparece en el Administrador de eventos, la causa casi siempre es una de seis: un nombre de evento en minúsculas, un transaction_id que falta, el píxel ausente de la página de confirmación real, una redirección de pago externa que rompe la sesión, un checkout de una sola página que reinicia el píxel, o eventos deduplicados frente a un flujo de la API de Conversiones.
Revísalas en ese orden. Las tres primeras explican la mayor parte de lo que encuentro.
Del seguimiento en Snapchat se escribe mucho menos que de Meta o Google, así que cuando se rompe estás prácticamente solo. Los artículos que existen suelen escribirlos empresas que venden un producto de seguimiento, así que se quedan en «instala nuestra app». Esta es la secuencia que sigo de verdad, en el orden en que la sigo, y por qué en ese orden.
Primero: confirma que el evento de verdad no llega
Antes de cambiar nada, averigua si el evento falta o solo llega con retraso. Dos comprobaciones, sesenta segundos.
Revisa la red, no el panel. Abre tu página de confirmación en Chrome, abre las DevTools (F12), ve a la pestaña Network y filtra por tr.snapchat.com. Haz una compra de prueba real. Si ves que sale una petición con tu ID de píxel y el nombre del evento, el navegador hace su trabajo y tu problema está más adelante: informes, deduplicación o atribución. Si no sale nada, el problema está en la página.
La extensión de navegador Snap Pixel Helper hace lo mismo con una interfaz más amable y además te dice si el píxel está instalado. Yo uso la pestaña Network porque muestra la carga exacta, y la respuesta suele estar en la carga.
Los informes del Administrador de eventos no son instantáneos. Antes de concluir que falta un evento, espera unas horas y vuelve a comprobar. He visto a gente reescribir un checkout que funcionaba porque miró un panel noventa segundos después de un pedido de prueba.
Las seis causas, ordenadas
El nombre del evento está en minúsculas
Los eventos estándar de Snapchat van en mayúsculas: PURCHASE, ADD_CART, PAGE_VIEW, START_CHECKOUT. Si envías purchase, no se reconoce como evento estándar. Lo traicionero es que puede dispararse igualmente y aparecer en algún sitio: simplemente no se trata como la conversión estándar, así que la optimización de campañas y los informes se comportan como si no hubiera pasado nada.
Es la número uno porque produce exactamente el síntoma que la gente describe, «el píxel se dispara pero el Administrador de eventos no muestra nada», y porque copiar una implementación de Meta es lo más natural. Meta usa Purchase. Snapchat no.
{
event: "Purchase",
price: 24.00,
currency: "USD"
}
{
event: "PURCHASE",
price: 24.00,
currency: "USD",
transaction_id: "1047"
}
PURCHASE. Aquí las mayúsculas no son un detalle estético.No se envía ningún transaction_id
Sin transaction_id, Snapchat no puede distinguir un segundo pedido real del mismo cliente recargando la página de confirmación. Snap documenta una ventana de deduplicación de 30 días con transaction_id, frente a 48 horas con client_dedup_id.
El fallo corta en ambos sentidos, por eso está tan arriba. Si lo omites, las recargas inflan tu número de compras. Si envías un valor que no es realmente único por pedido (un ID de carrito, de checkout o de sesión), pedidos legítimos se fusionan en uno y desaparecen. El segundo caso se ve exactamente igual que «mis eventos no se disparan».
transaction_id es distinto en cada uno y que coincide con el número de pedido que asigna tu tienda.El píxel no está en la página que realmente confirma el pedido
Casi todo el mundo instala el píxel en toda la web y supone que la página de confirmación lo hereda. Muchas veces no es así. Los checkouts alojados, las páginas de estado del pedido y los flujos de venta adicional tras la compra suelen generarse fuera del tema o la plantilla que lleva tu código de seguimiento.
Vale la pena comprobarlo en concreto: si usas una venta adicional tras la compra, la página a la que llega el cliente justo después de pagar quizá no sea la que tú consideras la página de agradecimiento.
Una redirección de pago externa rompe la sesión
Cuando el checkout pasa a una pasarela externa y devuelve al cliente a una página de pedido recibido, ese ida y vuelta puede romper la sesión del navegador de la que depende el píxel. La compra se completa, el cliente ve su confirmación y el evento nunca llega a Snapchat, o llega sin los identificadores necesarios para atribuirlo.
Aquí es donde una configuración solo de navegador deja de ser suficiente. El seguimiento server-side mediante la API de Conversiones es la solución duradera, porque el evento sale de tu servidor y nunca depende de sobrevivir a una redirección.
Un checkout de una sola página reinicia el píxel
En aplicaciones de una sola página, si la inicialización del píxel se ejecuta en cada vista de página virtual, el estado del píxel se reinicia cada vez. Los datos de coincidencia avanzada recogidos antes en el flujo se pierden, y el evento de compra llega sin los identificadores que lo hacen útil: pobre, mal emparejado y a veces sin atribuir.
El evento se dispara. Solo que no lleva lo que necesita, por eso es fácil confundirlo con algo que «funciona».
La deduplicación se come el evento
Si usas el píxel y la API de Conversiones (como deberías), Snapchat deduplica con client_dedup_id (ventana de 48 horas) o transaction_id (30 días). Dos eventos que comparten identificador se cuentan una vez, por diseño.
Se convierte en un problema cuando el navegador y el servidor no coinciden en cuál es ese identificador. Si la correspondencia está mal, o cuentas todo dos veces o pierdes un lado en silencio. Según Snap, los eventos que no son de compra corresponden a client_dedup_id y los de compra a transaction_id, y lo fundamental es que el valor debe coincidir en todos los caminos que envían ese evento.
transaction_id queda protegida 30 días. Con client_dedup_id esa protección caduca a las 48 horas, por eso Snap asigna las compras a transaction_id y todo lo demás a client_dedup_id.De dónde salen mis propios números
No tengo una muestra grande de clientes en Snapchat y no voy a fingir lo contrario. Lo que tengo es una tienda que llevé de principio a fin, la mía, donde el seguimiento funcionaba, y esa es la única razón por la que puedo hablar de lo que produce una configuración de Snapchat sana.
AlphaMart: mi propia tienda, no un cliente
- Inversión publicitaria
- $1,452
- Compras
- 1,034
- Costo por compra
- $1.40
- ROAS
- 5.69×
Contexto importante, porque si no estas cifras me favorecen: con 5,69× sobre 1.452 $ son unos 8.262 $ de ingresos medidos en 1.034 pedidos, un ticket medio de unos 8 $. Era un producto barato. Un costo por compra de 1,40 $ es un logro muy distinto con un ticket de 8 $ que con uno de 80 $, y quien cita un CPA sin el ticket medio al lado te está mostrando medio número.
Las cifras son de un periodo que terminó en mayo de 2024. Las fecho en lugar de presentarlas como actuales.
Lo que hace que esas 1.034 compras importen en este artículo no es el ROAS. Es que una tienda que envía a ese volumen un evento PURCHASE limpio, bien nombrado y correctamente deduplicado te da una referencia fiable de cómo se ve «funcionando», y hace evidente cuándo algo ha dejado de funcionar.
Lo que no puedo decirte
Dos limitaciones honestas, porque un artículo que no admite ninguna suele esconder alguna.
No puedo darte un ranking de frecuencia basado en una muestra grande. El orden anterior refleja un número pequeño de cuentas más lo que implican lógicamente los modos de fallo: un nombre de evento en minúsculas rompe los informes siempre, así que va arriba sin importar cuántas veces lo haya visto yo. Toma el ranking como un orden de búsqueda sensato, no como una estadística.
La interfaz de Snapchat cambia. Las rutas de menú se quedan obsoletas rápido, por eso las comprobaciones de arriba se apoyan en la petición de red y la carga y no en dónde está hoy un botón. La carga es lo que de verdad es cierto.
La versión corta
- Abre la pestaña Network, filtra por
tr.snapchat.comy haz un pedido de prueba. - Confirma que el nombre del evento es exactamente
PURCHASE, en mayúsculas. - Confirma que
transaction_idestá presente y es único por pedido. - Confirma que el píxel existe en la página a la que llega realmente el cliente.
- Si el checkout sale de tu dominio, planifica la API de Conversiones.
- Si usas píxel y CAPI, confirma que el identificador de deduplicación coincide exactamente en ambos lados.
Si pasas las seis y el evento sigue sin llegar, el problema normalmente no es el píxel: es que la página que estás probando no es la que alcanzan tus clientes. Vuelve atrás y haz una compra real con dinero real, en un teléfono, desde un clic en un anuncio. Los pedidos de prueba con un enlace de staging se saltan justo las partes que se rompen.
¿No sabes cuál de las seis es?
Envíame la URL de tu tienda y te diré qué está haciendo tu seguimiento. No necesito acceso a la cuenta para empezar, solo el enlace.
Consigue una auditoría gratuita de seguimiento →