Questa esercitazione si applica se disponi sia di Adobe Audience Manager (AAM) che di Adobe Analytics e stai attualmente inviando un hit dalla pagina a AAM utilizzando DIL (Data Integration Library) e invia anche un hit dalla pagina ad Adobe Analytics. Poiché hai entrambe queste soluzioni e poiché entrambe fanno parte di Adobe Experience Cloud, hai l'opportunità di seguire la best practice per attivare l'inoltro lato server, che consente alle Analytics server di raccolta dati per inoltrare i dati di analisi del sito in tempo reale ad Audience Manager, invece di far sì che il codice lato client invii un hit aggiuntivo dalla pagina a AAM. Questa esercitazione descrive i passaggi necessari per passare dall’implementazione DIL lato client precedente al metodo di inoltro lato server più recente.
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:
Se utilizzi questo metodo per ottenere i dati di Adobe Analytics in AAM, hai due hit provenienti dalle pagine web: Uno che va a Analyticse una AAM (dopo aver copiato il Analytics nella pagina Web. Segments vengono restituiti da 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 questo non è conforme alle best practice, gli svantaggi di utilizzare questo metodo includono:
È consigliabile passare a un metodo di inoltro lato server per l'implementazione AAM.
Come mostrato nell'immagine precedente, un hit viene dalla pagina web ad Adobe Analytics. Analytics quindi inoltra tali dati a AAM in tempo reale e i visitatori vengono valutati in caratteristiche AAM e segments, proprio come se l’hit fosse arrivato direttamente dalla pagina.
Segments vengono restituiti sullo stesso hit in tempo reale per Analytics, che inoltra la risposta alla pagina Web per la personalizzazione e così via.
Il passaggio a Server-Side Forwarding non comporta alcun rallentamento. L'Adobe raccomanda vivamente a chiunque abbia sia Audience Manager che Analytics utilizza questo metodo di implementazione.
C'è un bel po' di informazioni su questa pagina, ed è tutto importante, ovviamente. Tuttavia, tutto si riduce a due cose principali che è necessario fare:
Se salti una di queste attività, l'inoltro lato server non funzionerà correttamente. Sono stati aggiunti passaggi e dati aggiuntivi a questo documento per aiutarti a eseguire correttamente questi due passaggi per la configurazione.
Quando si passa dall'inoltro lato client all'inoltro lato server, una delle attività che si avrà è la modifica del codice al nuovo codice di inoltro lato server. Questa operazione viene eseguita utilizzando una delle seguenti opzioni:
doPlugins
all'interno della appMeasurement.js
file , se non utilizzi (ancora) Adobe LaunchdoPlugins
, ovunque l’altro gestore di tag memorizzi l’ AppMeasurement codiceDi seguito sono elencate le seguenti opzioni Aggiornamento del codice sezione .
I passaggi seguenti descrivono l’implementazione.
Il prerequisito principale per lo spostamento all'inoltro lato server è 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 l’esecuzione prima qualsiasi altra soluzione di Adobe. Consulta la sezione Documentazione ECID per ulteriori dettagli. 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.
Leggere l'intero documento prima di implementarlo. La sezione "Timing" riportata di seguito contiene informazioni importanti su quando devi implementare ogni pezzo, incluso ECID (se non è ancora implementato).
Quando ti prepari a passare dal codice DIL lato client all’inoltro lato server, 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:
siteCatalyst.init
Modulo DIL - Non devi preoccuparti di questo, perché il suo compito è solo quello di inviare il normale Analytics e questo accade semplicemente avendo abilitato l'inoltro lato server.DIL.create
funzione, prendere nota del partner
parametro . Questo è noto come "sottodominio partner" o talvolta come "ID partner" e sarà necessario quando inserisci il nuovo codice di inoltro lato server.In Opzioni di implementazione (in precedenza), vengono fornite più opzioni su come e dove implementare l'inoltro lato server. 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.
Guarda il video seguente per scoprire come spostare in Experience Platform Launch le opzioni di implementazione dal codice DIL lato client all’inoltro lato server.
Guarda il video seguente per scoprire come spostare le opzioni di implementazione dal codice DIL lato client all’inoltro lato server in AppMeasurement che risiedono in un file o in un sistema di gestione dei tag non Adobe.
Finora in questa esercitazione 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 è 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 per consentire l’implementazione completa dell’inoltro sul back-end dell’Experience Cloud.
Come promemoria, esistono due attività principali per passare da DIL lato client all’inoltro lato server:
Ma la domanda è, quale fai prima? Importa? Ok, scusate, erano due domande. Ma le risposte sono… dipende, e sì, è può importante. Com'è vago? Distruggiamola. Ma prima una domanda aggiuntiva che può venire fuori se siete una grande organizzazione con numerosi siti: Devo fare tutto immediatamente? Quella è un po' più facile. No. Potete farlo pezzo per pezzo.
Il motivo per cui la tempistica e l'ordine contano è a causa di come l'inoltro davvero lavori, riassunti nei seguenti elementi tecnici:
Sulla base di questi dettagli tecnici, ecco le raccomandazioni per il momento in cui eseguire e quando:
Inverti l'interruttore Analytics per ciascuno report suite che verrà attivato per l'inoltro lato server.
Per sito, aggiorna il codice da DIL lato client all’inoltro lato server (potrebbe essere nei tag Platform) o sulla pagina, come descritto in un’altra sezione precedente).
Prepara e pianifica in modo da essere pronto ad aggiornare il codice dall’inoltro lato server a DIL report suite che verrà attivato per l'inoltro lato server:
Inverti l'interruttore Analytics per abilitare l'inoltro lato server.
Al più presto, aggiorna il codice da DIL lato client all’inoltro lato singolo (potrebbe essere nei tag di Platform o sulla pagina, come descritto in un’altra sezione precedente).
È 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, l'inoltro lato singolo avrà iniziato l'invio di dati da Analytics AAM e poiché il codice di DIL è ancora nella pagina, ci sarà anche un hit che va direttamente dalla pagina a AAM, raddoppiando in tal modo i dati. Non appena aggiorni il codice dall’inoltro lato server da DIL, questo verrà eliminato.
Se preferisci avere una piccola discrepanza nei dati invece di una piccola duplicazione dei dati, puoi cambiare l’ordine dei passaggi 1 e 2 precedenti. Lo spostamento del codice dall’inoltro lato server a DIL interromperebbe il flusso di dati in AAM fino a quando non si è riusciti a capovolgere lo switch per attivare l’inoltro lato server per il report suite. In genere, i clienti preferiscono raddoppiare i dati anziché lasciarli alle caratteristiche e segments.
Questo argomento è trattato brevemente nelle sezioni precedenti, in quanto la strategia principale può essere riassunta come segue:
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:
A causa di questi elementi, può diventare un po' complicato. Le migliori cose che posso suggerire sono:
Il modo principale per verificare che l'inoltro lato server sia in esecuzione, consiste nell'esaminare la risposta a uno degli hit Adobe Analytics provenienti dall'app.
Se non esegui l'inoltro lato server dei dati da Analytics ad Audience Manager, allora non c'è veramente alcuna risposta al Analytics beacon (oltre a un pixel 2x2). Tuttavia, se esegui l'inoltro lato server, ci sono elementi che puoi verificare nella Analytics richiesta e risposta che ti informerà di questo Analytics comunica correttamente con l'Audience Manager, inoltra l'hit e riceve una risposta.
Attenzione al falso esito “Success”. Se c'è una risposta e tutto sembra funzionare, assicurati di avere stuff
nella risposta. Se non lo fai, potresti vedere un messaggio che dice "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 nei tag Platform o AppMeasurement, ma che l'inoltro nel 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 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 sull'inoltro lato server, consulta la documentazione.