La migrazione da Adobe Analytics a Customer Journey Analytics (CJA) richiede un’attenta preparazione in termini di raccolta dati, configurazione della piattaforma e integrazioni. Questa guida delinea i passaggi chiave per favorire una transizione fluida e sfruttare appieno il potenziale di CJA in Adobe Experience Platform.
La migrazione da Adobe Analytics (AA) a Customer Journey Analytics (CJA) è un processo complesso ma vantaggioso che consente alle aziende di sfruttare funzionalità analitiche più avanzate all’interno di Adobe Experience Platform (AEP). Il processo di pre-migrazione dipende principalmente dalla raccolta dei dati, dalla configurazione di Adobe Analytics corrente e dalle integrazioni esistenti.
In questa guida vengono esaminati tre aspetti chiave per garantire una pianificazione della migrazione fluida, ovvero la fase di preparazione di CJA.
1. Informazioni sui requisiti per la raccolta dati
Importanza della qualità dei dati
Dati errati in ingresso producono risultati errati in uscita. Garantire una raccolta dati di alta qualità è essenziale, in quanto rappresenta la base delle analisi. Prima della migrazione, è necessaria una revisione completa dell’implementazione di tracciamento per mantenere precisione e coerenza.
Web SDK e AppMeasurement
Uno degli aspetti più critici della migrazione consiste nel valutare la configurazione corrente della raccolta dati:
- Se le piattaforme (proprietà dei tag di Adobe) utilizzano già Web SDK, la migrazione risulta più semplice.
- Se le piattaforme utilizzano ancora AppMeasurement, è necessario più tempo per adattarsi, in quanto Web SDK introduce diversi nuovi concetti, quali gli schemi XDM (Experience Data Model), le identità e i set di dati. Sebbene AppMeasurement possa essere tecnicamente utilizzato con AEP, nel tempo comporta una maggiore complessità. È altamente consigliato di utilizzare solo Web SDK.
Revisione del livello dati e del sistema di gestione dei tag
La migrazione offre l’opportunità di rivedere e ottimizzare il tuo approccio alla raccolta dati:
- Allinea e standardizza il livello dati tra le diverse piattaforme. Scegli la configurazione corretta del livello dati. Potresti voler aggiornare il livello dati dal tradizionale Customer Experience Digital Data Layer (CEDDL) a un approccio basato su eventi (EDDL) o ibrido.
- Assicurati che Adobe Tags (Launch) o qualsiasi altro sistema di gestione dei tag sia ottimizzato per supportare i requisiti di AEP/CJA.
- Rivedi la Solution Design Reference (SDR) e adegua le strategie di raccolta dati ai requisiti di CJA.
L’approccio
Per fortuna, avevamo già eseguito la migrazione di tutte le piattaforme su Web SDK e conoscevamo i concetti di AEP. Inoltre, il nostro livello dati e la configurazione di gestione dei tag erano standardizzati su tutte le piattaforme (grazie a un approccio ibrido al livello dati che combina CEDDL ed EDDL). Tuttavia, abbiamo condotto un audit approfondito delle proprietà Launch e della SDR. Ci siamo assicurati che gli attributi chiave, come i dati di pagina e di evento, fossero tracciati in modo coerente con un’elevata qualità dei dati. All’interno della SDR, abbiamo esaminato in modo critico ciascun attributo, mettendone in discussione la necessità e analizzando come potesse essere migliorato grazie alle nuove funzionalità di CJA (possibilità di configurazione dei componenti, come i campi derivati).
2. Valutazione della configurazione di Adobe Analytics
L’ambiente di Adobe Analytics corrente ha un impatto importante sulla complessità della migrazione. Alcune considerazioni chiave includono:
Strategia di migrazione dati
Durante la migrazione dei dati da Adobe Analytics a CJA, è fondamentale stabilire quali dati debbano essere migrati e il periodo di riferimento appropriato (durata del backfill). Invece di trasferire tutti i dati, sfrutta questa opportunità per perfezionare la configurazione dell’analisi e i piani di tracciamento, garantendo che vengano inclusi solo i dati rilevanti.
Per impostazione predefinita, Adobe consente l’importazione di 13 mesi di dati storici in CJA. Tuttavia, a seconda delle esigenze di business, potrebbe essere necessario un periodo di conservazione dei dati più lungo. Ad esempio:
- Se la tua azienda presenta picchi stagionali (ad esempio, da settembre a novembre) e utilizza un ciclo di analisi di tre mesi, possono servire 15 mesi di dati storici. Questa considerazione non è importante solo ai fini dell’analisi, ma anche per i requisiti di licenza.
- Un periodo di conservazione dei dati più lungo consente confronti anno su anno più accurati e un’analisi delle tendenze più efficace, ma comporta anche un aumento del volume dei dati, dei costi di archiviazione e della complessità di elaborazione. Valuta attentamente i casi d’uso che desideri trattare con CJA.
Trovare il giusto equilibrio tra le necessità di conservazione dei dati e le risorse di archiviazione è cruciale per ottimizzare la configurazione di CJA.
Scelta di un metodo di migrazione dati
Stabilire le modalità di trasferimento dei dati in CJA rappresenta un ulteriore passaggio cruciale. Sono disponibili due opzioni principali:
- Connettore di origine di Adobe Analytics: un metodo più semplice e automatizzato per l’integrazione con CJA.
- Feed di dati: un approccio più flessibile ma complesso, che consente una maggiore personalizzazione del trasferimento dei dati.
La scelta del metodo corretto dipende dalle specifiche esigenze di dati e dall’infrastruttura. Per le esperienze acquisite in tema di migrazione di dati, consulta questo articolo.
Migrazione dei componenti
Anziché effettuare la migrazione dei componenti uno a uno da AA a CJA, questa transizione offre un’opportunità per ripartire da zero. Nel corso del tempo, le implementazioni Adobe Analytics tendono spesso ad accumulare componenti ridondanti, obsoleti o privi di adeguata documentazione.
L’approccio
Abbiamo scelto di non utilizzare lo strumento per la migrazione dei componenti, optando per una configurazione nuova e semplificata. Per garantire una transizione fluida, un’analisi degli stakeholder ha identificato quali dashboard fossero essenziali. Questo ha ridotto il numero totale di oltre il 50% ed eliminato i rapporti e i componenti duplicati o inutilizzati. Abbiamo esaminato e ottimizzato segmenti, metriche e componenti per impedire la migrazione di elementi obsoleti.
Per la migrazione dei dati, abbiamo scelto i feed di dati invece del connettore di origine di Adobe a causa delle relative limitazioni (evitando l’inclusione di eVar e prop nella nuova configurazione di CJA). Invece di trasferire semplicemente le vecchie complessità nel nuovo sistema, abbiamo considerato la migrazione come un’opportunità di pulizia e ottimizzazione, creando infine un ambiente di analisi più efficiente e una maggiore capacità di self-service.
3. Integrazioni personalizzate e trasformazione dei dati
Questa rappresenta spesso la fase più complessa della migrazione. Molte organizzazioni integrano Adobe Analytics con sistemi di terze parti, ad esempio:
- Data warehouse (tramite API, FTP o pipeline personalizzate)
- Sistemi di mailing, strumenti di automazione del marketing e sistemi di consigli
- CRM e sistemi di personalizzazione
Poiché CJA funziona all’interno di AEP (e presenta alcune limitazioni riguardo all’esportazione), queste integrazioni devono essere configurate nuovamente utilizzando le opzioni disponibili, tra cui:
- API di acquisizione dati di AEP
- Connettori sviluppati da Adobe e personalizzati
- Pipeline di preparazione dei dati per la trasformazione e l’indirizzamento dei dati
Problemi legati alla trasformazione dei dati
La trasformazione dei dati rappresenta una delle principali difficoltà durante la migrazione. Sebbene i connettori standard offrano un certo livello di trasformazione, gli approcci basati su API (ad esempio Query Service) richiedono una gestione attenta dei dati orientati agli oggetti di AEP quando vengono convertiti in strutture relazionali (ad esempio tabelle, viste o data lake). Una corretta strutturazione e ottimizzazione di questi processi è essenziale per assicurare l’usabilità dei dati su diverse piattaforme.
L’approccio
La configurazione di importazione ed esportazione dei dati è stata relativamente semplice, anche se abbiamo trasferito alcuni dati nel nostro data lake interno. Per questo, ci siamo affidati a esportazioni quotidiane dal data warehouse tramite FTP e all’API del data warehouse. Poiché CJA attualmente offre opzioni limitate per tali esportazioni (ad esempio il supporto all’esportazione completa di tabelle con 10 dimensioni e 10 metriche), abbiamo scelto di esportare i dati in base a set di dati da AEP.
Per le nostre esigenze, l’utilizzo dell’API di Query Service insieme ad AEPP ha rappresentato la soluzione più efficace. Questo ci ha permesso di accedere ai set di dati dal nostro data lake interno e di conservali in base alle esigenze. Tuttavia, poiché i dati provenivano da AEP anziché da CJA, non includevano attributi persistenti, come l’attribuzione dell’ultimo clic o le metriche basate sulle visite. Per colmare questa lacuna, abbiamo utilizzato SQL e Python per ricreare questi elementi. Per fortuna, Adobe offre funzioni predefinite per l’identificazione delle visite e le funzioni finestra standard di SQL consentono di ricostruire ogni elemento presente in CJA.
Pianificare in anticipo le pipeline dati è fondamentale, in quanto la modifica di questi processi richiede risorse IT interne. Maggiore è il numero di operazioni di importazione/esportazione coinvolte, maggiore è la complessità, aumentando sia le attività di manutenzione che le risorse richieste. Mantenere il processo il più semplice possibile consente di ridurre il sovraccarico garantendo al contempo la coerenza dei dati.
Considerazioni finali
La migrazione da Adobe Analytics a Customer Journey Analytics non è un semplice trasferimento diretto, ma richiede una pianificazione attenta, l’ottimizzazione dei dati e decisioni strategiche. Attraverso la revisione della raccolta dati, l’ottimizzazione dei componenti e una gestione accurata delle integrazioni, le aziende possono sfruttare appieno il potenziale di CJA riducendo le complessità superflue.
Una migrazione eseguita correttamente pone le basi per un ambiente di analisi più potente, flessibile e scalabile all’interno di AEP.