Guía de supervivencia para el analista digital moderno - De data collection a data pipelines (1)

Primera parte de la transición del rol tradicional de data collection a uno mucho más técnico y adaptado a los nuevos procesos

Aún recuerdo la primera vez que me pidieron “etiquetar todo lo relacionado con el formulario de registro” en un proyecto de inbound. Por entonces, ni siquiera había tocado Google Tag Manager. Me dieron un documento de cinco páginas en Word, un mapa de clics y, por supuesto, suerte. Mi misión era traducir esas palabras en eventos concretos: “sign_up” cuando el usuario hacía clic en “Crear Cuenta”, “generate_lead” al completar el formulario, enviar el email al CRM… (bueno, en realidad la estructura era la de universal, con su category, action y label, pero ya me entendéis).

Poco a poco fui entendiendo el valor de todo aquello, y la verdad: lo veía fácil. Parecía cuestión de arrastrar y soltar etiquetas en GTM, probar en modo preview y listo. En ese momento, “Data Collection” significaba exactamente eso: “llevar mis eventos desde el navegador hasta Google Analytics sin pérdidas”. Si es que data collection significaba algo, porque realmente no había perfiles tan dedicados solo a esto. Era una de esas tareas que caían, como por inercia, en la mochila del analista digital.

Antes de seguir, aquí viene la cuña publicitaria donde os recuerdo que:

Hoy, cuando pienso en data collection, la imagen que me viene a la mente es completamente distinta. Ya no se trata solo de colocar etiquetas de un modo prolijo ni de entender lo básico de GTM y GA4. Ahora hablamos de construir pipelines que recojan datos desde muchos puntos diferentes, los normalicen y los encaminen hacia un único repositorio confiable, manejando como toca bloqueadores de publicidad, restricciones de privacidad y la fragilidad de los scripts en el navegador. En este capítulo quiero contar, desde mi experiencia, cómo hemos pasado de “etiquetar botones” a diseñar arquitecturas capaces de manejar millones de eventos por minuto.

---

La esencia original de “Data Collection”

Durante muchos años, hacer data collection era, en esencia, hacer dos cosas:

Elaborar y documentar el plan de etiquetado
Imagina que trabajas en una web de reservas de hoteles. El equipo de producto te pide: “queremos saber cuántos usuarios hacen clic en ‘Buscar Disponibilidad’ y cuántos acaban reservando”. Eso, en la práctica, significaba abrir una hoja de cálculo y dejar bien detallado:

• El nombre de cada evento (“clic_buscar”, “envío_form_reserva”).

• El selector CSS del elemento al que había que enganchar la etiqueta.

• Las variables a capturar (precio, usuario, campaña de origen…).

• Cuándo disparar la etiqueta (al hacer clic, al cargar la página de confirmación, etc).

Implementar y validar los eventos en GTM
Una vez cerrado el plan, pasabas a Google Tag Manager. Allí, gracias a su sistema de tags, triggers y variables, podías montar todo sin tocar el código de la web. Creamos el tag, definimos el trigger (ejemplo: “clic en #btn-buscar”), y lo asociamos a un evento de analytics. NO era lo mejor, pero era lo que se hacía.
El proceso de validación era igual de concreto: abrías el modo Preview, navegabas por la web y replicabas las interacciones clave. Si todo iba bien, veías el tag ‘clic_buscar’ disparado correctamente y podías comprobar en GA4 o Adobe Analytics que el evento y sus parámetros llegaban con los valores correctos.

Este ciclo —documentar, implementar, validar— se repetía para cada botón, formulario o interacción relevante, y acabó siendo el núcleo de la disciplina de data collection. Dominar GTM y entender cómo funcionaba la plataforma de analítica te convertía, casi por defecto, en “el dueño de los datos” dentro del equipo digital.

¿Por qué funcionaba este enfoque?
Porque el modelo web era predecible y los scripts de analytics se ejecutaban sin apenas fricciones. Los cambios eran incrementales y rara vez te encontrabas con verdaderos retos técnicos. Los bloqueadores y las regulaciones de privacidad eran anecdóticos. Bastaba con tener algo de lógica, sentido común y voluntad de probar para tener bajo control casi todo lo importante.

---

Cuando el mundo se complicó: nuevas tecnologías, nuevos problemas

Pero nada dura para siempre, y la analítica digital no iba a ser la excepción. Pronto empecé a encontrarme con casos en los que lo de “etiquetar y ver si salta el tag” ya no era suficiente.

1. Single Page Apps: cuando el “pageview” dejó de funcionar

Recuerdo la primera vez que me tocó medir una SPA (Single Page Application) construida en React. El equipo de marketing me dijo: “los usuarios navegan mucho, pero los informes dicen que nadie pasa de la home”. Yo repasaba el plan, comprobaba los triggers, y, efectivamente, todo estaba correcto… hasta que entendí el problema: la página nunca se recargaba.
Con React (o Angular, o Vue), el usuario puede pasar de la home al checkout, a la confirmación de compra, sin que el navegador recargue.
¿El resultado? Google Analytics no veía esos cambios, porque su script solo se dispara en un page load tradicional.

¿Qué aprendí?
Que ya no valía solo con GTM: tenía que hablar con los desarrolladores, pedirles que lanzaran manualmente un evento al dataLayer cada vez que el usuario cambiaba de vista, y luego capturar ese evento en GTM para lanzar el tag correspondiente.
Descubrí que existía un nuevo idioma técnico: hooks de React, routers, callbacks, estados…
El trabajo del analista se volvía más transversal: ya no podías vivir solo en tu Excel, tenías que entender cómo funcionaba la aplicación por dentro.

---

2. Mobile y el salto fuera del navegador

Mientras tanto, las apps móviles (iOS y Android) crecían en tráfico y negocio. De repente, los datos más valiosos ya no estaban en la web, sino en la app.
¿Y cómo se mide ahí? Olvídate de GTM, olvídate de tags visuales.
Aquí entra Firebase Analytics (o el framework que tenga la app), y con él la necesidad de colaborar estrechamente con los desarrolladores mobile.

Recuerdo la primera vez que tuve que explicar al equipo de apps qué era un “purchase event” y qué parámetros debían enviar (user_id, revenue, producto). Me encontré documentando eventos para varias plataformas, asegurándome de que el evento “purchase” fuera el mismo en web y mobile, y luego revisando en BigQuery que todo llegaba de forma unificada.

Lo que parecía una complicación, en realidad, me empujó a entender mejor los datos y cómo viajan de una app a la nube, y a ser mucho más preciso con la nomenclatura y la consistencia.

---

3. Bloqueadores, Consent Mode y el desafío de la privacidad

A todo esto, la privacidad y los bloqueadores empezaron a cambiar las reglas del juego. El día que Safari activó Intelligent Tracking Prevention (ITP) y Brave se popularizó, empecé a ver caídas extrañas en los informes:

• Usuarios que nunca generaban una sesión.

• Eventos de compra que no aparecían en los dashboards.

• Métricas de retención imposibles de calcular.

El GDPR añadió otra capa de dificultad: ahora, sin consentimiento, no puedes disparar ningún evento que use cookies de analítica o marketing. Descubrí que la lógica de “lanza todos los tags y ya está” era peligrosa (y podía salir muy caro en multas).

La respuesta fue doble:

• Aprender a condicionar todos los tags de GTM al consentimiento recogido en el CMP (Consent Management Platform).

• Configurar Consent Mode, para que Google Analytics supiera cuándo había consentimiento real y cuándo no, y modelase el resto.

Este periodo fue un baño de humildad: aprendí a documentar todo, a no fiarme de los datos por defecto y a pensar siempre en el edge case (usuarios bloqueando todo, navegadores exóticos, configuraciones de cookies, etc).

---

4. La madurez del campo

Pero si hay un cambio que lo ha acelerado todo, ha sido el salto en madurez tanto del sector como de quienes trabajamos en él.
Antes, el data collection era el purgatorio del analista digital: un rito de paso, algo que se aprendía casi por imitación y que se mejoraba a base de prueba y error. Hoy, en cambio, la disciplina ha evolucionado, y con ella, los perfiles. Ya no vale con ser “apañado” en GTM y tener buena voluntad: el contexto exige un conocimiento mucho más técnico, transversal y orientado a la ingeniería.

Hay varias razones para este salto cualitativo:

• El mercado ha madurado: Las empresas han entendido que los datos no son un subproducto del marketing, sino la columna vertebral de cualquier proceso de negocio, desde el reporting hasta la automatización de campañas y el machine learning.

• La escala lo ha cambiado todo: Cuando gestionas millones de eventos diarios en múltiples canales (web, app, backend, incluso IoT o retail físico), ya no hay sitio para el azar ni para los procesos manuales. El pipeline se vuelve una pieza crítica de la arquitectura de empresa.

• El entorno es más hostil: Con la privacidad, los bloqueadores, las restricciones de cookies y la presión regulatoria, el dato fácil desapareció. Ahora, sobrevivir (y crecer) implica diseñar arquitecturas sólidas, testables y preparadas para auditoría, cambio y fallo.

• La colaboración es clave: El nuevo analista ya no puede vivir en un silo: tiene que sentarse en la mesa con desarrolladores, legal, compliance, marketing, data engineering… y hablar todos los idiomas (al menos, lo suficiente para entenderse y anticipar los impactos).

Todo esto ha hecho que el “perfil de analista” clásico haya evolucionado.
Ahora, en una entrevista para un equipo de data, ya no basta con saber montar dashboards: se valoran skills como versionado de código, conocimiento de pipelines ETL, integración con APIs, automatización de QA, diseño de esquemas y, sobre todo, cultura de documentación y control.

---

La metamorfosis: del tracking al pipeline

Lo que antes era un ejercicio de “a ver si el tag salta”, se ha transformado en diseñar, desplegar y mantener pipelines completos de datos.
Este salto ha sido progresivo, a veces forzado, pero siempre necesario.

¿Qué ha hecho posible esta evolución?

1. Server-Side Tagging:
   Ahora no dependemos solo del navegador. Podemos enviar los eventos a un endpoint propio, desde donde:

   • Validamos si hemos recogido las cosas con el debido consentimiento.

   • Enriquecemos el evento con datos del backend o del CRM.

   • Lo enviamos a múltiples destinos: Google Analytics, Facebook CAPI, TikTok, BigQuery, Snowflake…

   • Almacenamos el evento bruto para posteriores análisis o auditoría.

2. Conexión con data warehouses, data lakes y gestores de colas:
   Antes, los datos vivían en la plataforma de analytics y poco más. Ahora, puedes enviar todos los eventos crudos a un data warehouse (BigQuery, Snowflake) o un data lake (GCS, S3), o canalizarlos por Pub/Sub, Kafka, etc. Esto abre la puerta a:

   • Métricas y reporting personalizados.

   • Activaciones en tiempo real.

   • Modelos de machine learning directamente sobre el histórico de eventos.

3. APIs de plataformas de marketing y orquestación avanzada:
   Gracias a la integración server-side, ahora puedes enviar datos directamente (y sin pérdidas) a Facebook CAPI, TikTok Events API, Google Ads API, LinkedIn, Criteo…
   Esto permite:

   • No ser dependientes de cambios en navegadores, duraciones de cookies o bloqueadores restrictivos.

   • Enviar más información (user_id, revenue, detalle de producto, LTV, audiencias…) de forma fiable y segura.

   • Orquestar reglas: solo enviar ciertos eventos a ciertas plataformas bajo ciertas condiciones (por ejemplo, según país, canal, consentimiento, etc).

---

El nuevo perfil: arquitecto de pipelines de datos

Este viaje me ha enseñado que el rol clásico de “analista digital” ha mutado. Ahora, el verdadero valor está en:

• Entender cada fuente de datos: web, apps, backend, sistemas batch, APIs de terceros.

• Saber trabajar codo a codo con desarrollo: frontend y backend, data engineering, marketing, legal…

• Diseñar y mantener pipelines robustos: desde la ingesta, pasando por la validación, la transformación y el activado (en dashboards, campañas, modelos).

• Gestionar calidad, privacidad y versionado: documentar, monitorizar y auditar cada cambio, y anticipar problemas antes de que estallen.

• Pensar siempre en términos de escalabilidad y automatización: lo que hoy haces para una web, mañana puede ser para veinte productos, tres apps, y cuatro mercados, con legislaciones diferentes.

Y, sobre todo, a no conformarme con “que salte el tag”. Ahora la pregunta es:

• ¿El dato es correcto?

• ¿Llega a todos los destinos?

• ¿Cumplo privacidad y puedo escalar el modelo?

---

De “poner etiquetas” a “arquitectar flujos de información”

Todo este cambio ha sido un viaje. Uno a veces forzado por el contexto (navegadores que bloquean, leyes que aprietan, negocios que escalan), pero también una oportunidad para aprender y reinventarse.
Hoy veo claro que saber etiquetar un botón ya no basta. El reto está en construir sistemas que recojan, limpien y activen datos de calidad —en tiempo real, en cualquier canal, y siempre bajo control.

Y aquí es donde comienza de verdad el trabajo interesante: cuando, como analista, empiezas a pensar como ingeniero, como arquitecto y como garante de la calidad. Ese es el nuevo data collection. Y ahí, la aventura no ha hecho más que empezar. En la segunda parte de este capítulo veremos un caso concreto en el que usaremos los datos de dataLayer para realizar un flujo de información que llegue hasta un data warehouse.