Este tópico contém respostas para as perguntas mais frequentes sobre o uso de ofertas de redirecionamento ao usar Adobe Analytics como fonte de relatórios para Adobe Target (A4T).
Sim, se sua implementação usar at.js. No entanto, sua implementação deve atender aos requisitos mínimos listados abaixo para usar ofertas de redirecionamento em atividades que utilizam o Analytics como a fonte de relatórios.
Existe um problema conhecido que faz com que um número limitado de clientes que usam redirecionamentos com A4T vejam uma porcentagem maior de taxas de hit não unificadas. Consulte Problemas conhecidos e problemas resolvidos.
Sua implementação deve atender os seguintes requisitos mínimos:
As três bibliotecas devem ser incluídas na página com a oferta de redirecionamento e na página para a qual o visitante será redirecionado.
Algumas discrepâncias de dados são esperadas. Para obter mais informações, consulte Variações de dados esperadas entre o Target e o Analytics ao usar ou não o A4T.
Um número limitado de clientes relatou graus mais altos de variação na distribuição do tráfego ao usar ofertas de redirecionamento em atividades configuradas com Analytics para Target (A4T).
Considere o seguinte:
Ordem incorreta de Target e Analytics as chamadas podem ser responsáveis por graus mais altos de variação.
O Target a chamada deve preceder a Analytics na página de origem (onde o redirecionamento ocorre) e na página de destino (onde o redirecionamento termina).
Certifique-se de usar as ofertas de redirecionamento nas atividades de redirecionamento do A4T.
Se houver vários Target solicitações de localização na página de origem (onde o redirecionamento ocorre), Adobe A recomenda executar a atividade de redirecionamento na primeira Target solicitação de local.
Execução da atividade de redirecionamento na primeira Target solicitação de local reduz as chances de qualquer qualificação de atividade ocorrer em outros Target solicitações de localização e sendo contadas no relatório. Os visitantes que são redirecionados não precisam ser contados nos relatórios de outras atividades, pois não verão as experiências.
Ao usar a at.js versão 1.6.3 ou posterior, contar as exibições de página em ambas as páginas não é um problema. Essa condição de corridas afeta apenas os clientes que usam as versões anteriores. A equipe do Target mantém duas versões do at.js, a versão atual e a segunda versão mais recente. Atualize o at.js conforme necessário para garantir que você esteja executando uma versão compatível.
Se você estiver usando uma versão anterior não compatível do at.js, existe a possibilidade de ocorrer uma condição de corrida que pode fazer com que a chamada do Analytics seja acionada antes que o redirecionamento seja executado na primeira página. Essa situação pode fazer com que as visualizações de página na página original e na página de redirecionamento sejam todas contadas. Essa situação resulta em uma exibição de página extra na primeira página, quando o visitante nunca "viu" realmente essa primeira página.
Usar o compositor baseado em formulário para criar uma atividade de redirecionamento é recomendado para aumentar a velocidade do redirecionamento da página devido ao local em que o código é executado na página. Além disso, é recomendável criar uma oferta de redirecionamento para cada experiência, até mesmo para a experiência padrão, na qual o redirecionamento retornaria a página original. Criar uma oferta de redirecionamento para cada experiência garante que, se ocorrer uma contagem incorreta, ela ocorra em todas as experiências. Os relatórios e análises ainda são válidos para o teste.
Um motivo para usar ofertas de redirecionamento para todas as experiências na atividade, incluindo a experiência padrão (controle), é colocar as mesmas condições em todas as experiências. Por exemplo, se a experiência padrão não tiver uma oferta de redirecionamento, mas as outras experiências tiverem ofertas redirecionadas, a velocidade da experiência sem a oferta de redirecionamento terá uma vantagem inerente. O redirecionamento de ofertas é recomendado apenas para cenários temporários, como testes. O redirecionamento de ofertas não é recomendado para cenários permanentes, como personalização. Depois de determinar o “vencedor”, você deve remover o redirecionamento para melhorar o desempenho do carregamento da página.
Para obter mais informações sobre esse problema, consulte as informações das “Ofertas de redirecionamento” em Problemas conhecidos.
Sim, ambos os compositores são compatíveis, desde que você use as ofertas de redirecionamento integradas.
Se você usa seu próprio código personalizado para o redirecionamento, deve garantir que preenche os dois novos parâmetros associados aos URLs de redirecionamento (adobe_mc_sdid
e adobe_mc_ref
, explicados abaixo).
Os seguintes parâmetros de cadeia de caracteres de consulta estão associados a ofertas de redirecionamento:
Parâmetro | Descrição |
---|---|
adobe_mc_sdid |
O adobe_mc_sdid passa a ID de Dados Suplementares (SDID) e a ID de Org de Experience Cloud da página padrão para a página nova. Essas IDs permitem que o A4T "junte" a solicitação do Target na página padrão com a solicitação do Analytics na nova página. |
adobe_mc_ref |
O parâmetro adobe_mc_ref passa o URL de referência da página padrão para a página nova. Quando usado com o AppMeasurement.js versão 2.1 (ou posterior), o Analytics usa esse valor de parâmetro como o URL de referência na nova página. |
Esses parâmetros são adicionados automaticamente aos URLs de redirecionamento ao usar as ofertas de redirecionamento integradas no VEC e no Experience Compose baseado em formulário quando o serviço de identificação do visitante está implementado na página. Se você estiver usando seu próprio código de redirecionamento personalizado no VEC ou no Compositor baseado em formulário, deve certificar-se de passar esses parâmetros com seu código personalizado.
Trabalhe com sua equipe de TI para ter esses parâmetros ( adobe_mc_sdid
e adobe_mc_ref
) incluir na lista de permissões.
Use um redirecionamento codificado personalizado se:
No entanto, como prática recomendada, convém manter o parâmetro adobe_mc_ref
no URL para relatar as informações do referenciador ao Analytics corretamente.
Se você usa o A4T e ofertas de redirecionamento, o Target anexa os parâmetros adobe_mc_ref
e adobe_mc_sdid
ao URL. Esses valores já estão codificados por URL. Na maioria das vezes, tudo funciona conforme o esperado, no entanto, alguns clientes podem ter balanceadores de carga ou servidores WEB que tentam codificar os parâmetros de cadeia de caracteres de consulta mais uma vez.
Devido a essa codificação dupla, quando a API de visitante tenta decodificar o valor adobe_mc_sdid
, ele não pode extrair o valor SDID e gera um novo SDID. Esse processo faz com que valores SDID incorretos sejam enviados para o Target e o Analytics, e você vê a divisão desigual para redirecionamentos nos relatórios do Analytics.
A Adobe recomenda que você converse com sua equipe de TI para garantir que adobe_mc_ref
e adobe_mc_sdid
são incluir na lista de permissões para que esses valores não sejam transformados de forma alguma.
Suponha que um visitante clique em um link em www.google.com
na sua página inicial (www.mysite.com/index.html
) na qual uma atividade de redirecionamento está ao vivo e é redirecionada para uma nova página (www.mysite.com/index2.html
).
Anteriormente, a solicitação do Analytics na nova página relataria um URL de referência do www.mysite.com/index.html
em vez de www.google.com
. Isso causava a geração de relatórios imprecisos no Analytics associados aos URLs de referência (relatórios de canal de marketing, por exemplo). Os relatórios perderam o fato de que você veio ao site de www.google.com
.
Com at.js versão 0.9.6 (ou posterior) e AppMeasurement.js 2.1 (ou posterior), a variável Analytics na nova página, relata um URL de referência de www.google.com
.
Não, você deve usar as ofertas de redirecionamento incorporadas para atividades que usam o Analytics como fonte de geração de relatórios (A4T). Da perspectiva do Target, as ofertas de HTML são opacas: o Target não pode saber que uma determinada parte do HTML contém JavaScript que instancia um redirecionamento.
As seguintes perguntas frequentes fornecem mais informações sobre o uso do A4T e ofertas de redirecionamento com a Platform Web SDK.
Sim, o A4T por meio do SDK da Web da plataforma é compatível ofertas de redirecionamento.
Sim, o Visual Experience Composer (VEC) e a Experience Composer baseado em formulário são compatíveis se você usar ofertas de redirecionamento incorporadas.
Não, você deve usar uma oferta de redirecionamento integrada para atividades que usam o A4T. No Target em perspectiva, as ofertas de HTML são opacas. Target Não é possível saber que uma determinada parte do HTML contém JavaScript que instancia um redirecionamento.