El comercio electrónico mejorado en Google Analytics 4 (GA4)

Para quienes hemos tenido la oportunidad de afrontar proyectos de analítica en App con Firebase, el nuevo Google Analytics 4 (GA4) no nos ha pillado por sorpresa. El cambio de paradigma parece grande con respecto a versiones previas de Google Analytics, sin embargo, si profundizamos observaremos que la lógica sigue siendo más o menos similar.

Hay muchos cambios y novedades en esta nueva versión, así como ajustes y optimizaciones semanales por parte de Google para intentar mejorar su producto estrella. Al fin y al cabo esta nueva versión está conviviendo con Universal Analytics (UA), el cual sigue estando vigente y «muy vivo». De hecho, te recomiendo que si no has añadido GA4, lo hagas cuanto antes aunque sea con una configuración básica. De esta forma tendrás un histórico de datos más amplio. Se puede resumir la nueva lógica de GA4 como …

Analítica cross-device que obliga a recoger todas interacciones como eventos, dejando de lado el concepto page view tal y como lo conocíamos hasta ahora. Aunque, lógicamente, siguen existiendo pages y screens como no podría ser de otra forma. Además, el concepto de sesiones usado hasta ahora pasa a especificarse de distinta manera. Esencialmente se basa en el evento session_start, el cual se registra de manera automática. Esto conlleva algunas diferencias que repercutirán en diferencias claras entre la propiedad UA y la nueva GA4.

En este sentido y desde mi punto de vista, ahora todo se ha simplificado mucho más. El proceso es algo tan sencillo como enviar un evento a GA4 con unos parámetros que contienen información añadida. Esto, como siempre, se puede hacer desde el propio código de nuestra App o web con la correspondiente librería o SDK, o con Google Tag Manager (GTM). Un ejemplo tipo sería este …

Nueva etiqueta de un evento de GA4

No obstante, el objetivo de este post no es detallar el nuevo GA4 (del cual ya se han escrito muchos artículos y que en alguno de mis próximos posts también trataré), sino profundizar en la parte más compleja y menos conocida de esta versión. Me estoy refiriendo como no podía ser de otra manera al Enhanced Ecommerce. Este ya existía y existe en UA y a día de hoy es un imprescindible para cualquier analista que estudie cualquier comercio electrónico. Aunque, por mi experiencia previa como analista en agencia, sé que muy pocos lo tenían correctamente configurado. ¿Por qué? En pocas palabras, porque se necesita un conocimiento técnico alto y experiencia previa en proyectos para implementar correctamente toda los datos a enviar. Todo se basa en los famosos dataLayers que tantos problemas siguen dando hoy en día.

El comercio electrónico mejorado de GA4

Para poder hacer un seguimiento exhaustivo de nuestro comercio electrónico en GA4 es imprescindible llevar a cabo las siguientes acciones:

1. Desarrollo de un plan de implementación (parte del plan de analítica global) donde se detallen los hits a recoger. Dentro de este plan es imprescindible detallar aquellos referentes al ecommerce y que se especifican a través de cada uno de los dataLayers propuestos por Google.
2. Añadir los correspondientes dataLayers de ecommerce a cada uno de los eventos a analizar. Concretamente son los siguientes: Product/Item list, Views/Impressions, Product/Item list clicks, Product/Item detail views, Adds/Removes from cart, Promotion views/impressions, Promotion, Clicks, Checkouts, Purchases yRefunds. Se pueden ver en detalle las clave-valor de cada uno estos eventos en este enlace.
3. Enviar esta información a GA4 a través de GTM. Se puede hacer también directamente desde el código con gtag.js, pero para este tipo de proyectos recomiendo hacerlo a través de un gestor de etiquetas ya que permite la escalabilidad del proyecto sin una dependencia total del depto. de desarrollo.

Se debe tener en cuenta que si ya se ha implementado previamente el enhanced ecommerce en una propiedad UA se podrá seguir utilizando ya que GA4 es perfectamente compatible con dichas estructuras. En cambio, si se usan los nuevos esquemas de GA4 basados en la clave items no podrá usarse lo implementado anteriormente.  

Puesto que sería tedioso mostrar cada uno de los dataLayers asociados a los eventos de comercio electrónico mejorado, voy a centrarme en la explicación de uno de ellos, el más importante: evento purchase.

Una vez que el equipo de desarrollo ha añadido correctamente este dataLayer, lo siguiente será configurar la etiqueta en nuestro GTM. Si ya lo hemos hecho en UA nos resultará familiar. En cualquier caso es relativamente sencillo ya que el trabajo más duro en este caso ya se ha hecho.

Por mi experiencia, y debido a que en muchos casos las personas encargadas de integrar los dataLayers están algo más alejadas del negocio, es imprescindible que todos aquellos que vayan a hacer uso de la analítica implementada (analistas, marketing, data, finanzas, etc.) la sometan a un riguroso análisis. Es muy habitual que aunque todo se haya especificado en el plan de implementación se cometan fallos de conceptualización. Por ejemplo, uno muy habitual es el relacionado con la clave ecommerce.purchase.items.item_price. ¿Este valor debe integrar impuestos (como el IVA) o no? La respuesta se encuentra más arriba, en la clave TAX del pedido al completo tramitado. Dicho de otra manera, no debe añadirse ningún impuesto al producto ya que se agregarán al conjunto del pedido realizado. Algo tan mínimo puede dar al traste al resto de métricas. 

Volviendo sobre la configuración de la etiqueta en GTM, simplemente se ha de llevar a cabo lo siguiente …

1)  Tag o etiqueta (Evento de GA4)

• • Nombre de la etiqueta: GA4 EC Purchase
  • Nombre del evento: purchase
  • Parámetros del evento:
    • items – {{Ecommerce items}}

2)  Variable (Data Layer)

• • Nombre de la variable: Ecommerce items
  • Nombre de la variable del Data Layer: ecommerce.items
  • Versión del Data Layer: Version 2

3)  Trigger o activador (DOM Ready o Custom Event)

• • Nombre del activador: Evento Purchase
  • ***

***)  En este caso concreto dependerá de cómo se genere la compra final en nuestro sitio web y de cómo se cargan las páginas: página resumen de compra  o evento lanzado asíncronamente (SPA, Single Page Application). También se debe tener en cuenta que aunque nuestra página se asíncrona, por ley nos vemos obligados a mostrar al usuario un resumen del pedido realizado a modo de factura. Bien en el momento de hacer la compra o enviando dicho documento al correo, por ejemplo.

Esta misma configuración se debe llevar a cabo para el resto de los eventos mencionados siempre y cuando existan en nuestro sitio web o App. Una vez se tenga ya todo perfectamente configurado solo quedará testear una y otra vez esta implementación. Como se ha dicho, suele haber bastantes errores no intencionados de base.

Si quieres practicar más sobre esta temática, lo mejor es hacerlo a través de la nueva demo account de Google, concretamente a través de este enlace.

Suficiente por esta semana. Te convoco para la siguiente 😉 Mientras puedes leer el resto de mis posts a través del índice de este Blog. ¡Hasta la semana que viene!