Show Menu
ARGOMENTI×

Offerte di reindirizzamento - Domande frequenti su A4T

Questo argomento contiene le risposte alle domande che vengono spesso poste in merito alle offerte di reindirizzamento durante l’utilizzo di Analytics come origine per la creazione di rapporti per Target (A4T).

Analytics for Target (A4T) supporta le offerte di reindirizzamento?

Sì, purché l’implementazione utilizzi at.js. Tuttavia, l’implementazione deve soddisfare i requisiti minimi elencati di seguito per utilizzare le offerte di reindirizzamento nelle attività che utilizzano Analytics come origine per la generazione di rapporti.
A causa di un problema noto, un numero limitato di clienti con reindirizzamenti A4T ottengono una percentuale più alta di hit non uniti. Consulta Problemi noti e problemi risolti .

Quali sono i requisiti minimi necessari per utilizzare le offerte di reindirizzamento con A4T?

L’implementazione deve soddisfare i seguenti requisiti minimi:
  • Servizio ID visitatore di Experience Cloud: visitorAPI.js versione 2.3.0 o successiva.
  • Adobe Analytics: appMeasurement.js versione 2.1.
  • Adobe Target: at.js versione 1.6.2 o successiva.
    La libreria mbox.js non supporta le offerte di reindirizzamento con A4T. L’implementazione deve utilizzare at.js.
Le tre librerie devono essere incluse sia nella pagina con l’offerta di reindirizzamento sia nella pagina a cui il visitatore viene reindirizzato.

Perché a volte sono presenti discrepanze di dati tra A4T e Analytics?

È possibile riscontrare alcune discrepanze di dati. Per ulteriori informazioni, consulta Varianze di dati previste tra Target e Analytics durante l’utilizzo con e senza A4T .

Perché a volte vengono conteggiate le visualizzazioni di pagina nella pagina originale e nella pagina di reindirizzamento?

Quando si utilizza at.js 1.6.3 o versione successiva, questo problema non si verifica. Questa situazione di tipo “race condition” interessa solo i clienti che utilizzano versioni precedenti. Il team di Target gestisce solo due versioni di at.js: la versione corrente e quella immediatamente precedente. Aggiorna at.js per assicurarti di eseguire sempre una versione supportata .
Se utilizzi una versione precedente e non supportata di at.js, si potrebbe verificare una situazione di tipo “race condition” a causa della quale potrebbe essere attivata una chiamata Analytics prima che sulla prima pagina sia stato eseguito il reindirizzamento. Questo può determinare un conteggio delle visualizzazioni di pagina sia nella pagina originale sia in quella di reindirizzamento. Questa situazione si traduce in una visualizzazione di pagina in più sulla prima pagina, anche se il visitatore non ha mai effettivamente “visualizzato” questa prima pagina.
Per aumentare la velocità del reindirizzamento della pagina, è consigliabile creare un’attività di reindirizzamento con il compositore basato su moduli. Questo è dovuto al punto in cui viene eseguito il codice nella pagina. Inoltre, è consigliato creare un’offerta di reindirizzamento per ogni esperienza, anche per quella predefinita, dove il reindirizzamento riporta alla pagina originale. Ciò assicura che, se si verifica un conteggio errato, questo si verifica in tutte le esperienze, in modo che il rapporto e l’analisi siano comunque validi per il test.
Potrebbe essere utile usare offerte di reindirizzamento per tutte le esperienze dell’attività, inclusa quella predefinita (esperienza di controllo), ad esempio, per inserire le stesse condizioni in tutte le esperienze. Supponiamo che sia stata impostata un’offerta di reindirizzamento per tutte le esperienze eccetto quella predefinita: la velocità dell’esperienza priva di offerta di reindirizzamento sarà avvantaggiata. Le offerte di reindirizzamento sono consigliate solo per scenari temporanei, ad esempio a scopo di test. Le offerte di reindirizzamento non sono consigliate per scenari permanenti, ad esempio a scopo di personalizzazione. Dopo aver determinato l’esperienza “vincitrice”, rimuovi il reindirizzamento per migliorare le prestazioni di caricamento della pagina.
Per ulteriori informazioni su questo problema, consulta le informazioni sulle “Offerte di reindirizzamento” nella tabella Problemi noti .

Posso usare le offerte di reindirizzamento con A4T se utilizzo la libreria JavaScript mbox.js?

La libreria mbox.js non supporta le offerte di reindirizzamento con A4T. L’implementazione deve utilizzare at.js.

Il Compositore esperienza visivo e il Compositore esperienza basato su moduli sono entrambi supportati?

Sì, entrambi i compositori sono supportati purché si utilizzano le offerte di reindirizzamento integrate.
Se utilizzi un codice personalizzato per il reindirizzamento, assicurati di compilare i due nuovi parametri associati agli URL di reindirizzamento ( adobe_mc_sdid e adobe_mc_ref , descritti di seguito).

Quali sono i nuovi parametri della stringa di query aggiunti agli URL di reindirizzamento?

I seguenti parametri di stringa di richiesta sono associati alle offerte di reindirizzamento:
Parametro
Descrizione
adobe_mc_sdid
Il parametro adobe_mc_sdid passa l’ID di dati supplementari (SDID) e l’ID dell’organizzazione di Experience Cloud dalla pagina predefinita alla nuova pagina affinché A4T “unisca” la richiesta di Target nella pagina predefinita con la richiesta di Analytics nella nuova pagina.
adobe_mc_ref
Il parametro adobe_mc_ref passa l’URL di riferimento della pagina predefinita alla nuova pagina. Se utilizzato con AppMeasurement.js versione 2.1 (o successiva), Analytics utilizzerà questo valore di parametro come URL di riferimento nella nuova pagina.
Questi parametri vengono aggiunti automaticamente agli URL di reindirizzamento quando si utilizzano le offerte di reindirizzamento integrate nel Compositore esperienza visivo e nel Compositore esperienza basato su modulo quando il servizio ID visitatore viene implementato nella pagina. Se utilizzi un codice di reindirizzamento personalizzato nel Compositore esperienza visivo o nel Compositore basato su moduli, assicurati di passare questi parametri con il codice personalizzato.

I miei server web rimuovono questi parametri dai miei URL, cosa devo fare?

Sarà necessario lavorare con il team IT per spostare questi parametri ( adobe_mc_sdid e adobe_mc_ref ) nella whitelist di parametri affidabili.

Cosa succede se non uso A4T con la mia attività di reindirizzamento e non voglio che questi parametri vengano aggiunti ai miei URL?

Se non utilizzi A4T con l’attività di reindirizzamento, disponi del servizio ID visitatore implementato e questi parametri non devono essere aggiunti automaticamente agli URL, utilizza un reindirizzamento con codice personalizzato.
Tuttavia, come best practice, è possibile mantenere il parametro adobe_mc_ref nell’URL per segnalare correttamente le informazioni di riferimento a Analytics.

Perché i parametri adobe_mc_ref e adobe_mc_sdid sono codificati con doppio URL nella mia implementazione?

Se utilizzi A4T e le offerte di reindirizzamento, Target aggiunge i parametri adobe_mc_ref e adobe_mc_sdid all’URL. Questi valori sono già codificati nell’URL. Nella maggior parte dei casi tutto funziona come previsto, tuttavia alcuni clienti potrebbero usare bilanciatori di carico o server web che tentano di codificare nuovamente i parametri della stringa di query.
A causa di questa doppia codifica quando l’API dei visitatori tenta di decodificare il valore adobe_mc_sdid , non può estrarre il valore SDID e genera un nuovo SDID. Questo porta all’invio di valori SDID errati a Target e Analytics, e vedrai una suddivisione irregolare dei reindirizzamenti nei rapporti di Analytics.
Si consiglia di parlare con il proprio team IT per assicurarsi che adobe_mc_ref e adobe_mc_sdid siano inseriti nelle whitelist in modo che tali valori non vengano trasformati in alcun modo.

Perché l’URL di riferimento deve essere passato alla nuova pagina?

Supponiamo che un visitatore faccia clic in `www.google.com` su un collegamento che porta alla tua pagina principale ([ www.mysite.com/index.html] ) sulla quale è stata pubblicata un’attività di reindirizzamento, e viene quindi reindirizzato a una nuova pagina (`www.mysite.com/index2.html`).
In precedenza, la richiesta di Analytics della nuova pagina avrebbe segnalato l’URL di riferimento `www.mysite.com/index.html` anziché `www.google.com`. Questo causava una segnalazione inesatta in Analytics associata agli URL di riferimento (ad esempio nei rapporti Canale marketing,). Nei rapporti andava perso il fatto che il visitatore era giunto al sito da `www.google.com`.
Con at.js versione 0.9.6 (o successiva) e AppMeasurement.js 2.1 (o versioni successive), la richiesta di Analytics sulla nuova pagina segnalerà `www.google.com` come URL di riferimento.

Posso usare le offerte di reindirizzamento personalizzate/HTML?

No, è necessario utilizzare un’offerta di reindirizzamento integrata per attività che utilizzano Analytics come origine per la generazione di rapporti (A4T). Dal punto di vista di Target, le offerte HTML sono opache: Target non può sapere che un particolare pezzo di HTML contiene JavaScript che crea un’istanza di un reindirizzamento.