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ón valiosa 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:
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, sin embargo, aún no existe una función dentro del API de tracking que te permita tener acceso al valor de una variable personalizada, así que tendríamos que acceder manualmente al valor de la cookie
___utmv .
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.
Publicado por Felipe Carrillo y Fernando Gavarrón, Multiplica (GAAC ), España
2 comentarios :
Este es un problema importante, no sólo por las transacciones duplicadas, si no por los pedidos cancelados o pedidos realizados doblemente, serían 2 transacciones pero contienen el mismo artículo.
Yo he pensado en ejecutar un script sobre la base de datos de manera semanal o mensual, obtener el id de pedido ( que es el id de transacción ) de todos los pedidos cancelados, generar el javascript correspondiente y borrar esa transacció. ( Creo recordar que había que especificar -1 en el precio y algún otro campo más )
Respecto a tú comentario sobre la utmv y las variables personalizadas.
En realidad, sí que existe una forma de acceder a las variables personalizadas, mediante la función GetCustomVar.
Un saludo,
Buenos días Asier,
Lo primero es agradecerte el comentario (al menos sabemos que alguien nos lee ;)), como dices, el control adecuado de las transacciones es fundamental si quieres tener unas métricas de las que poder fiarte.
En cuanto a lo que dices sobre las variables personalizadas, tienes toda la razón, el comentario iba dirigido a las variables de sesión (aunque admito que tras releerlo no queda claro) que en analytics no son accesibles (entiendo que por no ser cookies).
Como bien dices, la función getVisitorCustomVar permite obtener el valor de una cookie de visitante, en el próximo post que tenemos pensado publicar explicaremos la solución que empleamos nosotros usando una de las variables de visitante.
Un saludo y esperamos que te guste el próximo post.
Fernando
Publicar un comentario