Best practice per il monitoraggio delle applicazioni a pagina singola (SPA) in Adobe Analytics

In questo documento verranno descritte alcune best practice da seguire e di cui tenere conto quando utilizzi Adobe Analytics per monitorare le applicazioni a pagina singola (SPA). Questo documento si concentrerà sull’utilizzo di Adobe Experience Platform Launch, che è il metodo di implementazione consigliato.

NOTE INIZIALI:

• Gli elementi riportati di seguito presuppongono l’uso di Experience Platform Launch per l’implementazione sul sito. Le considerazioni sono valide anche se non utilizzi Experience Platform Launch, ma dovrai adattarle al tuo metodo di implementazione.
• Tutte le applicazioni a pagina singola sono diverse, quindi potrebbe essere necessario modificare alcuni dei seguenti elementi per soddisfare al meglio le tue esigenze. Abbiamo comunque voluto raccogliere alcune best practice che riguardano aspetti da tenere presenti quando si implementa Adobe Analytics nelle pagine di applicazioni a pagina singola.

Diagramma semplice dell’uso delle applicazioni a pagina singola in Experience Platform Launch

NOTA: come indicato, si tratta di un diagramma semplificato del modo in cui le pagine di applicazioni a pagina singola vengono gestite in un’implementazione di Adobe Analytics utilizzando Experience Platform Launch. Nelle seguenti sezioni di questa pagina, vengono trattati i passaggi ed eventuali problemi che dovresti considerare attentamente o su cui potresti dover intervenire.

Impostazione del livello dati

Quando si caricano nuovi contenuti o si esegue un’azione sulla pagina di un’applicazione a pagina singola, una delle prime operazioni da eseguire è aggiornare il livello dati. Questo deve accadere PRIMA che l’evento personalizzato si avvii e attivi regole in Experience Platform Launch, affinché Experience Platform Launch possa raccogliere i nuovi valori dal livello dati e inviarli in Adobe Analytics.

Di seguito è riportato un livello dati di esempio, i cui elementi possono essere modificati in seguito a una modifica della visualizzazione o a un’azione nell’applicazione a pagina singola. Ad esempio, per una modifica che coinvolge tutta la schermata o quasi, può essere opportuno modificare un elemento “pageName” in modo che il nuovo elemento possa essere acquisito in Experience Platform Launch e inviato ad Adobe Analytics.

<script>
    digitalData = {
        pageInstanceID: "Launch Demo Site",
        page:{
            pageInfo:{
                pageID: '2745374',
                pageName: 'acs demo - product listing page'
            },
            attributes:{
                project: "Experience Platform Launch Project"
            }
        },
        user : [ {
          "profile" : [ {
            "attributes" : {
              "gender" : "male",
              "age" : "35"
            }
          } ]
        }],
        libraries : {
          adobe : {
            launch : {
              state : 0, // 0 = not loaded , 1 = loaded
              domain : "assets.adobedtm.com"
            }
          }
        }

     };
    </script>

Impostazione di eventi personalizzati e ascolto in Experience Platform Launch

Quando un nuovo contenuto viene caricato sulla pagina o quando si verifica un’azione sul sito, è necessario informare Experience Platform Launch affinché possa eseguire una regola e inviare i dati a Analytics. Esistono due modi diversi per farlo: tramite rules Direct Call o Eventi personalizzati.

• Rules Direct Call: in Experience Platform Launch puoi impostare una rule direct call che viene eseguita quando viene chiamata direttamente dalla pagina. Se il caricamento della pagina o l’azione sul sito è molto semplice o se è univoco e può eseguire ogni volta un set di istruzioni specifico (imposta eVar4 su X e attiva event2 ogni volta), puoi utilizzare una rule direct call. Vedi la documentazione di Experience Platform Launch relativa alla creazione di rules direct call.
• Eventi personalizzati: per ulteriori funzionalità e per la possibilità di allegare dinamicamente un payload con valori diversi, è necessario impostare eventi JavaScript personalizzati e ascoltarli in Experience Platform Launch, dove puoi utilizzare il payload per impostare le variabili e inviare i dati ad Adobe Analytics. È più probabile che questa funzionalità sia necessaria, quindi questa opzione è considerata la best practice. Tuttavia, il metodo più appropriato dipende dalle funzioni specifiche del tuo sito. Per questo documento, si partirà dal presupposto che sia necessario utilizzare questo metodo con eventi personalizzati.

Esempi: in QUESTO documento dell’Aiuto trovi i link a siti basati su applicazioni a pagina singola di esempio in cui è implementato Analytics (oltre ad altre soluzioni Experience Cloud), nonché i documenti che descrivono ciò che è stato implementato. In questi esempi di applicazioni a pagina singola sono stati utilizzati i seguenti eventi personalizzati:

• event-view-start: questo evento deve essere attivato all’inizio della visualizzazione o dello stato che si sta caricando.
• event-view-end: questo evento deve essere attivato anche quando si è verificata una modifica della visualizzazione o dello stato ed è stato completato il caricamento di tutti i componenti dell’applicazione a pagina singola. Questo è l’evento che in genere attiva una chiamata ad Adobe Analytics.
• event-action-trigger: questo evento deve essere attivato quando si verifica un evento sulla pagina, ad eccezione del caricamento di una visualizzazione o uno stato. Potrebbe trattarsi di un evento clic o di una modifica minore del contenuto, che non comporta una modifica della visualizzazione.

Per ulteriori informazioni su come/quando vengono attivati, consulta le pagine o i documenti menzionati sopra. Non è necessario utilizzare gli stessi nomi di evento, ma la funzionalità indicata qui è la best practice consigliata. Il video seguente mostra un sito di esempio e la posizione in Experience Platform Launch per l’ascolto degli eventi personalizzati.

Esecuzione di s.t() o s.tl() nella Rule di Experience Platform Launch

Una delle cose più importanti da capire per Analytics quando si lavora con un’applicazione a pagina singola è la differenza tra s.t() e s.tl(). Verrà attivato uno di questi metodi in Experience Platform Launch per inviare dati in Analytics, ma è importante sapere quando inviarli.

• s.t() - La “t” sta per “track” ed è una normale visualizzazione pagina. Anche se l’URL non cambia, la visualizzazione è sufficientemente diversa da poter essere considerata come una nuova “pagina”? In tal caso, imposta la variabile s.pageName e utilizza s.t() per inviare la chiamata a Analytics

• s.tl() - “tl” sta per “track link” e viene normalmente utilizzato per monitorare i clic o le piccole modifiche al contenuto della pagina, anziché una modifica che interessa l’intera schermata. Se la modifica sulla pagina è piccola, tale da non essere considerata come una nuova “pagina” completa, utilizza s.tl() e non preoccuparti di impostare la variabile s.pageName poiché Analytics la ignorerà.

SUGGERIMENTO: una linea guida generale seguita da alcuni utenti prevede che, se la schermata cambia di oltre il 50%, deve essere trattata come una visualizzazione pagina e richiede quindi l’utilizzo di s.t(). Se la modifica della schermata è inferiore al 50%, si utilizza invece s.tl(). Tuttavia, dipende interamente da te, da cosa consideri una nuova “pagina” e come desideri eseguire il tracciamento nel tuo sito in Adobe Analytics.

Il video seguente mostra dove e come attivare s.t() o s.tl() in Experience Platform Launch.

Cancellazione delle variabili

Quando esegui il tracciamento nel tuo sito con Adobe Analytics, vorrai ovviamente inviare ad Analytics solo i dati giusti al momento giusto. In un ambiente con applicazioni a pagina singola, un valore tracciato in una variabile di Analytics può persistere ed essere inviato nuovamente in Analytics, anche se magari non serve più. Per questo motivo, nell’estensione Analytics di Launch esiste una funzione che consente di cancellare le variabili, in modo da ricominciare da zero quando si esegue la richiesta di immagine successiva e si inviano i dati ad Analytics.

Nel diagramma precedente, è riportata alla fine del processo affinché le variabili vengono cancellate dopo che l’invio dell’hit. In realtà può essere eseguita prima o dopo l’invio dell’hit, purché sia coerente nelle regole di Experience Platform Launch: la cancellazione dovrà avvenire sempre prima o sempre dopo l’impostazione e l’invio delle variabili. Se vuoi cancellare le variabili prima di eseguire s.t(), assicurati di cancellare prima le variabili, quindi imposta le nuove variabili e infine invia i nuovi dati ad Analytics.

NOTA: la cancellazione delle variabili non è sempre necessaria quando si esegue s.tl() perché s.tl() richiede anche l’utilizzo della variabile linkTrackVars ogni volta per indicare ad Analytics quali variabili verranno impostate (aggiunte automaticamente dietro le quinte in Experience Platform Launch). Pertanto, le variabili erranti di solito non vengono incluse quando si utilizza s.tl(), ma è molto consigliato che lo siano se si utilizza s.t() in un ambiente con applicazioni a pagina singola. Detto questo, è consigliabile adottare come best practice l’utilizzo della funzione di cancellazione delle variabili sia per s.t() che per s.tl() in un ambiente per applicazioni a pagina singola, per garantire una raccolta di dati di qualità.

Il video seguente mostra dove e come cancellare le variabili in Launch.

Considerazioni aggiuntive

Finestre per codice personalizzato in Experience Platform Launch

Nell’estensione Analytics di Launch puoi inserire codice personalizzato in due luoghi: nella sezione library management e nella sezione aggiuntiva “Configure Tracker Using Custom Code”.

È importante sapere che in entrambe queste posizioni il codice verrà eseguito solo una volta, quando il caricamento iniziale della pagina avviene sulla pagina dell’applicazione a pagina singola. Se il codice deve essere eseguito quando cambia la visualizzazione o quando si esegue una specifica azione sul sito, devi aggiungere un’ulteriore azione alla rule appropriata (ad esempio, nella rule “page load: event-view-end”), in modo che il codice venga eseguito ogni volta che viene eseguita tale rule. Quando crei tale azione nella rule, imposta Extension = Core e Action Type = Custom Code.

Siti ibridi regolari e con applicazione a pagina singola

Alcuni siti contengono una combinazione di pagine “regolari” e pagine da applicazioni a pagina singola. In tali situazioni, dovrai utilizzare una strategia che funzioni per entrambi i tipi di pagina. Quando configuri gli eventi personalizzati sul sito e attivi le regole in Experience Platform Launch, fai attenzione a che non finiscano doppi hit in Analytics dalla pagina, in base a modifiche hash, ecc. (se è così che hai scelto di attivare la regola Experience Platform Launch). In questo caso, dovrai eliminare una delle visualizzazioni di pagina affinché non fornisca dati errati ad Adobe Analytics.

Se decidi di suddividere la funzionalità in rules separate in modo da avere più controllo su di essa, assicurati di ricordare/documentare questa operazione: così le modifiche apportate a una rule potranno essere apportate anche all’altra rule, per proteggere l’integrità dei dati di Analytics.

Integrazione con Target tramite A4T

Solo un rapido callout. Se esegui l’integrazione con Target tramite A4T, assicurati che la richiesta di Target e quella di Analytics per lo stesso cambiamento di visualizzazione abbiano lo stesso SDID. In questo modo i dati verranno sincronizzati correttamente tra le due soluzioni.

Per visualizzare gli hit, utilizza un programma di debug o packet sniffing. Puoi anche utilizzare Experience Cloud Debugger, un’estensione per Chrome che puoi scaricare QUI. Target deve essere attivato prima sulla pagina, e puoi verificare anche questo nella console JavaScript o nel debugger.

Risorse aggiuntive

• Discussione su applicazioni a pagina singola nei forum Adobe
• Architettura di riferimento per mostrare come implementare applicazioni a pagina singola in Experience Platform Launch

Risorse Business.Adobe.com