Webtrends Optimize

Webtrends Optimize é uma plataforma de A/B testing + personalization. Permite criar variantes de página, testar e tomar decisões data-driven sem deploy de front.

:::warning Nenhuma brand tem Webtrends ativo hoje O único override que já teve um account ID é o da 7k-bet-br, e lá webtrendsAccountId é undefined em dev e prod — o valor está comentado no arquivo, preservado pra referência. Todas as outras brands têm null. Ative apenas quando há experimento real rodando. :::

Configuração por brand

{ webtrendsAccountId: "251da524-89d9-43b5-a186-8309fea3b93f" }

Brand	webtrendsAccountId (prod)
7k-bet-br	undefined — valor "251da524-…" comentado no override, pronto pra reativar
Demais brands	null (não configurado)

Em dev sempre null/undefined (não roda Webtrends em dev local).

Anti-flicker CSS — REMOVIDO

O anti-flicker (body { opacity: 0 } até o WT aplicar as variantes) não existe mais no front. O <style id="wt_tagHide"> que o root.tsx renderizava inline foi removido porque causava deadlock no primeiro carregamento: o CSS ficava ativo até initWebtrends() rodar, mas o init estava enfileirado atrás dos gates do scheduler antigo (LCP + 1ª interação + delay) — resultado: página invisível até o usuário scrollar ou clicar.

Trade-off aceito hoje: pode aparecer flicker visual quando um experimento do WT troca conteúdo above-the-fold, mas a página renderiza imediatamente.

O código de initWebtrends ainda tem a função removeAntiFlicker() e um timeout de segurança de 2000ms, mas como nenhum <style id="wt_tagHide"> é renderizado, hoje ela não tem nada pra remover.

Impacto em LCP: a penalidade de "+2s" documentada antes era do anti-flicker, não do script em si. Sem o anti-flicker, o custo do Webtrends é o custo dos scripts dele (que ainda é alto) — mas não há mais bloqueio de pintura.

Como debuggar

Webtrends Optimize dashboard

Web UI da plataforma — verifique experimentos ativos, variantes, stats de conversão.

Console

Os globais que o loader do front realmente define:

window._wt_loaded       // guard de injeção única
window.WT_ABORT         // 0 = carregando · -1 = carregou (onload) · 1 = abortou (erro/timeout)

(As versões anteriores desta página citavam window.wt_sdc e window.wto — não são setados pelo loader do front. O SDK do WT pode definir globais próprios; consulte a doc da plataforma.)

Network

Filtra webtrends. O loader do front injeta:

https://c.webtrends-optimize.com/acs/accounts/<accountId>/js/wt.js

Comportamento do loader

• No-op em iframe — se window.self !== window.top, o init sai fora. Evita double-load quando o app roda embarcado (ex: iframe de depósito) e double-count de experimento.
• Injeção única por sessão — guardado por window._wt_loaded.
• Eventos que o próprio script do WT dispara (AIM_startExperiment, impressionEvent, viewEvent, clickEvent, changeEvent, detect_user, cleanup_user_property_values) vão pro window.dataLayer, que é compartilhado com o GTM. É por isso que eles vazam pra relatórios GA4 — sanitize os triggers do GTM pra não encaminhar esses eventos.

Anti-patterns

1. Deixar webtrendsAccountId setado sem experimento ativo. Carrega scripts pesados por nada. Sempre desative entre experimentos.
2. Rodar 2+ experimentos sobrepostos no mesmo elemento. Resultado vira não-determinístico. WT permite traffic allocation, use.
3. Confiar em métricas de conversão do WT sem validar contra GA4. WT tem métricas próprias; cross-validate com GA4 / GTM events.
4. Deixar trigger catch-all no GTM. Os eventos internos do WT caem no dataLayer compartilhado e poluem os relatórios.
5. Reintroduzir anti-flicker CSS sem resolver o deadlock. Se o init pode atrasar, o CSS que esconde o body tem que ter timeout próprio garantido — foi exatamente esse acoplamento que derrubou a página antes.