Migrazione dell’implementazione AAM del sito da Client-Side DIL a Server-Side Forwarding

Questa esercitazione si applica agli utenti che dispongono sia di Adobe Audience Manager (AAM) che di Adobe Analytics e che attualmente inviano un hit dalla pagina a AAM utilizzando il codice "DIL" (Data Integration Library) e inviando anche un hit dalla pagina ad Adobe Analytics. Poiché entrambe le soluzioni sono in tuo possesso e poiché entrambe fanno parte di Adobe Experience Cloud, puoi seguire la best practice per attivare "Server-Side Forwarding (SSF)", che consente ai Analytics server di raccolta dati di inoltrare i dati analitici del sito in tempo reale ad Audience Manager, invece di far sì che il codice client-side invii un hit aggiuntivo dalla pagina a AAM. Questa esercitazione ti guiderà attraverso i passaggi necessari per passare dalla precedente implementazione "Client-Side DIL" al più recente metodo "Server-Side forwarding".

Client-Side (DIL) vs. Server-Side

Quando si confrontano e si confrontano questi due metodi per ottenere i dati di Adobe Analytics in AAM, può essere prima utile visualizzare le differenze nell’immagine seguente:

Client-side Implementazione di DIL

Se utilizzi questo metodo per ottenere i dati di Adobe Analytics in AAM, significa che due hit provengono dalle pagine Web: Uno che va a Analytics e uno che va a AAM (dopo aver copiato i dati Analytics sulla pagina Web. Segments vengono restituiti da AAM alla pagina, dove possono essere utilizzati per la personalizzazione, ecc. Questa operazione è considerata un’implementazione "legacy" e non è più consigliata.

Oltre al fatto che questo non è conforme alle best practice, gli svantaggi di utilizzare questo metodo includono:

• Due hit provenienti dalla pagina invece di uno solo
• Server-Side Forwarding è necessario per la condivisione in tempo reale di tipi di pubblico su Analytics, pertanto Client-side le implementazioni non consentono questa funzione (e potenzialmente altre funzionalità in futuro)

È consigliabile passare a un metodo di implementazione Server-Side Forwarding AAM.

Server-Side Forwarding Implementazione

Come mostrato nell'immagine precedente, un hit viene dalla pagina web ad Adobe Analytics. Analytics poi inoltra quei dati a AAM in tempo reale, e i visitatori vengono valutati in AAM traits e segments, proprio come se l'hit fosse venuto direttamente dalla pagina.

Segments vengono restituiti sullo stesso hit in tempo reale a Analytics, che inoltra la risposta sulla pagina web per la personalizzazione, ecc.

Il passaggio a Server-Side Forwarding non comporta alcun rallentamento. Si consiglia vivamente a tutti coloro che dispongono sia di Audienci Manager che di Analytics di utilizzare questo metodo di implementazione.

Hai DUE Attività Principali

C'è un bel po' di informazioni su questa pagina, ed è tutto importante, naturalmente. Tuttavia, tutto si riduce a due cose principali che è necessario fare:

1. Cambia il codice da Client-Side codice DIL a Server-Side Forwarding codice
2. Invertire l'interruttore in Analytics Admin Console per avviare l'effettivo inoltro dei dati (per report suite)

Se salti uno di questi due, SSF non funzionerà correttamente. Sono stati aggiunti passaggi e dati aggiuntivi a questo documento per aiutarti a eseguire correttamente questi due passaggi per la configurazione.

Opzioni di implementazione

Mentre passi da client-side a server-side, una delle attività che avrai sarà quella di modificare il codice nel nuovo codice Server-Side Forwarding. Questa operazione viene eseguita utilizzando una delle seguenti opzioni:

• Adobe Experience Platform Launch: opzione di implementazione consigliata per le proprietà Web. Vedrai che questo è un compito molto facile, come Launch ha fatto tutte le cose difficili per te.
• Nella pagina - Puoi anche inserire il nuovo codice SSF direttamente nella funzione doPlugins all'interno del file appMeasurement.js, se non lo sei (ancora) utilizzando Adobe Launch
• Altri gestori di tag : questi possono essere trattati come l’opzione precedente (Sulla pagina), in quanto il codice SSF verrà comunque inserito in doPlugins, ovunque l’altro gestore di tag memorizzi il codice AppMeasurement

Esamineremo ciascuno di questi elementi nella sezione Aggiornamento del codice .

Passaggi di implementazione

Passaggio 0: Prerequisito: Servizio Experience Cloud ID (ECID)

Il prerequisito principale per lo spostamento a Server-Side Forwarding è l’implementazione del servizio Experience Cloud ID. Questo viene fatto molto facilmente se si utilizza Experience Platform Launch, nel qual caso si installa semplicemente l'estensione ECID e farà il resto.

Se utilizzi un TMS non Adobe o nessun TMS, implementa ECID per eseguire before qualsiasi altra soluzione di Adobe. Per ulteriori informazioni, consulta la documentazione ECID . L’unico altro prerequisito riguarda le versioni del codice, in modo da applicare semplicemente le versioni più recenti del codice nei passaggi seguenti, sarà bene.

Passaggio 1: Opzioni del codice DIL attualmente in uso

Quando ti prepari a passare da Client-Side codice DIL a Server-Side Forwarding, il primo passaggio consiste nell’identificare tutte le operazioni che esegui con il codice DIL, incluse le impostazioni personalizzate e i dati inviati a AAM. Gli aspetti da considerare e da considerare includono:

• Variabili normali Analytics, utilizzando il modulo siteCatalyst.init DIL - Non dovrai preoccuparti di questo, perché il suo lavoro è solo quello di inviare le normali variabili Analytics, e ciò avverrà in virtù della semplice abilitazione di SSF.
• Sottodominio partner - Nella funzione DIL.create , annota il parametro partner . Questo è noto come "sottodominio partner" o talvolta come "ID partner" e sarà necessario quando inserisci il nuovo codice SSF.
• Visitor Service Namespace - Noto anche come "Org ID" o "IMS Org ID", questo è necessario anche quando imposti il nuovo codice SSF. Prendetene nota.
• containerNSID, uuidCookie e altre opzioni avanzate - Prendi nota di eventuali opzioni avanzate aggiuntive che stai utilizzando in modo da poterle impostare anche nel codice SSF.
• Variabili di pagina aggiuntive - Se altre variabili vengono inviate a AAM dalla pagina (oltre alle normali variabili Analytics gestite da siteCatalyst.init), sarà necessario prenderne nota in modo che possano essere inviate tramite SSF (spoiler alert: tramite variabili contextData).

Passaggio 2: Aggiornamento del codice

Nella sezione sopra intitolata "Opzioni di implementazione", sono fornite più opzioni relative a come/dove stai implementando Server-Side Forwarding. Affinché questa sezione sia efficace, dobbiamo suddividerla in queste sezioni (con due di esse combinate). Vai al metodo di questa sezione che descrive meglio le tue esigenze.

Adobe Experience Platform Launch

Guarda il video seguente per scoprire come spostare le opzioni di implementazione dal codice DIL in Server-Side Forwarding nel Experience Platform Launch .Client-Side

"Sulla pagina" o non-Adobe Tag Manager

Guarda il video seguente per scoprire come spostare le opzioni di implementazione dal codice DIL in Server-Side Forwarding nel codice AppMeasurement, che risiede in un file o in un sistema di gestione tag non Adobe.Client-Side

Passaggio 3: Abilitazione dell'inoltro (per Report Suite)

Finora in questa esercitazione abbiamo trascorso tutto il nostro tempo nel passare dal codice Client-Side DIL a Server-Side Forwarding. Va bene, perché è la parte più difficile. Questa sezione, anche se è super facile, è importante quanto l'aggiornamento del codice. Questo video illustra come capovolgere l’interruttore che consente l’effettivo inoltro dei dati da Analytics ad Audience Manager.

NOTA: come indicato nel video, ricorda che ci vorranno fino a 4 ore perché l'abilitazione dell'inoltro venga implementata completamente sul backend Experience Cloud.

Tempi

Come promemoria, ci sono due attività principali da spostare da Client-Side DIL a Server-Side Forwarding:

1. Aggiornamento del codice
2. Capovolgimento dell'interruttore in Analytics Admin Console

Ma la domanda è, quale fai prima? Importa? Ok, scusate, erano due domande. Ma le risposte sono… dipende, e sì, può può essere importante. Com'è vago? Distruggiamola. Ma prima una domanda aggiuntiva che può venire fuori se siete una grande organizzazione con molti siti: Devo fare tutto immediatamente? Quella è un po' più facile. No. Puoi farlo pezzo per pezzo… una specie. :

Una piccola immersione più profonda

Il motivo per cui la tempistica e la materia dell'ordine sono dovuti al funzionamento di avanzamento *realmente *, che può essere riassunto nei seguenti alcuni fatti tecnici:

• Se hai implementato il servizio Experience Cloud ID (ECID) e l'interruttore in Analytics Admin Console ("l'interruttore") è attivato, i dati verranno inoltrati da Analytics a AAM, anche se non hai ancora aggiornato il codice.
• Se non hai implementato ECID, i dati non verranno inoltrati, anche se hai attivato l’interruttore, e disponi del codice SSF.
• Il codice SSF (sia in Launch che sulla pagina) gestisce davvero la risposta ed è ovviamente necessario per completare la migrazione.
• Ricorda che l’interruttore SSF è abilitato da Report Suite, ma che il codice è gestito dalla proprietà in Launch, o dal file AppMeasurement se non utilizzi Launch

Best practice

Sulla base di questi dettagli tecnici, ecco le raccomandazioni per la tempistica di "cosa fare quando":

Se NON hai ancora implementato ECID

1. Capovolgi l'interruttore in Analytics per ogni report suite che verrà attivato per SSF

   1. L'inoltro non verrà ancora avviato perché non disponi di ECID

2. Per sito, aggiorna il codice da Client-Side DIL a SSF (potrebbe essere in Launch o sulla pagina, come descritto in un'altra sezione precedente)

   1. L’inoltro ora scorrerà (come hai aggiunto ECID) e dovresti anche ricevere una risposta JSON corretta al beacon Analytics (consulta la sezione Convalida e risoluzione dei problemi di seguito per ulteriori dettagli).

Se ECID è stato implementato

1. Prepara e pianifica in modo da essere pronti ad aggiornare il codice da DIL a SSF PER report suite che verrà abilitato per SSF:

   1. Capovolgere l'interruttore in Analytics per abilitare SSF

      1. L'inoltro verrà avviato perché l'ECID è abilitato

   2. Al più presto, aggiorna il codice da Client-Side DIL a SSF (potrebbe essere in Launch o sulla pagina, come descritto in un'altra sezione precedente)

      1. Dovresti ricevere una risposta JSON corretta al beacon Analytics (consulta la sezione Convalida e risoluzione dei problemi di seguito per ulteriori dettagli).

NOTA 1: È importante eseguire questi due passaggi il più vicino possibile tra loro, perché tra i passaggi 1 e 2 di cui sopra, si avrà una duplicazione dei dati in AAM. In altre parole, SSF avrà iniziato a inviare dati da Analytics a AAM e, poiché il codice di DIL è ancora nella pagina, ci sarà anche un hit che andrà direttamente dalla pagina a AAM, raddoppiando in tal modo i dati. Non appena aggiorni il codice da DIL a SSF, questo verrà mitigato.

NOTA 2: Se preferisci avere una piccola discrepanza nei dati piuttosto che una piccola duplicazione dei dati, puoi cambiare l'ordine dei passaggi 1 e 2 precedenti. Lo spostamento del codice da DIL a SSF arresta il flusso di dati in AAM fino a quando non è stato possibile capovolgere l’interruttore per attivare l’SSF per il report suite. In genere, i clienti preferiscono raddoppiare i dati anziché perdere l’accesso ai visitatori in traits e segments.

Tempi di migrazione quando hai molti siti e Report Suites

Questo argomento è trattato brevemente nelle sezioni precedenti, in quanto la strategia principale può essere riassunta come segue:

Esegui la migrazione di un sito/report suite (o gruppo di siti/report suites) alla volta.

Tuttavia, questo può diventare un po' complicato in base ad alcuni possibili scenari:

• Hai un sito che contiene diversi report suites distinti
• Hai un report suite che include diversi siti (come un report suite globale)
• Puoi utilizzare una proprietà Launch per coprire più siti
• Hai diversi team di sviluppo per siti diversi

A causa di questi elementi, può diventare un po' complicato. Le migliori cose che posso suggerire sono:

• Prenditi del tempo per elaborare una strategia per la migrazione a SSF, basata sulle cose illustrate sopra
• In base al fatto che una singola proprietà in Launch (o un singolo file AppMeasurement) in genere è mappata a 1 o 2 valori report suites distinti, è probabile che sarà possibile creare un piano che funzioni su questi gruppi distinti uno per uno, aggiornando l'azienda a SSF
• Se lavori con Adobe Consulting, rivolgiti a loro riguardo al tuo piano di migrazione, in modo che possano aiutarti in base alle tue esigenze

Convalida e risoluzione dei problemi

Il modo principale per verificare che Server-Side Forwarding sia in esecuzione, consiste nell'esaminare la risposta a uno degli hit Adobe Analytics provenienti dall'app.

Se non esegui server-side forwarding dati da Analytics all'Audience Manager, allora non esiste alcuna risposta al beacon Analytics (oltre a un pixel 2x2). Tuttavia, se esegui SSF, ci sono elementi che puoi verificare nella richiesta e nella risposta Analytics che ti informeranno che Analytics comunica correttamente con l'Audience Manager, inoltrando l'hit e ricevendo una risposta.

ATTENZIONE: Attenzione alle false operazioni riuscite - Se ricevi una risposta e tutto sembra funzionare, assicurati di disporre dell’oggetto “stuff” nella risposta. In caso contrario, potresti visualizzare un messaggio con la dicitura “status”:“SUCCESS”. Per quanto sembri folle, questa è la prova che NON funziona correttamente. Se viene visualizzato questo messaggio, significa che hai completato l’aggiornamento del codice in Launch o AppMeasurement, ma che l’inoltro in Analytics Admin Console non è ancora stato completato. In questo caso è necessario verificare di aver abilitato SSF nel Analytics Admin Console per il report suite. Se lo avete fatto, e non sono ancora state 4 ore, siate pazienti, in quanto può richiedere così tanto per fare tutte le modifiche necessarie sul backend.

Per ulteriori informazioni su Server-Side Forwarding, consulta la documentazione.