Cuatro formas de evitar transacciones duplicadas en tus informes de Comercio Electrónico

Imaginemos que tenemos un site de ecommerce que queremos medir con Google Analytics. Uno de los pasos obligados es instalar el tag de ecommerce en el paso de confirmación de compra. Con esto conseguiremos entre otras cosas tener una estimación de nuestras ventas, conocer los productos más vendidos, y averiguar el tiempo y el número de visitas que necesita un usuario para realizar una compra.

Como vemos, instalar el tag de ecommerce nos aporta una gran cantidad de informaciónvaliosa que nos puede ayudar a mejorar nuestra web (que es para lo que queremos Analytics).

No obstante la instalación del tag de ecommerce no está exenta de problemas. En este post hablaremos sobre uno de ellos, el envío de transacciones duplicadas.

El tag de ecommerce se suele colocar al final de una transacción realizada con éxito. Idealmente solo debería ejecutarse una vez por transacción pero, ¿qué sucede si el usuario recarga la página o guarda el link en favoritos y meses más tarde vuelve a la página? El resultado es que la transacción se vuelve a enviar, con lo cual estamos mandando una transacción “fantasma” o inexistente. El problema se agrava si la página de confirmación es lenta en cargar (porque se queda esperando algún componente), en este caso el usuario puede intentar recargar la misma más de una vez con lo cual nuestras estadísticas se estropearán.

Para evitar que esto suceda, podemos aplicar alguna de las soluciones siguientes:

Solución #1: Usar una cookie para almacenar el valor de la última transacción.

La idea es almacenar en una cookie de sesión el valor de la última transacción enviada. Antes de ejecutar el tag de ecommerce preguntamos si el id de transacción actual coincide con el último id de transacción enviado y, si es así, no realizamos el llamado.

De esta manera nos aseguramos de no enviar nunca transacciones duplicadas, el algoritmo que serviría para implementar esta solución sería:

…Llamado a ga.js y pageTracker…


if (idTransacciónActual != idUltimaTransaccion) {

…Ejecutar tag de ecommerse…

idUltimaTransaccion=idTransaccionActual

}

Incluso se podría plantear el uso de las variables personalizadas proporcionadas por Google Analytics como la cookie que necesitamos para esta solución.

Solución #2: Añadir a cada id de transacción un número aleatorio

De esta manera, se puede identificar en el Analytics las transacciones duplicadas y la fecha en la que se realizó. Esto nos permitiría detectar un problema que se esté produciendo con nuestras páginas de confirmación, cosa que con la primera solución no sería posible. No obstante, al enviar transacciones repetidas al Analytics, estaremos estropeando los datos del ecommerce con lo cual tendremos que exportar los datos y tratarlos con otra herramienta para analizarlos correctamente o aplicar un filtro de sustitución para unificar los valores.

Solución #3: Controlar, mediante programación de servidor, que no se envíen transacciones duplicadas.

Esta solución implica que se tiene acceso a la base de datos donde se almacenan las transacciones y se puede modificar la misma.

La idea es activar un campo en la base de datos que, para cada transacción realizada se compruebe si se mostró la página de confirmación y por tanto, se envió el tag de ecommerce.

Al cargar una página de confirmación, se comprueba si la transacción actual tiene la marca de enviada/mostrada activada, si es así, no se carga el tag de ecommerce.

Esta solución es probablemente la más segura a la hora de evitar el envío de transacciones duplicadas, ya que también nos sirve para controlar los accesos desde emails o en sesiones diferentes. El problema es el nivel de acceso que debemos tener para poder modificar la base de datos.

Solución #4: Asociar una marca de tiempo a cada id de transacción

Como hemos visto en las soluciones anteriores, uno de los inconvenientes que comparten es¿cómo controlar las transacciones que se producen meses después de la original?, por ejemplo cuando un usuario mira un mail de confirmación semanas después de la compra y pincha en el enlace.

La idea consiste en asociar a cada transacción una marca de tiempo o time stamp, de forma que automáticamente el sistema descarta las transacciones cuya diferencia temporal sea mayor de 30 minutos (una sesión).

Esto resuelve el problema de duplicados que se producen por mails de confirmación enviados, o cargas de páginas guardadas en favoritos.

¿Cómo saber si tienes problemas?

Es difícil detectar este problema ya que Google Analytics agrega las transacciones que tienen un mismo ID. Veamos a continuación un ejemplo:

Ejemplo de transacciones duplicadas

En la imagen podemos observar que se han comprado 7 productos cuando en realidad, la transacción original solo incluía 1 producto.

Los 6 productos restantes son el resultado de recargar la página de confirmación. Google Analytics ha agregado todo en una misma transacción, ya que se han producido todas con el mismo ID=1234 al actualizar la página de confirmación.

Como decíamos, el problema es identificar cuando es un problema de recarga y cuando no (¿quíen nos dice que no se ha realizado un pedido de 7 camisas?)

Evidentemente la única forma de determinarlo es verificando los datos de Analytics con los datos de nuestro gestor de pedidos de forma que podamos detectar posibles discrepancias en los datos.

¿La solución final?
Si queremos controlar o impedir el envío de transacciones duplicadas a Google Analytics, debemos implementar una combinación del time stamp (Solución 4) junto con el uso de cookies (Solución 1). Se podría utilizar una cookie propia o una variable personalizada de Analytics, en el próximo post daremos un ejemplo de como hacer esto usando las nuevas variables customizadas de Google Analytics.

Por último, en el caso de que queramos librarnos de transacciones duplicadas, Google proporciona una forma de eliminar datos de transacciones dentro del Google Analytics.

Esperamos que estas soluciones te sirvan para mejorar tus estadísticas y tus datos y te animamos a que compartas con nosotros otras posibles soluciones que estés aplicando.

Autor:

Fundador de Metriplica y socio de la consultora Multiplica Licenciado en Ciencias y técnicas estadísticas. Programador Mainframe Profesor de Masters y Postgrados en diversas universidades y escuelas de negocio.

Leave Comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.