¿Por qué mis páginas de AMP tienen un porcentaje de rebote tan alto?

(You can also read this article in English here)

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.

Las métricas de comportamiento para AMP son mucho peores. ¿Por qué?

 

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.

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.

Qué es AMP

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.

Ejemplo de acceso a página AMP desde los resultados de búsqueda de Google

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.

Div que alberga contenido AMP en SERP
Ese div es el que va a albergar el contenido de los resultados AMP si pinchamos en alguno

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á.

iframe con contenido de AMP
El contenido se carga dentro de un iFrame, que apunta a la URL de la caché de Google AMP

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”

Elementos LI en Top News AMP de Google
Cada elemento del carrusel de “Noticias destacadas” tiene su propio elemento li para albergar su contenido con un iFrame

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)

Link interno AMP
Si pinchamos en algún link interno (o externo) dentro del contenido de AMP, este nos lleva fuera de Google

 

Carga de página enlazada desde AMP
Y la página enlazada se sirve ya en su versión “normal” (no-AMP)

¿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

Página AMP servida desde Google
La página se sirve desde google.es, a través del dominio caché de Google para AMP (cnd.ampproject.org). No hay ninguna petición al dominio original (randomtrip.es)

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:

ClientId común (guardado en cookie _ga) para esta web

Info enviada a Google Analytics al acceder a la web
Al acceder de forma directa, el comportamiento de Google Analytics es el “normal”. Se genera un cliendID que se guarda en la cookie _ga y se envía a los servidores de GA

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):

Cookie generada para página AMP, en un mismo dominoi

Información enviada a Google Analytics al acceder a una página AMP.
Aunque estamos en el mismo dominio (randomtrip.es) y ya existe una cookie (_ga), el JS de Analytics en AMP utiliza una cookie diferente, y para Analytics somos dos usuarios diferentes.

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:

Cid asignado al acceder a AMP desde Google
Datos enviados a Google Analytics al acceder a página AMP desde búsqueda en Google
Al acceder a este resultado AMP desde los resultados de búsqueda de Google, este es el clientID que se envía a Google Analytics, diferente a los dos primeros para la misma web.

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:

ClientID al acceder directamente a la cdn de Google para AMP

Información enviada a Google Analytics al acceder directamente a la CDN de AMP de Google
Este sería nuestro 4º clientID para la misma web!

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):

ClientID al acceder a la URL de Google para AMP directamente

Información enviada a Google Analytics al acceder directamente a la URL propia que genera desde el SERP.
En este caso, estamos accediendo a un entorno en el que ya existe un cliendId anterior, por lo que se utiliza ese y somos el mismo usuario que antes.

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.

AMP en la App de Linkedin
En la app de LinkedIn, los contenidos AMP se cargan directamente desde la URL de la caché de Google

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:

Cookie generada para página AMP, en un mismo dominoi Cid asignado al acceder a AMP desde Google ClientId común (guardado en cookie _ga) para esta web ClientID al acceder directamente a la cdn de Google para AMP

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.)


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):


Espero que el post te haya sido útil. Si es así, compártelo! :)

28 comentarios en “¿Por qué mis páginas de AMP tienen un porcentaje de rebote tan alto?

  1. Muy buen post, muchas gracias por compartirlo Christian!

    No conocía tu @randomtrip_es y me ha flipado lo bien que te lo has sabido montar!!! Por casualidad hoy se está celebrando el DNX Buenos Aires, estaba ya con los dientes largos…y tus viajes aún me los ha puesto más, por envidia sana ;)

    Un saludo desde España

    1. Me alegra que te haya gustado, Iván! :)

      Sí, la verdad es que lxs de este mundillo somos privilegiadxs por tener más facilidades para cambiar a este estilo de vida. Llevamos 5 meses y la verdad es que muy bien!

      Saludos desde Tailandia!

  2. Hola, yo también he experimentado una subida del rebote, te doy datos:

    La media de la web era del 26% y los datos de amp, con un rebote de más del 40%, han llevado a la web a un horrible 35% de media.

    Los datos son de una web que uso como laboratorio de posicionamiento SEO > http://tdt.gratis – 100.000 visitas y 300.000 páginas vistas mensuales, todas de posicionamiento en buscadores.

    Llevo 3 dias con AMP y ha subido el tráfico movil más del 40%, en principio muy positivo.

    El problema es que la publicidad de adsense carga muy lenta en relación al resto de la web y he notado una ligera bajada en los ingresos por publicidad, que en principio puede ser casualidad por las campañas pero no lo creo, suele ser estable en este tema.

    Saludos ;)

    1. Hola Daniel, muchas gracias por pasarte y comentar tu experiencia!

      La verdad es que es complicado encontrar un equilibrio entre todas las “patas”.

      Cuando dices que te ha aumentado el tráfico móvil, cómo sabes que es debido a AMP? De momento no debería afectar, o al menos no de forma tan brusca. Con un rebote tan bajo, ten en cuenta que las visitas que antes seguían el siguiente patrón:

      1. Busca en Google
      2. Pincha en resultado de tu web y consulta la información
      3. Sigue navegando por tu web hacia otras páginas

      Ahora se duplicarían (tanto usuarios como visitas) por lo que probablemente estés sufriendo este problema en una proporción mayor por tener un rebote tan bajo. Seguramente con el “aumento de tráfico” (probablemente ficticio por esto que te comento) hayan empeorado las métricas de comportamiento.

      Échale un ojo y ya me cuentas!

      1. Hola Christian, gracias por contestar :)

        La versión AMP de la web está en http://tdt.gratis/amp y se enlaza desde la versión móvil de la página inicial (la portadas de pc y móvil son independientes y no se decide por el ancho de pantalla, si no por el tipo de dispositivo).

        Como te decía en el primer comentario, esta web es para experimentar, pruebo nuevas técnicas y después se las transmito a mis clientes, así que en un primer momento seguí una guía de Google en la que decía que la web AMP debía estar en un enlace independiente, más tarde, con la guia oficial del proyecto, vi que se podía estar en el mismo enlace (lo habría hecho así de saberlo desde el principio).

        Bien, al estar en /amp veo el tráfico de entrada de ese enlace en especial y al mismo tiempo a los usuarios que pasan de la versión AMP a la web normal.

        Cómo obtengo el porcentaje de rebote:

        La versión /amp tiene un rebote mayor que la web móvil normal, aquí veo que es responsable directo de la subida general, en las últimas horas el enlace AMP y las visitas que llegan de ella han bajado a un 32% pero en la misma proporción que lo han hecho las otras versiones, por ejemplo la versión pc está en el 20%, seis puntos menos, la misma cantidad de bajada.

        También veo que la subida de tráfico móvil está provocada por un CTR mayor en los resultados de google sobre las mismas búsquedas (hoy tengo datos de Google Webmasters del día 1 de experimento)

        Para medirlo utilicé el filtro de dispositivos y tomé como referencia las palabras clave en las que está posicionada primera, ya que no varía nada, y en las palabras importantes en las que está en segunda o tercera posición para ver cambios.

        Estos datos destacan un aumento enorme de CTR móvil que no se reproduce en versión pc. También se ve en la diferencia entre dispositivos de analytics (la web es mucho más popular en pc que en móviles porque funcionan de manera diferente)

        De dónde sale este 40% de subida móvil:

        – Antes de AMP el tráfico móvil era igual al 35% de las visitas/usuarios totales de versión Pc
        – Después de AMP el tráfico móvil es igual al 49% de las visitas/usuarios totales de versión Pc

        Me explico: por cada 1000 visitas de pc tenía 350 de teléfonos móviles y ahora son 490 (datos basados en las 8.000 visitas de los últimos 2 días)

        Así deduzco que el tráfico móvil ha aumentado, independientemente del que el tráfico general sea mayor o menor, ya que utilizó el tráfico de PC como referencia de control.

        Los 14 puntos de diferencia en el tráfico móvil son el 40% de ese 35% estimado, por lo que se confirma la subida de un 40% en relación a si mismo.

        Las correspondientes al primer día vienen de ese aumento de CTR de teléfonos móviles y no de mejores posiciones en SEO (por ahora)

        La verdad es que el objetivo de este experimento era saber cómo afectaba al posicionamiento y me llevo una grata sorpresa al comprobar que los usuarios hacen clic en una tercera posición de resultado, que cuenta con versión AMP, antes que otras mejor posicionadas que no lo tienen.

        Sobre Adsense, la obligación de anuncios con un máximo de altura de 100px exigido y que los anuncios cargan más tarde que el resto de los contenidos si afecta a las conversiones (comparando la versión móvil estándar y la versión móvil AMP), por suerte la subida de tráfico lo compensa y ha vuelto a sus cifras normales, eso sí, necesita ese tráfico.

        Sí AMP no aumenta el tráfico móvil se nota y mucho en conversiones por publicidad Adsense, supongo que esto mejorará con el tiempo según los anunciantes se vayan acostumbrando a este nuevo formato y mejoren la estética de banners. Esperemos que sean antes de que AMP se normalice y perdamos el plus de competencia.

        Saludos ;)

        1. Gracias por la explicación, Daniel.

          Tres cosas:
          – Podrías pasar datos del incremento de CTR? Me parece muy interesante
          – El % rebote, ten en cuenta que está erróneo.
          – El tráfico móvil, aunque haya subido por el CTR como comentas, también está mal en un %, por lo que explico en este post.

  3. Muchas gracias Christian! extraordinario y muy claro el artículo, AMP es un gran desconocido y además siempre es relevante tomar recaudos porque estamos “cediendo bastante”.

    Un saludo desde Sevilla!

  4. Mil gracias Christian por este pedazo de post explicativo. Nosotros en “El Confidencial” llevamos tiempo trabajando en ello, porque el incremento desvirtuado de usuarios únicos (a raíz de la implementación de AMP) con nuestras respectivas herramientas de medición era muy significativo y preocupante por la parte de medición, y más teniendo en cuenta el análisis cada vez más enfocado al comportamiento de usuario.
    Aún estamos en ello, pero cuando lo consigamos solucionar estaré encantada de compartirlo! :)

    Un saludo!

  5. Hola Christian, te felicito por este brillante post, otorga interesantes conclusiones para analítica web. Tengo una consulta y me parece que puede ir relacionada con tu post. El mes pasado hice unas campañas en Search, Display y Facebook Ads dirigidas a unos landings (con responsive design), revisando el reporte de adquisición de Analytics encontré un grupo muy alto en el canal Direct, más alto incluso que lo que reportaba Social, Adwords y Display y con un porcentaje de conversión del 40% en promedio. La consulta es si existe la posibilidad de que estos usuarios que pasan por tráfico AMP están pasando por Direct. Cualquier aporte será bien valorado. Un fuerte abrazo.

    1. Hola Pedro, muchas gracias por comentar!

      No creo, es muy raro eso que comentas. Esas landings, tienen versión AMP? A qué páginas va dirigido el tráfico que está marcado como Direct? Deberías revisar eso primero. En Direct ya sabes que entra todo lo que no se puede identificar, así que pueden ser mil cosas. Alguna de las campañas de pago no iba bien marcada?

  6. Buenas,

    Para evitar duplicar visitas con AMP.

    ¿Se podría usar la Lista de Exclusion de Rerencia de Google Analytics añadiendo AMP como referral?

    Con la exclusion consigues que te contabilice como una sola sesión, por lo tanto eliminas el referral y mantienes el organic como fuente.

    1. Hola Raúl, y gracias por pasarte a comentar!

      Me temo que esa solución no serviría, porque como puedes ver en el post, el problema de fondo viene de que las cookies de usuario de ambos escenarios son diferentes, y por lo tanto Google no puede “casar” esa información entre ambas sesiones.

      De todas formas, Google lanzó en Septiembre una solución (aunque de momento sólo para google.com). La he probado y funciona, así que pronto escribiré sobre ella. De momento puedes ir leyendo la documentación en https://support.google.com/analytics/answer/7486764?hl=en

      Cualquier cosa me dices

Deja un comentario