Cuando trabajamos con Adobe Analytics a gran escala, llega un momento en el que Analysis Workspace deja de ser suficiente.
Los dashboards funcionan.
Los reports también.
Pero en cuanto necesitamos:
- cruzar datos con CRM
- construir modelos de atribución propios
- alimentar Snowflake o BigQuery
- hacer machine learning
- o trabajar con datos hit-level
aparece el verdadero problema:
Adobe Analytics no está pensado para análisis masivo fuera de su ecosistema.
Y ahí es donde entran los Data Feeds.
El problema es que montar un pipeline serio alrededor de Adobe Data Feeds es muchísimo más complejo de lo que parece al principio.
Activar el feed es fácil.
Lo difícil es:
- entender las columnas
- controlar el volumen
- modelar correctamente los datos
- y evitar que Snowflake te destruya la factura a final de mes
Qué es un Data Feed y cuándo usarlo
Un Adobe Analytics Data Feed es una exportación raw de datos hit-level.
Es decir:
- no exporta métricas agregadas
- no devuelve tablas resumidas
- no funciona como Workspace
Devuelve directamente:
- hits
- eventos
- variables
- eVars
- props
- timestamps
- IDs
- contexto técnico del tracking
En otras palabras:
acceso casi completo a la materia prima de Adobe Analytics.
Y eso cambia completamente lo que podemos hacer después.
Diferencias entre Data Feed y Reporting API
Este es probablemente el error más común.
Muchos equipos intentan resolver casos enterprise usando únicamente la Reporting API.
Y normalmente termina mal.
Reporting API
La API está pensada para:
- dashboards
- reporting
- agregaciones
- visualización
- extracción limitada
Es útil para:
- Power BI
- Looker Studio
- reporting automatizado
- métricas resumidas
Pero tiene limitaciones importantes:
- sampling en ciertos casos
- límites de requests
- datos agregados
- menos flexibilidad analítica
Data Feed
El Data Feed está pensado para:
- raw data
- modelado avanzado
- pipelines data engineering
- machine learning
- atribución personalizada
- integración warehouse
Aquí trabajamos directamente con:
- billones de filas
- eventos individuales
- joins complejos
- procesamiento distribuido
La diferencia es enorme.
Cuándo recomendamos usar Data Feed
Nosotros normalmente recomendamos Data Feed cuando:
- el volumen es muy alto
- necesitamos datos hit-level
- vamos a cruzar Adobe con CRM o ERP
- queremos alimentar Snowflake o BigQuery
- necesitamos modelos de atribución custom
- vamos a construir un CDP o data lake
Cuándo NO recomendamos usarlo
Sinceramente: muchas empresas no necesitan Data Feeds.
Si solo necesitamos:
- dashboards
- reporting marketing
- visualización básica
la API suele ser suficiente.
Porque mantener pipelines raw implica:
- costes
- gobernanza
- almacenamiento
- observabilidad
- mantenimiento técnico
Y eso no es trivial.
Arquitectura típica: Adobe Analytics → S3 → Snowflake
La arquitectura más habitual que solemos ver es esta:
- Adobe genera archivos Data Feed.
- Los archivos se exportan a S3.
- Un proceso ETL/ELT los transforma.
- Snowflake o BigQuery ingieren los datos.
- BI consume tablas modeladas.
Parece sencillo.
No lo es.
Adobe puede generar:
- cientos de archivos diarios
- compresión pesada
- millones de filas por hora
- esquemas extremadamente amplios
Y además: cada columna tiene lógica propia.
Por eso el diseño inicial es tan importante.
Cómo configurar un Data Feed paso a paso
1. Crear el feed en Adobe Analytics
Desde Adobe Analytics:
- Admin
- Data Feeds
- Create Feed
Aquí configuramos:
- report suite
- frecuencia
- destino
- formato
- compresión
La mayoría de empresas usan:
- hourly feeds
- S3
- gzip compression
Porque es el setup más flexible para pipelines cloud.
2. Elegir correctamente las columnas
Este es uno de los mayores errores que vemos.
Muchísima gente exporta literalmente todas las columnas.
Y eso destruye:
- costes
- performance
- modelado
- tiempos ingestión
Adobe tiene cientos de columnas posibles.
Pero normalmente solo necesitamos una parte.
Conviene seleccionar cuidadosamente:
- identificadores
- timestamps
- eventos
- eVars relevantes
- marketing channels
- device data
- geo data
Cuantas menos columnas:
- menos coste
- menos complejidad
- mejor performance downstream
3. Entender las post columns
Aquí empieza la parte realmente importante.
Adobe genera columnas tipo:
- evar1
- post_evar1
Y NO significan lo mismo.
Las columnas post_ representan:
- valores procesados
- persistencias
- atribución aplicada
- lógica Adobe post-processing
Muchos joins rotos vienen exactamente de no entender esto.
Nosotros solemos trabajar casi siempre con:
- post_evar
- post_event_list
- post_campaign
Porque reflejan el estado procesado final.
4. Configurar compresión y delivery
Adobe genera muchísimo volumen.
Por eso recomendamos:
- gzip
- particionado horario
- delivery incremental
De lo contrario:
- ingestiones lentas
- costes absurdos
- pipelines inestables
Especialmente en Snowflake, esto importa muchísimo.
Las columnas más importantes de un Data Feed
post_visid_high + post_visid_low
Son claves para reconstruir visitantes únicos.
Muchos equipos los ignoran… y luego no entienden por qué los usuarios no cuadran.
visit_num
Permite reconstruir sesiones correctamente.
Muy útil para:
- customer journey
- attribution
- session stitching
event_list
Aquí viven prácticamente todos los eventos.
El problema: Adobe almacena múltiples eventos concatenados.
Así que normalmente necesitamos parsing posterior.
post_evar
Probablemente una de las columnas más importantes.
Especialmente para:
- atribución
- marketing channels
- persistencia variables
geo y device data
Muy útiles para:
- segmentación avanzada
- enriquecimiento
- modelado downstream
Pero también aumentan muchísimo el volumen.
Hay que seleccionar con cuidado.
Cómo cargar el feed en Snowflake o BigQuery
Aquí empieza el verdadero trabajo de ingeniería.
Porque Adobe no entrega:
- tablas limpias
- modelos listos
- esquemas amigables
Entrega raw data.
Parsing de archivos
Normalmente recibimos:
- TSV
- comprimidos
- particionados
Y necesitamos:
- descomprimir
- parsear
- validar encoding
- controlar duplicados
Modelado de tablas
Nosotros solemos separar:
- raw layer
- staging
- business layer
Porque trabajar directamente sobre raw feeds suele convertirse en un caos rápidamente.
Especialmente cuando:
- cambian eVars
- cambia tracking
- cambian mappings
Particionado y performance
Este punto es crítico.
Si no particionamos correctamente:
- Snowflake explota en costes
- BigQuery escanea demasiado
- Power BI se vuelve lentísimo
Lo normal es particionar por:
- fecha
- hora
- report suite
Errores frecuentes que vemos en casi todos los proyectos
Exportar demasiadas columnas
Error clásico.
Adobe permite exportarlo casi todo.
Eso no significa que debamos hacerlo.
Ignorar el crecimiento del volumen
Adobe puede generar cientos de GB diarios fácilmente.
Especialmente en:
- ecommerce
- media
- apps
- enterprise traffic
Muchos pipelines se rompen simplemente por escala.
No controlar costes en Snowflake
Este problema aparece muchísimo.
Los feeds raw:
- son enormes
- tienen muchas columnas
- requieren joins pesados
Sin gobernanza: la factura escala rapidísimo.
No entender las columnas post_
Probablemente el error técnico más frecuente.
Y también uno de los más peligrosos.
Porque genera:
- métricas inconsistentes
- atribución incorrecta
- joins rotos
- usuarios duplicados
No gestionar duplicados
Dependiendo de la arquitectura:
- retries
- reprocesados
- fallos ingestión
pueden generar duplicados silenciosos.
Y detectarlos después es doloroso.
Caso real: Adobe → S3 → Snowflake
En uno de nuestros proyectos necesitábamos cruzar:
- Adobe Analytics
- CRM
- datos ecommerce
- soporte cliente
El objetivo era construir modelos de atribución propios.
Workspace no era suficiente.
La API tampoco.
Así que montamos:
- Data Feed horario
- exportación S3
- ingestión Snowflake
- modelado dbt
El mayor problema no fue Adobe.
Fue el volumen.
En pocos días:
- cientos de millones de filas
- costes Snowflake disparándose
- queries lentas
- joins imposibles
La solución llegó cuando:
- reducimos columnas
- particionamos correctamente
- modelamos staging layers
- y dejamos de consultar raw directamente
Y sinceramente: ese suele ser el punto donde los proyectos empiezan a funcionar de verdad.
Cuándo recomendamos APIs en vez de Data Feeds
No siempre hace falta montar toda esta infraestructura.
Si solo necesitamos:
- reporting
- dashboards
- KPIs agregados
- automatizaciones ligeras
la API suele ser:
- más barata
- más simple
- más mantenible
Data Feed merece la pena cuando realmente necesitamos:
raw analytics engineering.
Conclusión
Montar un Data Feed de Adobe Analytics no es difícil.
Montarlo bien sí lo es.
Porque el verdadero reto no está en activar el export.
Está en:
- entender el modelo de datos
- controlar costes
- diseñar pipelines escalables
- y transformar raw hits en información útil
Y ahí es donde normalmente se diferencian:
- los proyectos que sobreviven
- de los que terminan siendo imposibles de mantener