Respostas às perguntas frequentes sobre a at.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.
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.
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:
A API do visitante é carregada, analisada e executada.
A at.js / mbox.js é carregada, analisada e executada.
Se a criação automática da mbox global estiver ativada, a biblioteca JavaScript do Target:
A API do visitante é carregada, analisada e executada.
A at.js / mbox.js é carregada, analisada e executada.
Se a criação automática da mbox global estiver ativada, a biblioteca JavaScript do Target:
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.
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
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.
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.
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.
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.
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.
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 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.
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).
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.
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.
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.
Sim, o mesmo que ocorre com a mbox.js.
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.
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.
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)) {
window.targetGlobalSettings = window.targetGlobalSettings || {};
window.targetGlobalSettings.cookieDomain = window.location.hostname;
}
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.
O tt.omtrdc.net é o nome de domínio da rede EDGE da Adobe, usado para receber todas as chamadas do Target.
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.
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.
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".
A solicitação da at.js é uma XMLHttpRequest
assíncrona, para a execução das seguintes etapas:
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.
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.
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.
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.