Cloudflare Zaraz para WooCommerce: eventos de ecommerce, consentimiento y pruebas

Cloudflare Zaraz puede enviar los eventos de ecommerce compatibles a herramientas de analítica y publicidad, pero WooCommerce sigue necesitando una fuente fiable de datos de producto, carrito, checkout y pedido. Una configuración en producción depende de la vía de integración, de reglas de consentimiento explícitas y de pruebas que comparen el seguimiento con los pedidos reales de la tienda.

¿Qué cambia Cloudflare Zaraz en el seguimiento de WooCommerce?

Zaraz encamina a través de Cloudflare las acciones compatibles de herramientas de terceros. WooCommerce o una integración siguen teniendo que emitir los eventos y datos de venta, y cada herramienta de destino, plugin y flujo de checkout necesita su propia comprobación de compatibilidad.

Zaraz ofrece una Web API de ecommerce con eventos con nombre a lo largo de todo el recorrido de compra, desde la actividad de producto y carrito hasta los pedidos completados y reembolsados. La referencia de Cloudflare enumera 19 nombres de evento compatibles, exige activar el seguimiento de ecommerce en la cuenta y en cada herramienta receptora, y advierte de que las cargas de pedido grandes pueden superar los límites de una herramienta de destino.

WooCommerce sigue siendo la fuente del estado de la venta. Sabe qué producto ha elegido el cliente, qué hay en el carrito y si un pedido ha llegado al estado que su empresa cuenta como compra. Zaraz envía los eventos a las herramientas configuradas.

Un evento puede aparecer en Zaraz y aun así no llegar a una herramienta de destino: su acción está desactivada, la carga no coincide con lo que espera la herramienta, la herramienta no admite ese evento de forma automática o el consentimiento lo ha bloqueado.

Trasladar las acciones de seguimiento a Zaraz puede reducir los scripts de terceros que el navegador ejecuta directamente. Varias herramientas, entre ellas la herramienta de Facebook de Zaraz, envían sus solicitudes desde el edge de Cloudflare en lugar de cargar un script del proveedor. El cargador de Zaraz se sigue ejecutando y algunas herramientas siguen funcionando en el navegador, así que mida las páginas de producto, carrito y checkout antes y después del cambio. El trabajo de optimización de velocidad de WordPress de IMADO puede incluir esta medición cuando los cambios de seguimiento forman parte de una revisión de rendimiento más amplia.

¿Cómo deben asignarse los eventos de WooCommerce a los eventos de ecommerce de Zaraz?

Use un único contrato de eventos documentado para producto, carrito, checkout y pedido, con IDs de producto, IDs de pedido, moneda, cantidades y valores coherentes. Emita Order Completed solo cuando se cumpla la condición de compra de la tienda.

Una llamada mínima a Order Completed con los campos que documenta Zaraz tiene este aspecto:

zaraz.ecommerce('Order Completed', {
  order_id: '10482',
  total: 349.00,
  revenue: 300.81,
  tax: 48.19,
  shipping: 0,
  currency: 'PLN',
  products: [
    { product_id: '275333', sku: 'DDS-M1', name: 'Silk scarf', variant: '63 x 63 cm', price: 349.00, quantity: 1 }
  ]
});

Decida si la empresa registra un pedido cuando el pago se autoriza, cuando se cobra o cuando se alcanza otro estado del pedido. Esto importa en las transferencias bancarias, el pago contra reembolso, las redirecciones de pago y las suscripciones, donde la finalización del checkout y la liquidación ocurren en momentos distintos.

Los productos variables necesitan una regla de ID pensada

Muchos clientes abren un producto variable y nunca eligen una variación. Los feeds de productos también difieren: un feed de Google Merchant Center suele listar las variaciones, mientras que los catálogos de Meta agrupan las variaciones bajo un producto principal. Una regla práctica es una vista de producto por carga de página: envíe el ID de la variación cuando exista una variación predeterminada o seleccionada y, si no, envíe a Meta el ID del producto principal con contenttype: productgroup. No envíe otra vista cada vez que el cliente cambie de variación.

Mantenga coherentes los campos de importe y los identificadores de producto

Use un ID de pedido estable para conciliar las compras entre WooCommerce y la analítica, y reutilícelo como ID de evento para que las herramientas de destino puedan eliminar duplicados de los reintentos. Indique la moneda de forma explícita. Deje por escrito si el valor de la compra incluye impuestos y envío y cómo se tratan los descuentos, y después asigne esos campos de la misma forma en todas las herramientas. Si una herramienta recibe un total bruto y otra un valor neto de mercancía, los informes no coincidirán aunque ambos flujos funcionen.

Trate los bloques de checkout y las redirecciones de pago como casos de prueba separados

Un clic en «Realizar el pedido» inicia el checkout. La validación puede fallar, un proveedor puede rechazar un cargo o una redirección puede volver sin un pedido correcto. Envíe los ingresos de la compra solo cuando WooCommerce o el flujo de pago los confirmen.

El checkout clásico, el Checkout Block, los carritos AJAX, los botones de pago exprés y las páginas de pago externas exponen eventos y rutas de retorno diferentes. Escuche los puntos de extensión del checkout que realmente utiliza y verifique el resultado con el registro final del pedido.

¿Plugin de WooCommerce o conexión de eventos de Zaraz a medida?

Use una integración con mantenimiento cuando sea compatible con su checkout, su configuración de consentimiento, sus herramientas de destino y su contrato de eventos. Elija una conexión a medida cuando el checkout o las reglas de pedido requieran un control que el plugin no ofrece.

Antes de adoptar un plugin, confirme que:

• Es compatible con su versión de WooCommerce, su tipo de checkout, sus métodos de pago y sus tipos de producto.
• Envía los nombres de evento y los campos que exigen sus herramientas de destino.
• Su integración de consentimiento funciona con su gestor de consentimiento.
• Puede revisar, exportar y restaurar la configuración de Zaraz.
• El equipo sabe qué sistema es responsable de cada evento y dónde investigar los problemas.

Antes de importar una configuración de Zaraz generada, revise los disparadores, las acciones y los ajustes de herramientas que modifica, pruébela en un entorno controlado y confirme cómo revertirla. Una auditoría de sitio WordPress puede revisar los plugins existentes, el seguimiento y el flujo de checkout antes de que usted elija.

Una conexión a medida suele encajar con checkouts personalizados, suscripciones, confirmación de pago diferida, reglas multimoneda, estados de pedido gestionados por un ERP o una combinación de señales del navegador y del servidor. Permite a los ingenieros definir cuándo se disparan los eventos y cómo se gestionan los reintentos, los reembolsos y los callbacks duplicados, y necesita un responsable cuando cambian WooCommerce, las pasarelas de pago o las extensiones.

Un enfoque híbrido puede funcionar: un plugin para los eventos estándar de producto y carrito, y una pequeña integración propia para una regla de compra o reembolso particular. Mantenga una única fuente de verdad por evento. Plugins, etiquetas de Google Tag Manager y acciones de Zaraz que se solapan para el mismo píxel pueden contar una misma compra varias veces.

Si está valorando estas opciones para una tienda con un checkout personalizado o varias plataformas publicitarias, hable con los ingenieros de WooCommerce de IMADO antes de decidir el enfoque.

¿Cómo se debe configurar el consentimiento de Cloudflare Zaraz en WooCommerce?

Asigne cada herramienta de terceros a una finalidad de consentimiento explícita y compruebe después que el consentimiento denegado la detiene. La documentación de Consent Management de Cloudflare indica que cada herramienta tiene una finalidad y que una herramienta sin asignar omite por defecto la comprobación del consentimiento, de modo que una herramienta recién añadida puede saltarse el control si nadie la asigna.

Incluya el inventario de consentimiento en la checklist de publicación: cada herramienta, su finalidad, el destino, los eventos que recibe y el estado de consentimiento que necesita.

Pruebe al menos estos estados:

• Todavía sin elección: las herramientas opcionales no envían nada antes del consentimiento.
• Consentimiento denegado: las solicitudes a la herramienta correspondiente se detienen.
• Consentimiento concedido: los eventos esperados llegan a la herramienta.
• Preferencia modificada: la herramienta sigue la nueva elección tras una recarga.
• Sesión recurrente: las preferencias guardadas se aplican sin una nueva acción de carrito o pedido.

Revise en especial la primera carga de página. La API de consentimiento de Zaraz suele estar disponible después de que se ejecuten los scripts propios de la página, por lo que una integración que compruebe el consentimiento de inmediato puede tratar a un visitante que ha dado su consentimiento como si no lo hubiera dado y descartar el evento. Espere a la API antes de decidir:

function onConsentReady(callback) {
  if (window.zaraz && zaraz.consent && zaraz.consent.APIReady) callback();
  else document.addEventListener('zarazConsentAPIReady', callback, { once: true });
}

Si las herramientas de Google funcionan en el modo avanzado de Consent Mode v2, pueden seguir enviando pings sin cookies cuando se deniega el consentimiento. Decida si eso se ajusta a su política y pruébelo de forma explícita.

Mantenga el funcionamiento de la tienda independiente del seguimiento: el carrito, la cuenta y el pago deben funcionar cuando un cliente rechaza las finalidades opcionales. Envíe solo los campos que necesita cada herramienta y no incluya datos personales en las cargas de eventos compartidas. Zaraz aplica las preferencias que usted configura; es el propietario del sitio quien decide qué finalidades y textos corresponden a cada mercado, así que pida a su responsable de privacidad o asesoría legal que los revise.

¿Cómo se prueban los eventos de ecommerce de Cloudflare Zaraz antes del lanzamiento?

Valide un pedido de prueba desde WooCommerce, pasando por Zaraz, hasta cada herramienta de destino en Preview o en staging, y luego compare los eventos y valores con el pedido de WooCommerce. Una página sin errores de JavaScript no demuestra que una compra se haya contado una sola vez ni que el consentimiento haya funcionado.

Siga una sesión de prueba y anote el evento esperado en cada paso: vista de producto, añadir al carrito, vista del carrito, inicio del checkout, resultado del pago, compra y reembolso. Revise por separado el evento de origen, el disparador y la acción de Zaraz y la herramienta receptora; un fallo en una capa parece en el panel final una laguna genérica de datos.

La matriz de pruebas debe incluir:

• Una sesión nueva sin elección de consentimiento y, después, consentimiento denegado y concedido, incluida la aceptación en la página de entrada.
• Un producto variable con y sin variación seleccionada, un cambio de cantidad y la eliminación de un artículo.
• Cupones, descuentos, envío, impuestos y cada moneda de la que informe.
• Cada tipo de pago: rechazado, pendiente, con redirección y correcto.
• Un pedido correcto seguido de una recarga de la página de confirmación.
• Un reembolso parcial o total, si informa de reembolsos.
• Cada vía de checkout que use la tienda: Checkout Block, AJAX, suscripción, pago exprés.

Guarde el ID de cada pedido de prueba y busque ese mismo ID en la herramienta de destino. Las herramientas de prueba de los proveedores ayudan: Test Events de Meta muestra si un evento de servidor incluía datos de usuario e IDs de producto. Elimine de la herramienta cualquier código de eventos de prueba antes de publicar, porque los eventos enviados con un código de prueba no cuentan en los informes de producción.

Use Zaraz Monitoring para separar el recuento de eventos de los disparadores, las acciones y los estados de las solicitudes del lado del servidor. Si Zaraz contó un evento pero la herramienta de destino no lo recibió, revise la configuración de la herramienta y su respuesta. Si Zaraz nunca lo contó, revise la integración de WooCommerce y el momento en que se dispara el evento. Registre los resultados aceptados y la versión de la configuración antes de publicar.

¿Qué falla en producción?

Los problemas más dañinos son las compras falsas y duplicadas, el consentimiento que se elude y los eventos que desaparecen sin avisar. Estos son los patrones que vemos con más frecuencia cuando las tiendas WooCommerce trasladan su seguimiento a Zaraz.

Los eventos de ecommerce se comparten con todas las herramientas que tienen el ecommerce activado.

Una llamada a zaraz.ecommerce() llega a todas las herramientas con el seguimiento de ecommerce activado, con la misma carga, y los campos no se pueden filtrar por herramienta. No incluya nunca direcciones de correo electrónico ni números de teléfono en los eventos de ecommerce. Para los datos específicos de una herramienta, envíe un evento zaraz.track() aparte con una propiedad de enrutamiento, asócielo solo al disparador de esa herramienta y use una regla como {{ client._zarazTrack }} igual a viewitem combinada con su indicador de enrutamiento.

La caché de página completa conserva la configuración de seguimiento antigua.

La configuración y las versiones de scripts que se imprimen en el HTML permanecen en las cachés de Cloudflare y del servidor tras un despliegue. Las páginas de producto y categoría en caché siguen enviando la estructura de eventos antigua, mientras que las páginas de carrito y checkout sin caché envían la nueva. Purgue las cachés de páginas, de recursos minificados y de Cloudflare con cada publicación de cambios de seguimiento.

Las herramientas del lado del servidor siguen necesitando datos de identidad limpios.

La herramienta de Facebook de Zaraz envía los eventos a través de la Conversions API y aplica ella misma el hash al correo electrónico, al teléfono y a otros campos de usuario. Envíe valores sin procesar normalizados: correo en minúsculas, teléfono con prefijo de país, código postal sin espacios ni guiones. Los valores con hash previo se procesan dos veces y dejan de coincidir. Un ID externo estable, como un hash del correo del cliente guardado en una cookie HttpOnly propia, permite asociar a los clientes recurrentes sin almacenar datos personales en el navegador.

Cambiar de herramienta reinicia los identificadores de cliente.

El plugin de píxeles que está sustituyendo probablemente lleva años enviando su propio ID externo. PixelYourSite, por ejemplo, genera un ID aleatorio y lo guarda en una cookie del navegador (pbid), en la cuenta del cliente y en los metadatos de cada pedido. Si la nueva configuración empieza a enviar en su lugar un hash del correo, Meta verá a cada cliente recurrente como una persona nueva, y la calidad de coincidencia y la continuidad de las audiencias caerán. Al planificar la migración, compruebe qué identificadores guarda la configuración actual y dónde. Después, reutilícelos en un orden fijo: el ID guardado en el pedido o en la cuenta del cliente, la cookie heredada y, solo en último lugar, un nuevo hash del correo. Guarde el ID elegido en los pedidos y cuentas nuevos para que se mantenga estable a partir de entonces.

Las acciones comodín generan duplicados.

Una acción genérica de «todos los demás eventos» junto a acciones específicas como ViewCategory dispara ambas, salvo que el disparador genérico excluya todos los eventos que tienen acción propia. Zaraz limita los valores de coincidencia a 128 caracteres, así que mantenga compactos los patrones de exclusión.

Algunos eventos no llegan nunca.

Los bloqueadores de anuncios y la ocultación automática de banners de cookies eliminan una parte de las señales del navegador, incluida la propia atribución de pedidos de WooCommerce. Cuente con una diferencia entre los pedidos y los pedidos atribuidos, mídala y use como referencia las compras confirmadas por el servidor.

Las compras falsas se producen al escuchar el clic de un botón, un paso previo al pago o la visita a una página de agradecimiento sin comprobar el estado del pedido. Use una referencia de pedido duradera y una regla idempotente para que un reintento o una recarga no vuelvan a registrar el pedido.

Si varios de estos puntos le resultan familiares, el problema suele estar en el diseño de la integración y no en un ajuste concreto. El equipo de WooCommerce de IMADO puede auditar el flujo de eventos y corregirlo en staging antes de que llegue a sus informes.

¿Cuándo merece la pena contar con apoyo técnico para una implementación de Zaraz en producción?

Recurra a un ingeniero de WooCommerce cuando las personalizaciones del checkout, el estado del pago, las herramientas de consentimiento o una analítica solapada dificulten demostrar que hay exactamente un evento válido por cada acción en la tienda.

Un ingeniero define el contrato de eventos con marketing y finanzas, elige entre plugin y conexión a medida, lo prueba con el checkout real y el ciclo de vida de los pedidos, y documenta qué herramienta es responsable de cada evento y cómo lo controla el consentimiento. Compensa cuando las compras perdidas o duplicadas afectan a las decisiones de campaña, a la conciliación o a la confianza del equipo en los informes. Tras el lanzamiento, el soporte y mantenimiento de WordPress o un plan de mantenimiento web mantienen las pruebas de regresión dentro del proceso de publicación a medida que cambian los plugins y las pasarelas.

Conclusión

Una configuración fiable de Cloudflare Zaraz para WooCommerce empieza por un contrato de eventos explícito, una finalidad de consentimiento para cada herramienta, una sincronización con el consentimiento en la primera página y pedidos de prueba que cuadren con los registros de la tienda. Elija entre plugin y conexión a medida según el checkout y las reglas de informes que realmente utiliza, y purgue las cachés y vuelva a probar con cada publicación de cambios de seguimiento.

¿Está planificando un despliegue de Zaraz o necesita corregir uno cuyas cifras no cuadran? Hable con IMADO sobre su proyecto de WooCommerce.