Show Menu
TÓPICOS×

Ofertas de redirecionamento - Perguntas frequentes sobre o A4T

Este tópico contém respostas para perguntas frequentes sobre o uso de ofertas de redirecionamento ao usar o Analytics como origem de geração de relatórios do Target (A4T).

O Analytics for Target (A4T) é compatível com as ofertas de redirecionamento?

Sim, contanto que sua implementação use 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 .

Quais são os requisitos mínimos necessários para usar as ofertas de redirecionamento com o A4T?

Sua implementação deve atender os seguintes requisitos mínimos:
  • Serviço de ID de visitante da Experience Cloud: visitorAPI.js versão 2.3.0 ou superior.
  • Adobe Analytics: appMeasurement.js versão 2.1.
  • Adobe Target: at.js versão 1.6.2 ou posteriores.
    A biblioteca mbox.js não é compatível com as ofertas de redirecionamento com o A4T. Sua implementação deve usar at.js.
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.

Por que algumas vezes existem discrepâncias de dados entre o A4T e o Analytics?

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 .

Por que as visualizações de página na página original e na página de redirecionamento são contadas às vezes?

Ao usar o at.js versão 1.6.3 ou posterior, isso 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. Isso 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. Isto acontece devido ao local onde 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. Isso garante que, se ocorrer uma contagem incorreta, ela ocorrerá em todas as experiências, de forma que o relatório e a análise ainda sejam 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 .

Posso usar as ofertas de redirecionamento com o A4T se eu estiver usando a biblioteca JavaScript da mbox.js?

A biblioteca mbox.js não é compatível com as ofertas de redirecionamento com o A4T. Sua implementação deve usar at.js.

O Visual Experience Composer (VEC) e o Experience Composer baseado em formulários são suportados?

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).

Quais são os novos parâmetros de cadeia de caracteres de consulta adicionados aos URLs de redirecionamento?

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 parâmetro adobe_mc_sdid passa a Id de Dados complementares (SDID) e a Id de Org da Experience Cloud da página padrão para a página nova para que o A4T "identifique" ao mesmo tempo a solicitação do Target na página padrão com a solicitação do Analytic na página nova.
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 superior), o Analytics usará o valor deste parâmetro como URL de referência na página nova.
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.

Meus servidores da web estão removendo esses parâmetros de meus URLs. O que devo fazer?

You will need to work with your IT team to have these parameters ( adobe_mc_sdid and adobe_mc_ref ) allowlisted.

E se eu não estiver usando o A4T com minha atividade de redirecionamento e não quiser que esses parâmetros extras sejam adicionados aos meus URLs?

Se você não estiver usando o A4T com sua atividade de redirecionamento, tiver o serviço de identificação do visitante implementado e não quiser que esses parâmetros sejam adicionados automaticamente aos seus URLs, será necessário usar um redirecionamento codificado personalizado.
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.

Por que os parâmetros adobe_mc_ref e adobe_mc_sdid estão codificados com URL duplo na minha implementação?

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. Isso faz com que valores SDID incorretos sejam enviados para o Target e para o Analytics. Você verá a divisão desigual para redirecionamentos nos relatórios do Analytics.
We recommend that you talk to their IT team to ensure that adobe_mc_ref and adobe_mc_sdid are allowlisted so that these values are not transformed in any way.

Por que o URL de referência precisa ser passado para a nova página?

Suppose a visitor clicks a link on `www.google.com` to your homepage ( www.mysite.com/index.html ) on which a redirect activity is live and is then redirected to a new page ( 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 a at.js versão 0.9.6 (ou posterior) e a AppMeasurement.js 2.1 (ou posterior), a solicitação do Analytics na nova página relatará um URL de referência do `www.google.com`.

Posso usar ofertas de redirecionamento personalizadas/HTML?

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.