Wascer Debugger

Extensão interna de DevTools (Chrome) para decodificar requisições de tracking ao vivo, detectar o container server-side da Wascer e correlacionar tudo com o dataLayer da página.

Ferramenta interna — time de dev, suporte e onboarding da Wascer.

---

O que é

Durante o trabalho de tracking, o DevTools mostra as requisições de saída como URLs gigantes e ilegíveis (/g/collect?v=2&tid=...&en=purchase&ep.value=...). O Wascer Debugger intercepta essas requisições e as traduz para uma visão legível — evento, parâmetros decodificados, destino e status — e mostra qual dataLayer.push gerou cada hit.

O diferencial: ele entende o tráfego do container GTM server-side hospedado pela Wascer no domínio first-party do cliente — inclusive quando o payload vem codificado em base64 (bypass de ad-block) — algo que nenhuma ferramenta de prateleira faz.

O diferencial server-side

A maioria das ferramentas (Omnibug, Meta Pixel Helper, GA Debugger) só lê o tracking client-side. O Wascer Debugger vai além:

• Detecta o custom loader da Wascer (ex.: soureicdn.loja.com.br/loja.js) varrendo o DOM da página.
• Decodifica o hit do container server-side no domínio first-party, mesmo codificado em base64.
• Correlaciona as duas pernas: o mesmo purchase saindo do browser para o container Wascer e dele para GA4/Meta, com o lado server-side destacado (via Wascer).
• Alerta double-count: o mesmo evento indo client-side e via Wascer pro mesmo destino — o bug nº 1 de quem migra pra server-side.

Começando

Pré-requisitos: Node 18+ e Chrome (ou Edge).

npm install          # instala dependências
npm run dev          # abre o Chrome com a extensão carregada (hot reload)

Depois: abra qualquer site, F12, aba Wascer Debugger.

Build de produção:

npm run build        # gera .output/chrome-mv3
npm run zip          # empacota para distribuição

Para carregar manualmente: chrome://extensions, ativar Modo desenvolvedor, Carregar sem compactação e selecionar .output/chrome-mv3.

Funcionalidades

Captura e detecção

• Painel no DevTools com tema adaptativo (segue o light/dark do F12).
• Captura via chrome.devtools.network + backfill (getHAR): abra o painel a qualquer momento e os hits que já rolaram aparecem.
• Coletor de dataLayer injetado no main world (resistente a CSP via injectScript).
• Detecção do container Wascer por loader (DOM scan), assinaturas first-party e payload base64.

Leitura

• Decodificação rica de GA4: Consent Mode (gcs para ad_storage/analytics_storage), itens de e-commerce, dicionário expandido e grupos ordenados.
• Status HTTP por hit (verde 2xx, amarelo 3xx, vermelho erro).
• Correlação client/server com fluxo visual dataLayer -> browser -> Wascer -> vendor.
• Visualizador de dataLayer com o payload JSON de cada push.

Auditoria

• Anomalias: double-count (client + server) e transaction_id duplicado.
• Validação: purchase sem value/currency/transaction_id/itens, PII/CPF/email em texto puro (LGPD) e Consent Mode ausente.

Ergonomia

• Filtros clicáveis (events / via Wascer / client), busca por evento ou destino, Preserve log e Clear.
• Copiar hit como JSON, URL ou valor individual; timestamp por hit.
• Export da sessão em JSON.
• i18n PT-BR / EN com troca instantânea (persistida em chrome.storage).

Destinos suportados

Destino	Client-side	Via container Wascer
Google Analytics 4	Sim	Sim (inclui base64)
Google Analytics (Universal)	Sim	—
Meta Pixel / CAPI	Sim	Sim
Google Ads	Sim	Sim
TikTok Pixel	Sim	—
Pinterest Tag	Sim	—
Microsoft Ads (UET)	Sim	—

Requisições não reconhecidas em domínio first-party aparecem na seção "unmatched" — útil pra descobrir um container ou endpoint que ainda não temos assinatura.

Como a detecção Wascer funciona

Tudo local e offline — nenhuma chamada a backend, nenhuma credencial. Os sinais:

1. Loader — <script src> first-party com nome renomeado/ofuscado ou em subdomínio dedicado (ex.: sgtm., server., soureicdn.), varrido direto do DOM via inspectedWindow.eval (funciona mesmo com o painel aberto depois do load e em sites com CSP estrito).
2. Assinaturas de request — paths first-party tipo /g/collect, /collect, /tr, /pagead, cookies FP* e payload GA4/Meta presente.
3. Payload codificado — query param que decodifica (base64) para um /g/collect?... interno.

As assinaturas são semeadas do nosso próprio wascer-watcher (mesma fonte de verdade).

Arquitetura

Extensão WXT + React + TypeScript, dividida em contextos que conversam por mensagens:

entrypoints/
  devtools/         registra o painel no F12
  panel/            UI React (painel, componentes, i18n, theme)
  background.ts     roteador de mensagens por aba
  collector.content.ts + page-collector.ts   hook do dataLayer no main world

lib/                núcleo puro, sem DOM, testável (futuro @wascer/tracking-catalog)
  catalog/          decoders, dicionários, registry, signatures, loader, base64, dedupe
  correlation/      correlação client/server
  analysis/         anomalias + validação
  export/ · messaging/

Decisões de design:

• Sem backend e sem auth — detecção 100% heurística local.
• Sem webRequest — chrome.devtools.network cobre a captura (request + corpo + resposta).
• lib/ é puro (sem DOM/chrome), testado sem browser e portável.
• Clean-room — conceito de provider/decoder inspirado no Omnibug, sem copiar código.

Idiomas

Toggle PT / EN no header, troca em runtime e persiste a escolha. Adicionar um idioma é só somar um bloco em entrypoints/panel/i18n/messages.ts. Os rótulos técnicos dos parâmetros (Measurement ID, ad_storage, ...) ficam em inglês canônico de propósito.

Testes e scripts

npm test             # testes unitários (puros, sem browser)
npm run compile      # typecheck (tsc --noEmit)
npm run build        # build de produção

Os decoders e análises são funções puras testadas com fixtures de hits reais.

Roadmap

• Wiki do repositório com guias por destino e exemplos.
• Mais destinos (Criteo, RD Station, etc.) conforme demanda.
• "Wascer Score ao vivo" a partir das regras de validação.
• Suporte a Firefox (já há scripts :firefox).

Créditos

O conceito de provider/decoder é inspirado no Omnibug (CC-BY-SA 3.0) — esta é uma reimplementação clean-room, sem uso de código do Omnibug. As assinaturas de detecção do container server-side derivam do wascer-watcher.