Ventas que no llegan a Analytics: el cliente no vuelve de Redsys

Si en PrestaShop tienes más ventas que en Google Analytics 4 o en tu herramienta de marketing, mira primero cómo vuelve el cliente desde Redsys. En el caso que se vio en el grupo, la mayoría de las ventas perdidas eran de clientes que pagaban y cerraban la pestaña en el recibo de Redsys. La solución corta: que Redsys devuelva al cliente a la tienda sin mostrar su recibo, y enviar las ventas desde el servidor.

Por qué se pierden las ventas

Casi todos los códigos de medición registran la compra cuando el cliente ve la página de confirmación del pedido. Gustavo, de la comunidad, lo explicaba así: si esa página no llega a cargarse, el gancho de la confirmación (displayOrderConfirmation) no se ejecuta y la venta no se envía. Pasa en tres casos:

• El cliente no vuelve a la tienda. Redsys le enseña su propio recibo con un botón «Continuar». Quien ya ha pagado muchas veces no lo pulsa.
• Lleva un bloqueador de publicidad o un navegador que bloquea el seguimiento. Una compañera lo comprobó al 100%: con bloqueador, la venta no llegaba.
• No ha aceptado las cookies. Con el modo de consentimiento de Google, a Analytics le llegan señales, pero según Gustavo los pedidos de quien rechaza las cookies se pierden si no se envían por otra vía.

El arreglo en Redsys

En el portal de Redsys (canales Redsys), en la configuración del comercio, hay una opción para los parámetros en las URL que permite volver a la tienda sin mostrar el recibo de Redsys. Con ella, tras el pago el cliente aterriza directamente en la confirmación del pedido. La compañera que abrió el hilo lo activó y dejó de perder casi todas las ventas en su herramienta de marketing; otro miembro confirmó que le resolvió el mismo problema.

Ten en cuenta que el ajuste es del terminal: afecta a todos los pagos que pasan por él, con tarjeta o con Bizum. Los menús del portal cambian algo según el banco, así que puede que la opción no esté en el mismo sitio en el tuyo.

Lo que queda: enviar la venta desde el servidor

Aunque el cliente vuelva, el bloqueador y el rechazo de cookies siguen ahí. Para eso, la venta hay que mandarla desde el servidor cuando se valida el pedido, no desde el navegador cuando se ve una página. Se habló de tres formas:

• Un script con tarea programada que busca los pedidos que no se enviaron a la herramienta y los manda uno a uno. Una compañera lo tenía hecho con un script PHP en cron que miraba qué pedidos había marcado como no enviados su módulo de etiquetas; si haces algo así, protégelo con un token.
• Un módulo que envía las compras por API a Google Analytics 4 y a las plataformas de publicidad. Gustavo tiene uno para Analytics 4 con modo de consentimiento.
• Gustavo contó que asigna un identificador de cliente fijo a los pedidos de quien no acepta cookies, para que la venta cuente aunque no se pueda atribuir. Si usas algo parecido, revisa con quien te lleve la parte legal cómo usas ese identificador.

Un caso parecido: GA4 recibe la compra con 0 €

Otro compañero veía en GA4 los artículos y las unidades de algunos pedidos, pero con importe 0 €, y en otros el importe sin IVA. Antes de culpar al módulo, Gustavo le propuso dos pruebas: haz un pedido con un bloqueador instalado y otro rechazando las cookies, y mira si esos pedidos llegan. Si no entran, el fallo está en el bloqueo, en el consentimiento o en que el pedido no se confirma, no en el cálculo del importe.

En Rekire tenemos RKR API Conversions Pro, que envía las conversiones desde el servidor a Meta, GA4 y Google Ads, y el pack Medición que no se pierde para dejarlo configurado.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación