comScore Mobile Metrix, U.S., Edad 18+, Junio 2017

A menudo, la creatividad del marketing se encuentra con limitaciones técnicas. Una página web puede cargar muy rápido. UX está limitado por los navegadores. Las soluciones de vanguardia sólo son accesibles para aquellos con grandes presupuestos.

Las aplicaciones nativas resuelven algunos de estos problemas pero conllevan sus propios costes de desarrollo, irregularidades en la plataforma, requisitos de descarga, necesidades de actualización y problemas de indexación de las búsquedas.

Los sitios para móviles reciben más visitantes, pero las aplicaciones tienen mejores resultados en cuanto a compromiso y tasas de conversión:

Las Aplicaciones Web Progresivas (PWAs) tienen el potencial de combinar el alcance móvil con la participación de aplicaciones nativas. Pero pocos profesionales del marketing saben en qué se están metiendo cuando siguen ese camino o deciden no hacerlo

Esa ignorancia es cara. Las decisiones relacionadas con el rediseño de los sitios suelen ser las más costosas y menos reversibles que toman los profesionales de marketing. Tomemos como ejemplo a Hertz: Ahora están demandando a su socio de marketing, Accenture, por 32 millones de dólares después de una revisión chapucera del sitio y la aplicación.

Cuando se trata de rediseños, usted puede ser el único que toma decisiones. Puedes ser simplemente una voz en la sala. En cualquier caso, usted necesita ver más allá de los objetos brillantes en las propuestas de diseño web y saber cómo la tecnología PWA le ayudará (o no) a alcanzar sus objetivos de marketing.

Este post ofrece conocimientos técnicos básicos sobre PWAs y se centra en aspectos -como UX, SEO y análisis- que más afectan a los equipos de marketing.

¿Qué son los PWAs?

Nacidos de las cuestiones destacadas anteriormente, los PWAs son-por Alex Russel, quien acuñó el término-«sitios web que tomaron todas las vitaminas adecuadas». Hecho posible por los navegadores modernos, los PWAs permiten una experiencia similar a la de una aplicación dentro de un navegador normal, mientras que evitan las dificultades de las aplicaciones nativas.

En otras palabras, los PWAs intentan combinar lo mejor de la web y las aplicaciones:

• Velocidades de carga rapidísimas, sin descargas voluminosas y actualizaciones constantes;
• Indexabilidad optimizada, sin sacrificar los beneficios UX de las aplicaciones nativas;
• Desplegable en todos los mercados de aplicaciones, sin requerir diferentes bases de código;
• Alcance ampliado mediante un menor uso de datos, sin reducir el rendimiento;
• Accesibilidad mejorada mediante la eliminación de las descargas y la compra de aplicaciones;
• Navegación web fuera de línea, acceso web a hardware móvil, vinculación…

Gartner ha predicho que las PWAs sustituirán el 50% de las aplicaciones móviles en 2020. Varios titanes digitales -Twitter, Forbes, Uber, Alibaba, AliExpress- ya se han cambiado a las PWAs, y hay una creciente colección de casos de estudio que muestran el efecto positivo de las PWAs en los KPI de marketing: conversiones, ingresos, tiempo dedicado, compromiso, re-compromiso, clientes potenciales, etc.

Consulte cualquiera de estos sitios en su dispositivo móvil para experimentar una PWA de primera mano:

1. Pida un café Starbucks.
2. Juega al juego 2048 en tu navegador.
3. Planifica tu viaje con MakeMyTrip.
4. Navega por una tienda de comercio electrónico de moda (demo).

Puede parecer que los PWAs son el sueño de todo profesional del marketing digital, pero existen importantes retos, que abordaremos en breve. Primero, sin embargo, vamos a sumergirnos en lo que hace que los PWAs funcionen.

¿Cómo funcionan los PWAs?

La web está llena de explicaciones reformuladas, así que en lugar de derramar más tinta, aquí está una de las mejores:

Una Aplicación Web Progresiva es una aplicación de software, escrita en la plataforma web y ejecutándose en el navegador, que se comporta como una aplicación nativa entregada en la nube.

Es una aplicación porque instala y ejecuta el código en el dispositivo u ordenador del comprador, con más velocidad y capacidad que las «aplicaciones JavaScript de una sola página» del pasado.

Es web porque está escrita en los lenguajes de la Web-HTML, CSS y JavaScript-en lugar de en algún lenguaje específico del dominio o en un marco de trabajo nativo cautivo de una plataforma.

Y es progresivo porque se carga por sí mismo, junto con cualquier dato y activo relevante, a medida que el usuario navega por su tienda.

¿Son los PWAs compatibles con la mayoría de los navegadores?

La compatibilidad con los navegadores modernos de características como las notificaciones push y el guardado de la pantalla de inicio es parte integral de los PWAs. Los PWAs requieren que los navegadores soporten a los «trabajadores de servicio» (más abajo), lo que hacen casi todos los navegadores modernos. (Safari, que con frecuencia se queda atrás, suele denominarse «el Internet Explorer de los PWAs»)

Pero la falta de soporte para características específicas no impide el uso de los PWA. Dado que los PWAs son sitios web, seguirán funcionando en todos los navegadores (sólo que sin todas las funciones).

¿Por qué los «trabajadores de servicio» son esenciales para los PWAs

Un sitio web que envía notificaciones push cuando no estás interactuando con tu teléfono? ¿Navegar por Internet cuando no tienes una conexión? Esto (y más) es posible gracias al trabajador del servicio. Pero, ¿qué es?

Matt Gaunt de Google definió al trabajador de servicio:

Un trabajador de servicio es un script que su navegador ejecuta en segundo plano, separado de una página web, abriendo la puerta a características que no necesitan una página web o la interacción del usuario.

Todos sabemos cómo funciona un sitio web: la base de código se almacena en un servidor, y cualquier persona puede acceder a ella a través de su navegador tecleando el nombre de dominio o la dirección IP directa.

Cuando se trata de PWAs, hay un elemento adicional: el trabajador de servicio. Reside entre el servidor y el navegador, añadiendo una nueva capa de funcionalidad en segundo plano para imitar las características de las aplicaciones (por ejemplo Mientras que la navegación web tradicional consiste en la interacción directa entre el usuario y el servidor, el trabajador de servicio permite una interacción indirecta :

En esencia, un trabajador de servicio es un archivo JavaScript del lado del cliente que se agrega a su base de código. (Si quieres una explicación más profunda y técnica, consulta esta charla de la comunidad de desarrolladores de Google Chrome)

La magia y las limitaciones del almacenamiento en caché

El trabajador de servicio también es un elemento crucial para el rendimiento del PWA que depende del almacenamiento en caché. Los PWAs dan a los desarrolladores un control sin precedentes sobre lo que se almacena y no se almacena en el dispositivo del usuario.

Hay una advertencia: En la primera carga, los usuarios no se beneficiarán de la «magia del cacheo» que es responsable de los tiempos de carga subsiguientes y rápidos. Los PWAs pueden servir un pequeño documento de shell con recursos en línea para dar la impresión de una primera carga rápida, durante la cual se instala el Service Worker.

Aunque esto puede mejorar ligeramente la experiencia del primer contacto, los PWAs todavía tienen que proporcionar velocidades instantáneas de inmediato. Ahí es donde entran en juego las Páginas Móviles Aceleradas (AMP).

AMP para la adquisición, PWAs para el compromiso

Los AMPs son páginas HTML ligeras diseñadas para cargarse lo más rápido posible. Los AMPs se usan principalmente para páginas estáticas (por ejemplo, sitios de noticias) en lugar de las páginas más dinámicas que se encuentran, por ejemplo, en los sitios de comercio electrónico.

Google integró AMP en sus resultados de búsqueda para móviles en 2016, y las páginas que utilizan AMP están intrínsecamente priorizadas en los resultados de búsqueda, marcadas con una insignia de «AMP»:

Para sitios web complejos con muchos elementos dinámicos, se puede combinar PWA y AMP para obtener lo mejor de cada plataforma.

PWA enriquece las experiencias y el compromiso del usuario a través de características como las notificaciones push, mientras que AMP puede ser integrado en páginas estáticas como la página principal y las entradas del blog.

Tokopedia -la plataforma de mercado más grande de Indonesia- construyó versiones de AMP de sus tres principales tipos de páginas de aterrizaje orgánicas: producto, categoría y tendencia. Esto creó 3.6 millones de páginas AMP para la búsqueda orgánica, su mayor embudo de descubrimiento de productos. Las páginas de AMP luego hicieron la transición de los usuarios a un PWA para asegurar velocidades consistentes y una gran UX.

Armados con un entendimiento de cómo funcionan los PWAs, vamos a sumergirnos en los resultados de la implementación de la tecnología.

El impacto de los PWAs en el rendimiento, UX, y accesibilidad

El beneficio del rendimiento de un PWA

Las primeras impresiones importan. Y la primera experiencia que los visitantes tienen con su sitio no es ni el diseño ni el contenido. Es el tiempo de carga de la página. El viaje de usuario más pulido no significa nada si no puedes llevar a tus visitantes a la línea de salida. Y en los móviles, un 53% de los visitantes abandonan una página que tarda más de 3 segundos en cargarse.

Los PWAs reducen el peso de las solicitudes de datos a una fracción de su nivel actual. Los adoptadores de PWA comúnmente citan hasta un 300% de mejora en el rendimiento. En el caso de los sitios que ya están optimizados en cuanto a velocidad, esto puede llevar a velocidades de carga casi instantáneas, similares a las de las aplicaciones nativas.

Incluso sin integrar AMP, los PWAs ayudan con la carga de la primera página priorizando la primera pintura significativa y sirviendo un documento de shell ligero con recursos en línea.

UX beneficios de los PWAs

Históricamente, las aplicaciones nativas superaban a los sitios web móviles en términos de compromiso del usuario. Las PWAs pueden cerrar esa brecha con las características reservadas anteriormente para las aplicaciones nativas, como la no recarga al cambiar de página. (Al diseñar un PWA, se recomienda proceder como si estuvieras diseñando una aplicación nativa, no una página web).

Los PWAs incluso superan a las aplicaciones nativas en algunos lugares, como en la eliminación de la fricción en la instalación de aplicaciones y en la disminución de las caídas de las instalaciones web a aplicaciones. A continuación se muestra un ejemplo de UX de un sitio web normal (izquierda) frente a un PWA (derecha):

He aquí otros siete beneficios de UX:

1. Ahorro en la pantalla de inicio

En un entorno cada vez más orientado a la movilidad, el bien inmueble digital más valioso es la pantalla de inicio del usuario, que anteriormente era propiedad casi exclusiva de las aplicaciones nativas. (Añadir sitios web a la pantalla de inicio, históricamente, ha sido un proceso de varios pasos. Chrome y otros navegadores modernos tienen ahora una función incorporada para guardar la pantalla de inicio con un solo toque.)

Una presencia en la pantalla de inicio pone su logotipo al frente y su sitio a un clic de distancia.

2. Notificaciones push

El trabajador del servicio hace posible las notificaciones push para su sitio web móvil. Beyond the Rack ha conseguido un incremento medio del 26% en el gasto y un 72% más de tiempo de permanencia en su PWA de los usuarios que lo visitan mediante notificaciones push. Carnival Cruise Line alcanzó una tasa de compromiso del 42% con sus notificaciones push.

Lanzar campañas de marketing, informar sobre el progreso de los pedidos, noticias de la marca – es un canal de comunicación único para ayudar a que su marca forme parte de la de sus usuarios cada día (suponiendo que utilice ese poder de forma inteligente).

3. Modo offline

«El modo offline» no es una experiencia offline completamente nativa (aunque podría ser posible- con un gran coste para UX). El trabajador del servicio puede anular la gestión de la caché del navegador estándar con reglas personalizadas, y el almacenamiento de la caché es independiente del servidor remoto.

Esto significa que, una vez que su conexión se cae, es posible continuar la navegación a través del trabajador del servicio. Imagine que está navegando por su tienda de ropa favorita mientras se desplaza por el metro de ondon o por una zona rural con cobertura irregular.

Cuando pulsa el botón de retroceso, en lugar de ver un error 404, el trabajador del servicio entrega una página en caché con los datos previamente recuperados. El modo offline es, efectivamente, a prueba de fallos.

(Técnicamente, es incluso posible hacer la comprobación fuera de línea; sin embargo, el pedido se procesaría después de restablecerse la conexión.)

4. Desplegable a app stores

Tener su aplicación listada en app stores es valioso. Es una de las razones por las que muchas empresas invierten en el desarrollo de aplicaciones nativas (costosas) para iOS y Android. Las PWAs pueden evitar esa necesidad.

Gracias a tecnologías como Trusted Web Activity, que envuelve una pestaña web en una aplicación, puedes convertir cualquier aplicación web progresiva en una aplicación nativa en pocas horas. (Sigue habiendo una única base de código: la aplicación nativa es parcialmente una vista web).

Es posible implementarla tanto en Apple App Store como en Google Play Store sin necesidad de desarrollar una aplicación nativa desde cero.

5. Actualizaciones automáticas

Las actualizaciones son una tarea para los usuarios y una responsabilidad para todos los implicados. Las PWAs no las requieren, actualizándose activamente en tiempo real, como un sitio web.

6. Agnosticismo de la plataforma

Cada plataforma tiene ventajas y desventajas, dejándole la poco envidiable tarea de superar las limitaciones específicas de la plataforma.

Las aplicaciones agnósticas de la plataforma son una alternativa eficiente a la construcción y mantenimiento de aplicaciones nativas separadas para iOS, Android y la web. Los PWAs proporcionan la misma experiencia de usuario a casi todo el mundo (dependiendo de la preparación de los navegadores para el soporte de los trabajadores de servicio).

7. Vinculación e indexación

Como con cualquier sitio web, los PWAs tienen URLs y pueden ser rastreados e indexados por los motores de búsqueda. A diferencia de las aplicaciones nativas, los usuarios pueden encontrar las páginas de los PWA directamente en las SERP. Los tiempos de carga más rápidos mantienen a los motores de búsqueda y a los usuarios contentos.

Accesibilidad

Los rápidos tiempos de carga de los PWA permiten la accesibilidad para las empresas que operan en mercados emergentes o que necesitan proporcionar a los usuarios un acceso al sitio consistente en todo momento.

Por ejemplo, la rápida expansión de Uber en nuevos mercados exigió una aplicación rápida y agnóstica a los dispositivos que funcionara bien independientemente de la ubicación. Por lo tanto, optaron por un PWA.

Las peticiones llegaron a sólo 50kb, permitiendo que el PWA se cargara en menos de 3 segundos en redes 2G.

Estos beneficios vienen de la mano de algunos retos importantes.

3 Desafíos del PWA que afectan a los comercializadores

Mientras que un PWA puede significar una interfaz de usuario familiar y una curva de aprendizaje plana para los usuarios, existen diferencias significativas en el backend, que afectan a los desarrolladores y comercializadores.

Hay tres cosas que hay que tener en cuenta:

1. Es fácil romper el SEO.
2. Los análisis de PWA son difíciles de configurar y gestionar.
3. Tu equipo de desarrollo puede no estar preparado para PWA.

1. Es fácil romper el SEO.

Hay conceptos erróneos sobre los PWAs y el SEO. El más popular afirma que «Google prioriza las páginas de PWA en sus resultados de búsqueda». Esto es falso.

A Google no le importan las PWAs, pero sí le importan los tiempos rápidos de carga, que también influyen en el comportamiento de los usuarios (y, a su vez, envían señales a Google). En otras palabras, simplemente tener un PWA won‘no te ayuda con el SEO, pero tener un good PWA puede.

Hay otros conceptos erróneos-y retos-cuando se trata de PWAs y SEO.

¿Por qué el SEO es un reto?

Los PWAs son sitios basados en JavaScript. La mecánica de renderizado de los PWAs difiere de la de los sitios web estándar basados en HTML. Para entender la diferencia entre los dos enfoques, es necesario entender el renderizado del lado del servidor y del lado del cliente:

• Los sitios web estándar utilizan un método de renderizado tradicional llamado Server-Side Rendering (SSR). Con SSR, el contenido completo de una página se renderiza previamente en el lado del servidor y se pasa cada vez que un usuario solicita una página. Por lo tanto, cada vez que un usuario visita una nueva página, la página completa se descarga, incluso si la diferencia entre las dos es mínima.
• Los sitios web basados en JavaScripts utilizan el renderizado del lado del cliente (CSR). La CSR renderiza un sitio web en el navegador de un usuario, de ahí el nombre. El usuario recibe un pequeño archivo JavaScript en lugar de un gran archivo HTML, y el navegador sólo solicita los elementos necesarios cuando cambia de página o carga contenido adicional. Esto es lo que hace que los sitios basados en JavaScript se carguen rápidamente.

CSR es superior desde la perspectiva de UX pero más complicado cuando se trata de SEO. Usted confía en los motores de búsqueda para mostrar su sitio web basado en JavaScript correctamente.

Por lo general, cuando un robot de un motor de búsqueda descubre una página, rastrea el código fuente de la página (es decir, HTML) y eventualmente indexa toda la información disponible. Esto es fácil para los sitios web con mucho HTML, ya que la mayor parte del contenido que buscan los rastreadores está disponible inmediatamente. Pero como los PWAs normalmente sólo tienen JavaScript en el código fuente, crea una capa añadida para que los motores de búsqueda la analicen.

Los motores de búsqueda recuperan el contenido de los sitios basados en JavaScript en oleadas. Durante la primera oleada de indexación, los motores de búsqueda rastrean su página e indexan sólo el contenido que no es de JavaScript. A medida que los recursos de renderización de un motor de búsqueda están disponibles, los rastreadores vuelven a su página para finalizar el proceso.

Dado que se trata de un proceso que requiere muchos recursos, incluso para Google, puede tardar varios días más en indexar el contenido. Para muchas empresas web, especialmente para los sitios de noticias, la velocidad de indexación de contenido es crucial. Esto también puede afectar a los sitios de comercio electrónico que tienen, por ejemplo, campañas de marketing con ofertas limitadas en el tiempo.

Hay una solución, pero es inestable.

Hay varias soluciones alternativas. El Renderizado Dinámico, por ejemplo, es el método recomendado por Google. Con Dynamic Rendering, se combinan ambos métodos de renderización: Los bots de los motores de búsqueda obtienen la versión SSR; los usuarios humanos obtienen la versión CSR.

(¿Esto cuenta como «cloaking», una técnica común de SEO de sombrero negro para servir contenido diferente a los motores de búsqueda vs. los usuarios? De acuerdo con Google, No.)

Los motores de búsqueda, especialmente Google, han elogiado la tecnología PWA, pero hay poca comprensión de la preparación de los motores de búsqueda para manejar sitios JavaScript. Como Google admitió:

Actualmente, es difícil procesar JavaScript y no todos los rastreadores de los motores de búsqueda son capaces de procesarlo con éxito o inmediatamente.

Otros motores de búsqueda líderes, como Bing y Yandex, no garantizan la correcta indexación de los sitios web basados en JavaScript.

Las mejores prácticas de SEO permanecen sin cambios

Dado que PWA no es un factor de clasificación, todas las mejores prácticas técnicas, de SEO en el sitio y fuera del sitio se aplican a PWAs también. Aquí tienes algunos de los sospechosos habituales de SEO que debes tener en cuenta si estás migrando tu sitio a un PWA:

1. Implementa canónicas auto-referentes para páginas únicas y canoniza los duplicados o establece los meta robots a «noindex, nofollow». (Esto es especialmente importante si está combinando PWA y AMP.)
2. Cada página debe tener una URL única.
3. Asegúrese de que las arañas pueden acceder a contenido valioso oculto en pestañas, desplazamiento infinito, etc. Si quiere que las arañas exploren el contenido detrás de los botones, imágenes, etc.., utilice un vínculo HTML.
4. Utilice el marcado de Schema.org para ayudar a los rastreadores a comprender el contenido de la página y el marcado Open Graph para que las URL se compartan de forma adecuada en los medios sociales.
5. No muestres a los usuarios un contenido diferente al que muestras a Google (salvo la advertencia anterior).
6. Asegúrate de que tu página supere la prueba de compatibilidad con Google para móviles.
7. Audita las páginas para comprobar la velocidad de Google PageSpeed Insights.

2. La implementación de Analytics es compleja

Digamos, por ejemplo, que has implementado la navegación y el pago sin conexión en tu PWA. ¿Cómo harán tus scripts de análisis y de marketing de terceros para rastrear esos eventos?

El principal desafío para el rastreo de datos en un PWA es el ecosistema híbrido de aplicaciones web. Dado que un PWA es un sitio web (lanzado de una manera ligeramente diferente), las herramientas de seguimiento estándar como Google Analytics pueden funcionar.

Seguimiento de vista de página estándar

Un PWA emplea marcos de JavaScript como Angular o React, lo que significa que el seguimiento de vista de página estándar no funcionará correctamente. Por ejemplo, la API de Historial ofrece a los desarrolladores la posibilidad de modificar la URL de un sitio web sin necesidad de actualizar toda la página.

Debido a que los PWAs cargan el contenido de la nueva página de forma dinámica, el código de análisis se dispara sólo una vez. Así que, ¿cómo puede hacer un seguimiento del comportamiento de los usuarios en cada página? Su implementación de PWA necesita un código de seguimiento ajustado para asegurar que las «vistas de páginas virtuales» se disparen en el momento adecuado.

La implementación del seguimiento con Google Tag Manager o directamente en el código requiere pruebas exhaustivas y cuidadosas para evitar problemas comunes:

• Desajustes entre las rutas/títulos de las páginas y el estado real de la aplicación;
• Las páginas vistas se dividen en varias URL;
• Las páginas vistas posteriores no son objeto de seguimiento.

La complejidad aumenta cuando se trata de comercio electrónico y otras implementaciones avanzadas de PWA. La secuencia de disparo de etiquetas y la capa de datos se enfrenta frecuentemente a obstáculos; el gobierno de la capa de datos es crítico.

Seguimiento de características únicas

¿Cómo se realiza el seguimiento de las características únicas de las notificaciones de PWAs-push, el modo offline, la pantalla add-to-home, etc.-en el análisis?

Eventos en la página

Los eventos en la página son la parte más simple. No hay ninguna diferencia en comparación con el seguimiento web normal.

Las acciones del usuario, como la suscripción a las notificaciones push o la pantalla de inicio, se pueden seguir fácilmente utilizando los métodos estándar de Google Analytics. Sólo tienes que enviar la información a la capa de datos para el evento personalizado que quieras rastrear.

Eventos del trabajador de servicio

Se hace más complicado cuando la funcionalidad es iniciada por el trabajador de servicio de tu PWA, como la notificación push en sí misma.

El trabajador de servicio de tu PWA se ejecuta fuera de la aplicación principal, lo que hace imposible acceder a la cola de Google Analytics y enviar datos sobre las notificaciones activadas por el PWA o los datos de navegación offline. En resumen, significa que no puedes seguir el comportamiento del trabajador de servicio a través de tu código de seguimiento habitual de Google Analytics. En su lugar, el trabajador de servicio debe enviar las visitas directamente a Google Analytics.

Esto es posible mediante el protocolo de medición, que evita el fragmento habitual de analytics.js para enviar los datos directamente desde el trabajador de servicio a una propiedad específica de Google Analytics.