Show Menu
TÓPICOS×

Minimizar contagens inflacionadas de visitas e visitantes no A4T

Informações para ajudá-lo a minimizar os efeitos de contagens inflacionadas de Visitas e Visitantes ao usar o Analytics como origem de geração de relatórios.
Em 14 de novembro de 2016, o Adobe Analytics mudou a forma como os dados são processados para clientes que usam a criação de relatórios do Analytics para Target (A4T). Essas alterações alinham melhor os dados do Adobe Target com o modelo de dados para Adobe Analytics. Essas alterações foram implementadas para todos os clientes utilizando A4T. Essas alterações são direcionadas especificamente a um problema em que alguns clientes notaram um contador de visitantes inflado quando há atividades do Target em execução.
Observe que essa alteração não é retroativa. Se seus relatórios históricos mostrarem contagens aumentadas e você quiser excluí-las de seus relatórios, poderá criar um conjunto de relatórios virtuais, conforme explicado abaixo.
Além disso, várias bibliotecas de JavaScript foram atualizadas para ajudar a minimizar as contagens infladas. Recomendamos que você faça upgrade das seguintes versões de biblioteca (ou mais recentes):
  • 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 0.9.6 ou posterior (exceto a versão 1.1.0, se estiver usando ofertas de redirecionamento com A4T).
A biblioteca mbox.js não é compatível com as ofertas de redirecionamento com o A4T. Sua implementação deve usar at.js.

O que mudou?

Quando o Adobe Analytics é usado para medir as atividades do Target (chamado A4T), o Analytics coleta dados adicionais que não estão disponíveis quando não há nenhuma atividade do Target na página. Isso ocorre porque a atividade do Target aciona uma chamada na parte superior da página, mas o Analytics geralmente aciona suas chamadas de coleta de dados na parte inferior da página. Na implementação do A4T até o momento, incluímos estes dados adicionais sempre que uma atividade do Target estava ativa. A partir de agora, incluiremos esses dados adicionais apenas quando as tags do Target e do Analytics forem acionadas.

Por que a Adobe fez essa alteração?

A Adobe orgulha-se de sua qualidade e precisão de dados. Quando a tag do Target é disparada, mas a tag do Analytics não, estamos registrando "dados parciais" (algumas vezes chamados de "acessos não corrigidos"), que não seriam capturados pelo Analytics se não houvesse atividade do Target. Embora a inclusão desses dados parciais nos relatórios do Analytics realmente forneça informações adicionais, ela também cria inconsistência com dados históricos de períodos em que não havia atividades do Target em execução. Isso pode causar problemas para os usuários do Analytics que estão analisando tendências ao longo do tempo. Com o intuito de assegurar a consistência dos dados no Analytics, nós excluiremos todos os dados parciais.

O que contribui para dados parciais?

Nós observamos alguns clientes com taxas muito altas de dados parciais no Analytics. Isso pode ser causado por implementação inapropriada, mas também há causas legítimas.
As causas identificadas de dados parciais incluem:
  • IDs de conjunto de relatórios desalinhadas (Implementação): O conjunto de relatórios especificado durante a configuração da atividade não corresponde ao conjunto de relatórios na página em que o teste foi fornecido. Isso se parece com dados parciais porque não foi possível reconciliar os dados nos servidores do Analytics.
  • Páginas lentas: Como as chamadas do Target estão no topo da página e as chamadas do Analytics geralmente estão na parte inferior, se a página carregar lentamente, aumenta a probabilidade de um visitante sair da página após o acionamento da chamada do Target, mas antes da chamada do Analytics. Isso pode ser especialmente problemático em sites web para dispositivos móveis onde as conexões sejam geralmente mais lentas.
  • Erros de página: Se houver erros de JavaScript ou outros cenários em que cada um dos pontos de contato não é acionado (Serviços de Experience Cloud ID, Target e Analytics), o resultado será dados parciais.
  • Ofertas de redirecionamento naTargetatividade: para ofertas de redirecionamento em atividades usando o A4T, sua implementação deve atender a certos requisitos mínimos. Além disso, há informações importantes que você precisa saber. Para obter mais informações, consulte Ofertas de redirecionamento - Perguntas frequentes do A4T .
  • Versões antigas das bibliotecas: No ano passado, a Adobe fez diversas melhorias nas bibliotecas do JavaScript (appMeasurement.js, at.js/mbox.js e visitorAPI.js ) para garantir que os dados sejam enviados da maneira mais eficiente possível. Para saber mais sobre os requisitos de implementação, consulte Antes de implementar .

Quais são as práticas recomendadas para reduzir os dados parciais?

Analise as seguintes etapas, em ordem, para reduzir a coleta de dados parcial:
Etapa
Tarefa
Certifique-se de que o conjunto de relatórios selecionado no Target seja o mesmo que o conjunto na(s) página(s) onde a atividade será apresentada.
Certifique-se de que as bibliotecas visitorAPI.js, appMeasurement.js, at.js / mbox.js estão em versões compatíveis com A4T. Para saber mais sobre os requisitos de implementação, consulte Antes de implementar .
Certifique-se de que o SDID está sendo configurado em todas as chamadas do Target e do Analytics deixando a página e que elas são correspondentes.
Faça isso usando um analisador de rede ou ferramenta de depuração para assegurar que o parâmetro mboxMCSDID na(s) chamada(s) do Target corresponde ao parâmetro SDID na chamada do Analytics.
Confirme que as bibliotecas de implementação são carregadas na ordem correta nos seus sites. Para obter mais informações, consulte Análise para implementação do Target .

Como posso ver quantos dados parciais eu tenho?

Embora essas informações não sejam disponibilizadas diretamente no Analytics, você pode entrar em contato com o atendimento ao cliente da Adobe para recuperar um relatório de dados parciais. Esse relatório é destinado a auxiliar na depuração.

Como posso visualizar as tendências históricas sem dados parciais?

Como essa alteração de processamento afeta dados somente depois da data de lançamento (14 de novembro de 2016), se você desejar ajustar sua métrica histórica para correspondência, recomendamos que você crie um segmento para excluir dados parciais.
As informações a seguir relacionadas a essa alteração incluem instruções para ajudar você a definir o segmento e aplicá-lo a um conjunto de relatórios virtual para que este segmento sempre seja aplicado às suas visualizações do Analytics.
Na maioria das situações, um acesso do Target é corrigido com um acesso do Analytics em cada página da Web. Essa correção acontece se houver uma SDID consistente nas chamadas do Target e do Analytics e um Experience Cloud ID (MCID) na chamada do Analytics na mesma página. O Target geralmente tem o MCID, mas se a chamada para o Target ocorrer antes que o ID de visitante retorne, o acesso ainda será corrigido por causa do SDID. Além disso, o usuário deve permanecer na página por tempo suficiente para disparar uma chamada do Analytics depois do disparo de uma chamada do Target. Este é o cenário ideal.
Acessos a dados parciais: Os usuários algumas vezes não permanecem em uma página tempo suficiente para enviar uma chamada do Analytics, mas o Target tem um MCID apropriado. Isso resulta em acessos a dados parciais (acessos sem visualização de página do Analytics). Se esses usuários voltarem ao seu site e visualizarem uma página contendo código do Analytics, serão contados apropriadamente como visitantes recorrentes. Esses são acessos que teriam sido perdidos se você só tivesse código do Analytics na página. Alguns clientes não querem dados desses acessos porque eles inflam certas métricas (visitas) e deflacionam outras métricas (visualizações de página por visita, tempo por visita e assim por diante). Você também verá visitas sem quaisquer visualizações de página. Entretanto, ainda há razões válidas para manter esses dados.
Para minimizar os acessos com dados parciais, você pode fazer sua página carregar mais rápido, atualizar para as versões mais recentes das bibliotecas, ou criar um conjunto de relatórios virtuais que excluem esses acessos. For step-by-step instructions, see Create virtual report suites in the Analytics Components Guide .
A ilustração a seguir mostra a definição de segmento para o conjunto de relatórios virtuais:
Ao criar o conjunto de relatórios virtuais, especifique a configuração a seguir para definição de segmento (conforme mostrado na ilustração acima):
  • Exibir acesso:
  • Analytics for Target: existe
  • E
  • Visualizações de página: não existe
  • E
  • Instâncias de link personalizado: não existe
  • E
  • Instâncias de link de download: não existe
  • E
  • Instâncias de link de saída: não existe
Ocorrências órfãs:  em poucas situações, os usuários não permanecem na página por tempo suficiente para obter uma chamada do Analytics e o Target não recebe uma MCID apropriada. Esses são os que definimos como acessos "órfãos". Esses acessos representam clientes que raramente retornam e inflam contadores de visitas e visitantes de maneira imprópria.
Para minimizar esses acessos "órfãos", você pode criar um conjunto de relatórios virtuais que exclua esses acessos conforme explicado acima.

O que isso significa para meus Target relatórios?

Quando essa alteração ocorrer, você poderá observar uma redução em novos visitantes e visitas para testes ao vivo, pois Adobe não processará os dados parciais de entrada. Conversões e acessos a outras Analytics métricas não serão alterados.