GA4: Transacciones, devoluciones y otras métricas.

Introducción

Comprender las métricas es esencial o debería de serlo en la vida diaria de un analista digital. No todas, pero si aquellas que uses o vayas a usar a diario. Sin embargo, este proceso no es sencillo. A menudo, es habitual creer que comprendes una métrica basándote en ciertas definiciones, criterios previos y descubres meses más tarde que tu razonamiento era erróneo o tu definición, imprecisa. Nos pasa a todos. Los aparatos y muchas veces la propia documentación no nos lo pone fácil y muchas veces lo único que nos queda es tirar de ingeniería inversa. Pero claro, estas imprecisiones, confusiones o errores pueden tener consecuencias en las interpretaciones de nuestros análisis.

Para mí, conocer la definición de una métrica es crucial, pero es igual de importante o más ser capaz de transmitírsela con la misma exactitud al público que va a leerla, usarla… Tarea que no es nada sencilla. O mejor dicho, es tremendamente complicado, especialmente cuando la persona que solicita la métrica tiene ya una concepción o definición propia de la misma. Esto es un problema, sí, pero no es algo por lo que debamos culparnos. Las herramientas no facilitan estas cosas y cada una suele tener su propia definición o variación de la misma.

A menudo, esta problemática se la atribuimos a la falta de madurez en el sector. La «aleatoriedad» y la imprecisión en las definiciones o cálculos de las métricas suelen ser comunes, y tampoco se descarta que exista un interés en que así sea por parte de las herramientas. Históricamente, las herramientas o los aparatos han sido caseros, más opacos que transparentes y al servicio de su negocio y no del tuyo. No ponen fácil el auditado ni la depuración, tampoco el entendimiento de las mismas. Como en todos lados existen excepciones, pero la tendencia ha sido siempre priorizar la cantidad o volumen sobre la calidad.

También es muy común que lo que un día consideramos la definición exacta de una métrica, al día siguiente podamos ver cambiada esta definición o descubramos que nos faltaba algún matiz. Y esto último, suele ser lo más habitual, por ejemplo, tras hablar sobre las transacciones de GA4 en la Datolada me faltó incluir un aspecto importante que era que las devoluciones también son transacciones para el aparato.

Y esto, no va de contabilidad, por supuesto que no, pero interpretar y no tener en cuenta que las devoluciones son transacciones te puede llevar a malas interpretaciones en los datos y algún disgusto a nivel análisis. Y esto es solo un ejemplo, pero puede ocurrir con cualquier otra métrica o dimensión con la que operes a diario.

¿Qué es un transacción para GA4?

Para tu negocio, para tu madre o para la Wikipedia una transacción puede tener un significado común, pero como puede ocurrir con otras métricas no tiene que coincidir exactamente con lo que GA4 considera una transacción.

Depende de que página de la documentación estés consultando tendrás una definición u otra, pero te digo que NO son el recuento de id de transacciones diferentes y lo que sí, las devoluciones, reembolsos o mejor dicho el evento refund si que son considerados una transacción en GA4. Lo importante, es que recuerdes y tengas presente que la documentación es útil hasta que alguien es capaz de demostrar que estaba equivocada. Y ocurre muchas veces, aquí un ejemplo claro.

Vamos a detallar un poco lo que considera GA4 importante a la hora de contar transacciones. Empezamos:

  • El parámetro currency es completamente obligatorio. Se tiene que mandar en el evento con el código ISO correcto de la moneda. Por ejemplo, ARS, EUR, USD… Independientemente del valor de la transacción como si el importe es 0 o que tu propiedad tenga únicamente una divisa..
El parámetro currency (moneda) es obligatorio aunque el importe sea cero.
  • El campo transaction_id es opcional, pero muy recomendable para poder cruzar con los sistemas internos o para poder minimizar las transacciones duplicadas. La funcionalidad de eliminar las transacciones duplicadas para un mismo usuario solo funciona en los flujos de datos web.
Se puede comprobar, cuadrados rojos, como el id de transacción es opcional para el conteo de la métrica transacciones y también vemos, rectángulo violeta como el (not_set) de la moneda provoca que las transacciones sean cero.
  • El nombre del evento tiene que ser purchase, in_app_purchase , ecommerce_purchase(obsoleto) o refund. Si amigos, las devoluciones o reembolsos en GA4 son considerados transacciones y esto puede llevaros a conclusiones o a picos inesperados en los informes.
Los reembolsos o devoluciones en GA4 son considerados transacciones.

En el único sitio en el que actualmente matizan esto de forma oficial es en la documentación que aparece en GA4 Dimensions & Metrics Explorer.

Eventos que contarían para la métrica transacciones: in_app_purchase, ecommerce_purchase, purchase, app_store_subscription_renew, app_store_subscription_convert, and refund

Es posible que te estés preguntando si el evento refund afecta a otras métricas relacionadas, por ejemplo, a las métrica transacciones por comprador (transactions per purchaser) o total compradores (total purchasers). En este caso, el aparato solo tiene en cuenta los eventos purchase, ecommerce_purchase y seguramente también los relacionados con las suscripciones (sin probar esto último).

En estas métricas no tiene en cuenta para el cálculo los eventos refund.

Algo que nos puede ser de gran ayuda sobre todo para las métricas calculadas de forma predeterminadas de GA4 es comprobar el campo Backend Name de GA4 SPY. Este campo nos puede dar muchas luz para entender e incluso replicar las mismas métricas en otros sistemas como Big Query o Looker Studio y también para entender como funcionan internamente en GA4.

El campo Backend Name de GA4 SPY nos ofrece información sobre las métricas y las operaciones que utiliza GA4 para el cálculo sus propias métricas calculadas.

Las devoluciones o el evento refund en GA4

La forma de operar con las devoluciones, reembolsos o el evento refund es muy similar a la forma que operamos con el evento purchase en GA4. Voy a recalcar un par de historias que considero importantes:

  • La moneda (currency) sigue siendo un parámetro obligatorio para las métricas monetarias y da lo mismo que tu propiedad solo opere en una única moneda. Mandar en el parámetro currency con el código ISO de la moneda es obligatorio siempre que utilicemos métricas monetarias.
Importante no te olvides de mandar el código ISO de la moneda en GA4 siempre que quieres ver métricas monetarias. De lo contrario, su valor será 0.
Se puede ver como se resta el importe de devolución (refund_value) en las métricas calculadas que nos trae GA4.

Esto podría provocarnos en alguna propiedad o activo, dependiendo de su naturaleza picos de ingresos negativos.

En la foto se puede ver como para la métrica Total de Ingresos(Total Revenue) muestra la métrica en formato negativo para las devoluciones. En cambio, para la métrica importe del reembolso (Refund Amount) la métrica es positiva.

Si ves en algún gráfico datos numéricos negativos y os hace ruído acordarse de revisar las devoluciones o el evento refund.

Pico de ingresos negativos en un gráfico de GA4.

Muy ligado al tema de los ingresos están las otras métricas que pueden formar parte de un devolución: gastos de envío, tasas… O cualquier otra métrica personalizada que necesitéis mandar en este evento o en cualquier otro tipo en el que necesitéis en lugar de sumar el valor lo que busquéis sea disminuir el valor de una métrica. En estos casos, se debe de enviar el valor en formato negativo(-).

Aunque la documentación de Google no lo detalla, para ajustar el valor de las métricas relacionadas con una devolución: tax, shipping, discount, o cualquier otra métrica personalizada es esencial mandar el valor en formato negativo.

En el evento refund deberíamos de enviar los valores shipping, tax, discount con importe negativos.

Los parámetros value y price de forma predeterminada ya aparecen restados en las métricas globales que utiliza GA4. Si los mandamos con importes negativos estaríamos provocando que se sumasen en el aparato. Por lo tanto, value y price siempre se mandarán con su valor positivo.

Si mandásemos los parámetros price y value con valores negativos se invertirían las métricas como podemos ver en el test_8. Estaría mal.

Advertencia: valor monetario, moneda, dimensiones y métricas de ecommerce.

Podemos decir que GA4 es más flexible que Universal Analytics, pero sigue sin ser todo lo flexible que nos gustaría. Sigue, por ejemplo, sin admitir la estructura de items en cualquier evento que no fuese de ecommerce o cuándo estás haciendo un uso más avanzado de la herramienta puede ser que descubras que hay dimensiones de Ecommerce como por ejemplo el id del cupón que si las quieres explotar en un evento que no sea de ecommerce como por ejemplo, un aplicar_cupon las tendrás que dar de alta.

Teniendo en cuenta que esto no tiene carácter retroactivo puede ser una gran putada. Pasa también con la dimensión currency que si la quieres cruzar o desglosar en acciones como pueden ser en un generate_lead o en el propio evento anterior, aplicar_cupon la tendrás que dar de alta si no no la podrás usar.

De la misma forma, que para tener valor monetario en un generate_lead o en cualquier otro evento que consideres importante para tu negocio digno de llevar una métrica monetaria no te quedará otra que crear una métrica personalizada. De la otra forma, tienes la opción de ver el valor del evento, pero no te servirá para todos aquellas propiedades multidivisa.

Dimensiones y métricas personalizadas para poder cruzar en eventos diferentes a los recomendados de ecommerce en GA4
Dimensiones y métricas personalizadas para poder cruzar en eventos diferentes a los recomendados de ecommerce en GA4

Acuérdate siempre de revisar que si la métrica o dimensión pertenecen a la categoría ecommerce es posible que no la puedas cruzar o usar en otros eventos que no sean los propios de ecommerce y no te quedará otra que darlas de alta.

Hasta aquí hemos llegado.

Brais Calvo
Brais Calvo

Más de 5 años en esto, solo sé que no se nada pero me motiva y me divierte la parte más técnica de los datos. Los entresijos, las anomalías y las automatizaciones. No os voy a engañar, los datos chorra son mi fuerte. Lo que sé me gusta contarlo y normalmente ya está Simo Ahava para documentarlo.

Deja un comentario