Questo argomento contiene le risposte alle domande che vengono spesso poste in merito alle offerte di reindirizzamento durante l’utilizzo di Adobe Analytics come origine di reporting per Adobe Target (A4T).
+++Risposta Sì, se l’implementazione utilizza 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.
+++
Le tre librerie devono essere incluse sia nella pagina con l’offerta di reindirizzamento sia nella pagina a cui il visitatore viene reindirizzato.
+++Risposta Sono previste alcune discrepanze di dati. Per ulteriori informazioni, consulta Varianze di dati previste tra Target e Analytics durante l’utilizzo con e senza A4T.
+++
Considera i seguenti aspetti:
Ordine errato Target e Analytics Le chiamate di potrebbero essere responsabili di livelli più elevati di varianza.
Il Target la chiamata deve precedere la Analytics sulla pagina sorgente (dove si verifica il reindirizzamento) e sulla pagina di destinazione (dove termina il reindirizzamento).
Assicurati di utilizzare le offerte di reindirizzamento nelle attività di reindirizzamento A4T.
Se sono presenti più Target richieste di posizione nella pagina sorgente (dove si verifica il reindirizzamento), Adobe consiglia di eseguire l’attività di reindirizzamento il primo Target richiesta di posizione.
Esecuzione dell’attività di reindirizzamento sul primo Target la richiesta di posizione riduce le possibilità che le qualifiche dell’attività si verifichino su altri Target richieste di posizione e conteggio nel rapporto. I visitatori che vengono reindirizzati non devono essere conteggiati nei rapporti di altre attività in quanto non vedranno le esperienze.
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. Questa situazione può causare il conteggio di tutte le visualizzazioni di pagina sulla pagina originale e sulla pagina 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.
Si consiglia di utilizzare il compositore basato su moduli per creare un’attività di reindirizzamento per aumentare la velocità del reindirizzamento della pagina a causa della posizione in cui il codice viene eseguito sulla pagina. Inoltre, è consigliato creare un’offerta di reindirizzamento per ogni esperienza, anche per quella predefinita, dove il reindirizzamento riporta alla pagina originale. La creazione di un’offerta di reindirizzamento per ogni esperienza assicura che il conteggio errato si verifichi in tutte le esperienze. I rapporti e l’analisi sono ancora 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.
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).
Parametro | Descrizione |
---|---|
adobe_mc_sdid |
Il adobe_mc_sdid Il parametro passa l’ID di dati supplementari (SDID) e l’ID dell’organizzazione dell’Experience Cloud dalla pagina predefinita alla nuova pagina. Questi ID consentono a A4T di "unire" la richiesta Target nella pagina predefinita con la richiesta Analytics nella nuova pagina.Il formato previsto per il passaggio di sdid nell’URL (per le app ibride o da un’app al sito web o da un sito web a un altro) è `ex. adobe_mc_sdid=SDID=123 |
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 utilizza 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.
+++Risposta Lavora con il tuo team IT per avere questi parametri ( adobe_mc_sdid
e adobe_mc_ref
) inserito nell'elenco Consentiti.
+++
Tuttavia, come best practice, è possibile mantenere il parametro adobe_mc_ref
nell’URL per segnalare correttamente le informazioni di riferimento a Analytics.
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 processo porta all’invio di valori SDID errati a Target e Analytics, e nei rapporti di Analytics viene visualizzata una suddivisione irregolare per i reindirizzamenti.
Adobe consiglia di parlare con il team IT per assicurarsi che adobe_mc_ref
e adobe_mc_sdid
vengono inserite nell'elenco Consentiti in modo che tali valori non vengano trasformati in alcun modo.
www.google.com
alla tua homepage (www.mysite.com/index.html
) sulla quale è stata pubblicata un'attività di reindirizzamento che viene quindi reindirizzata 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 successiva), il Analytics nella nuova pagina segnala un URL di riferimento di www.google.com
.
+++Risposta n., è 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.
+++
Le seguenti domande frequenti forniscono ulteriori informazioni sull’utilizzo di A4T e sulle offerte di reindirizzamento con Platform Web SDK.
+++Risposta Sì, A4T tramite Platform Web SDK supporta offerte di reindirizzamento.
+++
+++Risposta Sì, il Compositore esperienza visivo (VEC) e Compositore esperienza basato su moduli sono supportate se utilizzi le offerte di reindirizzamento integrate.
+++
+++Risposta n., è necessario utilizzare un’offerta di reindirizzamento integrata per attività che utilizzano A4T. Dalla sezione Target prospettiva, le offerte HTML sono opache. Target non può sapere che un particolare pezzo di HTML contiene JavaScript che crea un’istanza di un reindirizzamento.
+++