Migrar de Adobe Analytics a CJA: guía paso a paso

Migrar de Adobe Analytics a Adobe Customer Journey Analytics (CJA) no es cambiar de pantalla de reportes: es cambiar de modelo de datos. Tus datos pasan a datasets de Adobe Experience Platform (AEP) con esquemas XDM, las eVars y props dejan de existir como concepto, y la lógica que hoy se aplica al recolectar —persistencia, visitas, canales de marketing— se configura en una vista de datos y se calcula al correr cada reporte.

La prisa no viene del soporte: Adobe Analytics sigue vigente y sus avisos de fin de vida son de funciones, no del producto. La razón para migrar es lo que necesitas analizar. Si quieres ver en un mismo recorrido la web, la app, el CRM, el call center o la tienda física, eso es CJA; si tu análisis es solo web y funciona, puedes planear sin correr.

CJA es la herramienta de análisis de Adobe Experience Cloud que corre sobre AEP y permite explorar en Analysis Workspace datos de cualquier canal, unidos por persona; el detalle está en nuestra guía de Customer Journey Analytics. En WolfSellers implementamos Adobe Analytics, AEP y CJA. Aquí explicamos la ruta que recomienda Adobe, el proceso fase por fase, por qué los números no cuadran 1 a 1 y qué cuidar en México.

---

¿Adobe Analytics sigue vigente? Cuándo conviene migrar a CJA

Adobe actualiza las notas de versión de Adobe Analytics varias veces al mes; las vigentes al escribir esta nota son las de octubre de 2026, actualizadas el 29 de octubre. Su sección de fin de vida no trae una fecha de retiro del producto, sino de funciones:

• API de Adobe Analytics 1.4 y autenticación WSSE: se apagaron el 31 de agosto de 2026; las integraciones construidas sobre ellas ya no funcionan.
• Report Builder heredado: se retiró en junio de 2026; el nuevo Report Builder funciona con Adobe Analytics y con CJA.

Lo que Adobe sí marca es el rumbo: su guía de actualización recomienda pasar por completo a CJA y apagar Adobe Analytics cuando estés cómodo con los datos. Conservar los dos productos lo marca como no recomendado, porque tu contrato incluiría ambos y puede salir más caro con el tiempo.

Conviene migrar ya si:

1. Necesitas analizar recorridos entre canales —web, app, CRM, call center, punto de venta— con la persona como unidad, no el dispositivo.
2. Ya tienes o vas a implementar AEP, Adobe Real-Time CDP o Adobe Journey Optimizer (AJO): según Adobe, el Web SDK consolida en una sola implementación la recolección para esos productos.
3. Te topas con los límites de Adobe Analytics: hasta 75 props y 250 eVars, etiquetas Low Traffic o Uniques Exceeded, y cambios de configuración que solo aplican de ahí en adelante.

Todavía no, o con más preparación, si:

1. Dependes de funciones que CJA no tiene o resuelve distinto: Activity Map aún no está disponible, Contribution Analysis no tiene soporte, Data Feeds no tiene reemplazo exacto y las alertas no pueden ser por hora (en CJA son diarias, semanales o mensuales).
2. No tienes un identificador de cliente que puedas recolectar en todos tus canales. Sin él, la unión entre canales —el caso de uso principal de CJA, según Adobe— queda limitada.
3. Tu medición es de ecommerce web, está bien resuelta y no hay un caso de negocio entre canales. Ahí puede rendir más afinar lo que tienes; lo explicamos en la guía para medir tu ecommerce con Adobe Analytics.

Adobe Analytics frente a CJA: diferencias que cambian la migración

La fila que más se subestima es la de la lógica: en Adobe Analytics, una regla de procesamiento queda fija en el dato; en CJA vive en la vista de datos, y dos vistas pueden aplicar reglas distintas a los mismos datos.

Las rutas de migración que documenta Adobe

Adobe documenta varias rutas y clasifica cada una por esfuerzo y viabilidad a largo plazo. La recomendada combina una implementación nueva de Adobe Experience Platform Web SDK con el conector de origen de Analytics (Analytics source connector), que trae el histórico y permite comparar datos lado a lado.

Para elegir con tus datos, CJA trae una guía de actualización (Customer Journey Analytics Upgrade Guide): pestaña Workspace, opción Upgrade to Customer Journey Analytics. Pregunta por tu implementación, las funciones que usas y tus objetivos, y genera los pasos para tu caso como liga o archivo .csv. Sin acceso a CJA, tu equipo de cuenta de Adobe puede llenarla contigo.

Cómo migrar de Adobe Analytics a CJA, fase por fase

Así aterrizamos el proceso de Adobe en siete fases; las tres primeras definen si el resto sale bien.

1. Inventario: qué reportes, segmentos y alertas se usan de verdad

Analytics Inventory (menú Admin de Adobe Analytics, para administradores de producto) muestra cuántos proyectos, segmentos, métricas calculadas, report suites base y usuarios tienes. Adobe lo plantea para decidir qué migrar, qué limpiar antes y en qué orden. A ese conteo súmale el uso real:

1. Proyectos y reportes programados que alguien abre o recibe.
2. Segmentos y métricas calculadas críticos, con su definición y los campos que requieren, como pide Adobe.
3. Alertas, sobre todo las que corren por hora.
4. Integraciones: Data Feeds, Data Warehouse, Report Builder, APIs, Analytics for Target (A4T) y Audience Manager.

Lo que nadie usa no se migra.

2. Esquema XDM, datastream e identidades

Adobe recomienda un esquema a la medida en lugar del esquema de Adobe Analytics, que te obliga a seguir pensando en props y eVars. Si vas a usar CJA con Real-Time CDP, habilita Profile en el esquema. Luego vienen el dataset, el datastream con AEP como servicio y el Web SDK, por tags, manual o por API.

La identidad se decide aquí. Adobe pide que el ID de persona —número de cliente, de cuenta o un correo con hash— exista en todas las fuentes, venga en cada fila, no lleve datos personales en claro y tenga el mismo formato. El stitching distingue mayúsculas: Bob y BOB son dos personas. Más en nuestra guía de gobierno de datos en AEP.

3. Datos históricos con el conector de origen de Analytics

El conector crea un flujo de datos por report suite y copia sus datos a un dataset de AEP en XDM. Según Adobe:

1. Histórico: 13 meses por defecto en sandboxes de producción y 3 en las demás. Más de 13 meses requiere un SKU adicional.
2. Tiempo: un backfill de menos de 10 mil millones de eventos tarda menos de 4 semanas.
3. Qué copia: cada hit después de las reglas de procesamiento y antes del procesamiento de visita y visitante; por eso no trae, por ejemplo, el número de visita. Las marcas de tiempo llegan al segundo.
4. Vigencia: el histórico existe mientras exista el conector. Si detienes la recolección de Adobe Analytics, lo ya copiado se queda.
5. Varios report suites: analizar más de uno requiere el paquete Select de CJA. Si una eVar significa algo distinto en cada report suite, alinéalas o usa Data Prep, o se mezclan en una dimensión.

La alternativa es mantener Adobe Analytics un tiempo para consultar ahí el histórico (Adobe pone de ejemplo un año); esos datos no estarán en AEP.

4. Conexión y vista de datos: de eVars y props a dimensiones

La conexión une los datasets —Web SDK, conector y otros canales— y define el ID de persona; CJA ignora registros sin ID de persona o sin marca de tiempo. La vista de datos es donde se rehace la lógica de Adobe Analytics:

Todo es retroactivo: si cambias la persistencia de una dimensión, el histórico se recalcula al reportar.

5. Migración de proyectos y componentes

Adobe Analytics trae una herramienta de migración de componentes (Admin > All admin > Data configuration & collection > Component migration), también disponible por API. Recrea tus proyectos en CJA, mapea dimensiones y métricas de cada report suite a una vista de datos y recrea segmentos, rangos de fechas y métricas calculadas con ese mapeo, hasta 20 proyectos a la vez. Antes de usarla:

1. El mapeo es de toda la organización: aplica a todo lo que se migre después, sin importar quién lo migre. Adobe recomienda acordarlo antes del primer proyecto.
2. Con datos del Web SDK, todo se mapea a mano. Aun con datos del conector, algunas dimensiones y métricas siempre son manuales, como número de visita, tiempo invertido, rebotes y tasa de rebote.
3. No viajan la forma de compartir, la curaduría, las anotaciones, las carpetas, las etiquetas, los favoritos ni las programaciones.
4. Paneles sin soporte: A4T, comparación de segmentos, página de resumen y Contribution Analysis pueden hacer fallar la migración o dar errores. Quítalos antes.

6. Periodo en paralelo y conciliación

Adobe recomienda mantener Adobe Analytics un tiempo después de que CJA ya recolecta datos, para comparar lado a lado, y no apagarlo hasta que estés cómodo con los números. La conciliación tiene su propia sección más abajo.

7. Capacitación y retiro de Adobe Analytics

Workspace se parece en los dos productos, pero el modelo cambia. Adobe sugiere dar a los usuarios de 3 a 6 meses, apoyarse en champions entre los usuarios avanzados y capacitar con práctica sobre las diferencias del modelo de datos. Los proyectos no se comparten entre Adobe Analytics y CJA.

El retiro, según Adobe, va en tres pasos:

1. Detener la recolección de Adobe Analytics: AppMeasurement, extensión de tags, API o gestor de tags de terceros.
2. Quitar Adobe Analytics como servicio del datastream, cuando los usuarios ya trabajen en CJA.
3. Eliminar el conector cuando te baste el histórico que juntaste con el Web SDK.

Lo que puedes analizar después lo mostramos en ejemplos de análisis en Customer Journey Analytics.

¿Por qué no cuadran los números entre Adobe Analytics y CJA?

Según Adobe, las diferencias son normales y tienen causas conocidas. Estas son las que documenta para datos del conector, más una propia de comparar contra una implementación nueva:

Para validar volumen, Adobe documenta un método: contar registros por día en AEP con Query Service y compararlos con las filas de un Data Feed del mismo periodo, sin hits excluidos, filas de Data Sources ni keep-alive. Si el volumen coincide, lo que queda son diferencias de configuración, no datos perdidos.

Riesgos y errores comunes al migrar a CJA

1. Quedarse con el conector como implementación definitiva. Adobe le da la menor viabilidad: los datos llegan a CJA en menos de 3.75 horas sin stitching y en menos de 7 con stitching, y sigues atado a Adobe Analytics.
2. Copiar las eVars a XDM una por una. Replicar eVar1 a eVar250 conserva los problemas del modelo anterior.
3. Mapear componentes proyecto por proyecto. El mapeo es de toda la organización: una decisión aislada contamina las migraciones siguientes.
4. Exigir paridad 1 a 1. Sin un acuerdo previo sobre qué diferencias se aceptan por KPI, el paralelo no termina.
5. Apagar Adobe Analytics o el conector antes de tiempo. Con el conector se va el histórico que traía, y funciones como Data Feeds no tienen reemplazo exacto en CJA.
6. Identificadores inconsistentes. Mayúsculas, formatos distintos o datos personales sin hash rompen la unión de identidades.
7. Olvidar integraciones. Reportes por la API 1.4 (ya apagada), libros del Report Builder heredado, alertas por hora, paneles de A4T y exportaciones de Data Feeds.
8. Ingerir de más. Los derechos de uso de CJA se miden en filas de datos disponibles para análisis (promedio diario) y Adobe vigila el uso. Define retención desde el inicio: CJA permite una ventana móvil por conexión, y para el conector Adobe recomienda fijar la retención del dataset y empezar solo con el data lake antes de activar Profile.

Identidades, consentimiento y licencias en México

Unir identidades entre canales es tratar datos personales, y Adobe pide cumplir las leyes aplicables, incluidos los permisos necesarios, antes de activar el stitching. En México eso pasa por la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP). No es asesoría legal: valídalo con tu área jurídica.

• Consentimiento (art. 7). Por regla general vale el consentimiento tácito: el titular tuvo a su disposición el aviso de privacidad y no manifestó lo contrario. Los datos financieros o patrimoniales requieren consentimiento expreso, y los sensibles, expreso y por escrito (art. 8).
• Finalidades (arts. 11 y 15). El tratamiento se limita a las finalidades del aviso de privacidad; para una finalidad distinta hay que obtener de nuevo el consentimiento. Revisa que tu aviso cubra el análisis que harás al unir canales.
• Minimización. Adobe recomienda que el ID de persona no lleve datos personales en claro: aplica hash a lo sensible.

La privacidad también se migra. Con datos del conector, las solicitudes se atienden con Adobe Experience Platform Privacy Service, y AEP no copia las etiquetas de privacidad de Adobe Analytics: hay que configurar identidades y etiquetas en el esquema. El cambio del origen de privacidad se hace por flujo de datos y no se puede revertir una vez iniciado.

Licencias. WolfSellers no vende licencias de Adobe: Adobe Analytics, CJA y AEP se contratan con Adobe. El paquete de CJA define el método de stitching (basado en campos desde Select, en grafo desde Prime), el backfill de stitching y cuántos datasets lo admiten; el histórico de más de 13 meses requiere un SKU adicional, y mantener los dos productos implica tener ambos en el contrato.

Cómo lo hacemos en WolfSellers

Empezamos con un diagnóstico de tu Adobe Analytics: uso real de proyectos, segmentos, métricas y alertas; tipo de implementación y report suites; identificadores disponibles en cada canal, e integraciones que dependen de Data Feeds, APIs o Report Builder. Con eso respondemos si conviene migrar ahora y qué ruta de las que documenta Adobe encaja contigo.

Después diseñamos el esquema XDM, las identidades y la vista de datos; implementamos el Web SDK y el conector; acordamos el mapeo de componentes antes del primer proyecto; conducimos el paralelo con una conciliación documentada por KPI, y capacitamos a tus champions antes de proponer el retiro de Adobe Analytics. No damos plazos genéricos: los estimamos tras el diagnóstico.

Lo vemos en nuestros servicios de Adobe Analytics, Adobe Experience Platform y Data Engineering & Integraciones. Si quieres revisar tu implementación, escríbenos.

---

Preguntas frecuentes sobre migrar de Adobe Analytics a CJA

¿Adobe Analytics tiene fecha de fin de soporte?

Adobe no publica en sus notas de versión una fecha de retiro de Adobe Analytics: sus avisos de fin de vida son de funciones, como la API 1.4, apagada el 31 de agosto de 2026. Sí recomienda pasar por completo a CJA y apagar Adobe Analytics cuando estés cómodo con los datos.

¿Pierdo mi historial de Adobe Analytics al migrar a CJA?

No, si lo planeas. El conector de origen de Analytics trae 13 meses de histórico por defecto en sandboxes de producción, y más con un SKU adicional; ese histórico existe mientras exista el conector. También puedes mantener Adobe Analytics un tiempo y consultarlo ahí.

¿Necesito Adobe Experience Platform para usar CJA?

CJA funciona sobre AEP: analiza datasets de Experience Platform, y según Adobe tu derecho de uso de CJA incluye ingerir datos en AEP. Productos como Real-Time CDP o Journey Optimizer se licencian aparte; los necesitas, por ejemplo, para publicar audiencias desde CJA.

¿Puedo tener Adobe Analytics y CJA al mismo tiempo?

Sí, y Adobe lo recomienda durante la transición, para comparar datos y conservar el histórico. Lo que no recomienda es quedarte con los dos de forma permanente, porque tu contrato incluiría ambos productos.

¿Mis segmentos y métricas calculadas pasan solos a CJA?

No tal cual: no son compatibles con CJA. La herramienta de migración de componentes recrea los segmentos, rangos de fechas y métricas calculadas de los proyectos que migras, con el mapeo de dimensiones y métricas a tu vista de datos. Si tus datos llegan por el Web SDK, ese mapeo es manual.

¿Cuánto tarda migrar de Adobe Analytics a CJA?

Depende del tamaño de tu implementación y de cuántas fuentes unas, por eso no damos un plazo genérico. Dos referencias de Adobe: un backfill de menos de 10 mil millones de eventos tarda menos de 4 semanas, y sugiere dar a los usuarios de 3 a 6 meses para familiarizarse con CJA.

Servicios relacionados

Si este tema es relevante para tu negocio, estos servicios de WolfSellers pueden ayudarte a implementarlo:

• Adobe Experience Platform
• Marketing e-commerce
• Business Intelligence