GA4: Adiós productos, hola elementos

Google Analytics 4 trae debajo del brazo el concepto de elementos o items. Un término que puede sonar muy generalista inicialmente, pero que precisamente por eso consigue ser válido para cualquier tipo de web/negocio. Estos elementos que tienes en la web los puedes aterrizar como quieras: pueden ser productos, pueden ser servicios, pueden ser posts de un blog, pueden ser noticias… En definitiva los puedes adaptar a tus circunstancias, independientemente de que tengas un ecommerce o no. Y por eso yo doy gracias a GA4 por decir “Adiós productos, hola elementos”.

Introducción

Sin duda el etiquetado de comercio electrónico en GA4 ha sido uno de los grandes bloqueadores en muchas compañías a la hora de plantear el cambio de Universal Analytics a GA4. En Universal Analytics esta parte de la herramienta estaba muy madura y cualquier ecommerce que estuviera ya recogiendo datos con comercio electrónico mejorado encontraba mil razones para no hacer el cambio a GA4.

Durante muchos meses los de Google han trabajado para equiparar ambas soluciones y que los ecommerce dejasen de sentir que “perderían” datos cuando se cambiasen a la nueva versión. Este trabajo tuvo un gran avance a mediados de marzo de 2023 con la ansiada llegada de las dimensiones de ámbito producto a GA4.  

En mi opinión, todavía les quedan cositas que pulir para estar al nivel de lo que se ofrecía en Universal Analytics en los últimos años. Pero por otro lado, creo que el enfoque de GA4 es mucho más abierto y flexible, haciéndolo extensible a cualquier tipo de web y no sólo a ecommerce. 

En este post voy a hacer un repaso de los eventos recomendados que nos propone GA4 para hacer seguimiento de productos elementos. Los voy a clasificar según mi criterio personal en cuanto a la utilidad que les podemos dar, a ver si coincidís conmigo o no 🙂

Eventos de seguimiento de elementos

En este grupo incluiría los eventos relacionados con la visualización e interacción de elementos en una web.

view_item_list

Nos permite saber cuándo se visualiza una lista de elementos y qué elementos se están visualizando. 

El concepto de lista es algo que viene ya de Universal Analytics. Es un concepto que cuesta un poco interiorizar al principio, pero que una vez lo entiendes por completo te da información super útil de dónde tienes que colocar los elementos dentro de tu web.

El ejemplo típico es tener un producto que se muestra en dos parrillas distintas y que lo puedes comprar desde ambas. Imaginaos que tenemos un pantalón vaquero en la categoría de mujer>jeans, pero también está disponible en mujer>básicos. ¿En qué categoría se está viendo más el pantalón? ¿En cuál mis potenciales clientes muestran más interés por el pantalón interactuando con él de algún modo?¿En cuál de las dos parrillas se vende más?

Con este primer evento sólo podríamos contestar a la primera pregunta. Para responder a las demás necesitaremos alguno de los otros eventos de los que hablaremos más adelante, y en todos ellos será necesario enviar los parámetro item_list_name o item_list_id para poder contestarlas.

Hay que tener claro que las listas no tienen por qué ceñirse estrictamente al árbol de categorías de la web. Podemos definir otras listas como el buscador, carruseles de elementos relacionados o cualquier lugar de la web dónde estemos mostrando elementos o productos de los que queremos hacer seguimiento. De hecho eso es lo más interesante de las listas, el poder saber desde qué parte de la web se inició la compra de un producto al que se puede llegar de varias formas.

item_list_name vs item_category

Una confusión común es creer que la lista (item_list_name) equivale al parámetro de categoría (item_category). Esto sucede porque en muchas implementaciones se envía en el parámetro item_category el valor de la parrilla en la que se está mostrando el producto. Pero esto sería erróneo, esa información deberías de almacenarla en el parámetro item_list_name.

El item_category debería de recoger la categoría única a la que pertenece el producto, normalmente esta es una categorización a nivel de stock, una clasificación de todos los productos disponibles en el negocio y debería de ser una característica más dentro del feed de productos, como el nombre, el id o el precio.

Pongamos un ejemplo para ver la diferencia entre ambos parámetros. Como decíamos antes, un pantalón se puede visualizar en varios espacios de la web, poníamos como ejemplos la parrilla mujer>jeans, la parrilla mujer>básicos o el buscador. Estos valores de dónde se visualiza el producto irían en el item_list_name. En el item_category pondríamos la categoría asociada como característica del producto, que en este caso podría ser mujer>jeans, y acceda desde donde acceda el usuario el item_category siempre sería el mismo: mujer>jeans.

De esta forma podemos hacer dos análisis de rentabilidad de productos distintos. Utilizando el item_category podremos ver qué verticales de productos son las más rentables. Con el item_list_name desde qué lugar de la web se está vendiendo más.

select_item

Se envía cuando se hace un click en un elemento que se ha mostrado en una lista. Combinado con el evento anterior podemos sacar un primer CTR de veces que se ha clicado sobre un elemento vs veces que se ha mostrado. Esto será un buen indicador para ver qué elementos son más atractivos para nuestros clientes y puede revelarte información muy interesante.

view_item

Este evento deberías de enviarlo cuando se visualiza la página de detalle del elemento. Si hablamos de productos, sería cuando se visualiza la página de detalle del producto. Este evento puede parecer redundante con el select_item, ya que normalmente el click en el elemento te lleva directamente a la visualización de la página de detalle del elemento. Sin embargo, es interesante implementar ambos, ya que habrá ocasiones en las que el usuario acceda directamente a la página de producto a través de una campaña, porque le han compartido el enlace, por una promoción interna….

En este bloque de eventos es donde queda más palpable el cambio de enfoque de GA4. Dejar de hablar de productos para hablar de elementos tiene mucho más sentido para webs como la de Datola. 

Podríamos definir diferentes listas como newsletter, podcast, blog y buscador. E incluso dentro del blog podemos tener una lista por cada categoría del menú (blog-analítica digital, blog-herramientas…). Y con los datos recogidos podríamos ver desde dónde se están viendo más los elementos, es decir, los post de las distintas listas.

Eventos de seguimiento de promociones

En este grupo se incluyen todos los eventos relacionados con promociones internas que hacemos en la web, típicamente serán banners que nos encontramos en la home, en los laterales de otros contenidos de la web… Podemos utilizarlos para analizar el rendimiento de estos anuncios internos.

view_promotion

Se envía cada vez que se visualiza una promoción. En los parámetros asociados se recoge información que permita identificar ese banner, como el id o el nombre de la promoción. También se pueden añadir información sobre las creatividades utilizadas. En el caso de que la promoción esté enfocada a un producto/elemento concreto, se puede añadir la información de éste.

select_promotion

Se enviará cada vez que una promoción es clicada. Combinándolo con el evento anterior podremos calcular el CTR de cada una de nuestras promociones internas.

Eventos de venta

Este grupo si que está enfocado principalmente al ecommerce, aunque puede que la venta no se realice exclusivamente de forma online. Podría ser una web donde se hace una reserva (sin llegar a pagar) o donde se recoge un lead para hacer una posterior venta o contratación de un servicio offline.

Este grupo me gusta dividirlo en dos fases de compra: acciones preventa y proceso de checkout.

Acciones preventa

Estos eventos van a permitir analizar si los productos realmente son de interés para nuestros clientes, ¿están tentados a comprarlos o no?

add_to_wishlist

Deberías de enviar este evento cuando un producto se añade a la wishlist. Sin duda es la primera muestra de que el usuario se ha sentido atraído por este producto.

add_to_cart

Deberías de enviarlo cuando un producto se añade a la cesta. Si un producto se añade a la cesta la intencionalidad de compra es aún más alta. Esto te permitirá saber cuáles son esos productos que están más cerca de ser vendidos. Si implementas este evento no te olvides de añadirlo también cuando hay incrementos de unidades (el típico más que te encuentras en muchas cestas), es un error común en las implementaciones de este evento.

remove_from_cart

Se envía cuando se elimina un producto de la cesta. No es un evento que se utilice mucho, pero es interesante vigilar aquellos productos que se han eliminado mucho de la cesta, ¿por qué puede ser? ¿hay algo que no acaba de convencer con este producto? ¿cómo puedo mejorarlo?

Estos tres eventos llevan asociados una lista de items (en este caso productos o servicios) que son los que han sido añadidos/eliminados. Un error frecuente en estos eventos es no enviar la cantidad de items en el parámetro items.quantity, asegúrate de enviarlo con la cantidad correcta.

view_cart

Este evento se envía cada vez que el usuario visualiza el carrito.

Proceso de checkout

Aquí incluyo los eventos que nos van a permitir construir el funnel del checkout. Con estos eventos principalmente lo que se consigue es detectar posibles puntos de fricción que se están encontrando nuestros clientes a la hora de realizar un pedido.

Esta parte de la web o app debería de estar construida con mucho cariño, priorizando la experiencia de nuestros clientes. Estaréis de acuerdo conmigo en que es muy frustrante cuando estás decidido a comprar algo en un ecommerce y de repente algo no funciona en el proceso de checkout. Y más frustrante es aún para el vendedor tener una venta prácticamente cerrada y perderla porque “la caja” no está operativa en ese momento.

Estos son los eventos que debemos utilizar para analizar esta parte crítica del ecommerce:

begin_checkout

Se envía cuando accedes al proceso de checkout.

add_shipping_info

Se envía en el paso de recolección de la información de envío. Este evento tiene asociado el parámetro shipping_tier donde puedes recoger el método de envío uitlizado.

add_payment_info

Se envía en el paso de recolección de la información de pago. En este caso también existe un parámetro especial, el payment_type, para recoger el método de pago utilizado.

purchase

Se envía cuando ya se ha confirmado la compra, típicamente en la página de gracias. Es la joya de la corona de los eventos de ecommerce y probablemente el evento que debes de implementar sí o sí, si la venta final se hace en tu página.

Lo más complicado en este grupo de eventos es lanzarlos en el momento adecuado del proceso. Os encontraréis escenarios donde no es posible enviarlos en el momento preciso en el que se consuma la acción y tendréis que buscar una solución de compromiso.

Un ejemplo típico de esto es cuando el cliente hace una compra con paypal. En estos casos normalmente la web redirige al usuario a la página de paypal, ¿cuándo envías el evento de purchase? ¿cuando el usuario hace click para pagar o cuando llegas a la página de confirmación de compra? Si lo hace en el click de pagar, puede que el cliente se arrepienta en el último momento y no acepte el pago, por lo que contabilizarías una transacción que realmente no se ha hecho. Si lo haces en la página de gracias, puede que el usuario pague en la página de paypal y nunca vuelva a tu página, por lo que nunca verá la página de confirmación y no se registrará esa compra. ¿Qué es lo mejor? Pues de nuevo, depende de cómo se comporte tu página

Por supuesto, no es obligatorio el envío de todos estos eventos, es más puede que algunos no apliquen en tu negocio. Por ejemplo, si vendes servicios que no requieren del envío a casa de nada, probablemente no necesites el evento de add_shipping_info.

Eventos de post venta

Existe otro evento adicional que puede ser interesante en los ecommerce para hacer seguimiento de las devoluciones. Se trata del evento refund. Este evento lo puedes enviar desde tu página si tienes una funcionalidad en ella para gestionar las devoluciones. En otros casos he visto implementaciones donde se envían desde el lado del servidor con el measurement protocol o incluso se puede hacer un importación de estos datos offline a GA4.

Recursos interesantes

Como habéis visto hay un montón de eventos recomendados para hacer el seguimiento de cómo interactúan los usuarios con los elementos de tu activo digital. Aquí solamente hemos comentado los nombres de los eventos recomendados, dónde se deberían de enviar y que es lo que nos indican, pero todo esto se complica mucho más cuando empiezas a profundizar en los parámetros asociados a cada evento, métricas que nos devuelve la interfaz…

Os dejo por aquí algunos recursos útiles por si queréis profundizar en todo este tema:

• Documentación de los eventos recomendados de ecommerce (ventas online)
• Documentación sobre como implementar estos eventos en web
• Documentación sobre cómo implementar estos eventos en app
• Documentación sobre el informe de compras de comercio electrónico
• Listado de dimensiones y métricas que obtienes con la implementación de estos eventos. Recuerda que no todas las dimensiones y métricas están disponibles en todos los sitios (explorador, interfaz, API, Looker Studio), siempre puedes consultar nuestra gran chuleta para saber dónde las puedes consultar.
• Enhanced ecommerce demo, aquí puedes ver sobre una tienda de camisetas fake dónde y cómo se enviarían los eventos. Personalmente me gusta más la versión que nos mostraban en UA, que además también está adaptada para GA4

Tengo un presupuesto limitado, ¿qué eventos son imprescindibles?

Pues como siempre, todo depende del tipo de negocio que tengas y de las preguntas de negocio que quieras contestar con los datos. Si eres un ecommerce, lo más probable es que quieras tener el evento de purchase sí o sí. Si estás invirtiendo recursos en promociones internas, pues quizás te interese más ir a por los eventos de promociones.

Recuerda siempre que las herramientas de analítica están a disposición de tu negocio y no al revés. Debes de buscar la manera de recoger los eventos que necesites para contestar a tus preguntas de negocio. Es igual de válido que lo hagas utilizando los eventos recomendados de GA4, que utilizar eventos personalizados definidos según tus propias necesidades. Y esto es lo bonito de esta profesión, que puedes desarrollar tu creatividad buscando soluciones a medida, algo en lo que el joven GA4 supera con creces al viejo Universal Analytics.

Comportamientos diferentes en GA4 vs Universal Analytics

En el fondo los eventos de ecommerce de GA4 son muy similares a lo que teníamos en Universal Analytics, sin embargo hay algunas cosas que desde mi punto de vista deberían de acabar de pulir. Son cosillas que la comunidad ha ido detectando y reportando como bugs, aunque en algunos casos se ha declarado que no son errores, si no que simplemente la nueva herramienta funciona así.

Cambio de moneda

Si de repente ves que en GA4 tienes ingresos de productos que no encajan con el precio real de éste, no te asustes, no hay ningún error en tu implementación. Simplemente GA4 funciona así. Tú envías el valor en la moneda local, por su puesto con el parámetro currency adecuado. GA4 hace la conversión a USD según la tasa de cambio del día anterior y lo almacena en esa moneda. Cuando vas a recuperar el valor a través de un informe, vuelve a hacer el cambio según la tasa de ese día. Por lo que los valores van fluctuando.

Muchos analistas creyeron que estaban locos porque cada día veían un valor. Finalmente desde Google documentaron el comportamiento dejando claro que esto simplemente funcionaba así. Ojalá en un futuro lo cambien para poder tener algo más preciso.

Persistencia de los parámetros

Otro tema que creo que sería muy mejorable es la persistencia de los parámetros a lo largo de todos los eventos de ecommerce. Me explico, supongamos que queremos hacer la trazabilidad de las listas durante todo el proceso de compra. Esto nos permitiría saber por ejemplo, desde qué listas se añadieron los productos a la cesta y acabaron en una venta exitosa. Podríamos contestar a preguntas tan interesantes como ¿qué parrillas son las que más ingresos me generan?

En Universal Analytics sólo tenías que implementar correctamente el id del producto y el nombre de la lista en el evento de impresiones (el equivalente a view_item_list). Después, en base al id del producto, el sistema se encargaba de asociar el nombre de la lista a los demás eventos de ecommerce asociados a ese id. De esta forma, cuando llegabas al purchase, la herramienta era capaz de saber desde dónde había llegado cada producto de la cesta y así conseguíamos el seguimiento completo de esas listas.

Con GA4 esto no funciona. Si quieres tener ese nivel de detalle tienes que ser tú mismo el encargado de enviar los parámetros item_list_name e item_list_id en cada evento de ecommerce. Puede parecer una solución trivial, pero os aseguro que almacenar esos valores a lo largo de todo el proceso de compra del usuario es un esfuerzo titánico para los desarrolladores, lo más probable es que no acabe bien.

Esto mismo sucede con el parámetro position. De nuevo se trata de una información que tienes disponible sólo en el momento en el que estás visualizando la lista de productos. Sin embargo, es interesante asociar esta información con otros eventos del final del proceso como el begin_checkout o el purchase y para ello, los desarrolladores deben de buscarse la vida para llevar la posición hasta estos eventos.

Tengo que decir que en los inicios del enhanced ecommerce de Universal Analytics tampoco se mantenía esa persistencia de los valores de manera automática. Por eso tengo esperanza de que sea algo que en GA4 solucionen en el futuro.

Conclusiones

Desde mi punto de vista GA4 es mucho más inclusivo y flexible con respecto a los «antiguos» eventos de ecommerce. El simple hecho de cambiar la nomenclatura de producto a elemento (o item) hace que estos eventos se adapten mejor a todos los sectores. Este pequeño detalle lo hace mucho más comprensible y accesible a aquellos que están empezando y que no trabajan en un ecommerce.

Es cierto que podríamos esperar más de la herramienta. Actualmente toda la información de elementos sólo se puede enviar a través de los eventos recomendados de ecommerce. Se echa en falta poder enviar esa misma información en eventos personalizados, por ejemplo cuando el usuario selecciona una talla o un color. Pero esta es una limitación que ya teníamos en Universal Analitycs.

Como hemos visto, hay algunas otras cosillas que sí teníamos en Universal Analytics y que echamos en falta en GA4. El cambio de la moneda o la persistencia de las listas/posiciones son ejemplos claros. Seguro que en tu día a día te has encontrado con mas cosas de este estilo, ¿te animas a compartirlas? Prometo incluirlas en el listado de este mismo post o si son muchas, crear uno específico sobre esto 😉