Las 7 grandes mentiras del ecommerce mejorado de Analytics

¿Nosotros? ¿Acusados de clickbait? No sé de qué me habla señoría. 🙄

Antes de que hordas furibundas de analistas con ojos coléricos nos hostiguen con sus hoces y sus estacas ardiendo en la puerta de nuestro edificio, dejad que nos expliquemos. Calma.

Estas que vamos a nombrar son 7 piedras en el camino que, desde luego, no harán que el carruaje de tu analítica descarrile. Pero que teniéndolas en cuenta harán que tengas una visión más real de lo que pasa en una web.
Dicho esto, no queremos decir que a todos ecommerce les pase ni que no tengan solución. Pero sí que queremos poner un alto en el camino para reflexionar acerca de las posibles decisiones que tomemos cuando utilicemos información acerca del ecommerce mejorado de una web. Es conveniente tener estos conceptos presentes:

1. El CTR de las promociones internas

Quizás nos encontremos ante una de las funcionalidades más infrautilizadas de un ecommerce. Además de las campañas de pago para atraer usuarios de la calidad a la web, dentro de ella podemos guiar o reconducir la navegación mediante promociones internas que le puedan resultar interesantes al usuario.

Universal Analytics cuenta con unos datalayers de promoview y promoclic (en GA4 han cambiado el contenido del datalayer de envío de view_promotion) que nos brindan la posibilidad de medir las interacciones con estos elementos.
¿Y dónde está el problema? El problema reside en que si bien promoclic es un evento que se lanza cuando el usuario ha hecho clic en un banner, ateniéndonos a la documentación oficial de google, promoview es un datalayer de carga de página.

Código Datalayer, Promoview Universal Analytics (Fuente: GTM)

Lo que implica que si por ejemplo: Tenemos un slider en la home con 7 promos y queremos medir las veces que se han visto, Google nos dice que debemos lanzar a la vez el datalayer de todos los elementos, se hayan visto o no en pantalla. De manera que todas las promociones tendrán el mismo número de visualizaciones cuando evidentemente la última promo tiene menos posibilidades de ser clicada porque ha sido menos vista. Lo que reportará mejor CTR (Click Trougth Rate) de manera incorrecta.
Como hemos dicho en el ejemplo de GA4 este datalayer cambia para centrarse en una solo promo y con disparador de promo_view

Datalayer Promoview Google Analytics 4 (Fuente: GTM)

2. CTR de las impresiones/clics en producto

Al igual que en el caso anterior pero esta vez tanto en Universal Analytics como en Google Analytics 4, nos encontramos ante unos datalayers de impressions en UA y view_item_list en GA4, que nos dan información de los productos cargados en un listado de la página, ya sea por una categoría, una búsqueda o productos relacionados.

Pero este datalayer según la recomendación de Google se debe leer en la carga de la página, es decir, contará como vistos todos los productos que hay en esa listado, haya llegado el usuario a ver el último o no. Haciendo que en listados largos, sobre todo en versiones móviles con mucho scroll los últimos elementos no sean vistos y que por tanto tengan menos posibilidades de recibir un clic. Por tanto, el CTR de las impresiones y clics de producto estará desvirtuado puesto que siempre van a recibir más clics los primeros productos mostrados en detrimento de los últimos con un número de visualizaciones irreal.

3. Vistas de detalle de producto

Un datalayer de carga de página es información que se manda a Analytics al procesar una página, pero cada vez que un evento de página se ejecuta (clics en ampliar foto, compartir en redes sociales, clics en menú, etc.) y tenga en su variable de configuración de Analytics la opción de leer la capa de datos, nos volverá a leer esa información del datalayer haciendo que nuestra métrica de vista de detalles de producto no sea correcta. Entenderá que, en una sola carga de página, ha habido muchas vistas de detalle de producto. Tantas como eventos se hayan enviado.

• Una manera de saber si está bien configurado es comparar en un informe personalizado el número de vistas de detalles de un productos con las páginas vistas de este producto, si estas últimas son más puede ser que el problema sean los eventos.

Vista de detalle de producto en Analytics (Fuente: Semmantica)

Por lo tanto cuidado con la métrica vistas de detalle de producto porque puede no ser correcta en según qué configuraciones.

4. Porcentaje detalle/carrito; y, porcentaje compra/información de producto

Esta vez tenemos un 2×1, estas dos métricas siempre pueden llevar a engaño por varios motivos. Las métricas trabajan con vistas de detalle de producto, por lo que como hemos visto anteriormente, si no están bien configurados los eventos de la web pueden llevar a tener datos erróneos. Por otro lado, existen ciertas webs en las que la opción de añadir al carrito no se ejecuta siempre sobre la página de detalle. Pongamos algún ejemplo:

• Yo puedo añadir productos al carrito desde un listado de: Categoría, búsqueda o recomendado.
  

  Botón “añadir a cesta” ecommerce de jamones (Fuente: Semmantica)

Puedo añadir al carrito otro elemento desde mi cesta.

Página “mi cesta” ecommerce jamones (Fuente: Semmantica)

• Por lo que para determinadas páginas con opciones de añadir al carrito en diferentes puntos de la compra estas métricas de detalle / carrito y compra / detalle pierden su consistencia.

5. Sesiones con compras en el funnel global de comportamiento de compra

Cada vez existen en el mercado más herramientas útiles para atraer público cualificado a las páginas web: Campañas de búsqueda, de shopping, de remarketing, RTB (Real Time Bidding), colaboraciones con influencers, códigos promocionales etc. Pero, de todas hay una que afecta a funnel de comportamiento de compra de manera especial: La recuperación de carritos.
Es un servicio mediante el cual el sistema guarda en base de datos el correo electrónico del usuario y los productos que tiene en el carrito de compras. En caso de no llegar a realizar la compra se manda un email para recordarle que está a tan solo unos pocos pasos de poder comprar esos productos. Pueden pasar varias cosas:

• Si el sistema lo permite, al hacer clic en el correo accederá a la web en checkout con los productos ya añadidos en el carrito. Es decir, una nueva sesión sin haber ejecutado ni vista de producto ni añadir al carrito.
• Si es el mismo navegador y mantiene las cookies y toda la información de la sesión, accederá a checkout con el histórico que tenía en ese navegador. Con todos los productos en el carrito y una vez más sin haber ejecutado en su sesión ni vista de detalle de producto ni añadir a carrito.
• Si es un navegador sin cookies previas y el sistema no es capaz de añadir automáticamente a carrito los productos, el usuario accederá a la web con el carrito vacío y al ver que tiene que realizar todo el proceso de nuevo es posible que se vaya. Por lo tanto tendremos sesiones con rebote o con mala calidad.

Esto hará que en nuestro funnel de comportamiento existan sesiones con accesos a checkout pero sin vista de detalle de producto ni añadido a carrito. En caso de campañas de recuperación de carrito con alto volumen puede hacer que ese funnel se comporte de manera extraña.

Sesiones con compras en el funnel global de comportamiento de compra (Fuente: Semmantica)

5.1. Último paso funnel

Nos acercamos al punto crítico del proceso de compra, la tramitación de la compra. Es interesante ver en qué punto de nuestro proceso caen los usuarios para poder pulir los puntos conflictivos. En este sentido el último paso siempre suele ser el más crítico. Pero, ¿entendemos bien este último paso? Pongamos un ejemplo, un proceso de reserva con 4 pasos: Identificación, forma de pago, confirmación y transacción.

Ejemplo de un funnel de ventas en 4 pasos: Identificación, forma de pago, confirmación y transacción (Fuente: Semmantica)

La imagen muestra como en el último paso de confirmación hay 677 sesiones, de las cuales abandonan en ese punto 250 y finalmente 186 acaban comprando. Pero existe un factor interesante aquí, de esa caída de 677 sesiones en confirmación hay 186 sesiones con compra.

¿Cuántas podemos achacar a la web y cuantas al tpv? Porque si bien cuando accedemos al último paso de confirmación podemos leer el datalayer de checkout, ya no hay ninguna otra interacción en la página que nos diga si el usuario ha desaparecido habiendo rellenado todos los campos del ultimo paso o si ha fallado el tpv y no ha podido llegar a la página de gracias. Por lo tanto, ese último paso cargará con dos pesos: El de los usuarios que abandonan en el último paso y que puede ser solucionable a nivel de análisis web; y el de los usuarios que habiendo salido a la forma de pago no han conseguido llegar a la página de gracias y han abandonado la sesión. Lo que depende directamente de la forma de pago elegida.

Por lo que la información de ese último paso en el proceso de compra tiene una lectura más allá de la meramente relacionada con el funcionamiento de la web.

6. Transacciones

Siempre decimos que purchase es el rey del ecommerce, sin él muchas métricas o KPIs quedan desdibujados en la efectividad de una web pero, ¿es realmente la transacción el eje de un ecommerce? La respuesta es sí, pero hay que tener en cuenta que:

• Una transacción mide la venta realizada por un usuario en una sesión, si da su consentimiento en la aceptación de cookies.
• Tendemos mucho a comparar los datos que tenemos en el CRM con Analytics porque comparar euros con euros es muy fácil. Pero la analítica no se trata de eso, no se trata de contabilidad se trata de trazabilidad. En ese sentido si, por cuestiones legales, el usuario ha decidido que no quiere que se le registre la cookie de Analytics no estamos en derecho de medir nada. Por lo tanto, en nuestro sistema de analítica ese usuario queda descartado tanto como sesión como transacción. Sin embargo, en el CRM contará como venta realizada.

Pero, ¡no se levante del asiento que aún hay más!

• En determinadas ocasiones el usuario abandona la web para poder pagar mediante tpv, bizum o la plataforma que sea y por configuraciones del sistema vuelve y lo reconoce como una sesión nueva con transacción. Haciendo que en la fuente-medio original no haya registrado una transacción, mientras que esa nueva sesión que aterriza en la página de gracias con fuente-medio direct/none se le asigna una transacción. Por lo tanto, esa transacción existe en Analytics pero sin más información que la transaccional, no guardará la fuente-medio original de la sesión.

7. Nuevos protocolos de seguridad de los bancos

Y por último, desde la entrada en vigor de los nuevos protocolos de seguridad de los bancos PSD2 han hecho que el pago sea un entramado de procesos de login y claves cifradas. En determinado punto, cuando el usuario ve en la app de móvil la confirmación del pago y un correo confirmando que redirecciona a la página de gracias de la web pero este no lo hace, provoca que para Analytics sea una sesión sin venta cuando realmente esa transacción si que ha existido. La caída por salidas al tpv de pagos de bancos cada vez es más notoria.

Por ello, es importante tener en cuenta que no todas las transacciones se registran y que algunas que sí se registran lo pueden hacer sin una traza previa que identifique al usuario. Es por ello que tiene tanta importancia el concepto de trazabilidad en lugar de la contabilidad.

Conclusión

Estos han sido algunos de los puntos claves que pueden llevarnos a engaño en un análisis de una página web. Por supuesto, hay posibilidades de solucionar estos problemas de manera técnica para afinar mejor el análisis del comportamiento de usuarios y de la web.

¿Qué cómo lo hacemos nosotros? ¿Quieres saberlo?

Te lo vamos a explicar en nuestras redes sociales, estad atentos a nuestro: Twitter, Instagram o TikTok. Durante las próximas semanas iremos dando pequeñas cápsulas que darán solución a cada uno de los problemas expuestos en este post.