felvieira Closed-Loop Revenue — Do Clique à Margem
O produto nao termina no deploy. Esta skill cobre a cadeia que liga clique pago → evento → venda real → margem, e a disciplina de identidade que faz essa cadeia ser reconciliavel. Sem isso, o time otimiza para numeros que a plataforma de anuncios reporta, nao para dinheiro que entrou.
O erro central que ela previne: ROAS alto nao significa negocio saudavel. Uma campanha com ROAS 2,0 pode estar destruindo valor se a margem de contribuicao for 40%.
Governanca Global
Esta skill segue GLOBAL.md, policies/execution.md, policies/handoffs.md, policies/token-efficiency.md, policies/quality-gates.md e policies/evals.md.
Para formulas completas, contrato de evento por tipo de funil e receita de auditoria, consultar docs/skill-guides/closed-loop-revenue.md apenas quando necessario.
Fronteira com skills vizinhas:
- 21-data-analytics define o que trackear no produto (taxonomia de evento, funil de ativacao/retencao) — esta skill cobre a identidade e a reconciliacao com dinheiro
- 55-marketing-reporting-analytics faz setup de GA4/GTM e monta relatorio de campanha — esta skill garante que o dado dentro do relatorio bate com o financeiro
- 03-backend-api e dono da transacao e do registro de receita — esta skill define o contrato que o backend precisa expor
- 06-security-review e dono de PII e base legal — esta skill respeita o consent state, nao o define
Quando Usar
- instrumentar funil que gera receita (e-commerce ou lead gen)
- diagnosticar divergencia entre analytics, plataforma de ads e backend
- decidir se uma campanha da lucro de verdade, nao so ROAS
- enviar conversao offline ou valor de lead de volta pra plataforma
- definir o que enviar pro bidder quando a qualidade do lead varia
- montar measurement plan antes de escrever a primeira tag
Quando Nao Usar
- definir metrica de produto: ativacao, retencao, engajamento (isso e 21-data-analytics)
- montar relatorio de campanha ou configurar GA4/GTM do zero (isso e 55-marketing-reporting-analytics)
- escrever copy de anuncio ou landing (isso e 13-marketing-copy ou 50-direct-response-copy)
- decidir base legal de tratamento de dado pessoal — esta skill implementa o consent, nao interpreta a lei
Entradas Esperadas
- funil alvo e tipo (e-commerce, lead gen, assinatura)
- fonte de verdade da receita (backend, ERP, CRM)
- estrutura de custo: COGS, taxas, frete, reembolso, custo variavel
- plataformas de aquisicao e analytics em uso
Saidas Esperadas
- measurement plan com contrato de evento por etapa
- mapa de identidade (quais IDs existem, onde nascem, onde se juntam)
- relatorio de reconciliacao: backend vs. analytics vs. plataforma, com tolerancia declarada
- break-even ROAS calculado a partir da margem real
- checklist marcado
1. Measurement Plan Antes de Tag
A ordem correta e plano → contrato de evento → tag. Sair implementando tag primeiro produz evento que ninguem sabe interpretar e numero que nao bate com nada.
O plano responde, por etapa do funil: qual evento, o que ele significa em linguagem de negocio, quem dispara, quais parametros sao obrigatorios, e qual decisao ele vai suportar. Evento que nao suporta decisao nao entra.
Funil de e-commerce e funil de lead gen tem formatos diferentes:
E-commerce: view_item → add_to_cart → begin_checkout → purchase
Lead gen: view_landing → form_start → generate_lead → qualify_lead → close_convert_lead
A diferenca importa: em lead gen, generate_lead nao e receita. Otimizar bidding para submissao de formulario, quando a qualidade varia, ensina o algoritmo a comprar lead ruim barato.
2. Cadeia de Identidade
Cada identificador tem uma funcao. Tratar como intercambiavel e a causa mais comum de dado que nao reconcilia:
| ID | Nasce onde | Serve para | Nao serve para |
|---|---|---|---|
| GCLID | Clique no anuncio (auto-tagging) | Ligar a venda de volta a campanha; conversao offline | Identificar o usuario |
| UTM | URL da campanha | Taxonomia legivel, cross-channel | Atribuicao precisa (perde em redirect) |
| transaction_id | Backend, na transacao | Deduplicacao — a mesma venda contada uma vez so | Atribuicao |
| ID de usuario/lead | Cadastro ou CRM | Qualidade e valor real ao longo do tempo | Ser enviado cru pra plataforma |
Regras que evitam a maioria dos bugs:
- Auto-tagging ligado — sem GCLID, conversao offline nao existe
- GCLID persistido no backend, junto do lead/pedido, no momento em que ele chega — nao adianta so no analytics
- UTM padronizada, com taxonomia escrita e validada;
Googleegoogleviram duas fontes diferentes num relatorio transaction_ididempotente, gerado no backend, nunca no cliente- Dado pessoal enviado a plataforma so com hash e base legal — nunca cru
3. Reconciliacao — O Backend e a Fonte de Verdade
O evento purchase do lado do cliente nao e receita. Ele nao dispara quando o pagamento confirma fora do browser (PIX, boleto, retry), dispara duas vezes em refresh, e some com bloqueador.
A arquitetura correta:
Backend (fonte de verdade) → registra transacao com transaction_id
↓ ↓
analytics plataforma de ads
(evento marcado) (conversao importada)
O relatorio de reconciliacao compara os tres e declara uma tolerancia — nao existe bater 100%, e fingir que existe esconde problema real:
| Divergencia tipica | Causa provavel |
|---|---|
| Analytics > backend | Evento duplicado (refresh, back-button, sem transaction_id) |
| Analytics < backend | Bloqueador, consent negado, pagamento assincrono fora do browser |
| Plataforma > analytics | Janela de atribuicao diferente, modelagem da propria plataforma |
| Receita diferente com contagem igual | Moeda, imposto, frete ou desconto contados de forma diferente |
Divergencia acima da tolerancia bloqueia escala de midia. Escalar orcamento em cima de dado que nao reconcilia e multiplicar o erro.
Checkpoint: identificar a causa provavel na tabela → corrigir a fonte especifica (dedupe por transaction_id, ajustar janela de atribuicao, alinhar calculo de moeda/imposto) → rodar a reconciliacao de novo no mesmo periodo. So liberar escala quando a divergencia cair dentro da tolerancia declarada — nao redefinir a tolerancia pra "caber" o numero que já saiu.
4. Da Metrica Operacional ao Lucro
A hierarquia importa: quanto mais em cima, mais economico; quanto mais embaixo, mais operacional.
Lucro incremental / contribuicao ← o que importa
↑
Receita, CAC
↑
AOV, CVR, qualidade de lead
↑
CPC, CTR, impressoes ← nunca a meta
A conta que muda a decisao:
Margem de contribuicao = (Receita − custos variaveis antes da midia) / Receita
Break-even ROAS = 1 / Margem de contribuicao
Com margem de 40%, o break-even e 2,5. Um ROAS de 2,0 aparece verde no painel e destroi valor.
Custos variaveis a incluir antes de calcular: COGS, taxa de pagamento, frete e subsidio, reembolso e chargeback, suporte variavel. Deixar qualquer um de fora infla a margem e rebaixa o break-even artificialmente.
Nunca otimizar CTR quando o objetivo e margem. Sao metricas de camadas diferentes.
5. Alimentar o Bidder com Sinal Economico
Automacao de lance so e tao boa quanto o sinal que recebe. A progressao correta:
| Situacao | Estrategia |
|---|---|
| Tracking ainda nao reconcilia | Nao escalar automacao — lixo entra, lixo sai |
| Conversoes tem valor parecido | Maximizar conversoes / CPA alvo |
| Valores variam bastante | Maximizar valor de conversao |
| Volume e historico de valor suficientes | ROAS alvo |
| Lead gen com qualidade variavel | Valor offline — enviar a venda real, nao a submissao do formulario |
Para lead gen, a virada de chave e enviar de volta o desfecho real (lead virou venda? de quanto?), nao o formulario preenchido. Uma campanha com 1.000 leads baratos que nao fecham nao vale mais que 200 leads que fecham com margem — e sem esse retorno, o algoritmo nao tem como saber.
Mudanca grande de estrategia se testa com experimento (controle vs. tratamento), nao comparando com a semana passada — sazonalidade e ruido explicam quase qualquer diferenca semana a semana.
6. Consentimento
Instrumentacao e privacidade nao se separam. O estado de consentimento precisa chegar as tags antes de qualquer disparo, e a mudanca de consentimento (inclusive revogacao) precisa propagar.
- Rejeitar deve ser tao facil quanto aceitar — banner so com "aceitar" é padrao problematico
- Nada nao-essencial dispara antes do consentimento quando a base legal e consentimento
- Revogacao propaga; o estado nao pode ficar preso na primeira escolha
- Dado pessoal enviado a plataforma so hasheado, e so com base legal
A escolha de base legal e a interpretacao de caso concreto sao de responsavel juridico/DPO — esta skill implementa o mecanismo.
Anti-Padroes
- Implementar tag antes de existir measurement plan
- Tratar evento
purchasedo cliente como fonte de verdade de receita transaction_idgerado no cliente, ou ausente- Auto-tagging desligado (mata conversao offline)
- GCLID so no analytics, sem persistir junto do pedido/lead no backend
- UTM sem taxonomia —
Google,googleegoogle-adscomo tres fontes - Escalar orcamento com reconciliacao fora da tolerancia
- Otimizar bidding para
generate_leadquando a qualidade do lead varia - Usar ROAS como meta sem calcular o break-even da margem real
- Otimizar CTR ou CPC quando o objetivo declarado e margem
- Comparar performance com "a semana passada" em vez de experimento controlado
- Disparar tag de ads/analytics antes do consentimento
- Enviar e-mail ou telefone cru pra plataforma
Checklist
Plano e identidade:
- Measurement plan escrito antes das tags, com decisao suportada por evento
- Auto-tagging ligado; GCLID persistido no backend junto do lead/pedido
- UTM com taxonomia documentada e validada
-
transaction_ididempotente, gerado no backend - Dado pessoal so hasheado, com base legal
Reconciliacao:
- Backend declarado como fonte de verdade da receita
- Relatorio comparando backend × analytics × plataforma
- Tolerancia de divergencia declarada e monitorada
- Duplicidade testada (refresh, back-button, retry de pagamento)
- Pagamento assincrono (PIX, boleto) coberto por evento server-side
Economia:
- Margem de contribuicao calculada com todos os custos variaveis
- Break-even ROAS derivado da margem, nao arbitrado
- Meta declarada em lucro/contribuicao, nao em CTR ou CPC
- Lead gen envia desfecho real, nao submissao de formulario
Privacidade:
- Consent state chega as tags antes de qualquer disparo
- Rejeitar tao facil quanto aceitar; revogacao propaga
Evidencia de Conclusao
- measurement plan versionado, com contrato por evento
- relatorio de reconciliacao com numeros reais e tolerancia declarada
- break-even ROAS calculado e registrado, com os custos que entraram na conta
- checklist marcado, com item nao aplicavel justificado
Handoff
Recebe de
- 01-po-feature-spec — objetivo economico e metrica primaria
- 21-data-analytics — taxonomia de evento do produto
- 03-backend-api — contrato da transacao e fonte de verdade da receita
Entrega para
- 55-marketing-reporting-analytics — relatorio de campanha em cima de dado ja reconciliado
- 03-backend-api — requisito de persistir GCLID e expor
transaction_ididempotente - 06-security-review — revisao de PII, hashing e consent
- 05-qa-testing — duplicidade, consent negado e pagamento assincrono viram teste
Regra de Codigo Limpo
Comentario onde a regra de negocio nao e obvia: por que determinado custo entra no calculo de margem, por que um evento e server-side. Nome de evento e parametro seguem o padrao da plataforma, sem apelido interno.
Fontes
- Modelo de identidade de clique (GCLID) e conversao offline: documentacao do Google Ads.
- Nomes de evento recomendados e key events: documentacao do GA4.
- Estrategias de lance automatico e otimizacao por valor: documentacao do Google Ads.
- Consentimento e boas praticas de banner: orientacao da ANPD sobre cookies (LGPD).
- Formulas de margem de contribuicao e break-even: contabilidade gerencial padrao.
Integracao com Pipeline
- Orquestrador (skill 09): aciona esta skill antes de qualquer escala de midia paga
- Data Analytics (skill 21): dona da taxonomia de produto; esta skill cobre identidade e dinheiro
- Marketing Reporting (skill 55): consome o dado ja reconciliado que esta skill garante
- Backend (skill 03): implementa persistencia de GCLID e idempotencia da transacao
- Security Review (skill 06): valida PII, hashing e consent
- QA (skill 05): transforma duplicidade e consent em teste de regressao