Handoff de Tracking — Patrimonial (Funil B)

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

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

Por que o tracking do B é diferente do A (a tese)

O Funil A (distrato) tem volume e ciclo curto: dá para otimizar por LeadQualificado direto. O Funil B é o oposto — ticket alto, volume baixo, ciclo de meses. Três consequências que mudam toda a instrumentação:

1. Sinal de conversão é escasso. Otimizar uma campanha por um evento que acontece poucas vezes por semana não treina o algoritmo. Por isso o B otimiza o topo por uma micro-conversão com volume (ExposicaoGerada) e reserva a conversão rara para lookalike de valor, não para otimização direta de campanha.
2. O que importa é qualidade, não volume. O motor do B é Value-Based Lookalike: subir a conversão offline com valor (consulta estratégica de alto patrimônio / cliente fechado) e deixar o Meta/Google encontrarem mais gente parecida com quem vale. É aqui que o LTV do funil se paga.
3. Janela de atribuição longa. Clique de hoje vira consulta em 30–90 dias. Atribuição curta esconde o resultado e faz desligar campanha boa. Configurar janelas longas e ler por coorte, não por dia.

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

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

Mapa de eventos (jornada patrimonial)

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

ExposicaoGerada carrega o nivel (Baixa/Moderada/Alta/Crítica). Isso permite audiência de remarketing só de Alta/Crítica — exatamente quem o criativo de fundo deve reimpactar. É o equivalente patrimonial do EstimativaGerada do distrato.

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 (o mesmo do A serve; trocar os nomes de evento para DiagnosticoIniciado/ExposicaoGerada): Pixel + horus-tracker.js + data-horus-form + botões data-horus-wa + Consent Mode v2 (LGPD).
• Captura: gclid, _fbc/_fbp → ocultos horus_* → seguem ao 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) — valida contra schema antes. [PLACEHOLDER credenciais]
2. meta_test_event_code temporário na validação.
3. CRM: definir HORUS_TENANT; um único caminho offline (trigger recomendado) — dois = conversão em dobro.
4. Closed loop com valor (diferença central do B):

   bot (tier=quente) → handler /leads do CRM (server-side, chave forte do porteiro)
     → CAPI: LeadQualificado (+ _fbc/_fbp + event_id)
   consulta agendada / cliente fechado (CRM)
     → CAPI: ConsultaEstrategicaAgendada / ClienteFechado COM value (R$)
     → Google: offline conversion import COM value, por gclid
   

   A chave forte do porteiro nunca vai ao browser.
5. Configurar Value-Based Lookalike no Meta a partir de ConsultaEstrategicaAgendada/ClienteFechado com valor; espelhar com Customer Match de valor no Google quando houver base.

Estratégia de otimização (específica do B)

• Campanha de topo (prospecção): otimizar por ExposicaoGerada (volume suficiente para treinar) → encher o topo com gente certa.
• Remarketing: audiência ExposicaoGerada nivel∈{Alta,Crítica} + visitantes → criativo de fundo.
• Fundo / escala de qualidade: Value-Based Lookalike de ConsultaEstrategicaAgendada/ClienteFechado.
• Janelas de atribuição longas (Meta 7-day click mínimo; Google 30–90 dias) + leitura por coorte.
• Conversão primária de otimização: ExposicaoGerada no topo; ConsultaEstrategicaAgendada (valor) no fundo. Nunca Lead bruto.

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

• 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]
• CRM com campo de valor por oportunidade (para subir value) [?].
• LGPD: texto de consentimento + política publicada [?].

Validação técnica (gate técnico)

• Lead de teste: Pixel + Servidor com mesmo event_id (deduplicado) no Test Events
• ExposicaoGerada dispara com nivel correto
• gclid capturado; _fbc/_fbp criados; ocultos horus_* preenchidos
• Conversão offline com value sobe no Meta e no Google
• End-to-end real: diagnóstico → lead → CRM → consulta agendada com valor → conversão offline com valor sobe
• EMQ ≥ 8.0 e match rate offline ≥ 50%
• Consent Mode v2 ativo
• Se algum item falha → não liberar Fase 4.

Guardrails

1. Nunca redeployar o porteiro por cliente. 2. Chave forte nunca no browser. 3. Reusar event_id do front. 4. Um único caminho offline. 5. Sem validation-report, sem Fase 4. 6. EMQ ≥ 8.0 / match ≥ 50%. 7. Consent Mode v2 (LGPD) antes do go-live. 8. (B) otimizar topo por micro-conversão, fundo por valor — nunca por lead bruto.

O que está bloqueado agora

Provisionamento real depende de Gate 3, infra confirmada, credenciais, domínio real e campo de valor no CRM. Até lá, este handoff + o snippet (com nomes de evento do B) são o que avança sem efeito colateral.