(You can also read this article in English here)
Actualización: Desde Octubre de 2017, Google desarrolló y anunció una solución parcial al problema descrito en este post. Puedes leer más sobre ello aquí.
Además, Google anunció en Noviembre de 2018 que ha desarrollado una nueva tecnología que permitirá a los navegadores mostrar la URL original cuando sirvan la versión AMP desde la caché de Google, llamada «Signed Exchanges». Todavía no está implementado en las versiones más recientes de los navegadores pero solucionaría potencialmente los problemas detallados en este artículo.
Si te has subido al carro de AMP, y has indagado un poco en las métricas puede que te estés preguntando por qué tus nuevas páginas tienen un porcentaje de rebote tan alto (muchas veces mayor que las versiones «normales» de las mismas páginas).
Aquí tenéis un ejemplo, comparando el tráfico de un blog a posts (no categorías, ni home) AMP y NO AMP (tráfico orgánico a AMP, la web no sale en el carrusel de Noticias Destacadas). Como podéis ver, las métricas de comportamiento son mucho peores en el caso de AMP.
Es raro, ¿no? Podríamos decir que una posible explicación es que el tráfico no AMP tiene más usuarios recurrentes, y que por eso tiene mejor calidad. Pero no es el caso:
Lo que está pasando es mucho más simple (y a la vez complejo): Google Analytics (o la herramienta de medición que utilices) te está dando datos incorrectos: inflación de usuarios únicos y sesiones, porcentajes de rebote más altos de lo habitual, aumento del tráfico de referencia…
AMP trae «de regalo» un ecosistema en el que tú ya no eres el que sirve el contenido, con todo lo que eso conlleva de cara a la medición del uso de estas páginas. En este artículo, te explico con todo nivel de detalle cuál es el problema con las métricas en AMP, a qué se debe, y cómo se puede solucionar.
Tabla de contenidos
Cómo funciona AMP, en Google
Qué es AMP
Antes de profundizar en sus entresijos, conviene entender en qué consiste AMP.
AMP (Accelerated Mobile Pages) es un proyecto open source, liderado por Google pero secundado por otros partners (Pinterest, Twitter, Linkedin…), que pretende definir un estándar para realizar páginas para dispositivos móviles más rápidas.
Apareció, en parte, como respuesta a Instant Articles de Facebook (que no es open source) y ambos proyectos tienen el mismo objetivo: que cuando el usuario pinche en un link, dentro de sus plataformas, pueda visualizar el contenido de forma inmediata.
Como, a pesar de tener los recursos, las empresas (en general) no han creado webs móviles muy rápidas, y la causa de su lentitud suelen ser principalmente la publi y el uso de JS, Google (y Facebook) han decidido definir unos estándares con muchas restricciones para que sí o sí, tu web cargue muy rápido.
Para ello, en ambos casos, además de limitar el número de etiquetas html y elementos que se pueden incluir (JS, CSS, anuncios y demás), ambas plataformas cachean una copia de tu contenido en versión AMP/Instant Article para servirla directamente desde sus servidores.
¿Cómo se sirven las páginas AMP cuando realizas una búsqueda en Google?
En el caso concreto de Google, al clickar en cualquier resultado que muestre el símbolo del rayo y «AMP» al lado, cargará, sin salir del SERP de Google, la página correspondiente, de forma prácticamente inmediata.
Esto es así porque lo que Google hace es:
- Una vez detecta en una URL «común» la etiqueta que indica su versión AMP, la rastrea, valida que el html cumpla los estándares AMP
- Si es así, se guarda una copia en caché y marca que la URL «normal» tiene versión AMP, asociando la una a la otra.
- Además, como la URL tiene (o debería) tener una canonical apuntando a la normal, no se debería indexar por separado en el índice de Gogle.
Cuando alguien hace una búsqueda en mobile, si un resultado no tiene versión AMP, al pinchar en el link se abre esa URL en el navegador, se contacta al servidor del dominio en cuestión y se obtiene el contenido de la página (como toda la vida, vamos!)
Si un resultado sí tiene versión AMP, Google muestra el símbolo del rayo y las letras AMP. Al pinchar, en lugar de abrir la URL original del resultado en el navegador (ya sea la URL AMP o la «común»), lo que pasa es lo siguiente:
1. En el html mobile, Google tiene un div ya preparado para albergar el contenido de cualquier resultado AMP.
2. Al pinchar en el resultado, dentro de ese div se cargan una serie de elementos, entre ellos un iFrame. Esta capa carga el contenido del resultado correspondiente, sin salir de la página de resultados el la que el usuario está.
3. Ese iFrame, apunta a la URL de la caché de Google para la URL de AMP del resultado correspondiente (ej: http://cdn.ampproject.org/v/s/randomtrip.es/tarjeta-sim-portugal-internet-smartphone/amp/?amp_js_v=6 ). Lo mismo ocurre en el carrusel de «Noticias destacadas»
4. Si el usuario cierra con el aspa superior izquierda, se cierra la capa y sigue donde estaba (en el SERP)
5. Si el usuario hace «swipe» (en el caso del carrusel de «Top News») se pasa al siguiente elemento de la lista (otro iFrame con la URL de la caché de Google que corresponda)
6. Si el usuario pincha en algún link o elemento dentro del contenido de cualquiera de los artículos AMP, se va fuera y ahora sí se abre con el navegador la URL correspondiente (versión NO-AMP, aunque la URL la tenga)
¿Cómo funciona AMP a nivel de analítica?
Una vez hemos entendido cómo sirve Google las páginas AMP dentro de sus resultados de búsqueda, hay dos puntos fundamentales que afectan a nivel de analítica:
- Las páginas las sirve Google, no nuestro servidor. Nuestro servidor ni siquiera sabe que se ha servido una página.
- El dominio que sirve la página es cdn.ampproject.org, cuyo contenido se carga con un iFrame dentro del dominio de Google en el que se realizase la búsqueda (por ejemplo www.google.es)
Las páginas las sirve Google, no nuestro servidor
Si hacemos un análisis de logs en nuestro servidor de las URLs AMP que tengamos, veremos que probablemente el patrón de tráfico no tenga nada que ver con lo que nos muestra Google Analytics (o la herramienta de analítica que usemos). De hecho, puede que sólo tengamos peticiones de Googlebot.
Esto es así porque, a día de hoy, salvo que no tengamos versión móvil o web responsive y derivemos el tráfico móvil a AMP, las únicas formas de llegar a una página AMP son:
- A través de Google (u otros terceros que están adoptando la tecnología)
- Accediendo a la URL de alguna página AMP directamente desde nuestro navegador
- Que se haya escapado algún link a una URL AMP por algún lado (email, redes sociales, webs de terceros que nos enlacen…).
Si se llega a través de Google, la visita nunca llega a nuestro servidor: Google sirve directamente la página, las imágenes, etc., desde cdn.ampproject.org
Las páginas se sirven desde un dominio diferente
Al servir las páginas Google, desde sus servidores, el dominio que las sirve no es el nuestro, si no el que él elija. En este caso y actualmente, el dominio que está utilizando es cdn.ampproject.org (a veces aparece un subdominio de este, tipo tuweb.cdn.ampproject.org), mediante un iFrame insertado en google.es (o el dominio regional de Google que corresponda)
Esto a nivel de analítica tiene muchas implicaciones, ya que el código de analítica se está ejecutando desde un dominio diferente, y por lo tanto no puede acceder a la cookie del dominio original.
Algunas cosas que pasan a nivel de analítica, y que generan datos no fiables:
- Un usuario que visite una página nuestra en AMP desde Google, y otra no-AMP, son dos usuarios.
- Una visita que empiece en una página nuestra en AMP desde Google y pinche en algún enlace interno, son dos visitas.
- El rebote (medido por defecto) de una página AMP es 100% salvo que tengamos varios elementos en el carrusel de «Top News» y el usuario pase por varios de ellos en la misma sesión, o salvo que tengamos varios resultados del mismo dominio en un SERP y el usuario pinche en varios de ellos en la misma sesión.
- Una visita que viene a la web «común» después de pinchar en un enlace interno en la versión AMP servida por Google, tiene como fuente «Tráfico de Referencia» desde cdn.ampproject.org
A continuación, reproduzco paso a paso cada una de estas anomalías.
¿Por qué los datos de analítica de AMP mienten?
El término «usuarios» cada vez es más falso en el mundo de la analítica web. Diferentes navegadores, diferentes dispositivos y el uso de los modos incógnito (o borrado manual de cookies) hacen que prácticamente ningún usuario pueda ser identificado de forma unívoca con una cookie.
Esto quiere decir que, incluso sin AMP, estamos sufriendo «duplicidad» de usuarios constantemente.
¿Qué pasa con AMP? Hay diferentes casos, según desde dónde se cargue el contenido, y en algún caso, según el orden (en todos los casos hablo del uso desde un dispositivo móvil):
1. Usuario accede a la web desde su navegador móvil. Este es el caso típico de uso de nuestra web: alguien quiere acceder a ella, e introduce directamente la dirección en su navegador (o accede desde favoritos).
Para determinar si es un usuario nuevo o no, Google Analytics comprueba la cookie «_ga». Si existe, obtiene de ella el valor del «clientID» y lo envía. Si no es así, la genera, con un nuevo «clientId» para poder identificar al usuario en las próximas sesiones.
En este caso, al hacer las pruebas en un navegador desde 0, todavía no hay ninguna cookie y somos un usuario nuevo, por lo que se genera la cookie y el «clientID».
Nuestro clientID para este dominio:
2. Usuario accede directamente a página AMP: este caso, en general, no será común, salvo que compartamos o enlacemos nuestras URLs AMP (o hagamos nuestra versión móvil en AMP directamente).
Seguimos estando en nuestro dominio (randomtrip.es), y por lo tanto, al acceder a una página la cookie generada en el paso anterior nos debería identificar y, por lo tanto, seríamos el mismo usuario, ¿no?
Pues no es así (empieza la fiesta):
Lo que pasa aquí es que el JS de Analytics que se utiliza en AMP sí utiliza una cookie, pero la cookie que utiliza (AMP_ECID_GOOGLE) es distinta de la cookie que utiliza Analytics en las páginas no AMP (_ga).
Por lo tanto, la información del clientID es distinta para este caso, y para estas dos interacciones secuenciales, somos dos usuarios y dos visitas diferentes.
3. Usuario hace búsqueda en google y pincha en resultado AMP. Este es el caso más típico de uso de AMP.
El contenido se carga desde la caché de Google, en el dominio de google (pongamos google.es) a través de un iFrame que apunta a cdn.ampproject.org, y la información de identificación del usuario (clientID) se guarda en LocalStorage para el dominio google.es, no en una cookie (ni _ga, ni AMP_ECID_GOOGLE). El valor que guarda ahí es único y diferente al valor del clientID de la cookie del dominio real del contenido.
¿Divertido, eh? :D (Nótese el sarcasmo). Pues esta, que sería la tercera interacción secuencial, envía la siguiente información a Analytics:
Por lo tanto, ya somos tres usuarios y tres sesiones diferentes!
4. Usuario accede directamente a la caché: Este caso empieza a ser común para terceros diferentes a Google (LinkedIn, Pinterest…), o se podría dar en el extraño caso de que el usuario accediese directamente a la fuente del iFrame (a la caché de Google para AMP), accediendo por ejemplo a una URL como esta: http://cdn.ampproject.org/v/s/randomtrip.es/barco-flores-lombok-komodo/amp/?amp_js_v=6
En este caso, se utiliza el mismo sistema que en el caso anterior (el LocalStorage, y no la cookie) pero para el subdominio cdn.ampproject.org, con lo cual el valor que se almacena para el clientID es distinto del anterior. Ya tenemos nuestro cuarto clienId distinto, todo para la misma web, desde el mismo navegador y sin borrar cookies.
En este caso, el clientID que nos asigna es el siguiente:
5. Usuario accede directamente a la URL de Google que muestra el iFrame desde la caché: este caso es común ya que se da cuando un usuario hace una búsqueda en Google, pincha en un resultado de AMP, y al ver el contenido decide compartirlo bien copiando y pegando la URL tal cual, bien a través de las funciones nativas del navegador (enviar a…).
Google está intentando evitar este comportamiento, pero creo que de una manera poco efectiva. La URL visible sigue siendo la suya propia ;)
La URL sería de este estilo: http://www.google.es/amp/s/randomtrip.es/barco-flores-lombok-komodo/amp/ (no se puede acceder desde Desktop, ya que hace redirección a la URL original. Sí se puede acceder desde móvil).
En este caso, estamos en dominio google.es, y el valor del clientID también se guarda en el LocalStorage.
Y aquí pasa una cosa interesante.
Si existen dos valores diferentes para el clientID en los LocalStorage de google.es (o el dominio que corresponda) y cdn.ampproject.org, prima el del segundo. Por lo tanto, una vez que hayamos accedido alguna vez a «cdn.ampproject.org», los casos 3, 4 y este mismo (5), deberían devolver el mismo valor para clientID (menos mal! :D)
En este caso, el clientID que nos asigna es el siguiente (el mismo que en el caso 4):
Es decir: el clientID generado en el paso 3, ya nunca más se va a utilizar, porque ahora prevalece el del paso 4. Dependiendo de la secuencia de interacción del usuario, se generarán ambos o no, y tendremos mayor o menor inflación de usuarios y visitas.
6. Usuarios que acceder a versión AMP a través de apps de terceros: hay un último caso, que está empezando a despegar todavía ahora, y son las apps de terceros.
LinkedIn, Pinterest, Flipboard… ya están incluyendo la versión AMP de los links en vez de la normal en sus aplicaciones móviles, dirigiendo el tráfico directamente a la URL de la caché de Google (cdn.ampproject.org o tuweb.cdn.ampproject.org), que sería el caso 4.
No he podido comprobarlo todavía, pero al abrir estas apps los links en un viewer html dentro de la propia app, es posible que para cada una de ellas se genera un nuevo usuario (aunque algunas usan el motor de Chrome, así que puede que no sea así). Si lo compruebas, avisa en los comentarios para completar la info! :)
Por lo tanto, tenemos 6+ escenarios, de los cuales 4, al menos, generan un clientID distinto, lo cual quiere decir que lo que antes de tener implementado AMP contaba idealmente como un usuario único (en el mismo navegador, en mobile), ahora puede llegar a contar como hasta 4 usuarios únicos:
Todo esto lo tenéis aquí explicado también por el propio Google y confirmado por el creador y líder tecnológico de AMP, Malte Ubl, en Twitter
Métricas afectadas
Como te podrás imaginar, las consecuencias de estas discrepancias a la hora de medir hacen que muchas de las métricas no representen la realidad tal y como la imaginamos, por lo que hay que tener mucho cuidado a la hora de analizar e interpretar los datos si hay tráfico AMP de por medio
- Usuarios únicos: como acabamos de comprobar, un usuario desde un mismo dispositivo, con un mismo navegador y sin borrar cookies puede llegar a contar como 4 usuarios diferentes en función de cómo visite nuestras páginas AMP.
- Visitas/Sesiones: si un usuario visita una página en AMP, en cualquiera de los entornos, y se va, no hay problema (desde un punto de vista de medición). El problema viene si el usuario navega. En ese caso, al pinchar en cualquier link o elemento que le lleve a otra página de nuestra web (normalmente, a páginas no AMP), al igual que se cambia de usuario, se inicia una nueva sesión, partiendo una única sesión en dos.
- Porcentaje de rebote: debido a lo anterior, al partir una sesión en dos, la primera sesión tendrá una sola página vista y por lo tanto contará como un rebote, cuando en realidad no lo es. La segunda visita, si solo ve una página y se va, también contará como rebote. Entonces, está aumentando el porcentaje de rebote de forma totalmente ficticia (una sesión que no sería considerada rebote – el usuario ve dos páginas – se convierte en dos sesiones, ambas consideradas rebotes). Tanto para AMP como para las páginas no AMP visitadas desde la versión AMP.
- Páginas vistas por sesión: totalmente ligada a los dos puntos anteriores, en lugar de tener 2 páginas vistas por sesión pasaríamos a tener 1.
- Fuentes de tráfico: el tráfico que navega hacia otras URLs de nuestra web desde los escenarios en los que el contenido lo sirve Google (o un tercero), cuenta como tráfico de entrada (sesiones nuevas) y su Fuente de tráfico pasa a ser Tráfico de referencia desde cnd.ampproject.org (o tuweb.cdn.ampproject.org)
Estas son las métricas más comunes directamente afectadas. Como os podéis imaginar, a raíz de estas, prácticamente todo el resto de métricas se ven afectadas, al depender la gran mayoría de estas para su cálculo.
Por ejemplo, en un e-commerce, si un usuario accede a través de AMP y termina comprando en esa misma sesión, la venta se atribuiría al usuario de la web, no al de AMP, y tendría fuente de tráfico «Referencia» en vez de «Buscadores».
Cómo evitar que Analytics duplique usuarios con AMP
Por suerte, existe una solución para evitar que los clientID sean diferentes en todos estos casos, técnicamente compleja, pero factible. Sirve para los datos recogidos a raíz de su implementación, pero no para los datos que ya tengamos recogidos en Google Analytics.
Es increíble que Google no haya hecho todavía para arreglar esta situación (igual que no ha hecho nada por solucionar el tema del Spam en Google Analytics), cuando AMP lleva ya casi un año implementado en las SERPs.
ACTUALIZACIÓN (07/03/2017): Eduardo Garolera me ha pasado este linkazo en el que Google explica de forma muy específica y detallada el «approach» que recomienda seguir para minimizar el impacto de la duplicación de cookies de usuario. Viene a explicar lo que ha hecho Simo, y que cuento aquí abajo, pero con una solución también para el caso en el que el usuario que visita alguno de los escenarios AMP sin haber visitado antes nuestra propia web.
La solución, aunque no la he probado todavía, la podéis encontrar en este post de Simo Ahava:
http://www.simoahava.com/analytics/google-analytics-client-id-amp-pages/
Básicamente consiste en crear un proxy en nuestro dominio (se necesita http sí o sí).
En la configuración del componente amp-analytics, en AMP, se puede indicar que antes de enviar los datos a Google Analytics, se obtenga información de configuración extra desde una URL externa.
A diferencia de la mayoría de recursos en AMP (que los cachea Google y los sirve desde sus propios servidores), esta petición a la URL externa no se cachea y se realiza siempre desde el cliente, en el momento en que la página se termina de cargar y el foco está puesto en ella.
Al ser una petición a una URL de nuestro dominio, se envían las cookies de ese dominio al servidor, por lo que el proxy lo que hace es comprobar si recibe la cookie _ga, y si es así, extraer el valor del clientID para devolverlo al cliente y que se incluya ese clientID en la petición a Analytics, en vez del que ha generado el propio Google Analytics.
Además, hay que actualizar la cookie de la misma manera en que Google Analytics lo haría, para reproducir el comportamiento por defecto de GA.
Problemas:
- No es una implementación tan trivial
- Necesitas tener http en tu servidor (al menos para la URL del proxy)
- No es algo oficial, por lo que si la forma de medir de Google Analytics cambia es probable que tengamos que actualizar nuestro «workaround»
- Si lo hacemos mal, la podemos liar todavía más.
- No funciona si el usuario no visita primero en AMP y luego en nuestra web
- No funciona en Safari cuando se accede al contenido a través de la caché de Google AMP.
ACTUALIZACIÓN (02/03/2017): Malte Ubl, creador y responsable tecnológico del proyecto AMP, acaba de decir en Twitter que la solución de Simo es, de hecho, buena, con la salvedad de que no funcionaría en el caso de Safari, al acceder al contenido a través de la caché de Google (ya que Safari bloquea las cookies de terceros)
¿Y qué pasa con los datos históricos?
Si te atreves a implementar la solución anterior, obviamente sólo se arreglará el problema a partir del momento en que pongas la solución en producción, por lo que los datos recogidos hasta ese momento seguirán estando mal.
¿Qué puedes hacer? No mucho, pero si de verdad necesitas intentar darle un vuelvo a los datos (al menos a los más básicos) de lo que tengas hasta ahora, puedes intentar utilizar la siguiente información para obtener una aproximación.
- Como las sesiones que hayan consumido más de una página acaban irremediablemente en tu web, las tenemos controladas: están bajo «Tráfico de referencia» desde el subdominio cdn.ampproject.org.
- Si quieres corregir el rebote, puedes sacar por un lado las visitas a AMP, por otro las visitas desde cnd.ampproject.org y recalcular el dato. Ej: si tienes 1000 visitas a páginas AMP, con un 89% de rebote, y 200 visitas desde cnd.ampproject.org, tendrías:
- 110 visitas (11%) no fueron rebotes, porque visitaron varios resultados en los SERPs de AMP de tu dominio
- 200 visitas se han considerado rebote, pero en realidad no lo fueron, porque accedieron a tu web desde AMP y se han categorizado como tráfico de refencia
- Por lo tanto, 310 visitas no han sido rebotes.
- Aproximación de rebote corregido: 690 (1000-310) de 1000 (69% en vez de 89%)
Partiendo de esto, puedes hacer lo mismo con otras métricas (para descontar usuarios y sesiones, reajustar páginas vistas, etc.)
Cómo solucionar (parcialmente) este problema con la solución propuesta por Google
Google desarrolló una solución parcial a este problema funcional en todos los dominios de Google desde 2017. Puedes leer sobre ello aquí y también echar un ojo a la presentación sobre el tema que hice en el Searchmetrics Summit 2017:
Es importante destacar que está solución no viene incluida «por defecto» en AMP, así que si usas AMP en alguna de tus webs, necesitas hacer lo siguiente para tener la solución funcionando:
1. En todas tus páginas no-AMP, setear el volumen del parámetro ‘useAMPclientID’ a «true»
2. En todas tus páginas AMP, incluir el siguiente tag en el head:
<meta name="amp-google-client-id-api" content="googleanalytics">
3. Usar exclusiones de referencia en GA: necesitas dar de alta exclusiones de referencia para el dominio cdn.ampproject.org
Más información sobre cómo implementar y comprobar que está funcionando esta solución en https://support.google.com/analytics/answer/7486764?hl=es
Aparte de esto, Google anunció que gracias al uso de una nueva tecnología, Signed Exchanges, los navegadores podrán servir páginas AMP desde la caché de Google mostrando la URL original del contenido, que potencialmente solucionaría los problemas detallados en este post.
Conclusión (TL/DR)
Acabamos de ver y demostrar cómo un mismo «usuario» (mismo navegador con cookies habilitadas en un mismo dispositivo móvil) puede multiplicarse por 4 por culpa de AMP en las herramientas de Analítica, arrastrando consigo un aumento de visitas, un descenso de páginas vistas por visita y un aumento del rebote, todo totalmente «ficticio».
Y lo peor de todo, es que seguramente ni te habías dado cuenta. Y puede que hasta te hayas preocupado con el alto rebote de tus páginas en AMP.
De momento, salvo que te atrevas a probar la solución que he señalado en este post, no hay mucho que hacer. Pero por lo menos, es importante tenerlo en cuenta a la hora de analizar, y evitar sacar conclusiones precipitadas cuando haya tráfico AMP de por medio.
Lo ideal es que Google proponga una solución «oficial». De momento hay una tarea en el Github de AMP, pero lleva ahí unos meses sin mucho movimiento. Además, si la adopción de AMP en apps de terceros sigue, el número de usuarios por dispositivo móvil puede crecer todavía más.
ACTUALIZACIÓN (02/03/2017): Google es completamente consciente del problema y está tratando de encontrar una solución (aunque no es fácil)
Lecturas adicionales (en inglés):
- Accelerated Mobile Pages via Google Tag Manager
- What’s Going On With AMP Analytics?
- How To Set Up Adjusted Bounce Rate on Accelerated Mobile Pages (AMP) Using Google Tag Manager
Espero que el post te haya sido útil. Si es así, compártelo! :)