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.

OBSERVAÇÃO

A API do visitante e a at.js ou a mbox.js têm um impacto no tempo de carregamento de página apenas quando estiver usando a mbox global (por causa da técnica de ocultação do corpo). As mboxes regionais não são afetadas pela integração da API do visitante.

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.
OBSERVAÇÃO

Para novos visitantes, quando a API de visitante estiver presente, o Target precisará transmitir as informações várias vezes para garantir que as solicitações do Target contenham os dados de ID de visitante da Experience Cloud. Para os visitantes recorrentes, o Target transmitirá as informações apenas para recuperar o conteúdo personalizado.

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 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 é via Adobe Experience Platform Launch. Consulte a lição Adicionar Adobe Target do tutorial Implementar o Experience Cloud em sites com o 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 estiver implantando a at.js por meio de uma implementação assíncrona do Launch, certifique-se de incluir o trecho pré-ocultação diretamente nas páginas, antes do código Incorporado do Launch, conforme descrito no Adicionar o trecho de pré-ocultação do Target do Implementar o Experience Cloud em sites com o Launch tutorial.

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.

OBSERVAÇÃO

Os seguintes exemplos não são necessários se estiver usando a at.js versão 1.2 ou posterior.

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?lang=pt-BR)) { 
    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 criada dinamicamente e a at.js não pode encontrar o elemento .

  • A página está sendo criada lentamente (devido a uma rede lenta) e a at.js não consegue encontrar 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.

Nesta página

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now