Opciones Avanzadas
Ajusta con precisión cómo se carga el pixel, gestiona módulos de pago no estándar, excluye clientes o pedidos específicos del seguimiento, y configura selectores personalizados para temas que se desvían del diseño estándar de PrestaShop.
Disponible desde v2.0
Resumen
El panel de Opciones Avanzadas cubre casos límite y requisitos de compatibilidad que no afectan a la mayoría de las tiendas. Si tu pixel está registrando correctamente y tus eventos Purchase son precisos, puedes dejar todo aquí con sus valores predeterminados.
Necesitarás este panel cuando:
- Tu tema no incluye el hook de pie de página estándar de PrestaShop, por lo que el pixel nunca se dispara
- Los pedidos de un módulo de pago específico no se están registrando porque usa un flujo no estándar
- Los pedidos de personal, pedidos de revendedores o compras de prueba internas aparecen en las estadísticas de tu campaña de Meta
- Tu CDN o caché de servidor está sirviendo una versión desactualizada del script del pixel
- Tu tema usa un botón personalizado para Añadir al Carrito, o un módulo de checkout no estándar
El panel está dividido en varias secciones: Optimización de Carga del Pixel, Opciones de Conversión, Evento de Reembolso/Cancelación, Filtrado de Clientes, Opciones de Visualización, Opciones de Registro, Opciones de PageView, Detección de Inicio de Checkout, Prevención de Caché y Selectores Personalizados. Cada sección se describe a continuación.
Configuración
Optimización de Carga del Pixel
Estos ajustes controlan dónde y cuándo se inyecta el script del pixel en las páginas de tu tienda.
| Campo | Predeterminado | Descripción |
|---|---|---|
| Forzar Pixels en Header | Desactivado | Carga el pixel en el <head> en lugar del pie de página. Actívalo solo cuando tu tema no incluya el hook de pie de página de PrestaShop. El enfoque de pie de página es preferible porque evita bloquear el renderizado de la página. |
| Carga diferida | Desactivado | Retrasa la inicialización del pixel hasta después de que la página termine de cargar. Puede reducir el tiempo de carga percibido en conexiones lentas, pero cualquier acción del cliente que ocurra antes de que termine el retraso no se registrará. |
| Segundos de diferimiento | 0 | Segundos a esperar después de que la página haya cargado por completo antes de que el pixel se inicialice. Valor recomendado: 2–3 segundos cuando la carga diferida está activada. Solo números enteros. |
| Diferir solo la primera vez | Activado | Aplica la carga diferida solo en la primera página de una sesión. En páginas posteriores, el script del pixel ya está en la caché del navegador y se carga instantáneamente, por lo que el diferimiento no es necesario. Deja esto activado siempre que la carga diferida esté activa. |
Forzar Pixels en Header y Carga diferida abordan problemas diferentes. Si activas ambos, el pixel se dispara desde el header inmediatamente — el diferimiento no tiene efecto. Elige un enfoque según tu situación.
Opciones de Conversión
Estos ajustes controlan cómo se disparan y validan los eventos Purchase.
| Campo | Predeterminado | Descripción |
|---|---|---|
| Excluir pedidos del Back Office | Activado | Los pedidos creados desde el Back Office (por el personal) no disparan un evento Purchase. Mantén esto activado a menos que quieras específicamente que se registren los pedidos del personal. |
| Usar Ajax para confirmar que la conversión se ha enviado | Activado | El navegador valida la disponibilidad del pixel mediante AJAX antes de disparar el evento Purchase. Esto evita eventos perdidos para métodos de pago que redirigen al cliente fuera de la página de confirmación estándar. Recomendado — déjalo activado. |
| Usar Cookies para evitar duplicados de conversión | Desactivado | Evita que el evento Purchase se dispare una segunda vez para el mismo pedido si la página de confirmación se recarga o se sirve desde caché. Actívalo si ves conversiones duplicadas causadas por un módulo de caché o Cloudflare. |
| Forzar el Modo Básico del evento Purchase para | Ninguno | Casillas por módulo de pago. El Modo Básico fuerza que el evento Purchase se dispare cuando el cliente visita la página de confirmación del pedido, evitando el flujo de detección estándar. Necesario para módulos de pago que usan flujos de confirmación de pedido no estándar. Actívalo solo para los métodos de pago específicos que lo necesiten. Nota: el modo básico no evita duplicados por sí solo — activa también el modo cookie si se producen duplicados. |
| ¿Recargar después del pedido? | Desactivado | Fuerza una recarga de página única después de que se cargue la página de confirmación del pedido. Para un pequeño número de módulos de pago que muestran la confirmación antes de que el pedido esté completamente validado en PrestaShop. Normalmente no es necesario. |
| Excluir el envío del total del pedido | Desactivado | Informa el total del pedido sin los costes de envío en el campo de valor del evento Purchase. El envío se guarda como un campo personalizado dentro del evento. |
| ¿Enviar el importe del pedido con impuestos? | Activado | Cuando está activado, el valor de Purchase incluye impuestos. Desactívalo para informar importes sin impuestos. |
| Registrar solo pedidos con Pago Validado | Desactivado | Función beta. Cuando está activada, solo los pedidos que alcanzan un estado de pago validado disparan un evento Purchase de inmediato. Los pedidos con pago no validado se retienen hasta el número de días establecido a continuación. Si se validan dentro de ese período, el evento Purchase se envía retroactivamente vía la API de Conversiones. Requiere que CAPI esté configurada. |
| Límite de validación de pedidos no validados | 7 días | Cuántos días se retiene un pedido pendiente antes de descartarlo. Solo se aplica cuando "Registrar solo pedidos con Pago Validado" está activado. |
| Estados de pedido a excluir | Ninguno | Los eventos Purchase se suprimen cuando un pedido alcanza cualquiera de los estados seleccionados. Úsalo para excluir estados marcados como fraude, de prueba o administrativos. |
Modo de Depuración del evento Purchase (descrito más abajo en Filtrado de Clientes) evita toda la lógica de deduplicación. Nunca lo dejes activo en una tienda en producción.
Evento de Reembolso / Cancelación
El evento Refund es la señal canónica de reembolso solo-CAPI. La configuración y las notas viven en la única fuente de verdad en Evento de Reembolso.
Filtrado de Clientes
Estos ajustes te permiten suprimir eventos Purchase para clientes o grupos específicos.
| Campo | Predeterminado | Descripción |
|---|---|---|
| Grupos de clientes a excluir | Ninguno | Los eventos Purchase se suprimen para clientes pertenecientes a los grupos seleccionados (por ejemplo, Empleados, Revendedores, Interno). Este es un ajuste por tienda. |
| ID de cliente a excluir | — | Lista separada por comas de IDs de cliente de PrestaShop. Los eventos Purchase se suprimen para estos clientes específicos. Este es un ajuste global — se aplica a todas las tiendas en una configuración multi-tienda. |
| Modo de Depuración del evento Purchase | Desactivado | Evita toda la lógica de deduplicación y permite que el mismo pedido dispare el evento Purchase varias veces. Úsalo solo para pruebas en un entorno de desarrollo. Causa estadísticas infladas en Meta si se deja activado. |
Opciones de Visualización
| Campo | Valores | Predeterminado | Descripción |
|---|---|---|---|
| Uso de External ID | Solo en usuarios registrados / Todos los usuarios | Solo en usuarios registrados | Controla cuándo se genera el identificador de coincidencia entre dispositivos (external_id). Lo predeterminado es lo recomendado: generar un external_id para visitantes invitados y luego uno diferente después de que se registren crea dos IDs para la misma persona, lo que puede causar problemas de atribución en Meta. |
Opciones de Registro
| Campo | Predeterminado | Descripción |
|---|---|---|
| Usar Ajax para confirmar Registros de Clientes | Activado | Valida eventos CompleteRegistration mediante AJAX. Recomendado — déjalo activado. |
Opciones de PageView
| Campo | Predeterminado | Descripción |
|---|---|---|
| Restringir PageView a controladores conocidos | Desactivado | Cuando está activado, los eventos PageView solo se disparan en páginas estándar de PrestaShop: producto, categoría, carrito, checkout, CMS y páginas de contacto. Cuando está desactivado, PageView se dispara en cada página, incluidos errores 404 y páginas de módulos personalizados. |
Detección de Inicio de Checkout
| Campo | Valores | Predeterminado | Descripción |
|---|---|---|---|
| Modo de Inicio de Checkout | Página inicial / Clic en el botón | Página inicial | Página inicial dispara el evento InitiateCheckout cuando el cliente llega por primera vez al checkout. Clic en el botón se dispara cuando el cliente hace clic explícitamente en "Continuar al Checkout". Usa el modo de botón si ves eventos InitiateCheckout duplicados en el Administrador de Eventos de Meta. |
Prevención de Caché
| Campo | Valores | Predeterminado | Descripción |
|---|---|---|---|
| Prevención de Caché de Archivos Estáticos | Desactivado / Siempre / Diario / Semanal / Mensual / Trimestral | Desactivado | Añade un parámetro dinámico de anti-caché a las URL de archivos estáticos de Pixel Plus. Actívalo solo cuando un CDN o caché de servidor (LiteSpeed, Nginx, Cloudflare) esté sirviendo una versión desactualizada del script del pixel tras una actualización del módulo. Elige una frecuencia que coincida con la frecuencia con la que actualizas el módulo. |
| Prevención de Caché Mejorada | Desactivado / Activado | Desactivado | Añade parámetros extra a las llamadas AJAX para evitar que las respuestas en caché interfieran con el seguimiento. Actívalo solo si experimentas eventos perdidos o comportamiento inconsistente del pixel causado específicamente por la caché a nivel de servidor. |
Selectores Personalizados
Estos campos son para tiendas cuyos temas o módulos no coinciden con el diseño estándar de PrestaShop.
| Campo | Descripción |
|---|---|
| Selector personalizado de Añadir al Carrito | Selector jQuery o CSS para un botón de Añadir al Carrito personalizado. Úsalo cuando tu tema sobrescribe el botón predeterminado y los eventos AddToCart no se disparan. |
| Selector de inicio de personalización | Selector CSS para un botón de personalización de producto — un botón en el que el cliente debe hacer clic antes de personalizar un producto. Déjalo en blanco si tu tienda no usa personalización de producto. |
| Nombre del módulo (Página de Checkout Personalizada) | Nombre técnico de un módulo de checkout personalizado si tu tienda no usa el checkout estándar de PrestaShop. Se usa para disparar eventos InitiateCheckout desde las páginas del módulo personalizado. |
| Controlador de búsqueda | Nombre del controlador de un módulo de búsqueda personalizado. Visible en la URL después del parámetro controller= cuando se realiza una búsqueda. Déjalo en blanco para usar el SearchController predeterminado de PrestaShop. |
| Parámetro de consulta de búsqueda | Nombre del parámetro URL para la cadena de consulta de búsqueda. Valores comunes: s, q, term. Déjalo en blanco para usar el predeterminado. |
Cómo Funciona
Estrategia de Carga del Pixel
Por defecto, el script del pixel se carga en el pie de página. Este es el enfoque más seguro: los scripts de pie de página no bloquean el renderizado de la página, por lo que tu tienda parece cargar más rápido. Si tu tema no incluye los hooks displayFooter o displayBeforeBodyClosingTag, el pixel nunca se dispara — activa Forzar Pixels en Header para inyectarlo desde la etiqueta <head> en su lugar.
La carga diferida es una tercera opción: el pixel espera hasta que toda la página haya terminado de renderizarse antes de inicializarse. Esto puede mejorar las puntuaciones de PageSpeed porque el pixel ya no está en la ruta crítica de renderizado. La contrapartida es que las acciones del visitante realizadas inmediatamente después de que la página se cargue — antes de que haya pasado el retraso configurado — no se capturarán. El refinamiento "Diferir solo la primera vez" resuelve la mayor parte de esto: una vez que el script del pixel está en la caché del navegador desde una página anterior en la misma sesión, se carga esencialmente al instante y el diferimiento es innecesario.
Entrega del Evento Purchase
La mayoría de los módulos de pago siguen un flujo estándar: el cliente completa el pago, el módulo de pago redirige a la página de confirmación del pedido de PrestaShop, y el módulo dispara el evento Purchase desde ahí. Cuando un módulo de pago usa su propia página de confirmación o redirige al cliente fuera del flujo estándar de PrestaShop, la detección estándar falla. Forzar el Modo Básico del evento Purchase indica al módulo que recurra a disparar en la URL de la página de confirmación independientemente de cómo se creó el pedido.
Usar Ajax para confirmar que la conversión se ha enviado añade una capa de validación: antes de disparar el evento Purchase desde el navegador, el módulo comprueba mediante AJAX que el pedido se ha registrado correctamente. Esto evita que el evento falle cuando una redirección de pago interrumpe la carga normal de la página.
Filtrado de Clientes
La exclusión por grupo de clientes (FCTP_ORDER_CUSTOMER_GROUP_EXC) se evalúa en el momento en que el evento Purchase normalmente se enviaría. Si el cliente que realiza el pedido pertenece a un grupo excluido, el evento se omite silenciosamente. El pedido se procesa normalmente en PrestaShop — solo se suprime el seguimiento de Meta.
La exclusión por ID de cliente (FCTP_ORDER_CUSTOMER_ID_EXCLUDE) funciona de la misma manera para individuos específicos en lugar de grupos. Al ser un ajuste global, se aplica a todas las tiendas en una configuración multi-tienda — útil para excluir una cuenta usada para pruebas regulares entre tiendas.
Ejemplos de Uso
Ejemplo: Tema sin hook de pie de página
Tu tienda usa un tema personalizado que se construyó sin los hooks de pie de página estándar de PrestaShop. El pixel nunca se dispara porque el punto de inyección de pie de página no existe. Activa Forzar Pixels en Header — el pixel se inyecta entonces en el <head> de cada página, que todos los temas incluyen.
Ejemplo: Pedidos de personal y revendedores inflando las estadísticas de conversión Notas que el recuento de eventos Purchase de Meta es superior a tus ventas reales de clientes porque se incluyen pedidos de personal y de revendedores. Añade tus grupos de clientes "Empleados" y "Revendedores" a Grupos de clientes a excluir. A partir de ese momento, los pedidos de esos grupos no generan un evento Purchase, mientras que los propios pedidos siguen procesándose normalmente en PrestaShop.
Ejemplo: Eventos Purchase duplicados por una caché de página Tu tienda ejecuta un plugin de caché de página completa y estás viendo eventos Purchase duplicados para el mismo pedido en Meta. Activa Usar Cookies para evitar duplicados de conversión — el módulo establece una cookie de corta duración cuando se dispara el evento Purchase, y si la página de confirmación se carga de nuevo (desde caché) la cookie evita que se envíe un segundo evento.
Ejemplo: CDN sirviendo un script de pixel desactualizado Después de actualizar Pixel Plus, algunos visitantes siguen disparando eventos usando lógica de seguimiento antigua porque tu CDN cacheó la versión anterior del script. Establece Prevención de Caché de Archivos Estáticos en Semanal — esto añade un parámetro basado en fecha a la URL del script que cambia semanalmente, forzando al CDN a obtener y servir el archivo actualizado.
Ejemplo: InitiateCheckout disparándose dos veces Ves dos eventos InitiateCheckout por sesión de checkout en el Administrador de Eventos de Meta. Esto ocurre cuando el cliente tanto llega a la página de checkout como hace clic en un botón "Continuar", ambos disparando el evento. Cambia Modo de Inicio de Checkout de Página inicial a Clic en el botón para que el evento solo se dispare con el clic explícito.
Notas Importantes
- Forzar Pixels en Header y Carga diferida se pueden activar al mismo tiempo, pero el resultado es que la colocación en el header gana: el script se carga inmediatamente desde el
<head>. No hay ningún beneficio combinado — elige la opción que se ajuste a tu situación. - Modo de Depuración del evento Purchase nunca debe dejarse activo en una tienda en producción. Evita todas las comprobaciones de deduplicación y provoca recuentos inflados del evento Purchase en Meta, lo que corrompe los datos de optimización de campañas.
- ID de cliente a excluir es un ajuste global — se aplica a todas las tiendas en una configuración multi-tienda. La exclusión por grupo de clientes es por tienda.
- Registrar solo pedidos con Pago Validado es una función beta y requiere que la API de Conversiones esté activa. Los pedidos retenidos en la cola pendiente se procesan retroactivamente mediante la CAPI — el pixel del navegador no envía eventos retrasados.
- Prevención de Caché de Archivos Estáticos aumenta las tasas de fallo de caché del CDN para los archivos estáticos de Pixel Plus. Actívalo solo cuando hayas confirmado que la caché de archivos obsoletos está causando activamente un problema de seguimiento.
- El ajuste Uso de External ID afecta a la atribución entre dispositivos en Meta. Cambiarlo de "Solo en usuarios registrados" a "Todos los usuarios" generará valores de
external_idpara visitantes invitados. Si un invitado se registra más tarde, tendrá dos valores deexternal_iddiferentes, lo que puede reducir la precisión de la atribución.
Solución de Problemas
| Problema | Solución |
|---|---|
| El pixel no se dispara en absoluto en la tienda | Tu tema probablemente no incluye un hook de pie de página. Activa Forzar Pixels en Header. |
| Faltan eventos AddToCart en un tema personalizado | Añade el selector jQuery/CSS para el botón de Añadir al Carrito de tu tema en Selector personalizado de Añadir al Carrito. |
| InitiateCheckout se dispara dos veces por checkout | Cambia Modo de Inicio de Checkout de Página inicial a Clic en el botón. |
| Pedidos de personal o pruebas internas aparecen en las estadísticas de Meta | Asegúrate de que Excluir pedidos del Back Office esté activado. Añade también IDs de clientes internos o un grupo de clientes de personal a los campos de exclusión. |
| Eventos PageView de páginas de error 404 contaminando los datos de Meta | Activa Restringir PageView a controladores conocidos. |
| Eventos Purchase duplicados en Meta | Activa Usar Cookies para evitar duplicados de conversión. Asegúrate también de que el módulo de pago para el que se producen duplicados no esté configurado en Modo Básico sin protección de cookie. |
| Eventos Purchase no registrados para un método de pago específico | Activa Forzar el Modo Básico del evento Purchase para ese módulo de pago. Si aparecen duplicados después, activa también Usar Cookies para evitar duplicados de conversión. |
| Se sirve un script de pixel desactualizado tras una actualización del módulo | Activa Prevención de Caché de Archivos Estáticos y elige una frecuencia adecuada (Diario o Semanal). |
| Faltan eventos que parecen relacionados con la caché de AJAX | Activa Prevención de Caché Mejorada para añadir parámetros anti-caché a las llamadas AJAX. |
Preguntas Frecuentes
¿Debería activar la carga diferida en mi tienda?
Solo si has confirmado que el script del pixel está en la ruta crítica de renderizado y afecta a tu puntuación de PageSpeed. Para la mayoría de las tiendas, la carga predeterminada en el pie de página es suficiente y garantiza que no se pierda ningún evento. Si la activas, activa también 'Diferir solo la primera vez' para minimizar el riesgo de perder eventos en visitantes recurrentes.
¿Debería informar el valor de Purchase con o sin envío?
La mayoría de los anunciantes incluyen el envío para informar el importe de ingresos completo. Si comparas el valor de Purchase informado por Meta con tus propios informes de ingresos, lo más importante es la coherencia con el método que usa tu contabilidad. Elige el ajuste que coincida con cómo mides los ingresos en otros lugares.
¿Cuál es la diferencia entre 'Solo en usuarios registrados' y 'Todos los usuarios' para External ID?
external_id es un identificador de coincidencia entre dispositivos que Meta usa para vincular las acciones de un visitante entre sesiones y dispositivos. Con 'Solo en usuarios registrados', solo se genera un ID estable una vez que el visitante tiene una cuenta. Con 'Todos los usuarios', también se crea un ID temporal para visitantes invitados. El riesgo con 'Todos los usuarios' es que un invitado que se registre más tarde recibirá un segundo ID diferente — Meta puede tratarlos como dos personas separadas, reduciendo la precisión de la atribución.
Mi módulo de pago personalizado no se está registrando. ¿Qué debería probar primero?
Primero, activa Forzar el Modo Básico del evento Purchase para ese módulo de pago. Esto fuerza que el evento Purchase se dispare cuando el cliente llega a la página de confirmación del pedido, independientemente de cómo se procesó el pago. Si aparecen eventos duplicados después de activar el modo básico, activa también Usar Cookies para evitar duplicados de conversión.
¿Puedo excluir solo uno o dos clientes específicos sin crear todo un grupo de clientes?
Sí. Introduce sus IDs de cliente de PrestaShop como una lista separada por comas en ID de cliente a excluir. Ten en cuenta que este es un ajuste global — se aplica a todas tus tiendas en una configuración multi-tienda, no solo a la tienda actual.
¿Qué ocurre con los pedidos retenidos en la cola pendiente si el pago nunca se valida?
El módulo retiene los pedidos no validados durante el número de días establecido en Límite de validación de pedidos no validados (7 días por defecto). Si el pedido no se valida dentro de ese período, el evento Purchase se descarta y nunca se envía a Meta. Esto evita que pedidos obsoletos o fallidos generen señales de conversión falsas.
Funciones Relacionadas
- Ajustes Avanzados del Evento Purchase — Seguimiento solo de pedidos validados, pagos diferidos, prevención de duplicados y exclusiones de estado de pedido.
- Eventos Registrables — Activar, desactivar y personalizar valores para todos los eventos registrados.
- GDPR y Consentimiento de Cookies — El bloqueo de consentimiento interactúa con cómo y cuándo se carga el pixel.
- API de Conversiones (CAPI) — Necesaria para que funcionen el evento Refund y los eventos Purchase diferidos.