Implementazione di Adobe Analytics: hack che non conosci

Alcuni anni fa, i nostri sviluppatori hanno implementato Angular su alcune pagine Web chiave, senza consultare il team di analisi web. Le visualizzazioni di pagina su alcune delle pagine improvvisamente sono scese quasi a nulla.

Ho comprato due libri su Angular per cercare di trovare una soluzione. Nel frattempo, il mio manager si è imbattuto in una sintassi alternativa per il monitoraggio delle visualizzazioni di pagina in Adobe Analytics. Come abbiamo scoperto, esiste anche una sintassi alternativa simile per tenere traccia dei clic (e di qualsiasi altra cosa).

La mia prima reazione è stata che entrambe le sintassi erano equivalenti, ma non avrei potuto essere più sbagliato. Si è inoltre scoperto che Adobe ha appena documentato le funzionalità che stai per scoprire.

1. Monitoraggio delle visualizzazioni di pagina

In entrambi gli esempi precedenti, passate le stesse informazioni ad Adobe. Osservando l'URL della richiesta di tracciamento nella scheda Rete degli strumenti di sviluppo del browser, non è nemmeno possibile stabilire quale delle due sintassi viene utilizzata dalla pagina Web.

I vantaggi della sintassi di sostituzione emergono quando è necessario taggare un'applicazione a pagina singola (SPA). Una SPA tende a caricare una pagina una sola volta, quindi la aggiorna parzialmente per creare la pagina successiva che deve essere visualizzata. Questo produce l'illusione di una nuova pagina ma si carica più velocemente perché cambiano meno cose: non è necessario ricaricare la navigazione superiore, il piè di pagina, ecc.

Considera la seguente sequenza:

1. Un visitatore atterra su una SPA e la prima pagina viene caricata completamente:

s.pageName = "casa";
s.channel = "casa";
s.prop1 = "casa";
s.t ();

2. Lo stesso visitatore vede una seconda pagina:

s.pageName = "pagina prodotti 1";
s.channel = "prodotti";
s.t ();

Con Adobe Analytics, il problema è che contiene la tua seconda richiesta di visualizzazione di pagina s.prop1 ancora. Questo perché la seconda pagina non è stata caricata come nuova pagina, solo una versione aggiornata. Di conseguenza, il s.prop1 è ancora lì fino a quando non viene caricata una nuova pagina o non la ripristini su nulla:

s.pageName = "pagina prodotti 1";
s.channel = "prodotti";
s.prop1 = ""; // resettando s.prop1 a nulla
s.t ();

Non so te, ma ricordando di pulire tutto oggetti di scena, eVars, eventi, contextData, stringhe di prodotti, ecc. richiedono molta disciplina. È probabile che qualcuno ne dimentichi uno (o alcuni) nelle loro guide ai tag.

Puoi usare s.clearVars prima di tracciare le visualizzazioni di pagina per reimpostare la maggior parte dei punti dati su niente, ma non contextData valori. Il s.clearVars è in circolazione da almeno il 2016, ma molte aziende usano ancora versioni antiche delle librerie di Adobe Analytics.

Utilizzando la sintassi di sostituzione, esiste un modo più efficiente e chirurgico per pulire questi punti dati rispetto a s.clearVars supportato anche dalle vecchie librerie di Adobe Analytics. Rivisitiamo la sequenza della seconda pagina ma utilizziamo la sintassi di sostituzione:

1. Un visitatore atterra su una SPA e la prima pagina viene caricata completamente:

s.t ({
pageName: "home",
canale: "home",
prop1: "casa"
});

2. Lo stesso visitatore vede una seconda pagina:

s.t ({
pageName: "pagina prodotti 1",
canale: "prodotti"
});

Ora, se osservassi le richieste di tracciamento per entrambe le visualizzazioni di pagina, lo vedresti prop1 è nella prima richiesta di visualizzazione di pagina ma non nella seconda. Non è più necessario ricordare cosa ripristinare; non hai bisogno s.clearVars o.

I punti dati che dichiari all'interno del JSON che passi come parametro per il tuo s.t () call ha un ambito strettamente limitato a quello s.t () chiamata. Con questo sostituisce la sintassi, dichiari privato punti dati. Usando la sintassi classica, dichiari pubblico punti dati.

Nel contesto di una SPA, Adobe Analytics ricorda i punti di dati pubblici e dimentica quelli privati.

2. Tracciamento di clic e altre interazioni degli elementi della pagina

Come menzionato nell'introduzione, esiste anche la sintassi di sostituzione per il tracciamento dei clic. È inoltre possibile utilizzare la sintassi di sostituzione per qualunque interazione dell'elemento di pagina, non solo clic.

Il s.tl () Il metodo consente di tenere traccia di queste interazioni tra gli elementi della pagina. Può richiedere un quarto parametro, che è un oggetto di sostituzione JSON simile a quello per il monitoraggio delle visualizzazioni di pagina.

Il modello di cipolla a tre strati

Qualsiasi punto dati dichiarato all'interno dell'S-code (antico) o della Libreria AppMeasurement (il nuovo nome ormai da diversi anni) funge da costante per tutti i siti Web che utilizzano quella versione specifica della libreria Adobe Analytics.

I dettagli sui server di monitoraggio, il codice valuta e il set di caratteri sono esempi tipici di tali costanti. Questa è una funzionalità documentata delle implementazioni di Adobe Analytics.

È possibile utilizzare la sintassi classica dopo aver caricato la libreria di Adobe Analytics, rendendo tali punti dati pubblico punti dati. Puoi controllare i loro valori nella console JavaScript degli strumenti di sviluppo del browser.

Esempi tipici sono il nome della pagina, la sezione del sito, la sottosezione, ecc. Esiste anche una sintassi di sostituzione che consente di creare punti di dati privati:

1. Nel file della libreria di Adobe Analytics: costanti per tutto il sito;
2. Nel codice della pagina proprietà specifiche della pagina pubblica;
3. Dentro il s.t () e il s.tl () chiamate: proprietà specifiche per il monitoraggio privato.

Per un sito Web non SPA, probabilmente hai usato solo i livelli 1 e 2 insieme. È possibile sostituire le proprietà del codice della pagina con la sintassi di sostituzione (ovvero utilizzare invece i livelli 1 e 3). Ma con un sito Web SPA, è necessario utilizzare tutti e tre i livelli, riutilizzando il livello 2 per dichiarare solo le costanti a livello di modello.

Se sei un fan del funzionalismo, potresti aver classificato tutte le pagine web in tipi di pagina. Vorrei prendere in considerazione la dichiarazione del tipo di pagina usando un oggetto di livello 2 con path abilitato. (Il funzionalismo è un argomento per un altro post sul blog. Leggi i post sul blog di June Dershewitz e il white paper originale di Gary Angel, Joel Hadary e Paul Legutko.)

Nel linguaggio SPA, gli sviluppatori fanno riferimento al contenuto che aggiorna un modello di pagina per creare l'illusione di nuove pagine come frammenti. Quando si passa da una pagina all'altra, la SPA carica i frammenti per aggiornare la pagina in cui ci si trovava prima di fare clic su quel collegamento. Probabilmente anche il nome della pagina è cambiato a seguito di quel clic.

Si desidera tenere traccia del nome di quella pagina sul livello 3, all'interno di JSON di sostituzione che si passa come parametro di input a s.t () chiama perché il nome della pagina è specifico per la richiesta di tracciamento della visualizzazione di pagina.

E il gioco è fatto: Adobe Analytics su tutti e tre i livelli. Adobe non ha mai documentato il modo in cui questi livelli lavorano insieme.

Un quarto strato per il modello di cipolla?

Ho spiegato come è possibile dichiarare i punti dati come costanti per l'intero sito Web o una raccolta di siti Web quando li si dichiara in un livello all'interno del codice della libreria di Adobe Analytics.

I concetti di costanti e valori predefiniti sono strettamente correlati. È possibile dichiarare un punto dati sul livello 1, quindi dichiarare nuovamente il valore per quel punto dati sul livello 2 o 3. In tal caso, un determinato punto dati verrà impostato su valori diversi durante il rendering della schermata.

In generale, l'ultimo valore che passi a un punto dati sarà il valore che vedrai nei tuoi rapporti. La sintassi di sostituzione sostituisce tutti i valori precedenti contenuti nel punto dati (se si dovesse dichiarare il suo valore nell'oggetto di sostituzione JSON).

Ma questo non è sempre vero.

La libreria di Adobe Analytics contiene una funzione chiamata s_doPlugins (). Devi impostare il s.usePlugins funzione a vero, o il s_doPlugins () la funzione non verrà mai eseguita.

A questo punto, dovresti chiedere quale differenza fa dichiarare un punto dati all'interno del file della libreria rispetto all'interno o all'esterno della funzione. Si scopre che dentro rende il punto dati di sola lettura e la nuova dichiarazione nei Livelli 2 o 3 non fa alcuna differenza: il valore originale all'interno di s_doPlugins () La funzione è il valore che vedrai nei rapporti.

Questo succede perché s.t () controlla il s.usePlugins flag e se è impostato su vero, esegue il s_doPlugins funzione che dichiara di nuovo i punti dati. Si potrebbe chiamare questo il quarto strato del modello di cipolla:

1. La libreria di Adobe Analytics carica e dichiara i punti dati dichiarati all'esterno di s_doPlugins () funzione per la prima volta.
2. Il codice della pagina ne rinnova alcuni.
3. Il s.t () la funzione ne ridimensiona alcuni nell'oggetto override JSON.
4. Il s.t () la funzione esegue e controlla il s.usePlugins bandiera:
   • Se è impostato su falso, i rapporti mostrano i valori dei punti dati impostati all'interno dell'oggetto di sostituzione JSON nell'oggetto s.t () chiamata di funzione.
   • Se è impostato su vero, i rapporti mostrano i valori dichiarati all'interno di s_doPlugins () funzione.

utilizzando s.t () per tutte le tue esigenze di tracciamento

Se ormai non lo avevi indovinato, trovo strani modi per passare il mio tempo libero. Una volta ho deciso di deobfuscolare l'H.26 s_code.js Libreria di Adobe Analytics. Ho trovato il codice per il s.t () e il s.tl () funzioni che gestiscono rispettivamente il monitoraggio delle visualizzazioni di pagina e il monitoraggio delle interazioni degli elementi di pagina.

Il s.tl () la funzione chiama il s.t () funzione, che alla fine chiama una funzione Adobe Analytics più profonda chiamata s.mr (). (Presumo che Sig sta per "fare richiesta" poiché quella funzione crea l'URL di pixel per il tuo s.t () e s.tl () chiamate.)

Se stai cercando idee per pesci d'aprile per confondere il tuo sviluppatore Adobe Analytics junior, puoi farlo s.t () chiamate usando la sintassi di sostituzione che si comporta proprio come s.tl () chiamate. Ecco come:

document.querySelector ( "pulsante"). addEventListener (
"click", function () {
s.t ({
lnk: true,
linkTrackVars: "channel, prop1, prop2, prop3",
linkTrackEvents: "Nessuno",
linkName: "È stato fatto clic sul pulsante",
linkType: "o",
pageName: dataLayer.pageName,
canale: dataLayer.channel,
prop1: dataLayer.prop1,
prop2: dataLayer.prop2,
prop3: dataLayer.prop3
});
}
);

callback

Adobe ha introdotto il supporto per la richiamata in AppMeasurement 1.8.0 nel 2017. Questi sono i s.registerPreTrackCallback () e s.registerPostTrackCallback () funzioni. Sono documentati e ti consentono di eseguire il codice in risposta a una richiesta di tracciamento appena prima che si attivi, o subito dopo che è stato attivato.

Se stai lavorando con una versione precedente della libreria di Adobe Analytics e hai bisogno di questi callback, non tutto è perduto, ma ciò che segue non è supportato da Adobe: è necessario modificare il codice nella parte "non modificare" della libreria ( che potrebbe annullare il tuo supporto).

Ho già detto sopra s.mr () le funzioni generano la richiesta di tracciamento e generano la richiesta HTTP. La funzione contiene questa riga di codice:

im.src = rs;

• sono è un elemento tag creato al volo. Questo oggetto ha un src proprietà che è l'URL di quello etichetta.
• Il rs è una stringa contenente l'URL del pixel di tracciamento. Se hai commentato quel comando apparentemente innocente, le richieste di tracciamento smettono del tutto di sparare.

Impostazione di src proprietà di un tag attiva una richiesta GET HTTP. È possibile chiamare una funzione JavaScript personalizzata prima e / o dopo questa riga di codice per supportare i callback con versioni precedenti del codice della libreria Adobe Analytics.

Per un disaccoppiamento del codice ancora maggiore, considera la possibilità di attivare due distinti eventi Javascript personalizzati, uno prima e uno dopo la richiesta di tracciamento. Ognuno di questi eventi JavaScript personalizzati può accettare un oggetto JSON personalizzato, che potrebbe essere lo stesso JSON che hai usato con la sintassi di sostituzione (o un sottoinsieme o superset di esso).

document.body.dispatchEvent (nuovo CustomEvent (
"PreCallback",
dettaglio: {}, // JSON opzionale, può essere il tuo oggetto JSON di sostituzione
bolle: true // opzionali
));
im.src = rs;
document.body.dispatchEvent (nuovo CustomEvent (
"PostCallback",
dettaglio: {}, // JSON opzionale, può essere il tuo oggetto JSON di sostituzione
bolle: true // opzionali
))

Due cose da ricordare (a meno che tu non voglia generare infinite chiamate del server e essere licenziato):

1. Non chiamare mai s.registerPreTrackCallback () o s.registerPostTrackCallback () dentro il s_doPlugins () funzione.
2. Non chiamare mai s.t () o s.tl () dentro il s.registerPreTrackCallback (), s.registerPostTrackCallback (), o s.mr () funzioni.

Si noti che le versioni più recenti di Adobe Analytics supportano le richieste HTTP POST. Le versioni precedenti di Internet Explorer supportano solo URL con un massimo di 2.083 caratteri. Questo porta al troncamento e il troncamento porta alla perdita di dati.

Dal 2014, Adobe Analytics supporta il passaggio da HTTP GET (ovvero l'utilizzo tag per inviare i dati ai server Adobe) a HTTP POST (ovvero inviando un modulo nascosto). Questo articolo non tratta la creazione di callback per HTTP POST, ma sono sicuro che le menti determinate troveranno l'equivalente HTTP POST di im.src = rs.

Conclusione

Credo che Adobe inizialmente avesse un solo metodo per tenere traccia delle visualizzazioni di pagina e delle interazioni degli elementi di pagina. Quindi, le versioni successive di Adobe Analytics hanno introdotto una funzione separata per tenere traccia di queste interazioni, e così il s.tl () la funzione è nata — e il s.t () era limitato al monitoraggio delle visualizzazioni di pagina.

Credo anche che la sintassi di sostituzione fosse il modo originale di tracciare; il codice della pagina è arrivato più tardi. Omniture, quindi Adobe, ha dovuto garantire che l'aggiornamento di s_code.js file e, in seguito, il codice della libreria AppMeasurement non ha costretto i clienti a ripetere tutti i tag.

Le versioni più recenti e future della libreria Adobe Analytics continueranno a contenere codice che supporta implementazioni antiche. Mi piace la sintassi di sostituzione. Lo trovo elegante e ha funzionato molto bene per noi, specialmente nelle nostre SPA.