¿Qué es y para que se utiliza un análisis de cohortes?
El análisis de cohortes consiste en realizar un análisis del comportamiento de un segmento determinado de usuarios que tienen una característica en común durante un periodo de tiempo. De esta manera se pueden encontrar patrones en el comportamiento del usuario a lo largo de dicho periodo.
Un análisis de cohortes sirve para detectar cambios en tendencias y responder en consecuencia. Clic para tuitear
A principios de año, Adobe Analytics, incorporó esta nueva funcionalidad en el workspace. En la imagen anterior se puede ver como hay 2 bloques a configurar.
El primer bloque que vemos, marcado en color rojo, consta de 2 partes: Los criterios de entrada y los criterios de salida.
El bloque azul, es el bloque de configuración, donde primero escogeremos el tipo de tabla (retención o churn)
Tabla de retención
Este tipo de tabla informa de los usuarios que cumplen ambos criterios, el de entrada y el de salida. Cada celda de datos muestra el porcentaje de usuarios y número sin procesar.
Es decir, indica en qué medida los visitantes regresan a la web a lo largo del tiempo. Es el análisis de cohortes que más se suele ver y que indica un comportamiento de regreso y repetición por parte del usuario.
Tabla de Abandono
Es el análisis inverso al de retención, justamente nos informa de aquellos usuarios que se desviaron o no cumplieron los criterios de retorno.
Ambos tipos de tablas se pueden configurar y personalizar. Se puede seleccionar la granularidad del periodo del tiempo a analizar, esta granularidad puede ser diaria, semanal, mensual, cuatrimestral o anual.
Si aplicamos el “rolling calculation” lo que sucederá es que forzaremos una especie de embudo. De manera que los usuarios que estén por ejemplo en la semana +4 han tenido que pasar obligatoriamente por las semanas previas.
Si activamos las funcionalidades avanzadas podremos añadir una dimensión personalizada o usar una tabla de latencia.
Tabla de Latencia
La tabla de latencia mide el tiempo que ha pasado antes y después del criterio de inclusión. Esto viene muy bien para realizar un análisis previo/posterior.
Tabla con dimensión personalizada
La tabla con dimensión personalizada nos permite hacer un cohorte basado en dicha dimensión y no en el tiempo. Esto es de gran utilidad para ver cómo cambia la retención en función de los distintos canales de marketing, campañas, productos, etc.
Se puede aplicar hasta 10 segmentos y 3 métricas en los distintos criterios.
Todo esto lo vamos a entender mejor con un ejemplo.
Imaginemos que tenemos un site de asesoramiento y lanzamos una campaña geolocalizada para atraer tráfico al site. Seguro que nos interesa saber si realmente la campaña está funcionando y queremos valorar la fidelidad de dichos usuarios. Y sobre todo qué.
Para este tipo de análisis es perfecto el cohortes.
Podemos crearnos un segmento que incluyan las primeras visitas de dicha campaña y ver cómo se van comportando semana a semana dicho grupo de usuarios.
En este caso se puede ver de manera muy gráfica cómo semana a semana los usuarios van perdiendo interés. Y que Valencia es donde están los usuarios con menor interés.
Otra cosa muy chula que permite Adobe es crear un segmento para las celdas seleccionadas, simplemente pulsando con el botón derecho del ratón te mostrará la opción de configurar segmento. De esta manera, puedes centrarte en analizar ese segmento en particular.
Conclusiones
Este tipo de análisis puede ayudar a analizar el largo plazo. El análisis de cohortes puede ayudarnos a saber qué sucedió en el tiempo con los clientes que compraron por primera vez de la campaña X y los que compraron para la campaña Y, por ejemplo.
¿Has utilizado este tipo de análisis? ¿te han sido de utilidad? Explícanos qué uso le has dado en los comentarios o cómo crees que puedes darle uso
¿Quién no ha pensado alguna vez que la información que ofrece el User Explorer puede llegar a ser muy valiosa pero que es bastante tediosa su utilización?
El uso principal de esta API es poder obtener toda la información de un usuario segmentada por hit.
Con la API de Google Analytics resumiremos todo esto en una sola tabla y podremos utilizar los correspondientes identificadores de cliente y sesión.
En esta entrada os explicaremos cómo descargar estos datos a través de R. De este modo, accederemos a información muy detallada y segmentada por hits, sin necesidad de utilizar Big Query u otra herramienta de pago. Así, una vez tengamos los datos se podrán transformar y utilizar para los análisis pertinentes.
Código en R
El primer paso para utilizar la librería de Google Analytics con el complemento del User Activity, será instalar y actualizar los paquetes necesarios. Para ello debemos ejecutar las siguientes líneas de código e instalar los paquetes necesarios:
Una vez tengamos la librería cargada, el siguiente paso es permitir a la librería acceder a los datos, para ello, debemos utilizar una cuenta de servicio o crear un token con nuestro proyecto de Cloud.
Cuando tengamos acceso, podremos realizar nuestra consulta a la API. Una de las limitaciones de esta función es que sólo podemos realizar una consulta seleccionando aquellos usuarios que queramos estudiar a través de su clientID.
Por tanto, si quisiéramos consultar toda la trayectoria en la web de dos usuarios en un periodo de dos meses deberíamos ejecutar el siguiente código:
Donde el primer parámetro contiene los clientId de los usuarios, el segundo la vista en la que se encuentra la información de estos usuarios y, por último, las fechas que queremos consultar.
Consejo: Para conseguir los usuarios de forma masiva podemos hacer uso de la tabla del User Explorer o de Big Query, teniendo en cuenta que esas consultas serán mucho menos costosas ya que sólo pediríamos el clientId.
Resultados
Una vez hayamos ejecutado el código, two_users contendrá la información completa de estos dos usuarios en dos tablas.
La primera se trata de la información general de las sesiones que han realizado los usuarios que hemos consultado: device, platform, source…
View(two_users$sessions)
Sin embargo, la tabla que realmente nos puede interesar es aquella que incluye todos los hits, tanto la página, como los eventos o las custom Dimension:
En la imagen anterior sólo se muestran las primeras columnas en las que cada fila es un hit.
Esta tabla contiene un total de 26 columnas, entre ellas: customDimension, pagePath, ecommerce, goals o eventCategory.
Consejo: Las columnas de customDimension o ecommerce viene dada por una lista de listas. Para poder obtener una sola dimensión personalizada o algún dato en particular del ecommerce, se puede ejecutar el siguiente código:
Lo cual devuelve dos columnas que se pueden pegar, posteriormente, a la tabla principal.
Conclusiones
Si queremos la información histórica de un usuario segmentada por hits, esta API es muy valiosa. Se pueden obtener datos muy detallados y útiles para la realización de análisis más avanzados. Además, puede ser un sustituto parcial de herramientas de pago como Big Query.
Nos podemos encontrar ciertas limitaciones por la gran cantidad de llamadas a la API que se requieren para sacar un volumen considerable de datos. Además, no se pueden descargar todos los usuarios de un periodo, sino que se tienes que seleccionar individualmente.
Para indagar un poco más y sacar el mayor partido posible a la API desde R se puede consultar este Post de Mark Edmonson en el que desarrolla un poco más las capacidades de esta herramienta:
El Activity Map (AM) es una funcionalidad que ofrece de manera gratuita Adobe Analytics (AA) y que como único requerimiento indispensable para que funcione o para disponer de dicha herramienta es que se tenga una versión del código de AA igual o superior a 1.6. El siguiente paso será habilitar los informes de Activity Map en Report Suites > Settings > Activity Map y dar acceso a estos informes a los usuarios que se quiera.
Para saber qué versión se tiene se puede ver en la información del hit de AA en consola. Para ello, nos fijaremos en el parámetro “j”.
El AM nos permite ver información de la página en tiempo real, ver dónde clican más los usuarios, qué eventos se están produciendo más. Además de poder crear segmentos para centrarnos sólo en aquellos usuarios que realizan una determinada actividad, por ejemplo si nos interesa ver aquellos que en la ficha del producto pero que no acaban comprando.
Qué hacen estos usuarios, cuánto tiempo pasan en nuestro site, qué contenidos les interesan más y qué problemas tienen.
Extensión Adobe Analytics Activity Map
Para todo lo relativo con el tiempo real necesitamos instalarnos la extensión de Activity Map en nuestro navegador, aquí se puede acceder al enlace para Chrome.
Configurar extensión
Una vez instalada la extensión entraremos en la página a analizar y pincharemos en el icono de la extensión hasta que se ponga de color.
Dejaremos que se cargue y nos saldrá un modal para registrarnos con nuestros usuario de Adobe.
Una vez activado y sincronizado con nuestro usuario de Adobe, se cargará la página otra vez pero sin la extensión activada. Pinchamos en el icono otra vez, y dejamos que se cargue.
Una vez cargado nos saldrá una barra de herramientas y dependiendo de la información que deseemos ver, la configuraremos de una manera u otra.
Para acceder al panel de configuración haremos click en la rueda.
La herramienta se compone de distintos bloques:
1- Tipo de informe: el estándar es el que tira del histórico en base al periodo seleccionado. Mientras que si se coge “activo” analizar el tiempo real según lo que se configure. Para el activo cambia la barra de herramientas ligeramente.
2- Métricas: Aquí tenemos un desplegable con todos los eventos detectados en el report seleccionado, así como las métricas básicas de Adobe Analytics.
3- Segmentos: Aquí estarán disponibles todos los segmentos configurados con la cuenta sincronizada para ver el comportamiento de los usuarios de dicho segmento en esa página.
4- Tipo de visualización: Burbujas equivale a bocadillos con los datos, degradación escala de colores.
5-Periodo a Analizar: sólo está disponible cuando se tiene un informe tipo estándar.
Además, si pinchamos en el ojo de la barra de herramientas en la pantalla del navegador veremos desplegada toda la información acerca de la configuración que hemos realizado en dicha barra para la página que estamos analizando.
En el caso de la imagen se puede ver el número de clicks y el porcentaje que supone del total de clicks, así como el literal del elemento clicado e información sobre dónde está situado y si está visible o oculto como podría ser en el caso de un menú desplegable.
Como se puede ver ofrece mucha información de utilidad cuando nos interesa saber qué hacen los usuarios de nuestro site en una determinada página.
Ahora bien, cabe destacar que esta es una herramienta gratuita que ofrece AA, ¿pero cómo funciona realmente?
Resulta que la información que vemos del AM la obtenemos una vez el usuario ha interactuado con algún elemento de nuestro site y ésta información se ha enviado en un hit posterior.
Es decir, que si el usuario hace una acción y luego no se lanza ningún hit o se va del site, perderemos esa información del AM.
En la imagen anterior se puede ver la información del AM cuando se ha hecho click en la zona de acceso al área privada de un site.
Espero que os sirva de ayuda para ir empezando con Activity Map. Sin duda es una magnífica herramienta a la que se le puede dar un uso muy interesante.
Add a header to begin generating the table of contents
El CRO, del inglés “Conversion Rate Optimization”, es un ámbito de la analítica digital que tiene como objetivo proporcionar mayor rentabilidad a cualquier negocio online. Se trata de mejorar la tasa de conversión actual sin cambiar la cantidad de tráfico que recibe tu activo digital.
La fórmula es la siguiente: misma cantidad de tráfico + cantidad de conversiones más elevada = mayor rentabilidad.
En el caso de un eCommerce, si el mismo nivel de tráfico genera más conversiones, tu negocio obtendrá más beneficios ya que invirtiendo la misma cantidad de dinero en marketing y producción, conseguirás más ventas y aumentarás tu facturación.
Para mejorar tu rentabilidad, necesitas tener en cuenta varios métodos clave del CRO. A continuación te explicamos 4 métodos para que tu CRO mejore.
El método Trinity
Este método, creado por Bryan Eisenberg, se basa en el análisis de tres variables a través de tu funnel de conversión, desde la captación de usuarios hasta su conversión en clientes:
Relevancia.
Valor.
Call to Action.
Relevancia
Valor
Call to Action
Relevancia
Tu negocio tiene que ser relevante en relación con las necesidades y búsquedas del usuario.
Si tu negocio sale en los buscadores de forma orgánica o en anuncios de pago cuando un usuario busca “móviles baratos” o “móviles de segunda mano”, al clicar en tu anuncio, el usuario tiene que encontrar exactamente lo que busca. Si lo llevas a una página con todo tipo de móviles o a una página que tiene de todo menos el producto que busca, no sólo saldrá sin comprar sino que muy probablemente no volverá.
Tus anuncios o tus snippets en los resultados de búsqueda también tienen que ser relevantes en relación con lo que ofertas en la página de aterrizaje.
Si el usuario busca “móviles de segunda mano” y quieres salir en los resultados de esta búsqueda, asegúrate de que tus anuncios tengan la palabra clave y la página de aterrizaje sólo ofrezca lo que busca el usuario.
Cuanto más concreto, más relevante con las necesidades del usuario y cuanto más relevante, más conversiones obtendrás. Clic para tuitear
Valor
Si eres tan relevante como un competidor tuyo pero este competidor tiene una propuesta de valor clara y tú no, seguramente él se llevará las conversiones que deseas. Necesitas analizar tu competencia para ver lo que ofrece y mejorar sus propuestas de valor.
Una vez hayas diseñado una propuesta de valor original y viable, tiene que ser visible en todo el funnel de conversión.
Por ejemplo, “transporte gratis a partir de 40€ de compra” podría aportarle valor al usuario, pero si no está visible en todas las etapas del embudo, no lo tendrá presente. El valor es lo que te diferencia de otras webs y tiene peso en la decisión final del usuario.
Call to Action
Si eres relevante, le aportas valor al usuario pero no le indicas claramente las acciones que tiene que realizar dentro del embudo que has creado, puede que salga de tu activo digital en alguna etapa por no dejarle claro lo que tiene que hacer.
Las llamadas a la acción, como “ver producto”, “añadir al carrito”, “comprar” o “registrarse”, tienen que ser visibles, aplicarse a los elementos correctos y funcionar adecuadamente para que el usuario no se pierda, sepa en cualquier momento las acciones que puede llevar a cabo y se encuentre siempre en el paso previsto después de llevar a cabo la acción.
Un negocio digital claro que indica correctamente las acciones que se pueden llevar a cabo y que funciona según lo esperado, le proporcionará confianza al usuario.
El método Trinity mejora la experiencia de usuario para obtener más conversiones.
Más adelante veremos el método test A/B o multivariante que se puede aplicar al método Trinity para testear propuestas de valor, llamadas a la acción e incluso la relevancia del negocio.
El método de investigación cuantitativa y cualitativa
Analiza constantemente tu negocio digital a través de herramientas como Google Analytics para encontrar el ¿qué? Por ejemplo, puedes encontrar problemas como una tasa elevada de pérdida de usuarios en alguna etapa del embudo de conversión o una bajada en el número de conversiones para un producto en particular.
También puedes encontrar más ¿qué? con encuestas online: “al 50% de encuestados, no le convence un producto en particular”.
La investigación cuantitativa es la que revela estos ¿qué? y es importante para conocer qué etapa del proceso de conversión o qué indicador claves de rendimiento fallan o son mejorables.
Sin embargo, también necesitas saber el ¿por qué? del ¿qué? . Una vez hayas detectado un punto mejorable a través de métricas que no tienen el rendimiento esperado en algún punto del embudo (tasa de navegación de un paso a otro baja, cantidad de salidas de usuarios alta, cantidad elevada de encuestados descontentos con un servicio/producto en particular, etc.), tienes que descubrir por qué pasa.
Sólo podrás sacar conocimientos accionables (“actionable insights”) cuando sepas el porqué. Los conocimientos accionables son razones por las cuales pasan algunas cosas en tu negocio digital y sobre las cuales puedes actuar para mejorar la experiencia de tus usuarios, así como tu tasa de conversión.
Para saber el porqué, se utiliza la investigación cualitativa. Existen muchas maneras de llevar a cabo este tipo de investigación. Aquí te dejamos algunas:
Estas herramientas te permiten grabar la navegación y las acciones de tus usuarios en las partes de tu activo digital que quieres analizar.
Por ejemplo, vendes muebles y has detectado a través de Google Analytics una pérdida importante de tráfico en el listado de sillas. Con Hotjar u otra herramienta del mismo tipo, podrás grabar el comportamiento de tus usuarios en la página de sillas.
De esta manera, muy probablemente encontrarás el porqué.
Tests de usuarios
Asimismo, puedes invitar a algunos usuarios a que participen en un test.
Puedes utilizar estas pruebas para ver cómo usan un elemento o una sección de tu web en vivo, para detectar los problemas con los cuales se topan mientras navegan y para ver cómo entienden tu negocio o cómo les gustaría que sea para cubrir sus necesidades de la mejor manera posible.
Tienes que diseñar el objetivo de tus pruebas e incentivar a los usuarios, mediante algún premio, para que participen.
Los tests son una de las herramientas más potentes para entender el ¿por qué? de diferentes irregularidades en el rendimiento de tus métricas y para destapar algunos disfuncionamientos dentro de tu activo digital.
También son utilizados a la hora de diseñar productos centrados en el usuario. En este caso, se trata de encontrar la manera óptima de diseñarlos con el fin de proporcionar una experiencia única al público objetivo.
Entrevistas de usuarios
Como para los tests de usuarios, necesitas darles algún tipo de incentivo a tus usuarios para que acepten participar en entrevistas personales.
Estas entrevistas te sirven para conocer la opinión personal de varios usuarios con respecto a alguna sección de tu web o al producto entero, para entender por qué y cómo usan tu activo digital y para saber si personalmente han tenido algún problema en una de las secciones en las cuales has detectado una irregularidad.
Estas entrevistas te darán muchos insights sobre tu negocio e ideas para mejorar su rendimiento.
«ARIZONA WATER PERSONAS / ENGAGEMENT TIMELINES» de Angela Schill, CC BY-NC 4.0 : ejemplo de una “user” persona creada a través de una entrevista de usuario.
Los conocimientos accionables que sacarás de tu investigación cualitativa te permitirán crear hipótesis que utilizarás en tests A/B o multivariantes.
Estos tests te servirán para confirmar o no tus hipótesis. Las hipótesis siempre se basan en el impacto positivo que pueda tener una mejora en la web sobre la tasa de conversión.
Tanto durante las investigaciones cuantitativas como en las investigaciones cualitativas, la clave es aprender del análisis para actuar sobre los elementos que supuestamente tendrán más impacto en la mejora de la tasa de conversión.
El método de tests A/B o multivariantes
A continuación, utilizarás los conocimientos accionables para hacer pruebas dentro de tu activo digital. Las pruebas pueden ser de dos tipos:
Pruebas A/B
Pruebas multivariantes
Pruebas A/B
En las pruebas A/B, testeas dos diseños diferentes de la misma página. Mostrarás uno de estos diseños a una parte de tu tráfico y su variante a otra parte de los visitantes.
Por ejemplo, en tu investigación cuantitativa, has detectado una salida elevada de visitas en la primera etapa de tu checkout, justo cuando los usuarios están a punto de convertir.
Para entender qué es lo que pasa en tu primera etapa del checkout, invitaste a un panel de usuarios para que te explicaran, mediante entrevistas personales, su experiencia dentro de tu ecommerce, cuáles son las etapas menos entendibles, cómo se mueven dentro de tu checkout, etc.
En estas entrevistas descubriste que para la mayoría de tus entrevistados, el diseño de la primera etapa del checkout era confuso y no lo entendían correctamente.
Por tanto, decidiste crear un diseño nuevo para testearlo frente a la versión actual. La variante se muestra a 50% de tu tráfico y la versión de control a la otra mitad.
Pruebas multivariantes
A diferencia de las pruebas A/B, en las que dos versiones de una misma página compiten entre sí, las pruebas multivariantes se usan para testear diferentes combinaciones entre diferentes variables de una página o diferentes variaciones para la misma variable.
Se trata de entender cuál es la combinación de elementos que mejor funciona para tu público objetivo.
Si solo quieres testear 2 variaciones de una variable, la prueba tendrá 2 combinaciones en total. Cojamos el ejemplo del último Call to Action “comprar” en el checkout de tu ecommerce. Esta es la única variable que quieres testear y la única variación que le quieres aplicar es un cambio de posición. Por tanto, tendrás 1 variable y 2 versiones:
variable + posición control
variable + variación en la posición
Por ende, testearás 1 variable x 2 variaciones = 2 combinaciones.
En cambio, si quieres probar 2 variaciones de 3 variables distintas, testearás 2 variaciones de la primera variable x 2 versiones de la segunda x 2 versiones de la tercera = 8 combinaciones en una misma página.
En general, se prueba cada combinación en partes iguales del tráfico.
Priorización de los tests
Es posible que saques de tus investigaciones cualitativas varios conocimientos accionables. Para cada uno de ellos, tienes unos tests pensados, pero ¿por cuál de estos tests tendrías que empezar?
Para obtener la respuesta, utiliza el ICE score. Las siglas ICE se refieren a las tres palabras clave siguientes:
impacto
confianza
esfuerzo
Impacto
Aquí lo que valorarás del 1 al 5 es el impacto real que piensas que esta acción pueda tener sobre tu tasa de conversión. Si puede tener mucho impacto, le pondrás un 5.
Confianza
Se trata de saber si tienes mucha confianza en que la mejora testeada funcione. Si estás convencido de que funcionará, también le pondrás un 5 a este punto.
Esfuerzo
Finalmente, tienes que valorar el tiempo y el esfuerzo que necesitarás para llevar a cabo esta prueba. Si no necesitas la ayuda de desarrolladores y no necesitas muchos recursos para llevarla a cabo, también le darás un 5 a este punto.
Esta triple valoración la tienes que hacer para cada prueba que tienes en mente. La puntación máxima es 5x5x5 = 125.
La prueba que se acerque más a esta puntación es la prueba que priorizarás. La segunda que llevarás a cabo será la segunda en la clasificación de tu valoración ICE.
Esta es la manera de encontrar un orden en la ejecución de tus pruebas.
Nivel de confianza estadística
El nivel de confianza es un elemento importante que tendrás que aplicar a tus pruebas. Ojo, este elemento no tiene nada que ver con la variable confianza del ICE score. Se trata de la fiabilidad estadística de tu prueba. Indica la probabilidad de que el resultado de la prueba se mantenga al repetirla.
La referencia para tener un resultado fiable es un nivel de confianza de 95%. Si aplicas este nivel de confianza a tu prueba y tienes un ganador, la probabilidad es que, si repites la prueba 100 veces, salga el mismo ganador 95 veces.
Eso sí, ten en cuenta dos aspectos importantes:
Cuanto más alto el nivel de confianza, más elevada tiene que ser la cantidad de tráfico para poder llegar a esta fiabilidad estadística.
Estarás más cerca del nivel de confianza que defines cada vez que la diferencia entre los resultados de tu diseño de control y los de tu variación crezca.
Duración del test
Antes de lanzar un test, calcula cuánto tiempo lo tendrás que ejecutar para poder tomar una decisión que sea fiable cuando acabe. Existen varias calculadoras online que te ayudarán en esta labor. Una de ellas es la calculadora de Tests A/B y Multivariantes de VWO.
Los campos imprescindibles que tendrás que rellenar para que esta calculadora te devuelva una duración de ejecución seria y realista son los siguientes:
Tasa de conversión existente.
Mejora mínima en la tasa de conversión que esperas.
Cantidad de combinaciones que lleva tu test.
Cantidad media de usuarios diarios.
Porcentaje de usuarios incluidos en la prueba.
Impacto del test
Cuando acabe el test, tendrás que calcular si su resultado es lo suficientemente significante como para llevar a cabo un cambio en tu negocio digital.
Si el test confirma tu hipótesis, se trata de saber si la diferencia entre el resultado de tu versión A y el de tu variación B es lo suficientemente elevada para pensar que el cambio tendrá un impacto importante en tu tasa de conversión.
Los datos que necesitarás entrar para que funcione la calculadora son los siguientes:
El número de visitantes en cada variante.
El número total de conversiones en cada variación.
La calculadora te calculará la tasa de conversión de cada versión y el porcentaje en la mejora de la tasa de conversión de una variante respecto a otra. Según el resultado que salga, obtendrás la valoración de la calculadora sobre el posible impacto de la versión ganadora.
Herramientas de tests A/B y multivariantes
Existen muchas herramientas de tests A/B y multivariantes. Aquí te dejo algunas:
Siendo gratis, Google Optimize es una de las herramientas más utilizadas, pero tienes que valorar cada herramienta según tus necesidades y lo que te permita hacer.
Google Optimize es una opción muy válida para empezar. Si necesitas ir más allá, pide una demo de varias herramientas de pago para encontrar la que más te convenga.
El método personalización
La personalización es una disciplina del CRO que tiene como objetivo personalizar el contenido de tu activo digital según el tráfico que te llega y también según el tráfico que sale y la parte de tu embudo de conversión por la cual sale.
Herramientas como Dynamic Yield y A/B Tasty te ayudan en esta labor de personalización.
Puedes usar estas herramientas para crear audiencias y contenido personalizado para cada una de ellas.
Por ejemplo, vendes muebles online y quieres crear una audiencia de visitantes que ya han comprado mesas para mostrarles otros productos que les podrían interesar según el tipo de mesas que hayan comprado. En este caso, podrías mostrar a los usuarios que han comprado mesas de centro, sofás y butacas en sus próximas visitas. Es lo que se llama “cross-selling”.
También podrías crear una audiencia de retargeting para impactar a todos los usuarios que han salido de la sección de sofás de tu activo digital con el fin de enseñarles anuncios de sofás con descuentos. Las landing pages asociadas a estos anuncios tendrían que mostrar los mejores sofás con descuentos que tengas.
Varias herramientas de personalización permiten automatizar el contenido que muestras a través del machine learning. Estudian el comportamiento del usuario y según su comportamiento, le muestran un tipo de contenido u otro. Usan los datos en tiempo real de los usuarios para que tus campañas o tu contenido obtengan el mejor impacto en un momento dado.
Como puedes ver, la personalización es una herramienta muy potente a la hora de optimizar tu tasa de conversión.
Gracias a las herramientas de personalización, podrás aprender mucho sobre el comportamiento de tus usuarios con el fin de modificar tu contenido para ofrecer a cada una de tus audiencias o a cada uno de tus usuarios el contenido más apto para su conversión en cualquier momento. Se podrá llevar a cabo en tiempo real o según las audiencias y el contenido que creas para cada una de ellas.
Conclusiones
Puedes aplicar los 4 métodos clave del CRO en el mismo orden que en este artículo o creando la estrategia que mejor se ajuste a tus necesidades. En todo caso, podrás constatar que cualesquiera de estos métodos pueden mejorar tu tasa de conversión si los trabajas de forma adecuada y recurrente.
Algolia es un motor de búsqueda muy potente que puede implementarse de manera muy sencilla y rápida en cualquier página web o aplicación móvil. En este artículo encontrarás una guía básica para implementar Algolia de principio a fin.
Cuando decimos “preparar los datos” nos referimos a que los datos deben seguir unas especificaciones concretas para que el motor de búsqueda pueda procesarlos y también a optimizar los datos para su búsqueda, y así mejorar la velocidad y calidad de la respuesta.
Formato
Algolia funciona exclusivamente con datos en formato JSON.
Los tipos de atributos que se puede utilizar son cadenas (string), números (integer y float), booleanos (true o false), objetos anidados y arrays. No admite, por ejemplo, el formato de fecha (date). Para trabajar con fechas habría que convertirlas a unix timestamp. Un registro podría ser el siguiente ejemplo:
Optimización de los datos
Para esta parte la premisa principal es el lema “Menos es más” como decía el arquitecto Mies van der Rohe.
No es una buena práctica pasar toda la base de datos del feed de producto a la herramienta. Lo recomendable es hacer una selección de aquellos datos que se consideren relevantes para la búsqueda. Podemos diferenciar varios tipos distintos:
Searchable attributes: los atributos que pueden ser buscados. Por ejemplo, para un registro de películas estos podrían ser título, actores, género o descripción.
Filtering/facetting attributes: atributos que van a permitir refinar la búsqueda y conseguir un mejor resultado, como podrían ser el año, género, puntuación o palabras clave.
Display attributes: atributos que se utilizarán para visualizar los resultados, como por ejemplo la URL que permitirá visualizar una imagen.
Business metrics attributes: atributos decisivos para que los mejores resultados aparezcan por delante de otros menos relevantes.
Subir los datos a Algolia
El primer paso es configurar el cliente API instalando el paquete algoliasearch. Utilizaremos NPM para este ejemplo, pero puedes utilizar el gestor de paquetes que tú prefieras.
npm install --save algoliasearch
A continuación hay que crear una instancia del cliente con el appID y apiKey de la cuenta que quieras utilizar. Esta información la encontrarás en tu Dashboard de Algolia:
El código para crear la instancia es el siguiente:
Ahora ya podemos subir los registros. Hay varias formas para hacerlo: directamente desde el código fuente, importando un archivo JSON o importando los datos desde la base de datos.
La forma más común de cargar los datos es utilizando un fichero JSON, y sería desde la sección de Indices desplegando el submenú de Upload records y seleccionando Upload file:
Podríamos hacer lo mismo desde código con las siguientes sentencias:
const movies = require("./movie_dataset.json");
index.addObjects(movies);
Después habría que ejecutar en consola el siguiente comando:
node main.js
Paso 2: Definir reglas de relevancia
Por defecto todos los atributos que aparecen en el JSON de feed de producto son “buscables” y eso genera mucho ruido. Así que habrá que definir las reglas de relevancia para mejorar la calidad de la respuesta de las búsquedas que haga el usuario.
Searcheable Attributes
Son aquellos atributos que se quieren controlar, se excluirían por ejemplo, las URLs de imágenes o la página web asociada al registro. Además podemos ordenar los atributos por relevancia o ponerlos al mismo nivel de importancia si se diera el caso. Por último, también podríamos indicar si el orden en el que se escriben las palabras es relevante para cada atributo o no lo es.
En el ejemplo anterior estamos indicando que el atributo title y alternative_titles tienen la misma relevancia. El siguiente atributo más importante es genre y por último actors. Además, en genre indicamos que no es relevante el orden que tengas las palabras de atributo utilizando unordered.
Custom ranking attributes
Cuando varios registros tienen exactamente la misma relevancia textual para una consulta dada, se define una clasificación personalizada que provocará el desempate y colocará los resultados más relevantes en primer lugar.
Siguiendo con el mismo ejemplo podríamos definir lo siguiente:
En el ejemplo anterior estamos indicando que el desempate se basará en primer lugar en el valor del atributo rating en sentido descendente, en segundo lugar por el atributo year y en tercer lugar por el atributo score. Si queremos que se tengan en cuenta en sentido ascendente solo habría que cambiar desc por asc.
Faceting
Además, se pueden definir una especie de filtros que facilita la búsqueda del usuario. Se definen de la siguiente manera:
Podemos definir también el número máximo de resultados que se muestran al usuario por página del siguiente modo:
index.setSettings({
'maxValuesPerFacet': 1000
});
Todo esto y muchas más reglas se pueden configurar también desde el Dashboard del proyecto Algolia. En la sección de Indices, si accedes a la pestaña de Configuración podrás configurar de forma completa la búsqueda en función de los intereses comerciales del momento.
Fase 3: Desarrollo de la interfaz del usuario
Hay dos formas fundamentales de visualizar la búsqueda en la web. Dropdown menu que se aconseja cuando el buscador es accesible desde distintas páginas de la web y la más utilizada que es Instant search result page, donde se pasa a una página dedicada en exclusiva a la visualización de resultados. Generalmente, esta última garantiza una mejor experiencia de usuario.
Se puede ver un ejemplo de la primera en la web de noon y un ejemplo de la segunda en la web de Mercadona.
Instant search result page
La página de resultados instantánea es válida para aplicaciones móviles iOS como Android y además para aplicaciones web siendo compatible con Vanilla, React, React Native, Angular y Vue.
Las posibilidades que permite Algolia para desarrollar la parte front del buscador son múltiples y variadas. Encontrarás mucha documentación interesante y sencilla de aplicar en la web oficial de Algolia.
Ejemplo para testear
Para concluir te dejamos aquí un ejemplo de sandbox para que veas lo fácil y rápido que sería montar un proyecto propio:
Este año Google nos ha traído varias actualizaciones en el área de analítica, siendo la más reciente la inclusión de las propiedades App + Web. Este nuevo modelo de propiedades nos permite consolidar los datos de páginas webs y aplicaciones en un solo sitio, facilitando el análisis multiplataforma. Esta consolidación de datos viene acompañada de un cambio de paradigma en el modelado de datos. Este nuevo esquema de datos abandona el método tradicional de Session + Pageview, que el clásico Google Analytics ha utilizado durante más de 15 años y en su lugar, lo reemplaza por un modelo basado en eventos y parámetros (ya utilizado por Firebase), logrando de esta forma una consonancia entre los datos recogidos por las diferentes plataformas.
Las propiedades de App + Web admiten múltiples fuentes de datos, una sola propiedad soporta hasta 50 fuentes de datos de aplicaciones, sitios web y aplicaciones web diferentes. Esto nos permite ver métricas agregadas de todas sus aplicaciones y sitios web relacionados o aplicar filtros para hacer comparativas directas.
Por ejemplo, un comercio en línea con múltiples tiendas regionales, podría ver sus ventas globales totales en el mes o comparar las ventas de cada uno de sus sitios y aplicaciones regionales.
Como se puede apreciar en la imagen anterior, a primera vista, los widgets de la Home nos pueden recordar a los que tenemos en las antiguas vistas de Google Analytics, así como los grupos de informes tradicionales (Realtime,Users, Demographics y Behaviour).
Dentro del grupo de reportes ya empezamos a ver novedades, aquí aparece Technology, un reporte que se subdivide en web, app y cross-platform, donde se presenta datos agregados a nivel de usuario, filtrando por la plataforma escogida.
El reporte Cross-platform, tal y como su nombre indica, hace una comparativa entre las dos plataformas, permitiéndonos ver de manera rápida el rendimiento web vs. app y qué nivel de solape existente entre los usuarios.
Sección Análisis
La parte más cargada de novedades es sin duda la sección de análisis, aquí tenemos varios apartados como:
Analysis Hub
Agrupa todos los informes de análisis personalizados para crear, acceder, editar, copiar y compartir rápidamente.
Exploration
Herramienta drag-and-drop de métricas, dimensiones y segmentos que permite crear informes utilizando tablas, gráficos de anillos, gráficos de líneas, gráficos de dispersión y mapas geográficos. Es muy útil para análisis rápidos, nos recuerda un poco (salvando las distancias) al Workspace de Adobe Analytics.
Segment overlap
Permite crear y seleccionar múltiples segmentos de audiencia para compararlos y ver dónde hay superposiciones.
Funnel Analysis
Permite crear visualizaciones de embudo ad-hoc. Puede crear un «embudo estándar» que muestra cómo los usuarios están completando los pasos o un embudo de tendencias que permite ver el rendimiento de cada uno de los pasos a lo largo del tiempo, otra opción interesante es la de poder seleccionar un embudo abierto, de este modo se incluirá a las personas que ingresen al embudo en cualquier paso.
Path Analysis
Un informe muy útil, permite ver cómo las personas viajan a través de su sitio web y aplicación con un gráfico de árbol.
User explorer
Nos permite profundizar a nivel de usuarios individuales, ver las acciones que ha realizado y poder analizar cuál ha sido el flujo que ha seguido para conseguir una conversión.
Limitaciones
Hay que recordar que estas nuevas propiedades están en modo Beta y tienen ciertas limitaciones que se irán mejorando en el tiempo, de momento en el área de análisis solo se pueden utilizar datos de los últimos 90 dias.
Próximos Pasos
Para la próxima actualización se han anunciado ya nuevas adiciones al apartado de análisis como Cohort analysis, Backward pathing y User lifetime así como también insights automáticos basados en machine learning, para detectar tendencias y anomalías en la data.
Estate atento a las nuevas novedades que traerán estas nuevas propiedades, desde Dr. Metrics os iremos informando.
Una de las formas fundamentales y básicas de mejorar la conversión de un sitio web es realizar tests de optimización (A/B o multivariante).
Dada una versión inicial de un elemento (desde un texto o botón a una landing completa) y una o más variantes alternativas, iremos mostrando una y otra(s) a diferentes usuarios y midiendo la tasa de conversión de los diferentes grupos. Cuando se hayan recogido los suficientes datos, las frías y objetivas matemáticas nos dirán qué versión funcionó mejor.
Pero en muchas ocasiones, nos encontramos con que, por mucho que se alargue el test, no obtenemos más que resultados inconcluyentes o una victoria pírrica por parte de una de las opciones.
Ejemplo de un test de optimización sin resultados concluyentes
Puede ser que nuestra hipótesis de mejora no fuera correcta y que un posible cambio en lo que estamos poniendo a prueba no supone ninguna diferencia.
Pero es más habitual que esos resultados globales escondan otra cosa. Hablamos de que dicho cambio podría haber tenido una influencia positiva sobre una parte de los usuarios a los que se les mostró, mientras que fue negativa para otra parte, compensándose ambos resultados.
La clave aquí sería segmentar para poder dar con esos patrones. Y la manera más eficiente de hacerlo es con una herramienta especializada en personalización, como Dynamic Yield, de la que ya os hablamos hace un tiempo.
El predictive targeting o como personalizar con el piloto automático puesto
Simplificando, en Dynamic Yield podemos plantear un test A/B de una manera similar a como podríamos hacerlo, por ejemplo en Optimize.
Configuración de un test A/B en Dynamic Yield
Una vez lanzado, el test empezaría a mostrar una variante u otra a diferentes usuarios, midiendo su grado de conversión y arrojando, con el tiempo e idealmente, un vencedor. Nada nuevo aquí.
Pero en esta herramienta, por debajo y sin nuestra intervención, está funcionando la “magia” del predictive targeting.
¿En qué consiste? La herramienta podrá arrojar una variante vencedora en términos generales, pero internamente va evaluando el resultado contra diferentes perfiles de usuario. Ésto evitaría el problema que comentábamos antes de resultados positivos para una parte de los usuarios y negativos para otra que acaben compensándose y hagan pensar que el experimento no ha servido de nada. Esta es la verdadera personalización.
La clave aquí será la creación previa de una serie de reglas en la herramienta que nos permitan clasificar a los futuros usuarios en audiencias significativas. Las audiencias de Dynamic Yield se construyen de una manera similar a cuando creamos audiencias de remarketing en Google Analytics en base a segmentos avanzados. Definimos las condiciones para pertenecer a una audiencia y ésta se va poblando a medida que llegan visitas que cumplan esos criterios.
Aparte de las audiencias por defecto (por canal de adquisición, por tipo de dispositivo, etc.), podemos crear otras más personalizadas: usuarios que hayan visitado cierta sección, que hayan comprado en el último año, que se conecten desde cierto país y un largo etcétera.
Con el test en marcha, en el momento en que Dynamic Yield detecte que cierta variante funciona significativamente mejor que otras con cierta audiencia, nos avisará de ello, ofreciendo la opción de asignar de manera fija esa versión a los usuarios que encajen con ese perfil. ¡Voilà! Ya tenemos una personalización respaldada por un análisis con resultados estadísticamente significativos.
Ejemplo de oportunidades de personalización detectadas por el predictive targeting en un test A/B. Fuente: dynamicyield.com
De un test lanzado para el total de los usuarios iremos obteniendo, a medida que los datos lo permitan, personalizaciones concretas para ciertos grupos de usuarios. Serviremos a cada persona aquello que sabemos que va a funcionar mejor con ella o que le va a resultar más relevante. Y todo ello, de manera automática y sin que requiera un análisis concienzudo por nuestra parte.
¿Qué te parece? ¿Has probado ya Dynamic Yield? ¡La personalización es la clave!
La PSD2 (Payment Service Directive 2) es la nueva directiva europea con la que se pretende aumentar la seguridad y mejorar la protección en los pagos digitales relacionados con operaciones bancarias. Y además añade la peculiaridad de que se regula el acceso a nuestros datos bancarios por parte de empresas de terceros como pueden ser Amazon, Facebook, Twitter… Gracias a esta nueva directiva se suprimen los intermediarios en los pagos electrónicos y se refuerza la posición del consumidor.
¿Qué problemáticas nos puede traer la PSD2?
La parte que nos afecta en el ámbito de la analítica digital con respecto a esta nueva directiva de pagos es que a partir de ahora la cantidad de dominios de referencia a excluir será mayor ya que cada banco o cada plataforma de pago puede tener uno o varios dominios validadores. Además este nuevo proceso, supone la ruptura de la sesión ya que el usuario es redirigido a un dominio externo que no estará trackeado con nuestra herramienta de medición, en este caso Google Analytics.
Nos podremos encontrar con casos similares a este:
En este caso, a raíz de la implantación de la nueva directiva, la cantidad de dominios de referencia asociados directamente a las transacciones es enorme: 71 dominios diferentes en este caso concreto. Esto supone por un lado que los datos asociados a las transacciones de nuestro site estén muy desagregados y, por otro lado, que la asignación de las variables a los diferentes medios o campañas se pierda y se quede asignada a estas plataformas.
Muchos pensaréis que bueno, la solución es fácil, simplemente cogemos los 71 dominios y los ponemos en la lista de exclusión de referencia de la propiedad (uno por uno) y listo. Y la realidad es así para sites pequeños y con pocas propiedades.
En el caso de sites más grandes en los que puede llegar a haber hasta 50/80 propiedades para distintos equipos de la empresa o subdominios de la propia web, esta tarea, a groso modo, supone aproximadamente entre 3.500 y 5.600 interacciones manuales, conclusión: una pérdida de tiempo.
Esta problemática se podría resolver si las listas de exclusión de referencia se pudieran configurar mediante expresiones regulares o si se pudieran aplicar a un conjunto de propiedades con un solo click. Ese día, cuando Google lo implemente, este post quedará desfasado,pero hasta entonces hay una manera más sencilla que la de incluir 5600 veces varios dominios en la lista de exclusión de referencia.
¿Cómo podemos excluir dominios de referencia de forma eficiente?
La solución pasa por Tealium (o cualquier otro gestor de etiquetas) y su capacidad para editar el dominio de referencia registrado para los visitantes de nuestro site.
El proceso se resume en los siguientes pasos:
Crear una variable nueva llamada referrer_modified
Crear una nueva extensión custom JS
Modificar nuestro tag de Google Analytics de Tealium
Añadir un único dominio en la lista de exclusión de referencia de nuestra propiedad de Google Analytics.
Paso 1: Crear una variable nueva llamada referrer_modified
Como muchos habréis intuido la idea es modificar el dominio de referencia que tiene una visita. Por lo tanto lo primero que haremos será crear en el Data Layer de Tealium una variable llamada referrer_modified en la que almacenaremos la modificación del dominio:
Paso 2: Crear una nueva extensión custom JS
El siguiente paso consiste en crear una extensión nueva en nuestra librería, que llamaremos “JS – Set referral renaming payment platforms” que deberá ser del tipo custom JS y que configuraremos de la siguiente manera:
Cuyo código javascript contendrá lo siguiente:
utag_data["referrer_modified"]=window.document.referrer;
if(/({Dominios a excluir en formato regex})/.test(utag_data["referrer_modified"])){
utag_data["referrer_modified"]="{Nombre para nuestro dominio modificado}";
}
Donde deberemos sustituir los siguientes parámetros:
{Dominios a excluir en formato regex}: incluimos el listado de dominios que queremos excluir separados por una barra vertical |
{Nombre para nuestro dominio modificado}: pondremos el nombre del nuevo dominio que tendrá el usuario asignado (debe ser en formato dominio: https://www.dominioXXXX.es) para este caso vamos a utilizar https://www.pasarelapagopsd2.com
Este código lee el dominio de referencia del navegador del usuario, lo compara via regex con un listado de dominios que queremos excluir y, por último, asigna el valor que nosotros decidamos a la variable “referrer_modified” que habíamos creado previamente.
Paso 3: Modificar nuestro tag de Google Analytics de Tealium
El penúltimo paso es modificar nuestro tag de Google Analytics de Tealium para hacer que cuando envíe el hit a la plataforma de Google Analytics el dominio de referencia que se envíe sea el almacenado en nuestra variable referrer_modified. Para ello simplemente tendremos que configurar lo siguiente:
Entramos en el tag de Google Analytics de Tealium (analytics.js) y pulsamos sobre el botón edit de mapped variables:
Añadimos nuestra variable referrer_modified y la configuramos de la siguiente forma:
Guardamos y finalmente publicamos todos los cambios realizados.
A partir de la publicación empezaremos a ver en nuestro site datos similares a estos:
Como podemos ver, todas las visitas de nuestro site que tuvieran uno de los dominios de referencia que hemos incluido en nuestro listado en la extensión custom JS de Tealium. Por lo tanto, una vez incluidos todos y comprobado que funciona pasaremos al último paso:
Paso 4: Añadir un único dominio en la lista de exclusión de referencia de nuestra propiedad de Google Analytics
Y finalmente llegamos al final de este tutorial con la inclusión en la lista de exclusión de referencias de analytics el dominio personalizado que hemos configurado en Tealium:
Y con esto todo nuestro trabajo estaría terminado.
Conclusiones
Gracias a esta solución tan fácil y rápida conseguimos lo siguiente:
Las transacciones no se asignan a las pasarelas de pago de los bancos las cuales varían por entidad, país…
Nuestra lista de exclusión de referencias será lo más manejable posible y no estará llena de dominios de pasarelas de pago.
La atribución de las transacciones no se hará a las pasarelas PSD2 si no que mantendrán una correcta atribución.
Nuestra página estará preparada para incluir más pasarelas de pago cuando sea necesario sin necesidad de modificar varias propiedades ni incluirlas una a una ahorrandonos así muchísimo tiempo.
Y por último recordad que cada cierto tiempo habrá que comprobar en Analytics si han aparecido nuevos dominios de pasarelas de pago que tengamos que incluir en nuestra expresión regular de la extensión de Tealium.
¿Qué te ha parecido esta solución? Si tienes alguna duda escríbenos a través de los comentarios de este post.
En posts anteriores tienes toda la información sobre Google Data Studio: ventajas, funciones y conexiones con otras herramientas. Como no queremos ser repetitivos (pero sí proactivos), introduciremos una herramienta que aportará soluciones a la hora de crear cuadros de mando con datos sobre analítica social.
Hablamos de Supermetrics, cuya misión es ayudar a obtener mejores informes, a monitorear y analizar los datos conectando las plataformas de marketing con cualquier programa donde quieran usar esa extracción. Algunas de las plataformas con las que se conecta son:
Facebook
Twitter
LinkedIn
Instagram
Youtube
Snapchat
Pinterest
Google
HubSpot
Optimizely
Adobe Analytics
AdRoll
Yandex
Database
Searchmetrics
Ventajas y características de Supermetrics
Mejor integración de datos
Une datos desde todas las plataformas digitales en Data Studio.
Conecta con plataformas de pago, Pay-Per-Click, SEO, sociales, de análisis y de e-mail marketing.
Si no encuentras la integración que necesitas, contactas al equipo de Supermetrics y la construyen para ti.
Elaboración de informes inter-plataformas
Compara campañas de Google Ads, Facebook, Instagram, Twitter, LinkedIn y Bing en un solo gráfico.
Olvídate de copiar/pegar o importar archivos CSV.
Creación de informes automatizados y recopilación de datos.
Plantillas listas para usar
Crea tus informes en segundos con plantillas ya preparadas, creadas por profesionales.
Muy fácil de personalizar y añadir los logos de tus marcas.
Cómo conectar Google Data Studio con Supermetrics paso a paso
Lo primero es que crear un nuevo reporte, llamémosle “Test1”, en el cual decidimos crear una nueva fuente de datos:
En vez de elegir Google Analytics como fuente de datos, seleccionamos uno de los conectores que nos ofrece Supermetrics. En este ejemplo, conectaremos con Facebook Insights:
Necesitarás tener activa tu licencia o tu período de prueba, y responder a la información que te pide. Lo más importante es que indiques la cuenta asociada con la que vas a trabajar, y de forma opcional podrás agregar información sobre tu zona horaria y localización. Al finalizar, haz clic en “conectar”.
¡Listo! Ya puedes empezar a agregar gráficos y jugar con la información que quieras mostrar. Recuerda que los límites son pocos
Te dejamos un ejemplo de cómo quedaría un cuadro de mando después de la conexión con Supermetrics.
Déjanos tus dudas u opiniones sobre tu experiencia con esta útil y sencilla herramienta. ¡Nos encantaría leerte!
En un artículo
anterior explicamos que nos ofrecen las nuevas
propiedades App+Web de Google Analytics, hoy veremos cómo configurar una de estas propiedades para empezar a recibir
datos de una web.
Aunque su nombre
pueda sugerir otra cosa, no es necesario
tener una web y una app para utilizarlas, sino que podremos configurarla
con un solo flujo de datos, por ejemplo de web, como haremos a continuación.
Paso 1: Crear
la propiedad
En primer lugar, en Google Analytics, nos dirigiremos al menú de Administración y al crear una nueva propiedad nos dará la opción de que sea App+Web.
A continuación le damos un nombre, elegimos un sector, y ajustamos la zona horaria y la moneda. Que estos ajustes hayan pasado al flujo inicial de configuración ayudará a evitar el error tan común de tener las propiedades configuradas con los valores por defecto que corresponden a EE.UU.
Paso 2: Configurar un flujo de datos
Después tenemos que elegir una plataforma para configurar un flujo de datos. Cada app o cada web que vaya a mandar datos a esta propiedad es un flujo de datos y, aunque los mandemos todos juntos, luego podremos aislarlos y comparar su funcionamiento mediante filtros. Cara propiedad App+Web soporta hasta 50 flujos de datos simultáneos.
En nuestro caso elegimos “Web” y nos pedirá la URL del sitio y el nombre que le queramos dar.
Además, con un
solo clic podemos activar la medición
mejorada, o bien configurar qué opciones activamos y cuáles no si pinchamos
en la rueda dentada.
En el caso de que
optemos por crear un flujo de datos de app, nos pedirá el nombre de paquete de
la app y pasaremos al proceso de instalación de Firebase que requiere realizar
cambios en el código fuente de la app y escapa al objetivo de este artículo.
Paso 3:
Configurar la medición mejorada
Aquí encontramos
los siguientes elementos:
Páginas vistas
Un solo trigger
nos medirá tanto las cargas de página reales como los cambios de historial
provocados desde javascript en una SPA, de modo que si la SPA está bien hecha y
siempre cambia el historial, nos olvidaremos de mandar páginas virtuales y de
duplicar triggers. Si queremos podemos personalizarlo desactivando esto último.
Desplazamientos
Lanza un evento
al hacer scroll hasta el final de la página. Si queremos más detalle y medir
valores intermedios usaremos un trigger de scroll en una etiqueta creada
manualmente.
Clics de salida
Lanza un evento
cuando se pulsa en un enlace cuyo dominio no coincida con el de la propia web.
Búsquedas en el sitio
Manda un evento
de búsqueda y se registran los parámetros de búsqueda siempre que vayan en el
querystring de la URL. Se puede personalizar el nombre de los parámetros.
Interacción con vídeos
Eventos de play,
progreso y fin de vídeos insertados desde YouTube. Lo mismo que ya existía en
Universal Analytics.
Descargas de archivos
Evento cuando se
pincha un enlace con una extensión “común” de archivo. Lamentablemente no nos
permite configurar con qué extensiones queremos que se lance, por lo que si
tenemos archivos con extensiones menos comunes, tendremos que configurar una
etiqueta a mano.
Paso 4: Últimos
ajustes
Con esto ya tenemos una propiedad lista para recibir datos, pero aún debemos configurar tres cosas más:
Google Signals
Si no tenemos un CRM que nos asigne un ID de usuario a las visitas que hagan login, podemos activar Google Signals y dejar que supla las funciones de UserID. Esto nos proporcionará la capacidad de hacer seguimiento del usuario entre diferentes dispositivos, hacer remarketing y disponer de los informes demográficos. De momento está en beta (como toda la propiedad App+Web) y si se activa hay que revisar la política de privacidad para asegurarnos de cumplir el GDPR.
Retención de datos
Por defecto está ajustada a 2 meses, pero podemos cambiarla a 14. Lo justo para poder hacer un análisis mensual con comparación con el año anterior. No hay más opciones. Esto no significa que pasado ese plazo nos quedemos sin datos, sino que se eliminan los datos vinculados a UserID, cookie u otros identificadores. Pero los datos agregados de los informes permanecen intactos en la plataforma.
UserID y vinculación con otros productos
Por último debemos decidir cómo identificamos al
usuario, si solo por dispositivo (cookie en la web o ID de publicidad en
las Apps) o bien por UserID y dispositivo, en cuyo caso usará el UserID cuando
esté disponible, y de no estarlo recurrirá al ID del dispositivo, pero siempre
asignará un ID a cada usuario. Esto difiere del funcionamiento de Universal
Analitycs, en el que cuando un usuario no tiene UserID no se le asiga nada y no
se le incluye en la vista específica de UserID.
Con esto la
configuración de base queda completada y solo quedaría hacer los ajustes
específicos de nuestro modelo de datos, creando las propiedades de usuario que
hayamos definido (CONFIGURAR > Propiedades de usuario), las audiencias que
nos interesen (CONFIGURAR > Audiencias) y mapeando los parámetros de eventos
principales (EVENTOS > Todos los eventos).
En este último punto hay que destacar que con las propiedades App+Web Google ha ampliado el límite de 10 parámetros de texto y cuarenta numéricos que había en Firebase, hasta 50 de cada tipo. Que tampoco son muchos, pero al menos nos da más margen.
Paso 5: Configurar Google Tag Manager
Una vez que
tenemos nuestra propiedad configurada es el momento de hacer lo propio en
Google Tag Manager para completar la instalación.
Antes de nada, en Google Analytics iremos a Administrar > Propiedad > Flujos de datos > Web y al pulsar sobre el que acabamos de crear podremos ver su identificador.
Tomaremos nota de
el para usarlo en GTM.
A destacar, el
nuevo formato de ID, que pasa de usar una numeración consecutiva del tipo
UA-123456789-N a otra alfanumérica aleatoria del tipo G-XXXXXXXXXX. Esto
posiblemente ayudará a reducir el
referral spam que se dirigía indiscriminadamente a todos los números de ID.
Crear el
contenedor de GTM y las etiquetas de App+Web
El contenedor de
GTM no es especial para App+Web, de modo que creamos uno para web como lo hacemos siempre y lo instalamos con
la parte script en el head y la parte noscript en el body.
La novedad la encontramos al crear las etiquetas, que encontraremos dos específicas de App+Web que también están en beta.
La etiqueta de
configuración se debe activar en todas
las páginas y lo antes posible y es la responsable de:
Definir las
cookies.
Enviar los
eventos automáticos y de medición mejorada.
Determinar los
ajustes comunes de eventos posteriores (equivale a la variable de
configuración).
En ella
indicaremos el ID de la propiedad a la que queremos mandar los datos, las
propiedades de usuario (hasta 25) que se puedan mapear desde el principio y los
nombres de campo que necesitemos definir. Por el momento no hay documentación
sobre cuáles son estos nombres de campo, que en Universal Analytics incluían,
por ejemplo, el nombre de página, la anonimización de IP o las customTask.
La etiqueta de evento puede heredar los ajustes de la etiqueta de configuración que le indiquemos y se utiliza para mandar el resto de eventos.
Podemos elegir
una etiqueta de configuración, o bien asignar un ID a mano.
Necesitamos
indicar un nombre de evento, que puede ponerse directamente, si creamos una
etiqueta para un evento concreto, o tomarlo de una variable, como en la imagen,
si vamos a usar un trigger genérico para varios eventos.
Además podemos
mapear los parámetros del evento y, si se generan nuevos valores para
propiedades de usuario, las podremos añadir.
A partir de aquí
la configuración de GTM no se diferencia demasiado del uso que le dábamos hasta
ahora. Dependiendo del caso podremos crear etiquetas de eventos específicos que
se activen con triggers de clics, de scroll, etc, o bien usar el dataLayer (mucho
más robusto y estable) y que cuando se reciba un push con un evento nos active
nuestra etiqueta y recoja los datos desde el dataLayer, para lo cual tendremos
que crear variables para cada dato y mapearlas en los parámetros de evento y
propiedades de usuario.
¿Qué te ha
parecido este paso a paso? Si tienes algún problema en alguno de los pasos
comenta y te ayudamos a solventarlo
Gtag es una etiqueta de seguimiento que nos permite unificar los productos de Google y que está basada en eventos predefinidos.
Lleva activo desde 2017, pero es ahora con el lanzamiento de las propiedades de App + Web cuando realmente parece que se empieza a poner en marcha y resulta realmente útil para poder estandarizar y aunar la medición de nuestras apps y webs. (Aunque también puedes implementarlo sólo para web o sólo para app).
Pero vamos, que al final nos sirve a todos para poder estandarizar la medición de la analítica. Ahora, nos empezamos a plantear cómo comenzar a migrar toda la analítica de nuestra web hacia estas nuevas propiedades.
Sin embargo, hay que tener en cuenta que a las propiedades de App + Web están en beta y todavía le faltan muchas características como comercio mejorado, búsquedas, agrupaciones de contenido…
Por ello, y teniendo en cuenta el nivel de desarrollo del proyecto por parte de Google, de momento, la forma más correcta de hacerlo es manteniendo la implementación actual y hacer un doble etiquetado de la web. Por un lado, como lo estemos haciendo hasta ahora y por otra parte con Gtag (modelo App + Web, no Universal).
En un futuro, se podrá hacer la migración completa.
Funcionalidades de App + Web
Medición mejorada: Mide automáticamente algunos eventos comunes, como los vídeos, las descargas de documentos o el scroll. Solo con activarlo en la consola.
Embudos abiertos o cerrados: Permite construir embudos basados en el valor de los parámetros (Firebase Console sólo basado en el nombre de los eventos).
Explorador de usuarios
Análisis de rutas
Creación de audiencias por hit, sesión o usuario. Las audiencias incluyen criterios de tiempo y los usuarios pueden salir cuando dejan de cumplirlo.
El fragmento global debe estar al principio de cada página de tu web. Si el fragmento global no se añade al principio de una página, donde se ejecutan los comandos gtag(), no se podrán enviar datos usando comandos gtag().
Cada producto compatible genera etiquetas que pueden copiarse y pegarse en las páginas web.
También puedes crear un fragmento personalizado.
Para implementarlo, es tan simple como meter el siguiente fragmento en el <head> de todas las páginas de la web, vamos, como con Universal Analytics. Simplemente, sustituye el GA-TRACKING_ID por el ID correspondientede tu propiedad.
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=GA-TRACKING_ID"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'GA-TRACKING_ID');
</script>
Este fragmento carga la biblioteca gtag.js, asigna el ID de propiedad predeterminado de Google Analytics GA_MEASUREMENT_ID y envía un hit de página vista a Google Analytics.
Además, podemos recoger la información de todos los eventos para otras herramientas de Google como: Adwords (perdón, Google Ads), Double Click o Universal Analytics. Basta con añadir el tracking ID de cada herramienta.
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'UA-XXXXXXX-Y');
gtag('config', 'AW-XXXXXXXX'); // Conversion ID, en el caso de evento de compra.
Configurar productos y enviar datos
Puedes invocar comandos gtag() desde cualquier lugar de una página, después del fragmento global. Puedes utilizar tres comandos: config y set se usan para definir las propiedades generales, mientras que event se usa para enviar datos.
Inicializar productos con config
Usa el comando config para inicializar y configurar los ajustes de una cuenta de producto concreta. El comando config tiene el siguiente formato:
<target_ID> es el ID de la cuenta de producto a la que quieres enviar datos, y <additional_config_info> es un objeto opcional que se utiliza para especificar otras opciones de configuración.
El comando config sirve para eventos que queremos lanzar en el momento en el que se ve una página concreta.
Por ejemplo, cuando llegamos a una /thankyou page, utilizaremos el comando config para lanzar el evento de pageview.
El comando config te permite especificar qué productos y cuentas debe gestionar gtag.js, así como la configuración asociada. En función del producto que se haya especificado en target_ID, el comando config iniciará un comportamiento específico para ese producto.
Por ejemplo, en algunos casos, el comando config indica a gtag.js que inicie un hit de páginas vistas.
El ejemplo más básico de este comando consiste solo en el comando config y un target_id:
gtag('config', 'GA-TRACKING_ID');
Para ajustar y ampliar un comando config, especifica parámetros en el objeto opcional <additional_config_info>.
Por ejemplo, si añades el siguiente parámetro, impedirás que se envíen automáticamente los hits de páginas vistas de Google Analytics:
Hemos de tener en cuenta que ahora la forma de funcionar es diferente a como veníamos haciéndolo. Gtag funciona como GA4F (Google Analytics for Firebase) y todo va a través de eventos que tendremos que definir nosotrxs mismxs.
Dentro de los eventos que enviemos a Gtag, es bueno tener en cuenta:
No se debe usar un nombre de parámetro para dos significados distintos.
Los eventos no deben ser ni demasiado genéricos (clic), ni demasiado específicos (clic de descarga de la app v5).
Un punto intermedio sería “clic descarga” y en dos parámetros especificar que la descarga es la app y es la v5.
Enviar datos con event
El comando event te permite enviar datos de eventos, cuando estos son interactivos, es decir, acciones que debe realizar el usuario, como un clic o por ejemplo, puedes usar el comando event para enviar un evento de login con el valor «Google» asignado al method.
gtag('event', 'login', {
'method': 'Google'
});
Hay un conjunto de eventos recomendados y parámetros recomendados que son útiles en contextos específicos. También puedes enviar eventos personalizados que no están incluidos en la lista de eventos recomendados.
Enviar datos para cada evento con set
El comando set te permite establecer los parámetros que se asociarán a eventos concretos cada vez que se activen en la página. Es decir, son los datos del dataLayer, la información que enviaremos con cada evento para que sea reconocible y nos permita analizar los datos de las acciones de los usuarios.
Por ejemplo, si se usa la misma moneda en todas las transacciones de tu sitio web, incluye el comando set para especificar el valor del campo currency.
gtag('set', {'currency': 'EUR'});
Puedes establecer varios atributos con un único comando set:
Es la opción más sencilla ya que nos permite ser nosotrxs mismos los que establecemos la configuración sin tener que depender demasiado de los equipos de IT.
Etiqueta de configuración
Define las cookies.
Envía eventos automáticos y de medición mejorada.
Determina ajustes comunes de eventos posteriores (equivale a la variable de configuración).
Se debe activar en TODAS las páginas y lo antes posible.
Etiqueta de evento
Para el resto de eventos.
Si usamos GTM, la implementación en web es mucho más sencilla:
Advertencia sobre App + web
Como comentaba arriba, App + Web todavía está en beta, por lo que hay que tener en cuenta que hay ciertas cosas que no acaban de funcionar correctamente.
Algo bastante relevante es que no hay forma de enviar la matriz de elementos [item_list] (o cualquier otro objeto multidimensional) como parámetro de evento a Google Analytics cuando se usa GTM.
Same-Site Cookie es un atributo definido en 2016 en el documento RFC6265bis (actualizado en 2019). Éste permite a los servidores afirmar que una cookie no debe ser enviada en peticiones cross site. Gracias a este atributo, los navegadores con las nuevas mejoras reducirán el riesgo de fuga de información y, en consecuencia, mejorará la protección de ataques cross-site mediante peticiones falsas.
Navegadores como Chrome, Firefox, Edge y otros están modificando sus funcionalidades para estar en línea con la nueva propuesta de la IETF, la cual obliga a los desarrolladores a proveer estas mejoras de seguridad a los usuarios. Para más detalle podéis acudir al documento Incrementally Better Cookies.
En la web coockiestatus.com podéis encontrar más información respectiva a la gestión de cookies para los navegadores más utilizados del mercado.
En este otro enlace, podréis verificar las cookies generadas en vuestro site. Además, este site reporta las cookies creadas en gestores de tags como GTM y Tealium.
En el caso de Safari, webkit definió el protocolo ITP, el cual es todavía más restrictivo en relación a la gestión de cookies.
Este requerimiento de la IETF será adoptado por todos los navegadores web. La mejora implica mayor seguridad durante la sesión de los usuarios en la web.
Aquí os dejamos las implicaciones que tiene asignar un valor u otro al atributo SameSite:
SameSite = Strict
Si se establece esta configuración, sólo se puede acceder a la cookie cuando se visita el domino original dónde ésta ha sido establecida. Es decir, “Strict” bloquea por completo una cookie que se envía a doctormetrics.com desde metriplica.com donde ésta ha sido generada. Esto significa que en doctormetrics.com no tendríamos esta cookie perdiendo la información asociada a ésta. También al hacer click a un enlace top-level en un dominio third-party el cual redirige a tu site, el navegador bloqueará esta cookie.
Establecer una política de cookies con SameSite=Strict, puede ser una buena opción para aplicaciones que requieran un nivel de seguridad alto, por ejemplo, en el sector bancario.
SameSite = None
Estableciendo el atributo con valor None, las cookies funcionarán como lo han hecho hasta el día de hoy. Esto implica que se podrán utilizar en cross-site, pero con el añadido de que se debe añadir el parámetro Secure. Si la cookie no contiene el parámetro Secure, será rechazada.
El atributo ‘Secure’, sirve para informar al navegador que la petición es HTTPS. Este atributo hace tiempo que existe, pero entra como requisito vigente debido a las modificaciones que están haciendo los navegadores para cumplir con las recomendaciones de la IETF.
A diferencia de las cookies definidas como None, las cookies ‘Lax’ solo se envían en peticiones que ocurren dentro del mismo site. A diferencia con la política Strict, Lax permite acceder a peticiones top-level mediante HTTP como GET.
Eso sí, para las solicitudes POST en cross-domain o al cargar un site cross-domain, la cookie no se enviará. Esto implica que se debe enviar cuando se navegue al site a través de un enlace top-level.
Si el atributo SameSite no tiene asignado valor, una vez se actualicen los navegadores con las nuevas mejoras en estándares de seguridad, por defecto tratarán esa cookie como “Lax”. Esto solo ocurre con enlaces top-level, en otros casos el navegador no asignará ningún valor y la cookie será rechazada.
Para todas las peticiones que no sean top-level, se deberá forzar la inclusión del parámetro Lax. En la tabla os mostramos las que deberán ser forzadas por los developers, las que contienen Lax es porque las asigna el navegador por defecto, aún así recomendamos definir el atributo:
Afectaciones de las nuevas mejoras del atributo SameSite
Una vez se actualicen los navegadores, se verán afectados estos aspectos en relación a la gestión de las cookies. Esto también afecta a cross-site.
Iframes
Si en sites tenéis iframes que provean servicios a sites de domino third-party debéis asegurar de que la cookie sea considerada como third-party (SameSite= None; Secure).
Si este <iframe> lo invocan en su dominio o subdominio, debe definirse como Lax.
Entorno webview
Para el entorno de navegación WebView, en dispositivos Android, se deberá actualizar la cookie vía la CookieManager API.
Headers o JavaScript
Para las cookies generadas mediante headers o JavaScript, deben considerarse como “SameSite=None; Secure” si su uso es para cross-site.
Peticiones HTTP
Al enviar una petición GET, la cookie quedará marcada automáticamente como “SameSite=Lax”, ejemplo al hacer click a un enlace externo.
Sin embargo para peticiones POST que necesitan de validación (formularios web), deben asegurar que la petición de retorno defina la cookie como “SameSite=None; Secure.”
Servicios third party: píxels Google Analytics, Tealium, CRM, servicios de pago, etc.
Para todas las cookies relacionadas con píxeles de terceros o servicios de Analítica web cookie de Google Analytics, Adobe u otros, se deberá encargar el proveedor de añadir las mejoras pertinentes en sus snippets actualizando así sus servicios.
Desde Metriplica recomendamos estar pendientes de las posibles actualizaciones de dependencias o snippets de terceros para adaptarse al nuevo comportamiento.
Bugs o incompatibilidades
Hay aplicaciones server-side que no soportan el atributo “SameSite”, os proporcionamos un enlace con losclientes no compatibles.
En Safari 12, si se establece una cookie con la política de “SameSite=None”, lo interpreta como “Strict”.
Es decir, si se define para Chrome como “None”, Safari 12 la interpreta como “Strict”, esto hace que la cookie no funcione en cross-site si el usuario utiliza esa versión de Safari.
Por ello, desde el lado del servidor se deben de tomar las medidas necesarias para gestionar este caso en concreto. Para más información, podéis acudir a bugs.webkit.org.
Conclusión
Las nuevas modificaciones que van a adoptar los navegadores afectarán a la experiencia de navegación del usuario y al posible seguimiento de datos o funcionalidades de la web que se alimenten de la información almacenada en las cookies si no se toman las medidas pertinentes.
En el caso de píxeles de servicios third-party o cookies de servicios de Analítica, cada proveedor se encargará de gestionar este asunto.
Cada cliente debería revisar el resto de cookies que utilizan en su site para asegurar que cumplan con el estándar funcional de la IEF.
No dudes en contactar con nosotros, si quieres más información al respecto o tienes cualquier duda.
En ocasiones nos interesa predecir algún evento en base a la navegación de los usuarios de un site, o describir la relación entre las variables de navegación y ese evento. Como alternativa a otros modelos (regresión, redes neuronales…) haremos una introducción al análisis de supervivencia, técnica muy extendida en Ciencias de la Salud.
Orígenes y aplicaciones
Encontramos los antecedentes del análisis de supervivencia en las tablas de mortalidad publicadas por el astrónomo inglés Edmon Halley en el s.XVII.
El análisis de supervivencia tiene sus inicios en el campo de la ingeniería, con la finalidad de analizar la fiabilidad de los componentes de un dispositivo. La industria militar desarrolló estas técnicas durante la Segunda Guerra Mundial.
En los años 70 se extendió su aplicación en Ciencias de la Salud, en estudios clínicos y epidemiológicos que requerían seguimiento de pacientes.
Actualmente es una técnica bastante empleada en el análisis de abandono de usuarios (churn).
Descripción
El análisis de supervivencia lo conforman una serie de técnicas en las que se realiza el seguimiento de cada sujeto durante un periodo, registrando el tiempo transcurrido desde un evento inicial hasta el evento terminal (o hasta el final del seguimiento si no llega a ocurrir dicho evento).
El evento terminal se suele definir como estado ‘muerte’, de ahí lo de supervivencia, ya que en sus orígenes este evento se asociaba al fallo de un elemento o a la muerte de un paciente. Actualmente puede hacer referencia al alta del paciente, curación de una enfermedad…
El objetivo es describir, por un lado, la evolución de la tasa de riesgo de dicho evento a lo largo del seguimiento, y por otro, las probabilidades de ocurrencia.
Uso en analítica digital
Trasladado al mundo de la analítica, el evento terminal puede estar definido por una compra online, un registro de usuario… Dicho esto, cuando hablemos de supervivientes, nos referiremos a usuarios que aún no han llevado a cabo el evento de interés.
A través del identificador de usuario, haremos un seguimiento de su actividad a lo largo de todas sus sesiones en el site.
Incluso podemos ir más allá y conectar la actividad online con la offline, si disponemos de un identificador (ej: número de tarjeta de fidelización) que nos permita vincular la navegación logueada en el site con una conversión en tienda física.
Practicando en R
En este post nos centraremos en una introducción a la preparación de los datos, la estimación de la curva de supervivencia y el modelo de regresión de riesgos proporcionales de Cox, con la finalidad de describir la relación entre variables de navegación y compra online. Para ello haremos uso de la librería de R survival.
Preparación de los datos.
Dataset.
Nuestro dataset debe contener para cada usuario mínimo dos campos:
time: indica el tiempo transcurrido desde el inicio del seguimiento (ej: días desde primera sesión registrada).
label: valor binario que nos indica si el usuario ha llevado a cabo el evento terminal o no (ej: compra online=1, no compra online=0).
Con esta función, pasando como primer argumento el tiempo y como segundo el evento:
Nos devuelve un objeto tipo survival:
Curva de supervivencia.
Esta curva es la representación gráfica de la proporción de sujetos supervivientes en distintos intervalos de tiempo. El método más generalizado para su cálculo es el de Kaplan-Meier.
Pasando como argumento una fórmula basada en el objeto survival previamente creado, nos devuelve un objeto con la curva de supervivencia.
Interpretación.
De aquí podemos interpretar que en el cuarto día desde la primera sesión registrada la probabilidad de supervivencia (no haber comprado online) es 0.986.
Representación gráfica.
Modelo de regresión de riesgos proporcionales de Cox.
Este modelo nos permite evaluar el efecto de un conjunto de variables sobre la tasa de incidencia del evento de interés (tasa de riesgo o hazard rate).
Además podemos utilizar el modelo para explicar y predecir la evolución de la tasa de riesgo a partir de dichas variables.
Para este caso práctico asumimos que las variables continuas son lineales y comprobamos el supuesto de proporcionalidad.
Preparación de los datos.
Nuestro dataset original está compuesto por variables numéricas y categóricas.
Debemos transformar las variables con k categorías en k-1 variables dummy (1/0) respecto a una categoría de referencia.
Ej: la variable ‘device’ (dispositivo en primera sesión) con 3 categorías (mobile, tablet, desktop) pasaría a introducirse en el modelo como dos variables:
isMobile (1 si es mobile, 0 resto)
isDesktop (1 si es desktop, 0 resto)
donde la categoría tablet queda contemplada cuando isMobile=0 y isDesktop=0.
Esta función ajusta un modelo de regresión de riesgos proporcionales de Cox, pasándole como primer argumento una fórmula basada en un objeto survival y las variables predictoras (ej: dispositivo primera sesión, nuevo usuario, aterriza en la home en primera sesión…).
Validación del supuesto de riesgos proporcionales.
Para poder aplicar este modelo se ha de cumplir la condición de proporcionalidad, es decir, los valores que toma la tasa de riesgo para individuos con un patrón determinado de valores A, deben ser proporcionales a los de individuos con otro patrón B.
Aplicamos la función cox.zph al objeto devuelto por la función anterior.
El supuesto de riesgos proporcionales se cumple para las covariables isNewUser, diffCateg y adds (p-valor>0.05, aceptamos hipótesis nula de proporcionalidad).
Esto significa que el resto de variables habrá que introducirlas en el modelo previa estratificación (función strata).
Comprobamos supuesto de proporcionalidad en nuevo modelo.
Tanto el test global como por covariables es no significativo (p-valor>0.05), luego aceptamos hipótesis de proporcionalidad.
Interpretación del modelo.
Una vez comprobada la condición de proporcionalidad pasaremos a interpretar el modelo, aplicando la función summary al objeto que almacena el modelo.
Lo primero que podemos observar es que las variables con riesgos no proporcionales que se introdujeron estratificadas en el modelo no devuelven un coeficiente con el cual medir su efecto sobre la compra online.
Analizando el p-valor global del modelo (en verde al pie), vemos que es significativo (p-valor<<<0.05, rechazando hipótesis nula de no relación entre variables del modelo y tasa de riesgo).
Analizando el p-valor de las covariables, para este dataset las variables menos asociadas con la compra online son isNewUser (el usuario tuvo su primera visita al site en el periodo observado) y diffCateg (número total de categorías diferentes consultadas) con un p-valor>0.05 (en rojo). Por otra parte, y como era de esperar, encontramos adds (número de veces que se ha añadido a carrito) como variable más asociada a compra (p-valor<<<0.05).
Pasemos a interpretar los coeficientes devueltos por el modelo, en el caso de adds:
El coeficiente de regresión estimado es 0.12145, que al ser positivo indica un aumento en la tasa de riesgo (compra online) cuando se incrementa el valor de la variable (cuantas más veces se añade a carrito, mayor probabilidad de compra).
Tomamos exponencial del coeficiente, que valora el ‘riesgo’ de compra online de los usuarios según el número de veces que han añadido a carrito: [ exp(0.12145)=1.1291 ]
¿Cómo interpretamos este valor? 1.1291 es el factor por el que se multiplica la tasa de riesgo (compra online) cuando la variable adds se incrementa en 1 unidad y el resto de variables se mantiene constante.
Del intervalo de confianza del exponencial del coeficiente también podemos deducir que adds es significativa, ya que no contiene el valor 1 (hipótesis nula de no relación entre la variable y la tasa de riesgo) [ IC 95%: 1.1013 a 1.158 ]
Conclusiones del modelo.
La variable adds es significativa (p<<<0.05). El ‘riesgo’ de compra se multiplica por 1.13 (IC 95%: 1.10 a 1.16) cada vez que el usuario añade a carrito.
Conclusiones
En este post hemos planteado el uso del análisis de supervivencia como técnica para describir la asociación entre las variables de navegación en el site y la compra online. Para ello hemos revisado la curva de supervivencia de Kaplan-Meier y el modelo de regresión de riesgos proporcionales de Cox.
Con el Intelligent Tracking Prevention o ITP, Safari restringe el uso de las cookies para el seguimiento del comportamiento de los usuarios en cualquier página web.
En su versión 2.0, el ITP empezó a bloquear únicamente las cookies cargadas por servidores de terceros en todos los sitios web. Por tanto, desde que apareció esta versión, las cookies “Third-Party” desaparecen tan pronto como se crean. Esto afecta a la personalización, segmentación y retargeting de las audiencias. Las campañas de remarketing se vuelven menos personales que antes.
Además, las versiones posteriores del ITP afectan a todas las cookies JavaScript. La cookie “First-Party” de Google Analytics es una de ellas.
Primero, con el ITP 2.1, las cookies caducaban al cabo de 7 días. Si el usuario no volvía a visitar tu página web antes de que se acabaran estos 7 días, se convertía en usuario nuevo en su siguiente visita. La cantidad de usuarios recurrentes disminuía a la vez que el número de usuarios nuevos aumentaba.
Finalmente, el ITP 2.2 y, actualmente, el ITP 2.3 de Safari hacen desaparecer cualquier cookie JavaScript en 24 horas. A día de hoy, tus datos en Google Analytics y tus Tests A/B se ven aún más afectados por esta situación.
Tipo de usuarios, atribución y conversiones son los tres elementos más importantes que el ITP altera en Google Analytics.
Tal y como hemos explicado anteriormente, la cantidad de usuarios nuevos aumenta en Safari pero no es el único problema que ITP provoca con respecto a Google Analytics.
Si tu modelo de atribución tiene en cuenta la primera campaña que ha llevado al usuario a tu página web y tu usuario no convierte en las 24 horas de vida de la cookie de Analytics, sino en su segunda sesión dos días después de la primera, no podrás atribuir la conversión de primera interacción a la verdadera primera campaña que atrajo al usuario.
Además, el seguimiento de las conversiones tiene una ventana al pasado de 30 días, pero como los usuarios vuelven a ser nuevos un día después de su primera sesión si no ha habido otra visita en estas 24 horas, las conversiones de los usuarios recurrentes bajan de igual manera que las de los usuarios nuevos aumentan.
Por tanto, no podrás tomar las decisiones más adecuadas ya que no obtendrás los datos correctos con respecto a tus campañas y a tus usuarios en Safari.
Esta situación es más preocupante en el caso de los usuarios de móvil, ya que son más numerosos los que usan Safari en móvil. Asimismo, los usuarios que visitan una web a través de un móvil muchas veces son mayoritarios, y el iPhone es uno de los móviles más utilizados.
Puedes analizar cómo el ITP afecta tus datos de usuarios en Google Analytics con nuestro nuevo dashboard.
Dashboard de Metriplica que muestra el impacto del ITP en Google Analytics
ITP de Safari y A/B Testing
Las herramientas de experimentos usan cookies para incluir al usuario en un experimento y entender si ya ha visto el experimento o no.
Cuando un usuario llega a una página que tiene un experimento A/B en marcha, la cookie determinará si este usuario se tiene que incluir en el experimento. Acto seguido, la misma cookie le asignará una experiencia u otra: grupo de control, variación A o variación B.
Cuando el usuario vuelva a la página web, tendrá la misma experiencia. Si vio la variación A, en su segunda visita verá la misma variación gracias a la cookie.
De igual manera, si el usuario convierte, la conversión se atribuirá a la experiencia correcta.
El ITP rompe esta dinámica ya que la cookie sólo funcionará 24 horas.
En este caso, un usuario recurrente será tratado como nuevo y la herramienta le mostrará una experiencia nueva o la misma.
Si le toca la misma experiencia, será considerado como 2 usuarios en vez de 1, lo cual puede bajar la tasa de conversión de esta variación del experimento.
En cambio, si se le muestra una variación nueva, tendrá una visita que se incluirá en una variación y la otra en otra variación. Si el usuario no convierte en ninguna de las dos variaciones, puede bajar la tasa de conversión de las dos experiencias. También puede subir la tasa de conversión de una de las variaciones y bajar la de la otra. Además, le proporcionamos dos experiencias diferentes en la misma web y es incorrecto en términos de experiencia de usuario.
Solución
Mediante el uso de un condicional a la hora de crear la cookie de _ga y un microservicio en la llamada de pageview, se guardará el clientID en una cookie server side, las cuales no son borradas por el ITP, lo que permitirá darle un tiempo de vida de 2 años a dicha cookie.
El microservicio es un código que se pone en el servidor con el fin de crear nuestra cookie de Google Analytics con una caducidad de 2 años.
La solución se puede aplicar a través del código de seguimiento de Google Analytics dentro del código fuente de la página web o a través de GTM, además del microservicio que se tendrá que desarrollar del lado del servidor.
Te recordamos que puedes consultar el impacto que tiene el nuevo ITP en tus datos de Google Analytics a través de nuestro dashboard público.
Contacta con nuestro equipo si quiere saber más sobre el funcionamiento de la solución o implementarla.
BigQuery Omni de Google Cloud es una nueva solución multi-cloud de análisis de datos, impulsada por Anthos, la plataforma de Google que integra aplicaciones híbridas y multi-cloud.
Omni permite a los usuarios ejecutar BigQuery para analizar datos de las nubes de Amazon AWS y Microsoft Azure.
El coste de mover datos entre proveedores de la nube no es sostenible para muchas empresas, por ejemplo, AWS cobra $ 0.09 / GB, mientras que Azure cuesta $ 0.087 / GB por la transferencia de datos. Además del coste de transferencia de datos, existe una latencia involucrada en el movimiento de datos entre plataformas en la nube. Los clientes deberán esperar a que los datos se muevan a Google Cloud y luego cargarlos en BigQuery antes de realizar el análisis.
BigQuery Omni aborda ambos desafíos: el costo de transferencia de datos y la latencia. Esto es posible gracias a la separación de BigQuery entre el procesamiento y el almacenamiento. Básicamente, acerca la computación a los datos en lugar de mover los datos a la computación.
Ahora podrás consultar datos en Amazon y Azure sin salir de la interfaz de usuario de BigQuery y sin latencia.
Cómo solicitar el acceso a BigQuery Omni
Google Cloud dio a conocer esta nueva herramienta durante Next ’20 como parte de su estrategia de multi-cloud. Este servicio está disponible en versión alfa privada para Amazon Simple Storage Service (S3) de AWS, y próximamente será compatible con Microsoft Azure. Si estás interesado, debes rellenar este formulario para solicitar acceso al servicio. Por ultimo si quieres más información sobre el tema te recomendamos esta presentación de Google Cloud Next ‘20: Analytics in a multi-cloud world.
Hasta ahora, las soluciones de tag managers como GTM se basaban en inyectar una librería y procesar toda la información en el navegador, ejecutando las solicitudes de seguimiento directamente desde el lado del cliente (navegador) a servidores de terceros. Con la llegada del nuevo contenedor de GTM server-side se agrega una capa adicional de administración de etiquetas al proceso.
Esta nueva forma de procesar los datos trae una serie de ventajas y desventajas.
Ventajas
Evita el bloqueo de cookies
Los navegadores web como Safari y Mozilla han lanzado una serie de actualizaciones como Intelligent Tracking Prevention (ITP), que funcionan contra las tecnologías de seguimiento al bloquear la información que se envía a terceros desde las web visitadas, una situación similar se presenta con Adblockers. A través del etiquetado server-side se puede evitar estas limitaciones ya que los hits serán enviados desde el servidor donde se encuentra el contenedor de GTM.
ITP y AdBlockers no podrán detectar ni bloquear el comportamiento de seguimiento, lo que le permitirá contabilizar a más usuarios. Más datos significa que, en última instancia, la calidad de estos datos también aumentará.
Reduce los tiempos de carga
La mayoría de las veces, el código de terceros y el tiempo de ejecución de JavaScript son uno de los mayores cuellos de botella en términos de tiempo de carga de la página. Cuando se realiza el envío de etiquetas mediante un contenedor server-side, se inyectan menos etiquetas en las visitas, lo que se traduce en tiempos de carga más rápidos y una mejor experiencia de navegación en general.
Seguridad de datos
Actualmente, la gran mayoría de etiquetas de terceros se implementan utilizando librerías Javascript, estas librerías pueden acceder e interactuar con otra información que los clientes ingresan en su sitio. Con el etiquetado server-side, las etiquetas en el contenedor de su servidor solo tienen acceso a la información enviada al servidor y ya no tienen acceso a la información ingresada en su sitio, por lo tanto se tiene mayor control y seguridad de que información recopilan las etiquetas.
Desventajas
Costes asociados
Aun cuando el contenedor server-side en GTM es gratuito, el servidor donde se aloja no. Por el momento, Google solo tiene la opción de alojar el contenedor en Google Cloud Platform, utilizando el servicio de APP Engine.
Para utilizar un contenedor server-side en modo de pruebas, se puede alojar en una instancia estándar de APP Engine, que entra dentro del free tier de Google Cloud, pero al querer tener el contenedor en un entorno de producción, Google recomienda utilizar APP Engine flexible y una configuración de 3 servidores por lo que el costo rondaría los 100$ en promedio. Cuantas más peticiones/datos procese, mayor será el precio.
Más complejidad a nivel técnico
Al involucrar más elementos al entorno de medición, las capacidades técnicas que necesita tener el equipo de analítica aumentan, ahora se suma el poder entender, mantener y escalar los servicios en la nube que alojen el contenedor server-side y poder configurar los endpoints y procesos internos del mismo.
Incompatibilidades
Al cambiar la forma en que se procesan y envían los datos, muchas herramientas que se basan en cookies de terceros y remarketing no son compatibles por los momentos, esto obviamente mejora con el aumento en la adopción de etiquetado server-side.
El etiquetado server-side no es nuevo, ya Teallium lo viene ofreciendo desde hace algún tiempo, pero que Google lo esté impulsando hace que otros proveedores y anunciantes quieran subirse al carro. Esta nueva forma de medición traerá consigo especialización por parte de los equipos técnicos y cambios para los anunciantes que dependen principalmente de la tecnología de cookies.
Si queréis saber más sobre las novedades de GTM server-side, no dudéis en contactarnos.
Google Analytics 4 (GA4) es la nueva generación de Google Analytics, antes conocida como Google Analytics App+Web. El lanzamiento de GA4 comporta la llegada de nuevos informes y capacidades que dan más potencia a tu herramienta de analítica. Para empezar a familiarizarte con ella, te explicamos paso a paso cómo crear una propiedad GA4 y la implementación en GTM.
Es importante apuntar que esta implementación es básica y no contempla eventos avanzados.
Mejorar una propiedad de Universal Analytics
La primera opción que ofrece GA4, para aquellos usuarios que tengan una propiedad preexistente de Google Analytics Universal, es mejorarla a una propiedad de GA4. El término mejorarla no es del todo correcto, ya que lo que hace realmente es crear una nueva propiedad a la que enviar nuestro nuevo stream de datos.
Es importante entender, que esta mejora deja la propiedad actual de GA Universal intacta y añade la nueva de GA4.
1. Iniciando la migración
Para iniciar el proceso de migración/mejora, tenemos que entrar en la propiedad de Google Analytics Universal que queremos migrar.
Una vez dentro, accedemos al administrador (si hemos ido a la vista), y en la columna de “property” deberíamos ver la opción de mejorar a GA4.
2. Seleccionar crear una nueva propiedad o usar una preexistente
La primera pregunta del asistente, es si queremos crear una nueva propiedad o por el contrario, utilizar una existente.
Nueva propiedad de GA4
Como su nombre indica, creará una nueva propiedad de GA4 migrando toda la configuración posible de Universal Analytics a la nueva propiedad (no todos los parámetros de configuración de Universal existen en GA4). Un ejemplo de las configuraciones que copia serían:
Timezone
Currency
URL
Adicionalmente, se activarán los eventos de enhanced measurement.
Al final del proceso, podremos acceder a un asistente de configuración para revisar la misma.
Si tenemos marcado nuestro sitio con gtaj.js (hardcoded), podremos activar la opción de “Enable data collection using your existing tags”. Esta opción no replica las customizaciones que podamos haber hecho sobre el tag.
Conectar a una propiedad de GA4
Seremos nosotros los encargados de poner el código en el sitio.
Si seleccionamos esta opción, se presupone que tenemos una propiedad previa de GA4, la seleccionaremos del listado que nos aparece y ya tendremos las propiedades conectadas. En esencia no habremos hecho mucho, ya que hasta que no pongamos el código no se enviarán datos a la nueva propiedad de GA.
3. Activar la recolección de datos
En esencia, configurar el código gtag del sitio para que mande datos a la nueva propiedad. Hay varios escenarios que se pueden dar:
Tengo el analytics.js en el sitio. Tendremos que seguir las siguientes instrucciones para realizar el nuevo etiquetado.
Crear propiedad Google Analytics 4 de cero
Cuando accedemos a la administración de Google Analytics tenemos la opción de “crear propiedad” o “actualizar a GA4”
Si pulsamos sobre la opción “upgrade to GA4”, Google Analytics nos crea una propiedad GA4 directamente con las mismas especificaciones que la propiedad de Universal que tenemos seleccionada, sin eliminarla.
Google Analytics toma el nombre y el dominio para crear el data stream del que tenemos definido en la propiedad de Universal, junto con otras características.
El proceso es un poco más rápido, pero nos deja menos libertad en la configuración.
Si pulsamos sobre el botón de “crear propiedad”, por defecto ya nos da la posibilidad de crear una propiedad GA4 con el proceso completo.
Al entrar en la configuración de la nueva propiedad indicaremos el nombre, la zona horaria para los informes y la moneda.
Si queremos incluir una propiedad de Universal, esta opción ya no aparece por defecto, tenemos que pulsar sobre el enlace “show advanced options”, activar la selección y decidir si queremos ambas o sólo Universal Analytics.
Después de pulsar en “Next”, rellenamos algunos detalles de nuestro cliente.
A continuación, incluiremos los data streams de las webs o apps sobre las que queremos hacer la medición.
En la rueda de configuración de la derecha podremos activar los eventos de medición mejorada automáticos.
Al crear el data stream nos devuelve un identificador de medición, que es el que utilizaremos para configurar nuestra etiqueta en GTM.
Crear etiqueta en GTM.
La implementación de la etiqueta básica en GTM recoge las páginas vistas por el usuario y los eventos que en nuestro data stream se configuraron como automáticos (scrolls, enlaces externos, descargas, búsquedas en la web y actividad con los vídeos de Youtube).
Al crear una nueva propiedad es una buena práctica incluirla en una carpeta que identifique como parte de la implementación de GA4.
Seleccionamos una etiqueta del tipo “Google Analytics: GA4 configuración”.
Por último, guardaremos la etiqueta y publicaremos el workspace.
Ungit es la herramienta de control de versiones de código abierto que viene directamente integrada en DataLab, de Google Cloud Platform. En este post encontrarás una guía básica de cómo utilizar ungit y los conceptos clave sobre control de versiones.
Un sistema de control de versiones es un sistema que permite registrar cambios de uno o varios archivos a lo largo del tiempo. De modo que permite volver a un momento específico y “viajar en el tiempo” para recuperar o consultar ese punto concreto más adelante.
Resulta especialmente útil cuando varias personas trabajan en un mismo proyecto. Se pueden comparar distintas versiones de un mismo archivo, y por supuesto volver a una versión previa si se produce un error o se elimina el archivo.
Conceptos básicos
Ramas
Git utiliza un sistema de ramas que facilita el trabajo de varias personas de manera simultánea en un mismo proyecto. En este caso, encontramos una rama master que es la principal, sobre la que no es aconsejable trabajar directamente. Adicionalmente creamos otras ramas. Algunos prefieren crear una por persona otros por funcionalidades. Dentro de las buenas prácticas se aconseja crear ramas por funcionalidades y cerrarlas conforme se vayan completando. Elegir una opción u otra puede depender de la madurez del equipo principalmente.
La interfaz se visualiza así:
Cada rama puede tener dos estados distintos: local y remoto. Local es el punto en el que está trabajando el usuario en su máquina y remoto es aquel punto de la rama al cual tienen acceso el resto de usuarios. Es aconsejable fijarse bien en el punto al que está apuntando el local antes de empezar a trabajar, así evitaremos conflictos posteriores al ‘publicar’ los cambios. En ungit el local viene representado por el nombre de la rama en color blanco y el remoto en color azul.
El contenido que veamos en datalab depende directamente de la rama sobre la que nos encontremos en ungit, y en todo momento se corresponderá con el estado en local, aunque el remoto de nuestra rama esté apuntando a otro punto.
Cuando un usuario ‘guarda y comparte’ los cambios (luego veremos a qué nos referimos con guardar y compartir), local y remoto estarán en el mismo punto. Sin embargo, el usuario puede decidir ir a un backup anterior para seguir trabajando, y entonces el local estará apuntando a un punto más atrasado que el remoto. O también se puede ‘guardar’ y no ‘compartir’ los cambios, entonces el local estará en un punto más avanzado que el remoto.
Cuando se considera que el contenido de la rama es correcto y funciona bien entonces se deberían ‘compartir’ los cambios con el resto pasándolos a la rama master (explicamos más adelante cómo hacerlo).
GitIgnore
El archivo .gitignore determina los archivos que queremos que git ignore. Si en datalab tenemos archivos que no queremos que formen parte del control de versiones deberemos incluirlos en este fichero. ¿ Qué tipo de archivo meteremos en gitignore ? Archivos muy pesados que no sufran cambios relevantes que traquear. Otro ejemplo sería, en una aplicación web, la carpeta node_modules que se incluiría en el fichero gitignore ya que se puede generar cada vez a partir de otro archivo.
Acciones
Hay varias acciones que nos permite realizar ungit para llevar a cabo el control de versiones.
Crear una rama
Siguiendo las buenas prácticas, es recomendable utilizar ramas distintas para cada funcionalidad. La forma de crearlas en ungit es muy sencilla. Hay que ubicarse en la rama que queremos como base y hacer click en el símbolo del “ + ”. Luego le damos un nombre y pulsamos la tecla del enter ( ↵ ) o el botón que indica “ branch ”.
Ten en cuenta que hasta que no hagas un push de la rama (lo vemos más adelante), para el resto de compañeros no existirá esa rama.
Checkout
El checkout nos permite cambiar de una rama a otra. Podemos visualizar en qué rama estamos trabajando fijándonos en el desplegable que se marca en la captura siguiente:
Para cambiar de rama solo hay que hacer click sobre el nombre de la rama a la que quiero ir y hacer click en checkout como se indica en la siguiente captura.
Recuerda que no es aconsejable trabajar directamente sobre la rama master, y que la información que veas en datalab dependerá directamente de dónde hayas hecho checkout.
Commit
Hacer un commit es equivalente a hacer un backup del estado actual de la máquina. Se genera un nuevo punto en ungit en mi repositorio en local, punto al que puedo volver en cualquier momento aunque siga haciendo más commits (equivaldría al Time Machine en Mac).
Lo aconsejable es ir haciendo commits de vez en cuando. Además, ungit no responde muy bien cuando se acumulan muchos cambios sin commitear.
Push
Al hacer push de la rama subimos los cambios al repositorio en remoto de la misma (nombre de la rama en color azul) y hacemos los cambios visibles para todos los usuarios. De momento los cambios solo están en la rama en la que estoy trabajando, y no han sido incorporados a la rama master.
Hacer un push equivale a compartir los cambios.
Reset
Es posible que hayamos hecho un commit y que antes de hacer el push decidamos eliminarlo y desechar esos cambios. En este caso habría que seleccionar el nombre de la rama en local y hacer click en reset para eliminarlo.
Pull
Dentro de una misma rama, puede que el repositorio en remoto esté más actualizado que el repositorio en local. Si esto es así podemos actualizar la información que vemos en nuestro repositorio en local de la siguiente manera:
Mover la rama en local (color del nombre en blanco) hasta donde está la rama en remoto (color nombre en azul).
Merge
Una vez hayamos finalizado de hacer cambios en la rama y la funcionalidad esté lista para pasarla a la rama master hay que hacer un merge. Hay que seguir unos sencillos pasos para pasar la información de nuestra rama a la rama master:
Click en la rama master en remoto (color del nombre en azul).
Click en checkout.
Click en la rama de la que quiero copiar los cambios.
Click en merge.
Click en la rama master en local (color del nombre en blanco).
Click en push.
En este momento estamos situados en la rama master con todos los cambios de la otra rama incorporados. Una vez hacemos merge de una rama en la master no debería seguir utilizándose. Deberíamos crear una nueva rama para la funcionalidad que vayamos a empezar a trabajar.
Resolución de conflictos
A veces cuando hacemos merge surgen conflictos. Ahora mismo es el punto flojo de la interfaz gráfica de Ungit. De momento la única opción que deja es marcar el conflicto como resuelto, pero no manipularlo para decidir qué es lo que prevalece y que es lo que no. Esperamos que pronto se puedan resolver con Ungit .
Conclusión
Ungit es un sistema de control de versiones que facilita utilizar todas las funcionalidades de ungit a través de una interfaz gráfica muy intuitiva. ¿Qué te ha parecido ungit? ¡Si quieres saber más cosas sobre ungit o su uso en datalab no dudes en escribirnos un comentario!
Con la ley en la mano, cuando un usuario entra a una web hay que preguntarle claramente si nos autoriza a ponerle cookies y, hasta que no dé su permiso no podemos ponerlas. De esos usuarios que o bien rechazan las cookies, o bien todavía no se han manifestado, perderemos toda la información. Y no solo en Google Analytics, sino también en las herramientas de publicidad. No sabemos cuántos son, ni cuántos han convertido. Y cualquier estrategia de ajuste de las pujas basada en el comportamiento de los usuarios quedará limitada a los usuarios que aceptan cookies.
Introducción a Consent Mode
Para tratar de mejorar un poco la situación con estos usuarios Google ha anunciado Consent Mode, una herramienta que tiene la finalidad de mejorar los datos en las plataformas publicitarias de Google al tiempo que simplifica la activación o bloqueo de tags según lo que autorice cada usuario.
Consent Mode no es una solución para sustituir al aviso de cookies, ni a los gestores de consentimiento (CMPs), sino que los complementa, haciendo que incluso cuando el usuario rechaza las cookies, podamos rescatar alguna información.
La idea es respetar la ley y no poner cookies ni usar ningún dato personal, pero no por ello renunciar a usar otros datos que, según nos comunican desde Google, está permitido usar. Nos referimos a datos muy genéricos, como la ciudad o la hora, entre otros.
Pero para disponer de esos datos es necesario seguir mandando información a los servidores de Google ¿cómo lo hace?
Os presento al ping, un hit sin cookies
Centrándonos en Google Analytics, hasta ahora la etiqueta necesitaba que existiera la cookie _ga para poder ejecutarse, y cuando lo hacía mandaba pequeños fragmentos de información que llamábamos ‘hits’. Un hit incluye información de lo que ha hecho el usuario (por ejemplo que ha visto la página de la home), y del propio usuario, como información asociada a su IP y el clientID, que es el único dato que se guarda en la cookie _ga. Cuando el usuario navegaba a otra página de la misma web, la cookie se encargaba de recordar que era el mismo usuario.
Con Consent Mode las etiquetas de Google también pueden ejecutarse sin cookies, y mandan exactamente la misma información, pero cuando no hay cookies Google, en lugar de hits, los llama pings.
Si abres la consola del navegador y en la pestaña Network buscas “collect” para identificar las llamadas de Google Analytics, verás que ambos tipos de llamadas llevan la misma información. Solo hay un parámetro que varía y que se llama gcs. No hemos encontrado información que nos confirme que es así como los distingue, pero todo apunta a que si, ¿gcs = Google Consent Status?
Valor de gsc
Cookies de publicidad
Cookies de analítica
G100
✗
✗
G101
✗
✓
G110
✓
✗
G111
✓
✓
Sin embargo, una vez que el dato llega a Google el comportamiento es muy diferente. Cuando el usuario no ha aceptado cookies el hit no se va a almacenar en Google Analytics, puede verse en tiempo real, pero no en los informes (inicialmente se veía en los informes durante el día y durante la consolidación nocturna desaparecía, pero esto ya no es así). Sin embargo, Google extraerá aquellos datos “legales” y descartará el resto, usando los datos que pueda para calcular usuarios y conversiones mediante modelado estadístico en las plataformas publicitarias.
La estrategia es crear clusters de usuarios que compartan características con datos que no les identifiquen, y, comparar clusters semejantes entre los datos de pings y los de hits, de manera, que si para el cluster de usuarios de Madrid que se conecta a las 10 de la noche, la conversión de los que tenemos cookies es del 1%, podemos asumir que para el mismo cluster de los usuarios que no tenemos cookies la conversión será similar.
Cuanta más y mejor información tengamos de los hits, mejor se podrán modelar los pings. Sin embargo esta es una parte de la beta en la que están trabajando y aún no están disponibles estos datos modelados, que primero llegarán a Google Ads, luego a Doubleclick, y más adelante a Google Analytics 4. Y aunque en Universal Analytics nunca los veremos es importante que se manden si usamos las conversiones de Analytics en Google Ads.
Algo importante en este modo de funcionamiento es que cuando el usuario no tiene cookies, el cid no será persistente entre cargas de página, aunque sí lo es dentro de la misma página gracias a que se guarda en la variable gaGlobal. De este modo cada página que se visite sería contabilizada como un nuevo usuario, y durante el modelado Google tiene que determinar que no lo es, en base a otras señales, para poder estimar correctamente el número de usuarios y sesiones.
Simplificar el bloqueo de cookies
La segunda utilidad de Consent Mode es simplificar el bloqueo de cookies (de Google) cuando el usuario no ha aceptado su uso.
Normalmente el mínimo de granularidad en el consentimiento de cualquier web sería pedir permiso por separado para las cookies de analítica y las de publicidad. Si el usuario acepta analítica, se puede lanzar Google Analytics, pero no Google Ads y viceversa.
Pero es más complejo. Google Analytics, cuando tiene activados los informes demográficos utiliza las cookies de publicidad, así que si un usuario acepta estadística, pero no publicidad, podríamos lanzar Google Analytics sólo si inhabilitamos estas funciones.
Con Consent Mode todo esto se hace de forma casi automática. Lo único que hay que hacer es actualizar el dataLayer con la información que indica la documentación técnica y las etiquetas de Google ya se encargan de leerla y adaptarse a la situación. Para no alargar este artículo, los detalles técnicos de cómo se implementa se pueden consultar desde la página de ayuda de Google Analytics sobre Consent Mode.
Lógicamente esto funciona con las etiquetas que leen el dataLayer, es decir que es compatible con gtag.js y con GTM, pero no con ningún otro código, de modo que si aun tenemos una implementación con analytics.js tocará actualizarla.
En realidad Consent Mode no bloquea las etiquetas, que se ejecutarán siempre, independientemente de lo que diga el usuario. Lo que hace es que la misma etiqueta mandará un ping si el usuario no ha aceptado cookies y un hit en caso de que si las haya aceptado. Y es importante no bloquearlas por nuestra cuenta, pues entonces perderemos toda la parte de modelado que hemos visto antes y que es la principal utilidad de esta solución.
Además, al tiempo del lanzamiento, se ha anunciado que algunos gestores de consentimiento ya se han adaptado para encargarse ellos mismos de hacer todo lo necesario cuando el usuario acepta o rechaza cookies, de manera que si en tu web utilizas Cookiebot, Iubenda, OneTrust, Osano o SourcePoint, estás de suerte, y seguramente te bastará con declarar el estado por defecto (ninguna cookie permitida para cumplir con la ley en España) al principio de cada página.
Cuidado con los usuarios nuevos que rebotan
Durante nuestras primeras implementaciones hemos observado que, con el funcionamiento por defecto de esta solución, si un usuario nuevo entra en la web, acepta cookies y se va sin haber navegado (usuario que rebota) Google Analytics no va a medirlo. En los siguientes esquemas se puede observar por qué.
Para solucionar esto, y mientras Google no ofrezca una alternativa mejor, debemos hacer que al cerrar el banner de cookies, si se han aceptado las mismas, se vuelva a mandar la misma página vista. Como la primera es un ping, y no se guarda en Universal Analytics, no hay riesgo de duplicar páginas.
Es fundamental, al hacer esto, que nos aseguremos de no mandar esta página hasta que no están aceptadas efectivamente las cookies, pues en caso contrario se repetiría como ping y no serviría. Para ello podemos comprobar en consola el valor del parámetro gsc de esta segunda llamada.
Y cuando el modelado de estos datos vaya llegando a las diferentes plataformas deberemos comprobar de qué manera afecta la existencia de esta página duplicada.
Con la aparición de GA4 y el nuevo paradigma de medición, sin vistas y basado en datastreams, en estado beta, surgen muchas dudas acerca de cómo vamos a obtener ahora los datos. En este post hemos planteado y tratamos de resolver de manera sencilla algunas de las dudas más frecuentes con las que nos encontramos día a día en este año de cambios.
Duda 1: planes GA360 vs. GA4
¿Va a estar GA4 en los planes de Google Analytics 360? ¿Contarán los hits de GA4 en la licencia 360?
Actualmente ya puedes pedir que te incluyan la cuenta de GA4 en la beta de 360.
Los hits no van a contar nunca para consumo, porque GA4 no se pagará por volumen de hits.
Los planes de licencia aún no los han publicado pero la idea es pagar por características. Es decir, Google Analytics 360 permitirá límites más altos, características nuevas y mayor rendimiento que la versión gratuita.
Aparte está BigQuery, que puedes activarlo o no, tanto si eres 360 como si no. Y si lo activas pagarás por lo que consumas.
Con BigQuery podremos obtener un mejor y más amplio análisis, ya que tendremos todos los datos disponibles para su extracción.
Duda 2: parámetros y eventos en GA4
GA4 te deja crear 50 parámetros de evento y 25 user properties. ¿Eso se aplica a la propiedad entera o a cada stream de propiedad? Es decir, ¿dentro de una propiedad cada stream puede tener 50 parámetros de evento y 25 user properties? ¿o es a nivel de propiedad?
En 360 los límites son mayores; es decir, podemos tener mayor número de eventos y parámetros. Con las dimensiones y métricas los parámetros se cuentan por propiedad y no por evento.Por lo tanto, ahora, si tienes un mismo parámetro en 2 eventos de cada stream de una propiedad y tienes 3 streams: solo tienes 1 parámetro de evento gastado para la propiedad.
Duda 3: user properties
¿Qué pasa entonces con las user properties?
En principio, tenemos 25 user properties y funciona igual que los parámetros de evento. Si tienes una user property en un evento, y esa user property se repite en otros tres eventos: sigue siendo 1 usada.
Si bien es cierto que no se pueden borrar, si se pueden archivar y liberan el “hueco” para poner otra.
Cuando creas una user property, puedes borrarla cuando ya no la necesites. Después, basta con que la mandes una vez cuando cambie su valor y se mantiene para posteriores hits.
Duda 4: límites etiquetas de configuración de GTM en GA4
Dentro de la etiqueta de configuración de GTM en GA4, puedes poner user properties y fields to set, pero… ¿sirven para poder medir parámetros que necesitas en todos los eventos sin gastarte el límite establecido de parámetros?
Cualquier cosa que pongas en fields to setque GA4 no reconozca como un nombre de campo, lo va a mapear o convertir en parámetro de evento, y cuenta para todos los límites exactamente igual que cualquier otro, con dos particularidades:
La etiqueta de configuración controla los eventos de página vista y medición mejorada, por lo tanto es a esos eventos a los que añadirá los parámetros del fields to set, no a todos.
La etiqueta de configuración se inicia una vez durante la carga de la página y los valores que tome serán los que use hasta que haya una recarga.
Así pues, por ejemplo, si en la carga tienes page_language = ES, luego lo actualizas a EN y se produce un evento de scroll de medición mejorada, este evento seguirá informando ES.
Esto quiere decir que la etiqueta de configuración que ponemos en todos los eventos, es solo para que esos eventos se relacionen con la propiedad GA4 adecuada, pero lo que está dentro de la etiqueta de configuración solo se carga una vez al cargarse la página y todos los eventos que se disparen con esa etiqueta no cambiarán los valores en fields to set o en user properties que se cargaron cuando se disparó la etiqueta de configuración.
Duda 5: límites de las properties en GA4
Las user properties que se ponen en la etiqueta de configuración cuentan como unas de las 25 UPs permitidas.
Como la etiqueta de configuración va en todos los eventos que tienes, si tienes tres user properties en esta etiqueta y tienes cuatro eventos, ya cuentan como 12 user properties gastadas, ¿o no?
Correcto, cuentan para el límite, pero las user properties no se mandan en todos los eventos, sino en las páginas vistas y eventos de medición mejorada, que son los que gestiona la etiqueta de configuración de GA4.
En cualquier caso, basta mandarla una vez para que se aplique a todo lo que ocurra después hasta que cambie su valor.
Duda razonable: Entonces ¿funcionan como los parámetros? Es decir, como en el ejemplo del idioma, si cambias de idioma, el valor no se reflejará a no ser que se cargue otra página y entonces se dispare la etiqueta de configuración con el nuevo valor. ¿Si eres un usuario sin login y haces login sin que se cargue otra página (lo que suele pasar), la user property de login todavía refleja el «no loggin» hasta que no cambies de página?
Debería ser así, puesto que el motivo de que no coja valores dinámicos es que la propia etiqueta de configuración se inicializa durante la carga de la página. En el ejemplo del login, habría que mapear (o convertir) la misma propiedad en la etiqueta de configuración para que recoja el valor inicial, y en los eventos de login y logout, para que recoja los cambios.
Si todavía tienes preguntas y te gustaría que te ayudemos en tu implementación de GA4, no dudes en ponerte en contacto con nosotres.
