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 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.
- 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.
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.
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).
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.
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.
- Las métricas que calcula el aparato de forma predeterminadas restan de forma automática los importes de devolución en las métricas relacionadas con los ingresos totales.
Esto podría provocarnos en alguna propiedad o activo, dependiendo de su naturaleza picos de ingresos negativos.
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.
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.
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.
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.
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.