DocumentazioneAudience ManagerTutorial su Audience Manager

Migrare l’implementazione Audience Manager del sito da DIL lato client all’inoltro lato server migrating-your-site-s-aam-implementation-from-client-side-dil-to-server-side-forwarding

Last update: Sat Jul 20 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Creato per:

  • Intermedio
  • Sviluppatore

Questo tutorial è applicabile se disponi sia di Adobe Audience Manager (AAM) che di Adobe Analytics e stai inviando un hit dalla pagina all'AAM utilizzando il codice DIL (Data Integration Library), nonché un hit dalla pagina ad Adobe Analytics. Poiché si dispone di entrambe queste soluzioni e poiché fanno entrambe parte di Adobe Experience Cloud, è possibile seguire la best practice per attivare l'inoltro lato server, che consente ai server di raccolta dati Analytics di inoltrare i dati di analisi del sito in tempo reale all'Audience Manager, anziché inviare un hit aggiuntivo dalla pagina all'AAM tramite il codice lato client. Questo tutorial illustra i passaggi necessari per passare dall’implementazione precedente di DIL lato client al più recente metodo di inoltro lato server.

Lato client (DIL) e lato server client-side-dil-vs-server-side

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

lato client a lato server

Implementazione di DIL lato client client-side-dil-implementation

Se si utilizza questo metodo per ottenere i dati di Adobe Analytics nell'AAM, si otterranno due risultati dalle pagine Web: uno da Analytics e uno da AAM (dopo aver copiato i dati di Analytics nella pagina Web. Segments vengono restituiti dall'AAM alla pagina, dove possono essere utilizzati per la personalizzazione e così via. Questa viene considerata un’implementazione legacy e non è più consigliata.

Oltre al fatto che non si tratta di seguire le best practice, gli svantaggi dell’utilizzo di questo metodo includono:

  • Due hit provenienti dalla pagina invece di uno solo
  • l'inoltro lato server è necessario per la condivisione in tempo reale dei tipi di pubblico AAM a Analytics, pertanto le implementazioni lato client non consentono questa funzionalità (e potenzialmente altre funzionalità in futuro)

È consigliabile passare a un metodo di inoltro lato server per l’implementazione dell’AAM.

Implementazione dell'inoltro lato server server-side-forwarding-implementation

Come mostrato nell’immagine precedente, un hit viene dalla pagina web ad Adobe Analytics. Analytics inoltra quindi tali dati all'AAM in tempo reale e i visitatori vengono valutati in caratteristiche AAM e segments, come se l'hit provenisse direttamente dalla pagina.

Segments vengono restituiti sullo stesso hit in tempo reale a Analytics, che inoltra la risposta sulla pagina Web per la personalizzazione e così via.

Non esiste alcun downside temporale per il passaggio a Server-Side Forwarding. Adobe consiglia vivamente a chiunque disponga sia di Audience Manager che di Analytics di utilizzare questo metodo di implementazione.

Hai due attività principali you-have-two-main-tasks

Ci sono un bel po 'di informazioni su questa pagina, ed è tutto importante, naturalmente. Tuttavia, tutto si riduce a due operazioni principali da eseguire:

  1. Modifica il codice da codice DIL lato client a codice inoltro lato server
  2. Capovolgere l'opzione in Analytics Admin Console per avviare l'effettivo inoltro dei dati (per report suite)

Se salti una di queste attività, l'inoltro lato server non funzionerà correttamente. In questo documento sono stati aggiunti passaggi e dati aggiuntivi per aiutarti a eseguire questi due passaggi correttamente per la tua configurazione.

Opzioni di implementazione implementation-options

Quando passi dall’inoltro lato client a quello lato server, una delle attività che dovrai svolgere è quella di modificare il codice per inserirlo nel nuovo codice di inoltro lato server. Questa operazione viene eseguita utilizzando una delle seguenti opzioni:

  • Tag Adobe Experience Platform: opzione di implementazione consigliata da Adobe per le proprietà web. Questa è un’attività semplice, poiché i tag di Platform hanno svolto tutto il lavoro necessario.
  • Sulla pagina - Puoi anche inserire il nuovo codice SSF direttamente nella funzione doPlugins all'interno del file appMeasurement.js, se non utilizzi (ancora) Adobe Launch
  • Altri gestori di tag: 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 implementation-steps

I passaggi seguenti descrivono l’implementazione.

Passaggio 0: Prerequisito: servizio ID Experience Cloud (ECID) step-prerequisite-experience-cloud-id-service-ecid

Il prerequisito principale per passare all'inoltro lato server è l'implementazione del servizio ID Experience Cloud. Questa operazione è più semplice se si utilizza Experienci Platform Launch, nel qual caso è sufficiente installare l’estensione ECID e fare il resto.

Se utilizzi un TMS non Adobe o nessun TMS, implementa ECID per eseguire prima di qualsiasi altra soluzione Adobe. Per ulteriori dettagli, consulta la documentazione ECID. L’unico altro prerequisito è relativo alle versioni del codice, quindi puoi applicare semplicemente le versioni più recenti del codice nei passaggi seguenti.

NOTE
Leggi l'intero documento prima di implementare. La sezione "Tempistiche" seguente contiene informazioni importanti su quando devi implementare ogni elemento, incluso ECID (se non è ancora implementato).

Passaggio 1: registra le opzioni attualmente utilizzate dal codice DIL step-record-currently-used-options-from-dil-code

Quando ti prepari a passare dal codice DIL lato client all’inoltro lato server, il primo passaggio consiste nell’identificare tutto ciò che si sta facendo con il codice DIL, inclusi le impostazioni personalizzate e i dati inviati all’AAM. Gli aspetti da considerare includono:

  • Variabili Analytics normali, utilizzando il modulo DIL siteCatalyst.init - Non è necessario preoccuparsi di questa, perché il suo lavoro consiste solo nell'inviare le normali variabili Analytics e questo accade in virtù della semplice attivazione dell'inoltro lato server.
  • Sottodominio partner: nella funzione DIL.create prendere nota del parametro partner. Questo è noto come "sottodominio partner" o talvolta "ID partner" e sarà necessario quando inserisci il nuovo codice di inoltro lato server.
  • Visitor Service Namespace - Noto anche come "Org ID" o "IMS Org ID", ne avrai bisogno quando imposti il nuovo codice di inoltro lato server. Prendetene nota.
  • containerNSID, uuidCookie e altre opzioni avanzate: prendi nota di eventuali opzioni avanzate aggiuntive in uso in modo da poterle impostare anche nel codice di inoltro lato server.
  • Variabili di pagina aggiuntive - Se dalla pagina vengono inviate a AAM altre variabili (oltre alle normali Analytics variabili gestite da siteCatalyst.init), dovrai prenderne nota in modo che possano essere inviate tramite inoltro lato server (avviso spoiler: tramite contextData variabili).

Passaggio 2: aggiornare il codice step-updating-the-code

Nelle opzioni di implementazione (sopra) sono disponibili più opzioni relative a come e dove si implementa l'inoltro lato server. Affinché questa sezione sia efficace, è necessario suddividerla in queste sezioni (con due di esse combinate). Vai al metodo di questa sezione che descrive meglio le tue esigenze.

Tag Adobe Experience Platform launch-by-adobe

Guarda il video seguente per scoprire come spostare le opzioni di implementazione dal codice DIL lato client all’inoltro lato server nel Experience Platform Launch.

https://video.tv.adobe.com/v/26310/?quality=12

"Sulla pagina" o gestore di tag non Adobe on-the-page-or-non-adobe-tag-manager

Guarda il video seguente per scoprire come spostare le opzioni di implementazione dal codice DIL lato client all'inoltro lato server nel codice AppMeasurement, che risiede in un file o in un sistema di gestione tag non Adobe.

https://video.tv.adobe.com/v/26312/?quality=12

Passaggio 3: abilitazione dell'inoltro (per Report Suite) step-enabling-the-forwarding-per-report-suite

Finora in questo tutorial abbiamo dedicato tutto il nostro tempo a passare dal codice DIL lato client all’inoltro lato server. Va bene, perché è la parte più difficile. Questa sezione, anche se è molto semplice, è importante quanto l’aggiornamento del codice. Questo video illustra come capovolgere lo switch che consente l’effettivo inoltro di dati da Analytics ad Audience Manager.

https://video.tv.adobe.com/v/26355/?quality-12

NOTA: Come indicato nel video, ricorda che saranno necessarie fino a 4 ore per consentire la completa implementazione dell'inoltro nel backend di Experience Cloud.

Tempistica timing

Come promemoria, ci sono due attività principali per passare dal DIL lato client all’inoltro lato server:

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

Ma la domanda è, quale fai per primo? Importa? Ok, scusate, erano due domande. Ma le risposte sono… dipende, e sì, può avere importanza. Com'è per essere vago? Suddividiamola. Ma prima una domanda aggiuntiva che può venire fuori se siete una grande organizzazione con numerosi siti: Devo fare tutto in una volta? Quello è un po' più facile. No. Potete farlo pezzo per pezzo.

Un po' più a fondo a-little-deeper-dive

Il motivo per cui la tempistica e l'ordine contano è a causa di come funziona l'inoltro realmente, che può essere riassunto nei seguenti fatti tecnici:

  • Se hai implementato il servizio ID Experience Cloud (ECID) e il commutatore in Analytics Admin Console ("il commutatore") è attivo, i dati verranno inoltrati da Analytics all'AAM, anche se non hai ancora aggiornato il codice.
  • Se ECID non è stato implementato, i dati non verranno inoltrati, anche se l’utente è acceso e dispone del codice di inoltro lato server.
  • Il codice di inoltro lato server (nei tag Platform o sulla pagina) gestisce davvero la risposta ed è necessario per completare la migrazione.
  • Ricordare che il commutatore di inoltro lato server è abilitato da report suite, ma che il codice viene gestito dalla proprietà nei tag di Platform o dal file AppMeasurement se non si utilizzano i tag di Platform.

Best practice best-practices

Sulla base di questi dettagli tecnici, ecco le raccomandazioni su cosa fare e quando:

Se NON hai ancora implementato ECID if-you-do-not-have-ecid-yet-implemented

  1. Capovolgere lo switch in Analytics per ogni report suite che verrà abilitato per l'inoltro lato server.

    1. L’inoltro non si avvia ancora perché non disponi di ECID.

  2. Per sito, aggiorna il codice da client-side DIL all’inoltro lato server (ad esempio nei tag di Platform) o sulla pagina, come descritto in un’altra sezione precedente.

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

Se ECID è stato implementato if-you-do-have-ecid-implemented

  1. Preparare e pianificare in modo da essere pronti ad aggiornare il codice da DIL all'inoltro lato server PER report suite che verrà abilitato per l'inoltro lato server:

    1. Capovolgere lo switch in Analytics per abilitare l'inoltro lato server.

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

    2. Non appena possibile, aggiorna il codice da client-side DIL all’inoltro lato singolo (potrebbe trattarsi dei tag di Platform o della pagina, come descritto in un’altra sezione in precedenza).

      1. Dovresti ricevere una risposta JSON corretta al beacon Analytics (per ulteriori dettagli, consulta la sezione Convalida e risoluzione dei problemi di seguito).
NOTE
È importante che questi due passaggi si avvicinino il più possibile, perché tra i passaggi 1 e 2 di cui sopra, si avranno duplicazioni dei dati che vanno nell’AAM. In altre parole, l'inoltro lato singolo inizierà a inviare dati da Analytics all'AAM e, poiché il codice DIL è ancora nella pagina, si verificherà anche un hit che passa direttamente dalla pagina all'AAM, raddoppiando in tal modo i dati. Non appena aggiorni il codice da DIL all'inoltro lato server, questo sarà alleviato.
NOTE
Se preferisci una piccola discrepanza nei dati piuttosto che una piccola duplicazione di dati, puoi cambiare l’ordine dei passaggi 1 e 2 precedenti. Se si sposta il codice da DIL all'inoltro lato server, il flusso di dati in AAM verrà interrotto finché non sarà possibile capovolgere lo switch per attivare l'inoltro lato server per report suite. In genere, i clienti preferiscono raddoppiare i dati in modo lieve, anziché perdere l'opportunità di convertire i visitatori in caratteristiche e segments.

Tempistica di migrazione quando si dispone di molti siti e report suites migration-timing-when-you-have-many-sites-and-report-suites

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

Eseguire 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:

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

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

  • Prendi un po’ di tempo per definire una strategia per la migrazione all’inoltro lato server, in base agli elementi spiegati in precedenza
  • Dato che una singola proprietà nei tag di Platform (o un singolo file AppMeasurement) in genere è mappata a 1 o 2 report suites distinti, è probabile che sia possibile creare un piano che funzioni su questi gruppi distinti uno per uno, aggiornando l'azienda all'inoltro lato server
  • Se lavori con Adobe Consulting, rivolgiti a loro per quanto riguarda il piano di migrazione, in modo che possano aiutarli quando necessario

Convalida e risoluzione dei problemi validation-and-troubleshooting

Il modo principale per verificare che l’inoltro lato server sia in esecuzione, consiste nell’esaminare la risposta a qualsiasi hit di Adobe Analytics proveniente dall’app.

Se non esegui l'inoltro lato server dei dati da Analytics all'Audience Manager, allora non esiste alcuna risposta al beacon Analytics (oltre a un pixel 2x2). Tuttavia, se esegui l'inoltro lato server, vi sono elementi che puoi verificare nella richiesta e nella risposta di Analytics che ti informeranno che Analytics sta comunicando correttamente con Audience Manager, inoltrando l'hit e ricevendo una risposta.

https://video.tv.adobe.com/v/26359/?quality=12

WARNING
Attenzione al falso esito “Success”. Se è presente una risposta e tutto sembra funzionare, assicurati di avere l'oggetto stuff nella risposta. In caso contrario, è possibile che venga visualizzato un messaggio che indica "status":"SUCCESS". Per quanto sembri folle, questa è la prova che NON funziona correttamente.
Questo significa che hai completato l'aggiornamento del codice nei tag di Platform o in AppMeasurement, ma che l'inoltro in Analytics Admin Console non è ancora stato completato. In questo caso è necessario verificare di aver abilitato l'inoltro lato server in Analytics Admin Console per report suite. Se lo hai fatto, e non sono ancora passate 4 ore, attendi, poiché potrebbe essere necessario attendere così tanto per apportare tutte le modifiche necessarie sul backend.

falso successo

Per ulteriori informazioni sull'inoltro lato server, consulta la documentazione.

recommendation-more-help
468cbaa0-07ce-4354-9a38-4f23b645a466