Handoff de Tracking — Distrato (Funil A)

Pinheiro Lima Advocacia · horus-tracking-setup (modo spec)

Estado: modo hipótese. Sem Gate 3 formal, sem credenciais do cliente e sem confirmação de infra. Este documento é o handoff/spec que a skill executa — não houve provisionamento real: nenhum tenant criado, nenhum SQL rodado, nenhum webhook ligado. Campos sensíveis marcados com [PLACEHOLDER] / [?]. Premissa da skill: ela não cria estratégia — consome a estratégia de ads + a LP e os torna mensuráveis. A publicação (Fase 4) só libera com validation-report aprovado.

Por que isto existe (a tese do funil)

O lead de distrato é caro e o ciclo é longo. Se a campanha otimizar por lead bruto (qualquer clique no WhatsApp), o algoritmo aprende a trazer volume ruim. O closed loop manda de volta para Meta/Google apenas o lead com mérito (tier quente do bot) — então a campanha otimiza pelo que vale dinheiro. É isso que torna o CPC caro do Google rentável. Sem tracking, publicar é queimar verba cega.

Pré-condições (Etapa 0) — bloqueadores

• gate-3.status === aprovado no run-state [?] (hoje: não)
• Estratégias estrategia-meta-ads.md + estrategia-google-ads.md existem [?] (definir eventos/ação de conversão antes)
• Infra da agência no ar: porteiro (Edge Function) responde, tracking.client_config existe, handler /leads do CRM ativo [?]
• Se a infra não existir → bloquear e sinalizar o runner. Não deployar porteiro por cliente.

Mapa de eventos (o que medir na jornada)

Contrato de dedupe (guardrail 3): o event_id é gerado no front no clique do WhatsApp e reusado no Lead server-side. Gerar um novo no servidor quebra o dedupe — bloqueador.

Nível 0 — browser-side (mesmo dia, não depende de token de servidor)

• Verificar domínio no Meta + HTTPS no domínio real [?].
• Google Ads: auto-tagging ON, ação de conversão "Lead", Enhanced Conversions for Leads ON.
• Meta: Dataset (Pixel) confirmado.
• Instrumentar a LP com o bloco de snippet-instrumentacao-lp.html: Pixel + horus-tracker.js + data-horus-form + botões data-horus-wa + Consent Mode v2 (LGPD).
• Captura: gclid (Google), _fbc/_fbp (Meta) → campos ocultos horus_* → seguem para o CRM no handoff do bot.

Nível 1+2 — server-side + closed loop (quando as credenciais chegarem)

1. Provisionar tenant: segredos no Vault + linha em tracking.client_config (via tenant-config.sql gerado do template) — valida contra schema antes de enviar. [PLACEHOLDER credenciais]
2. meta_test_event_code temporário durante a validação.
3. CRM: definir HORUS_TENANT; escolher um único caminho offline (trigger recomendado) — os dois = conversão em dobro (guardrail 4).
4. Fluxo do closed loop:

   bot (tier=quente) → handler /leads do CRM (server-side, chave forte do porteiro)
     → CAPI: LeadQualificado com _fbc/_fbp + event_id
     → Google: offline conversion import com gclid (ou EC for Leads com e-mail/telefone hasheado)
   

   A chave forte do porteiro nunca vai ao browser (guardrail 2).

Credenciais pendentes (handshake — disparar já, é o gargalo externo)

• Meta: dataset_id + token de System User (exige Business verification). [PLACEHOLDER]
• Google: customer_id, login-customer-id (MCC da agência), conversion_action_id, refresh_token. [PLACEHOLDER]
• Acessos admin: Meta Business, Google Ads, GA4, site/DNS. [PLACEHOLDER]
• LGPD: confirmar texto de consentimento + política de privacidade publicada [?].

Validação técnica (gate técnico — não é gate de cliente)

• Lead de teste: Pixel + Servidor com mesmo event_id (deduplicado) no Test Events
• gclid capturado; _fbc/_fbp criados; ocultos horus_* preenchidos
• Google Ads: uploads recentes + EC "registrando"
• End-to-end real: form/bot → lead no CRM → marcar quente → conversão offline sobe
• EMQ ≥ 8.0 e match rate offline ≥ 50%
• Consent Mode v2 ativo
• Se algum item falha → não liberar Fase 4. Iterar e revalidar.

Go-live readiness

• Remover test_event_code.
• Definir conversão primária no Google Ads (evita dupla contagem GA4 × nativo).
• Conversão de otimização da campanha = LeadQualificado (offline), não Lead bruto.
• Gerar tracking-runbook.md e sinalizar o runner.

Guardrails (da skill)

1. Nunca redeployar o porteiro por cliente. 2. Chave forte nunca vai ao browser. 3. Reusar event_id do front. 4. Um único caminho offline. 5. Sem validation-report aprovado, não há Fase 4. 6. EMQ ≥ 8.0 / match ≥ 50%. 7. Consent Mode v2 (LGPD) antes do go-live.

O que está bloqueado agora

Provisionamento real (tenant, Vault, webhooks, uploads) depende de: Gate 3 aprovado, infra confirmada, credenciais coletadas e domínio real. Até lá, este handoff + o snippet são o que avança sem efeito colateral.