Analítica web
Reflexiones sobre madurez digital, datos y tecnología

Server-side vs Client-side: ¿debo replantearme la estrategia de recolección y distribución de datos de mi organización?

Se lee en 3 minutos

Tras muchos años gestionando la recolección de los datos de nuestros activos digitales en el lado cliente (client-side), existe una tendencia a trasladar parte de estas funciones al lado servidor (server-side). ¿Qué ventajas nos ofrece esta arquitectura?, ¿debo plantearme un cambio de estrategia en mi organización? Para tratar de responder a estas preguntas, comencemos repasando las características de cada arquitectura:

Full client-side

La recolección y distribución de datos en el lado cliente ha sido la aproximación predominante durante los últimos años. Habitualmente, la recolección se centraliza en un data layer y la distribución corre a cargo de una librería específica (tag, SDK) para cada herramienta a la que enviamos datos. Estas librerías se gestionan desde un Tag Manager que también suele actuar sobre el data layer, lo que convierte a esta herramienta en pieza clave de esta arquitectura a la que voy a denominar full client-side.

fullclientside
Full client-side architecture

La ventaja con más peso, para que esta arquitectura haya sido la más utilizada durante mucho tiempo, es la agilidad y facilidad que tiene para introducir cambios, sobre todo en los entornos web. También en entornos web ha tenido mucho peso el uso de cookies de tercera parte para poder realizar seguimientos cross-domain.

En los contras podemos destacar el impacto en el rendimiento de las aplicaciones ya que implica cargar y ejecutar una librería por cada herramienta que deba recibir los datos, la dificultad para acceder a determinados datos sensibles desde el cliente o la falta de control sobre el código de terceros.

Full server-side

En este caso, los datos se recogen y envían a las distintas herramientas de nuestro stack desde los servidores de nuestros activos digitales. La ventaja principal de esta arquitectura es que aporta más seguridad y fiabilidad a los datos. Pero la mayor complejidad en su implementación, y que no permite recoger todas las interacciones del usuario, hace que su uso no esté muy extendido y se restrinja sólo a casos de uso en los que la fiabilidad del dato es crítica.

fullserverside
Full server-side architecture

Server-side delivery

Esta arquitectura introduce un cambio novedoso respecto a las dos anteriores: los datos se envían a un punto único, un hub que centraliza la recolección y  se encarga de distribuirlos al resto de herramientas. Esta distribución se realiza server-side (también se denomina cloud-delivery). El envío desde el activo digital hacía el hub se puede realizar desde el cliente (client-side) o desde el servidor (server-side):

serversidedelivery
Server-side delivery

Para desplegar esta arquitectura tenemos que introducir una nueva herramienta en la organización: el data hub (también llamado central hub, API hub o event gateway) lo que nos lleva a las preguntas con las que abrimos esta entrada: ¿qué ventajas me aporta?, ¿debo valorar una migración a esta arquitectura?

Al tratarse de una arquitectura híbrida que combina client-side y server-side nos permite sumar las ventajas de ambas aproximaciones sin tener ninguna de las desventajas.

  • Mejora de rendimiento de las aplicaciones, ya que permite eliminar muchas librerías de envío de datos al sustituirlas por cloud-delivery.
  • Ofrece mayor control de los datos enviados a cada herramienta sin perder agilidad para desplegar y validar cambios.
  • Minimiza esfuerzos en la recolección (sólo enviamos a una herramienta en vez de a “n”) y permite centrarse en recoger datos de más calidad y en más canales. Mención especial, en este apartado, para recolección de dispositivos IoT.
  • Facilita las labores de Data Quality, procesamiento y de enriquecimiento de datos en tiempo real.
  • Permite incorporar dato offline en formato batch de forma más eficiente. Al igual que en el caso del streaming, evitamos tener que hacer una carga por cada una de las herramientas.

Estas ventajas son razones de peso para plantearse esta arquitectura e introducir un data hub en nuestra organización. Más cuando existen en el mercado soluciones con un buen nivel de madurez y de fabricantes con garantías como Tealium EventStream y Segment Connections.

Pero esta arquitectura aporta una ventaja nueva que todavía no hemos mencionado y que desde mi punto de vista es diferencial:

Permite disponer de un dato unificado de todos los canales y nos ofrece capacidad de procesamiento en tiempo real para actuar sobre ellos

Si bien la implementación de un data layer habilita esta unificación a nivel individual de cada canal, la arquitectura basada en un data hub nos permite normalizarlo de manera transversal a todos los canales. Si te has interesado por la tecnología CDP (Customer Data Platform) y empiezas a ver el potencial de disponer de una visión única cliente, entonces ya sabes que este es el primer paso para poder conseguirlo.

Con todo esto vamos a intentar responder la pregunta, ¿debo plantearme un cambio en la estrategia de recolección y distribución de datos de mi organización?, ¿debería centralizar el envío de mis datos a un data hub y realizar la distribución server-side?

Sí, si el rendimiento de tus aplicaciones y la seguridad y el control sobre los datos de tus activos son claves para tu organización.

Y sobre todo, la respuesta es sí, si deseas construir una estrategia de datos más sofisticada, orientada al real-time y has comenzado a explorar la posibilidad de incorporar tecnología CDP. Disponer de data hub que normalice y centralice, en tiempo real, los datos de todos tus canales va ser un requisito indispensable y se trata de un buen punto de partida para adoptar tecnología CDP en tu organización y, por tanto, para comenzar el camino hacia  People-Based Marketing.


*Fuente de la imagen destacada: Unsplash

Escribe tu comentario

diecinueve − 4 =

Navegar