Perguntas frequentes sobre at.js

Respostas às perguntas frequentes sobre a at.js.

Quais as vantagens de usar a at.js versus a mbox.js?

Embora at.js substitua mbox.js, mbox.js continuará a ser suportado. No entanto, para a maioria das pessoas, at.js oferece vantagens em relação a mbox.js.

Entre outros benefícios, a at.js melhora os tempos de carregamento de página para implementações da Web, melhora a segurança e fornece opções de implementações melhores para aplicativos de página única.

O diagrama a seguir ilustra o desempenho do carregamento de página usando a mbox.js versus a at.js.

Como ilustrado acima, usando a mbox.js, o conteúdo da página não inicia o carregamento até que a chamada do Target seja concluída. Usando a at.js, o conteúdo da página inicia o carregamento ao iniciar a chamada do Target e não espera até que ela seja concluída.

Qual é o impacto da at.js e da mbox.js nos tempos de carregamento de página?

Muitos clientes e consultores querem saber o impacto da at.js e da mbox.js no tempo de carregamento de página, principalmente no contexto de usuários novos e recorrentes. Infelizmente, é difícil medir e fornecer números concretos sobre como a at.js ou a mbox.js influenciam no tempo de carregamento de página devido à implementação de cada cliente.

No entanto, se a API de visitante estiver presente na página, é possível entender melhor como a at.js e a mbox.js influenciam no tempo de carregamento de página.

As seções a seguir descrevem a sequência de ações para visitantes novos e recorrentes:

Novos visitantes

1. A API do visitante é carregada, analisada e executada.

2. A at.js / mbox.js é carregada, analisada e executada.

3. Se a criação automática da mbox global estiver ativada, a biblioteca JavaScript do Target:

   • Iniciará o objeto do visitante.
   • A biblioteca do Target tentará recuperar os dados de ID de visitante da Experience Cloud.
   • Como esse é um novo visitante, a API de visitante enviará uma solicitação de domínio cruzado para demdex.net.
   • Depois que os dados de ID de visitante da Experience Cloud forem recuperados, será enviada uma solicitação para o Target.

Visitantes que retornam

1. A API do visitante é carregada, analisada e executada.

2. A at.js / mbox.js é carregada, analisada e executada.

3. Se a criação automática da mbox global estiver ativada, a biblioteca JavaScript do Target:

   • Iniciará o objeto do visitante.
   • A biblioteca do Target tentará recuperar os dados de ID de visitante da Experience Cloud.
   • A API de visitante recuperará os dados dos cookies.
   • Depois que os dados de ID de visitante da Experience Cloud forem recuperados, será enviada uma solicitação para o Target.

Por que parece que vejo tempos de resposta mais lentos após a atualização de uma versão anterior da at.js para a versão 1.0.0?

A versão da at.js 1.0.0 e posteriores acionam todas as solicitações paralelamente. As versões anteriores executam as solicitações sequencialmente, o que significa que elas são colocadas em uma fila e o Target aguarda até que a primeira seja concluída antes de passar para a próxima solicitação.

A forma como as versões anteriores da at.js executam as solicitações é suscetível ao chamado "bloqueio do topo da linha". Nas versões da at.js 1.0.0 e posteriores, o Target muda para a execução de solicitação paralela.

Por exemplo, se você verificar a cascata da guia de rede para a versão da at.js 0.9.1, verá que a próxima solicitação do Target não será iniciada até que a anterior tenha terminado. Com as versões do at.js 1.0.0 e posteriores isso não ocorre, pois todas as solicitações são iniciadas basicamente ao mesmo tempo.

Da perspectiva de tempo de resposta, matematicamente, isso pode ser resumido assim

• versão at.js 0.9.1: tempo de resposta de todas as solicitações do Target = soma do tempo de resposta das solicitações
• at.js 1.0.0 e posteriores: tempo de resposta de todos as solicitações do Target = máximo do tempo de resposta das solicitações

Como é possível observar, a at.js 1.0.0 concluirá mais rápido as solicitações. Além disso, as solicitações da at.js são assíncronas, por isso o Target não bloqueia a renderização da página. Mesmo que as solicitações levem alguns segundos para serem concluídas, você ainda verá a página renderizada, mas apenas algumas partes da página ficarão em branco até que o Target receba uma resposta do Target Edge.

Posso carregar a biblioteca do Target de forma assíncrona?

A versão da at.js 1.0.0 permite carregar a biblioteca do Target de forma assíncrona.

Para carregar a at.js de forma assíncrona:

• A abordagem recomendada é por meio de um gerenciador de tags, como o Adobe Launch ou o Adobe Dynamic Tag Manager (DTM). Consulte a lição Adicionar Adobe Target do tutorial Implementação do Experience Cloud com Launch para obter mais informações.

• Também é possível carregar a at.js de forma assíncrona, adicionando o atributo async à tag do script que carrega a at.js. Use algo como o seguinte:

  <script src="<URL to at.js>" async></script>
  

• Você também pode carregar a at.js de forma assíncrona usando este código:

  var script = document.createElement('script'); 
  script.async = true; 
  script.src = "<URL to at.js>"; 
  document.head.appendChild(script);
  

Carregar a at.js de forma assíncrona é uma ótima maneira de evitar o bloqueio de renderização do navegador. No entanto, essa técnica pode levar à cintilação na página da Web.

Você pode evitar a cintilação usando um snippet de pré-ocultação que oculta a página (ou partes especificadas), exibindo-a após o carregamento completo da at.js e da solicitação global. O trecho deve ser adicionado antes de carregar a at.js.

Se você estiver implantando o at.js por meio de uma implementação de inicialização assíncrona, certifique-se de incluir o trecho pré-ocultando diretamente em suas páginas, antes do código Iniciar incorporação, conforme descrito na seção Adicionar o trecho de pré-ocultação do Público alvo da seção Implementação do Experience Cloud com o tutorial de inicialização.

Se estiver implantando a at.js por meio de uma implementação DTM síncrona, o snippet de pré-ocultação pode ser adicionado por uma regra de Carregamento de página acionada na parte superior da página.

Para obter mais informações, consulte Como o at.js gerencia a cintilação.

A at.js é compatível com a integração do Adobe Experience Manager (AEM)?

O Adobe Experience Manager 6.2 com FP-11577 (ou posterior) agora é compatível com implementações da at.js com a integração do Adobe Target Cloud Services. Para obter mais informações, consulte Pacotes de recursos e Integração com o Adobe Target na documentação do Adobe Experience Manager 6.2.

Como posso evitar a cintilação de carregamento de página usando a at.js?

O Target fornece várias maneiras de evitar a cintilação do carregamento de página. Para obter mais informações, consulte Como evitar a cintilação com o at.js.

Qual é o tamanho do arquivo da at.js?

O arquivo da at.js tem aproximadamente 109 KB quando baixado. No entanto, como a maioria dos servidores compacta automaticamente os arquivos para diminuir os tamanhos, a at.js fica com aproximadamente 34 KB quando é compactada (usando GZIP ou outro método) em seu servidor e é carregada conforme os usuários visitam o site. As configurações de compactação no servidor onde a at.js foi instalada determinam o seu tamanho compactado real.

Por que o at.js é maior que o mbox.js?

As implementações da at.js usam uma única biblioteca (at.js), enquanto as implementações de mbox.js na verdade usam duas bibliotecas, (mbox.js e target.js). Por isso, uma comparação mais justa seria de at.js versus mbox.js e target.js. Comparação entre os tamanhos gzipped das duas versões, a at.js versão 1.2 tem 34 KB e a mbox.js versão 63 tem 26.2 KB. ``

A at.js é maior, pois realiza muito mais análise de DOM em comparação à mbox.js. Isso é necessário porque a at.js recebe dados "brutos" na resposta JSON e precisa entender isso. A mbox.js usa document.write() e todas as análises são realizadas pelo navegador.

Embora o tamanho do arquivo seja maior, nossos testes indicam que as páginas carregam mais rápido com a at.js versus a mbox.js. Além disso, em questão de segurança, a at.js é superior, pois não carrega arquivos adicionais dinamicamente ou usa o document.write.

A at.js contém um jQuery? Posso remover essa parte da at.js já que tenho o jQuery no meu site?

A at.js atualmente usa partes do jQuery e, consequentemente, você verá a notificação de licença do MIT na parte superior da at.js. O jQuery não está exposto e não interfere na biblioteca do jQuery que já existe na sua página, que pode ser de uma versão diferente. A remoção do código do jQuery na at.js não é suportado.

A at.js é compatível com o Safari e com o domínio cruzado definido como somente x?

Não, se o domínio cruzado estiver definido como somente x e o Safari tiver cookies de terceiros desativados, a mbox.js e a at.js vão definir um cookie desativado e nenhuma solicitação de mbox será executada para o domínio desse cliente específico.

Para auxiliar os visitantes do Safari, um Domínio X melhor seria "desativado" (define apenas um cookie primário) ou "ativado" (define apenas um cookie primário no Safari, enquanto define cookies primários e de terceiros em outros navegadores).

Posso executar a at.js e a mbox.js paralelamente?

Não na mesma página. No entanto, ao implementar e testar a at.js, é possível executar a at.js em algumas páginas e a mbox.js em outras, até que você tenha validado completamente a at.js.

Posso usar o Target Visual Experience Composer nos meus aplicativos de página única?

Sim, você pode usar o VEC para SPA se utilizar a at.js 2.x. Para obter mais informações, consulte Página única (SPA) do Visual Experience Composer.

Posso usar o depurador da Adobe Experience Cloud com implementações da at.js?

Sim. Também é possível usar a mboxTrace para fins de depuração ou as Ferramentas de desenvolvedor do navegador para inspecionar as solicitações da rede, filtrando como "mbox", a fim de isolar as chamadas da mbox.

Posso usar caracteres especiais em nomes de mbox com a at.js?

Sim, o mesmo que ocorre com a mbox.js.

Por que as mboxes não estão sendo acionadas nas minhas páginas da Web?

Os clientes do, às vezes, usam instâncias baseadas em nuvem com o TargetTarget para testes ou fins de prova de conceito simples. Esses domínios e muitos outros fazem parte da Lista de sufixos públicos.

Se estiver usando esses domínios, os navegadores modernos não salvarão os cookies, a menos que você personalize a configuração de cookieDomain usando targetGlobalSettings(). Para obter mais informações, consulte Uso de instâncias baseadas em nuvem com o Target.

Os endereços IP podem ser usados como o domínio de cookie ao usar a at.js?

Sim, se estiver usando a at.js versão 1.2 ou posterior. No entanto, recomendamos que você se mantenha atualizado com a versão mais recente.

Dependendo de como você usa targetGlobalSettings, talvez seja necessário fazer modificações adicionais no código depois de baixar a at.js. Por exemplo, se você precisava de configurações ligeiramente diferentes para as implementações do Target em vários sites e não pode defini-las dinamicamente usando o JavaScript personalizado, faça essas personalizações manualmente depois de baixar o arquivo e antes de fazer upload para os respectivos sites.

Os exemplos a seguir permitem usar a função targetGlobalSettings() at.js para inserir um trecho de código para suportar endereços IP:

Este exemplo é para um único endereço IP:

if (window.location.hostname === '123.456.78.9') { 
    window.targetGlobalSettings = window.targetGlobalSettings || {}; 
    window.targetGlobalSettings.cookieDomain = window.location.hostname; 
}

Este exemplo é para uma série de endereços IP:

if (/^123\.456\.78\..*/g.test(window.location.hostname)) { 
    window.targetGlobalSettings = window.targetGlobalSettings || {}; 
    window.targetGlobalSettings.cookieDomain = window.location.hostname; 
}

Por que vejo mensagens de aviso, como "ações com seletores ausentes"?

Estas mensagens não estão relacionadas a funcionalidade da at.js. A biblioteca at.js tenta informar tudo que não pode ser encontrado no DOM.

Caso veja esta mensagem de aviso, as possíveis causas raiz podem ser as seguintes:

• A página está sendo construída dinamicamente e o at.js não consegue localizar o elemento.

• A página está sendo construída lentamente (devido a uma rede lenta) e o at.js não consegue localizar o seletor no DOM.

• A estrutura de página em que a atividade está sendo executada foi alterada. Se você reabrir a atividade no Visual Experience Composer (VEC), deverá receber uma mensagem de aviso. Você deve atualizar a atividade para que todos os elementos necessários possam ser encontrados.

• A página subjacente faz parte de um Aplicativo de página única (SPA, Single Page Application) ou a página contém elementos que são exibidos mais abaixo e o "mecanismo de buscas do seletor" da at.js não consegue encontrá-los. Aumentar o selectorsPollingTimeout pode ajudar. Para obter mais informações, consulte targetGlobalSettings().

• Todas as métricas de rastreamento de cliques tentam se adicionar a cada página, independentemente do URL em que a métrica foi configurada. Embora inofensiva, essa situação faz com que muitas dessas mensagens sejam exibidas.

  Para obter melhores resultados, baixe e use a versão mais recente da at.js. Para obter mais informações, consulte Detalhes da versão da at.js e Download at.js.

Qual é o domínio tt.omtrdc.net para o qual as chamadas de servidor Target são direcionadas?

O tt.omtrdc.net é o nome de domínio da rede EDGE da Adobe, usado para receber todas as chamadas do Target.

Por que a at.js e mbox.js não usam os sinalizadores de cookies HttpOnly e Seguro?

HttpOnly pode ser definido somente pelo código do lado do servidor. Os cookies do Target, como mbox, são criados e salvos pelo código JavaScript, para que o Target não possa usar o sinalizador de cookies HttpOnly.

Seguro pode ser definido somente por JavaScript, quando a página tiver sido carregada por HTTPS. Se a página inicialmente carregar por meio de HTTP, o JavaScript não poderá definir esse sinalizador. Além disso, se o sinalizador Seguro for usado, o cookie estará disponível somente nas páginas HTTPS.

Para garantir que o Target possa rastrear os usuários corretamente e, como os cookies são gerados no lado do cliente, o Target não usa nenhum desses sinalizadores.

Com que frequência a at.js dispara uma solicitação de rede?

O Adobe Target executa todas as suas decisões no lado do servidor. Isso significa que a at.js dispara uma solicitação de rede sempre que a página é recarregada ou uma API pública da at.js é chamada.

Na melhor das hipóteses, podemos esperar que o usuário não tenha nenhum efeito visível no carregamento da página relacionado à ocultação, substituição e exibição de conteúdo?

A at.js tenta evitar esconder previamente o HTML BODY ou outros elementos DOM por um longo período de tempo, mas isso depende das condições da rede e da configuração da atividade. O at.js fornece configurações que você pode usar para personalizar o estilo CSS de ocultação do BODY, de modo que, em vez de esvaziar todo o HTML BODY, você possa pré-ocultar apenas algumas partes da página. A expectativa é que essas partes contenham elementos DOM que precisam ser "personalizados".

Qual é a sequência de eventos em um cenário médio em que um usuário se qualifica para uma atividade?

A solicitação da at.js é uma XMLHttpRequest assíncrona, para a execução das seguintes etapas:

1. A página é carregada.
2. A at.js pré-oculta o HTML BODY. Há uma configuração para pré-ocultar um determinado contêiner em vez do HTML BODY.
3. A solicitação da at.js é disparada.
4. Depois que a resposta do Target é recebida, o Target extrai os seletores de CSS.
5. Usando seletores de CSS, o Target cria tags STYLE para pré-ocultar os elementos DOM que serão personalizados.
6. O HTML BODY que pré-oculta o STYLE é removido.
7. O Target inicia a pesquisa de elementos DOM.
8. Se um elemento DOM for encontrado, o Target aplicará as alterações do DOM, e o elemento pré-ocultando STYLE será removido.
9. Se os elementos DOM não forem encontrados, um tempo limite global desativa os elementos para evitar uma página quebrada.

Com que frequência o conteúdo da página é totalmente carregado e visível quando a at.js finalmente desmarca remove a ocultação do elemento que a atividade está mudando?

Considerando o cenário acima, com que frequência o conteúdo da página é totalmente carregado e visível quando a at.js finalmente desmarca remove a ocultação que a atividade está mudando? Em outras palavras, a página é totalmente visível, exceto pelo conteúdo da atividade, que é revelado um pouco após o restante do conteúdo.

A at.js não bloqueia a renderização da página. Um usuário pode notar algumas regiões em branco na página, que representam elementos a serem personalizados pelo Target. Se o conteúdo a ser aplicado não tiver muitos recursos remotos, como SCRIPTs ou IMGs, tudo deverá ser renderizado rapidamente.

Como uma página totalmente armazenada em cache afetaria o cenário acima? Seria mais provável que o conteúdo da atividade se tornasse visível depois que o restante do conteúdo da página fosse carregado?

Se uma página for armazenada em cache em um CDN próximo à localização do usuário, mas não próximo à borda do Target, esse usuário poderá ver alguns atrasos. As bordas do Target são bem distribuídas em todo o mundo, portanto, isso não é um problema na maioria das vezes.

É possível que uma imagem herói seja exibida e depois removida após um pequeno atraso?

Considere o seguinte cenário:

O tempo limite do Target é de cinco segundos. Um usuário carrega uma página que possui uma atividade para personalizar uma imagem herói. A at.js envia a solicitação para determinar se há uma atividade a ser aplicada, mas não há resposta inicial. Suponha que o usuário veja o conteúdo regular da imagem herói, porque nenhuma resposta foi recebida do Target sobre alguma atividade associada. Após quatro segundos, o Target retorna uma resposta com o conteúdo da atividade.

Nessa etapa, seria possível mostrar a versão alternativa? Então, depois de quatro segundos, a imagem herói pode ser removida e o usuário pode perceber essa troca de imagem?

Inicialmente, o elemento DOM da imagem herói está oculto. Depois que uma resposta do Target é recebida, at.js aplica as alterações do DOM, como a substituição do IMG e a exibição da imagem herói personalizada.

Qual doctype HTML é exigido pela at.js?

A at.js exige o doctype HTML 5.

Esta sintaxe é:

<!DOCTYPE html>

O doctype HTML 5 garante que a página carregue no modo padrão. Ao carregar no modo quirks, algumas APIs de JS das quais a at.js depende são desativadas. O Target desativa a at.js no modo quirks.