3rd party scripts, ¿caballos de Troya?

Una de las tareas con las que el analista se puede encontrar consiste en validar y comprobar los valores que el código o snippet javacript dispara para generar los datos de navegación del sitio web que analiza.
Esta verificación es clave en el momento de implantación de una herramienta de analítica web, ya que hay que revisar el etiquetado y asegurar que los diferentes ítems de información que va a recoger la herramienta de analítica web (variables, eventos… etc), contienen los valores esperados, y también para realizar tareas de “debugging” o detección y depuración de errores que se descubren en descuadres de datos en los informes, entonces hay que revisar exhaustivamente los valores que se están generando durante la navegación para resolver estas incidencias y comprobar que el snippet esté funcionando correctamente, ya que procurar la precisión de los datos es muy importante al ser la materia prima con la que luego se generarán informes y se proveerá de conocimiento a negocio.

Existen varios complementos que asisten al analista en esta tarea de validación y “debugging” como son el debug de Chrome (no requiere instalar complementos adicionales, basta con pulsar F12 dentro del navegador), Httpfox, Charles, Wasp, Firebug, Google Analytics Debugger…,etc, que sirven para examinar las distintas llamadas que se ejecutan en el sitio web.

En este post se enumeran y explica el uso de algunos de estos complementos, y en esta entrada en concreto, se explica el funcionamiento de Adobe Digital Pulse.

Un complemento interesante para revisar rápidamente los distintos snippets instalados en una página web es el complemento “Ghostery”, que muestra un panel con los “rastreadores” javascript encontrados cada vez que se carga una página web, clasificando su naturaleza (analítica, publicidad, widgets… etc) y con el que es posible bloquear o permitir los rastreadores.
– Desde Chrome podéis instalarlo desde: Configuración > Extensiones > Obtener más extensiones
– En Firefox: Complementos > Buscar complementos.
Por ejemplo, en la página de goear.com Ghostery enumera 58 rastreadores distintos:

Goear

Clicando en el icono del fantasmita, se abre una panel para controlar los rastreadores, y clicando sobre ellos, poder examinar las URLs de origen de rastreador detectadas donde se detallan los .js que ejecutan, este es el aspecto inspeccionando Dropbox.com:

dropbox

Examinando las distintas llamadas que muestra Ghostery, puede sorprender la existencia de una serie de rastreadores cuyos códigos javascript no se han etiquetado directamente en el código HTML ni han sido incluidos en el tag manager que utilicemos para gobernar las etiquetas del sitio web, en este caso estamos ante peticiones o “request” de 3rd Party content.

Tener peticiones y contenido de tercera parte supone una serie de implicaciones  técnicas y de seguridad, cuestiones en las que un perfil técnico podría profundizar más, por lo que aquí me gustaría enumerar algunos efectos que considero que es importante tener en cuenta como analista:

1.- Impacto en el “performance” de la web

Si el contenido de tercera parte supone que se ejecuten muchas peticiones, este contenido se encuentra alojado en servidores lejanos, se podría incurrir en un retardo de latencia considerable ya que estas peticiones requieren de más tiempo en resolverse,  y/o producen errores y si además están colocadas antes del evento “onload” (que se activa cuando se termina de cargar la página), tenemos todas las papeletas para que el tiempo de carga de la página se vea afectado, perjudicando la indexación de Google (que favorece a los sitios rápidos), empeorando además la experiencia de navegación de los usuarios, ya que la lentitud de carga en página es uno de los principales motivos de abandono.
Este estudio de TagMan (ahora Ensighten) demostró que 1 segundo de retardo en carga de página, provoca un caída de un 7% en las conversiones, de un 11% en las visualizaciones de página y hasta un 16% de pérdida de satisfacción del cliente, así que hablando en términos monetarios, si tu página web ingresa 100.000 euros al día, las pérdidas anuales motivadas por este fenómeno podrían ascender a 2,5 millones de euros en las ventas, por tanto, es un asunto a tomar en consideración y por el que merece la pena aplicar técnicas de WPO (Web Performance Optimization) para mejorar estos inconvenientes.

TOOLSET

HTTPArchive: Existen varias utilidades que permiten monitorizar los tiempos de carga y cuáles son los elementos de la página que más tiempo consumen, una de ellas es httparchive, un archivo histórico que almacena “screenshots” no solo del contenido de nuestra web (tipo web.archive.org), sino que se almacenan históricos de interesantísimas estadísticas de performance de una web como son el tamaño de las páginas, diagramas de Gantt (o HTTP waterfall) de los requests, una enumeración de las peticiones exportable en .CSV, si se detectan CDNs (un “content delivery network” o red de entrega de contenidos tipo Akamai, que aceleran cómo se sirve el contenido de una web).

httparchive

Existe otra utilidad por la que es posible comparar dos periodos distintos para ver la evolución que han tenido las estadísticas tanto en tiempos de carga de todos los elementos, como las distintas tipologías de peticiones y el tamaño del contenido en bytes.

TimmingsrequestsBytes

Webpagetest es un proyecto de código abierto desarrollado y apoyado por Google, con el objetivo de hacer la world wide web más rápida.

Esta herramienta permite lanzar un test sobre una página web y como resultado se obtienen unas estadísticas de rendimiento muy completas, navegando por la barra de menú, en “Details” se incluyen detalles de tiempos de carga con vistas de Waterfall que muestra cómo se distribuye la carga de elementos y scripts, el DOM del documento, el evento onload hasta la carga del documento completo.

waterfall_webpagetest

En “Performance Review” encontramos una ficha completa “Full Optimization Checklist” que muestra si el servicio del contenido está acelerado por el uso de un CDN, y en el apartado “Content breakdown” es posible hacer un split de contenido del sitio web y dominios que sirven contenido, donde se muestra en un gráfico de tarta la distribución de las peticiones por dominios y por el que podemos encontrar sorprendentes cifras como esta de Goear, donde solo el 15,6% del contenido corresponde a goear.com, el casi 85% restante de las peticiones son realizadas por terceros:

contentbymimetype_webpagetest contentbydomain_webpagetest

Merece la pena “cacharrear” con ambas herramientas y revisar las cifras que muestran para hacer un diagnóstico del performance de la web que deseemos analizar, además no debemos dejar de utilizar los informes de velocidad del sitio que nos proporcione la herramienta de analítica web con la que trabajemos, ya que nos darán buena cuenta de cómo los usuarios interactúan con el contenido de nuestro sitio web y con qué rapidez lo consiguen, aquí encontraréis una descripción de estos informes en el caso de Google Analytics.

VelocidadGA

2.- Escucha de la actividad

Cada vez con más frecuencia, acciones de captación de upper funnel, como display, afiliación y también retargeting, remarketing… requieren un tracking más sofisticado más allá del sencillo pixel de imagen de tamaño 1×1, ya que si se aplican tácticas de retargeting es necesario contar con información de la actividad inacabada de las sesiones de los usuarios que no lograron concluir la compra, para poder volver a impactarles con información personalizada en aras de lograr la ansiada conversión.

El problema que surge aquí es que estos pixeles ya no son una imagen, sino un script que ejecuta código a través de un funcionamiento que no está bajo nuestro control, ya que se trata de snipets que hacen referencia a contenedores (una especie de Tag Manager de pixeles) que son administrados por un proveedor externo, que en función de la configuración de la campaña, hace que salten unos u otros pixeles.

Esta configuración ajena puede hacer que se ejecute el javascript de muchos píxeles de terceros, de los que no podemos controlar ni su número ni su duración, y de los que la página web sufrirá en el performance si estos disparos de píxeles de terceros dan error, con el consiguiente perjuicio de retardo de carga comentado anteriormente.
Pero lo más desconcertante es que un pixel de estas características puede ejecutar la carga de un javascript que a través de muchas líneas de código, poder hacer una escucha silenciosa de la actividad del sitio web alimentando parámetros de conversión por ejemplo.

3.- Riesgos de seguridad

En la mayoría de las ocasiones, los sitios web no son conscientes de que con estos píxeles que ejecutan scripts se está abriendo una puerta de entrada a un “caballo de troya”, que además de ralentizar el performance de la web, esta se expone a escucha de la actividad de la web en función del código JS que se ejecute en el cliente, y si esto no está controlado y no existe buena fe, nos podríamos enfrentar a riesgos de seguridad del estilo de lo que en el mundo de la seguridad se conoce como un XSS (Cross Site Scripting), ataque por el que se trata de inyectar un código JavaScript malicioso en una página.

Por tanto, es muy recomendable revisar estos puntos, acotar los disparos de píxeles de 3rd party content con los proveedores para no ver penalizado el performance, revisar qué scripts se ejecutan y con qué objetivo y no dejar al azar la seguridad del sitio web, para no dejar fuera de nuestro control todas estas cuestiones importantes, revisando los acuerdos con los proveedores para exigir una conducta profesional y unas prácticas éticas que no vean comprometida la actividad de la página web, tal y como recomienda la DAA (Digital Analytics Association) en su código de buenas prácticas.

¿Os atrevéis a inspeccionar páginas web y descubrir esta interesante cuestión?.

 

Gema Mora

Analista en importantes compañías como Carrefour, Vocento e Iberia, donde ejerce en esta última como Responsable de Analítica Digital y colabora como docente en varias Escuelas de Negocio.
Gema tiene estudios de Diplomatura en Informática por la Universidad Politécnica de Madrid, es Master Executive en Relational Marketing, CRM and e-Commerce por ESIC-ICEMD y posee el Award of Achievement in Web Analytics por la Universidad British Columbia.

Twitter LinkedIn 

Hecho con cariño desde Madrid por las Madrid Geek Girls.