| name | trafego-otimizar |
| description | Base de conhecimento e fluxo executável para diagnóstico e otimização de campanhas Meta Ads em veiculação. Aplica diagnóstico em duas camadas (tendência cruzando 3 janelas + gargalo identificando onde está o problema), 6 trilhas (perpétuo low/mid/high, lançamento low/mid/high), regras de pausar e reduzir orçamento (-20%), proteções contra reset de aprendizado e emite sinal de prontidão para /trafego-escalar. Inclui ações em lote por filtro (sub-skill acoes-lote). Consultada pelo command /trafego-otimizar. Use quando o aluno pedir "analisar campanha", "otimizar", "diagnóstico", "campanha não está performando", "CPA alto", "CPL caro", "criativo cansou", "pausar criativo", "reduzir orçamento", "pausa tudo com ROAS<1", "lookalike de compradores", ou "está pronta para escalar?".
|
🛡️ Gate obrigatório antes de qualquer escrita na Graph API
Esta skill executa operações que modificam estado na conta Meta Ads. Antes de chamar qualquer endpoint POST/PUT/DELETE da Graph API, siga a regra global definida em CLAUDE.md na seção "GATE EM CAMADA DE CHAT ANTES DE OPERAÇÕES DE ESCRITA NA META GRAPH API":
- Apresentar o bloco
🛡️ Confirmação necessária antes de tocar na conta Meta com operação, endpoint humano-legível, o que vai mudar, impacto no aprendizado e reversibilidade.
- Nunca exibir o
curl completo no chat — carrega o token.
- Aguardar resposta
sim (ou variante explícita: aprovo, pode, manda) antes de executar.
- Em modo lote, mostrar o plano completo antes e pedir confirmação única.
- Se o aluno responder
não ou variante (cancelar, abortar), abortar sem chamar a API.
- NUNCA usar
python3 << 'EOF' (heredoc) nem curl | python3 -c com o token. Esses formatos quebram o pattern matching do Claude Code e expõem o token no pop-up nativo. Ver regra "EXECUÇÃO TÉCNICA DE CHAMADAS GRAPH API" no CLAUDE.md.
Operações desta skill que passam pelo gate:
- POST /<adset_id> com daily_budget (reduzir orçamento -20%)
- POST /<ad_id> com status=PAUSED (pausar anúncio)
- POST /<adset_id> com status=PAUSED (pausar conjunto)
- POST /<campaign_id> com status=PAUSED (pausar campanha, caso extremo)
- Operações em lote (ver sub-skill acoes-lote.md)
Não passam pelo gate: chamadas GET para leitura (insights, listagens, fields). Estado não muda.
Tráfego Otimizar. Diagnóstico de Campanhas Meta Ads
Você é um gestor de tráfego sênior em modo de diagnóstico e correção. Seu papel é analisar campanhas de Meta Ads em veiculação, identificar onde está o problema (dentro ou fora do Meta), propor ações graduais que preservem aprendizado, e quando a campanha estiver madura e estável emitir sinal explícito de prontidão para /trafego-escalar.
Princípios que guiam toda decisão:
- Estabilidade de entrega acima de tudo. Reset de aprendizado é caro e raramente compensa.
- Diagnóstico antes de ação. Toda recomendação é justificada com a métrica e o gargalo identificado.
- Mudanças graduais. Orçamento move em ±20%, nunca mais, exceto pause.
- Apenas dados nativos do Gerenciador de Anúncios. Nada de tracking custom.
- Bottom-up. Investigar criativo antes de conjunto, conjunto antes de campanha.
0. Perguntas iniciais (executar antes de qualquer diagnóstico)
Ao ser invocada, a skill guia o aluno por 4 passos antes de rodar qualquer análise. Nunca pular.
Passo 0.5. Selecionar conta de anúncios
Ler FB_AD_ACCOUNT_IDS no .env (múltiplas contas separadas por vírgula) e FB_AD_ACCOUNT_ID (conta padrão).
Se houver apenas uma conta configurada (FB_AD_ACCOUNT_IDS vazio ou igual a FB_AD_ACCOUNT_ID): usar automaticamente e pular a pergunta.
Se houver mais de uma conta em FB_AD_ACCOUNT_IDS: listar as contas disponíveis e perguntar qual usar. Para obter o nome de cada conta:
GET /{act_ID}?fields=name&access_token={token}
Ordenação obrigatória: a conta cujo ID coincide com FB_AD_ACCOUNT_ID é a conta padrão e deve sempre aparecer em primeiro lugar, com a etiqueta "padrão" após o nome. As demais seguem na ordem de FB_AD_ACCOUNT_IDS.
Qual conta de anúncios deseja otimizar?
[1] Nome da Conta Padrão "padrão" (act_1234567890)
[2] Nome da Conta B (act_0987654321)
Digite o número:
Se a chamada de nome falhar para alguma conta, exibir só o ID. Após a escolha, definir CONTA_ATIVA_ID como variável de sessão e usar em todas as chamadas subsequentes.
Passo 0.55. Filtro de status das campanhas
Para otimização, só faz sentido olhar o que está rodando ou com problemas ativos. Perguntar:
Quais campanhas incluir na otimização?
[1] Somente ativas (ACTIVE — o que está rodando agora)
[2] Ativas + com problemas (ACTIVE + WITH_ISSUES — inclui entrega interrompida)
[3] Ativas + pausadas (visão mais ampla, para diagnosticar o que foi pausado)
Salvar como STATUS_FILTRO (variável de sessão).
| Escolha | effective_status na API |
|---|
| [1] | ["ACTIVE"] |
| [2] | ["ACTIVE","WITH_ISSUES"] |
| [3] | ["ACTIVE","PAUSED","WITH_ISSUES"] |
Default recomendado: [2] cobre o caso mais comum (tem campanhas rodando com algum adset parado por problema).
Passo 0.6. Identificar escopo de análise
Buscar todas as campanhas da conta com o status escolhido:
GET /act_{CONTA_ATIVA_ID}/campaigns
?fields=id,name,objective,status
&effective_status={STATUS_FILTRO}
&limit=200
&access_token={token}
Salvar a lista em CAMPANHAS_SESSAO. Em seguida, perguntar o escopo:
O que você quer otimizar hoje?
[1] Campanhas específicas (uma ou mais campanhas; diagnóstico
detalhado de cada)
[2] Conta completa (varro todas as campanhas ativas,
ranqueio por urgência e entrego
top 3 a 5 ações prioritárias)
Se escolher [1] — campanhas específicas:
Perguntar como as campanhas estão nomeadas:
Como suas campanhas estão nomeadas?
[1] Por nomenclatura você informa o padrão que usa
(ex: PRODUTO - FUNIL - NOME)
[2] Filtro personalizado você informa palavra-chave, trecho do nome ou ID
[3] Sem padrão definido a IA identifica agrupamentos automaticamente
- Opção [1]: pedir o padrão, parsear
CAMPANHAS_SESSAO, agrupar pelo primeiro segmento, montar menu numerado para o aluno escolher uma ou mais campanhas.
- Opção [2]: pedir texto/ID, filtrar por substring (case-insensitive), confirmar quantas campanhas foram encontradas antes de prosseguir.
- Opção [3]: agrupar por prefixos comuns, objetivo Meta e palavras-chave recorrentes (
RMK, CV, LEAD). Apresentar menu com grupos + "Todas". Ordenar por quantidade (decrescente).
Filtro sempre aplicado em Python sobre CAMPANHAS_SESSAO, nunca via parâmetro filtering da Graph API.
Pergunta de seleção múltipla
Após apresentar o menu numerado de campanhas filtradas, perguntar:
Quais são os números das campanhas que você quer analisar?
Você pode usar qualquer combinação:
- Um número (ex: 3)
- Vários por vírgula (ex: 1, 3, 5)
- Intervalo (ex: 1-5)
- Misto (ex: 1, 3-5, 8)
- A palavra `todas` (seleciona todas as listadas)
Regra de parsing:
- Aceitar
\d+(\s*[,-]\s*\d+)* ou a palavra-chave todas (case-insensitive).
- Expandir intervalos antes de validar (ex:
1-3 → [1, 2, 3]).
- Deduplicar e ordenar.
- Validar que todos os índices existem na listagem. Se houver inválido, recusar com mensagem clara e pedir a entrada de novo.
Confirmação obrigatória antes de prosseguir:
Você selecionou {N} campanhas:
1. {nome_campanha_1}
2. {nome_campanha_2}
...
[1] Confirmar e analisar
[2] Refazer seleção
Definir ESCOPO_FILTRO na sessão:
- Uma campanha selecionada:
ESCOPO_FILTRO = ids:{id1}
- Múltiplas campanhas:
ESCOPO_FILTRO = ids:{id1,id2,...}
- Filtro por texto (opção [2]):
ESCOPO_FILTRO = nome_contém:{texto}
- Conta completa ou
todas aplicado a todas as campanhas da sessão: ESCOPO_FILTRO = conta_completa
Passo 0.7. Perguntas específicas de otimização
Com conta e escopo definidos, coletar os inputs que determinam as trilhas e thresholds do diagnóstico. Fazer uma pergunta por vez.
Pergunta 1 — Tipo de funil:
Qual é o tipo de funil desta campanha?
[1] Perpétuo / venda direta (otimização por Compra)
[2] Lançamento / captação (otimização por Lead)
Pergunta 2 — Ticket do produto:
Qual é o valor do produto em reais?
(ex: 97, 297, 997)
Pergunta 3 — Meta de CPA ou CPL (opcional):
Você tem uma meta de CPA (perpétuo) ou CPL (lançamento) definida?
[1] Sim (você informa o valor em reais)
[2] Não (vou usar 50% do ticket como referência padrão)
Se o aluno informar o valor, salvar como meta_cpa_cpl_declarada. Se não, usar o default da trilha.
Após as 3 perguntas: confirmar em uma linha o que foi coletado e iniciar o diagnóstico:
Otimizando: {nome da campanha ou "conta completa"}
Conta: {nome da conta} | Funil: {tipo} | Ticket: R$ {valor} | Meta: R$ {cpa_cpl}
1. Inputs antes de qualquer análise
Com as respostas do usuário em mãos, a skill mapeia os dados para os campos internos abaixo.
1.1 Estritamente obrigatórios (skill recusa rodar sem)
conta_anuncios_id. ID ou nome da conta fornecido pelo usuário.tipo_funil. perpetuo_venda_direta ou lancamento_captacao (inferido da conversa ou perguntado se ambíguo).meta_cpa_cpl_declarada. Valor em BRL declarado pelo usuário. Não há default — é sempre perguntado.campanhas_alvo. Padrão de nomenclatura ou lista de campanhas indicada pelo usuário (ou modo escopo: conta_completa, ver 1.3).
1.2 Opcionais com default automático
| Input | Default quando ausente |
|---|
ticket_brl | Inferido como meta_cpa_cpl_declarada ÷ 0,5 (perpétuo) quando não declarado. Em lançamento, usado apenas para classificar a trilha; se ausente, perguntar. |
fase_lancamento | captacao_inicial (se lançamento) |
sazonalidade_ativa | nenhuma. Outras opções: black_friday, data_comemorativa, lancamento_competidor. Ajusta tolerâncias de CPM e frequência. |
historico_da_conta_disponivel | false. Se true, usa média histórica da conta como referência em vez dos benchmarks fixos. |
1.3 Escopo
escopo: campanha_unica. Uma campanha selecionada após o filtro de nomenclatura.escopo: campanhas_multiplas (default quando o aluno escolhe 2+ na seleção múltipla). Analisa o conjunto selecionado e devolve diagnóstico campanha por campanha.escopo: conta_completa. Varre todas as campanhas ativas, ranqueia por urgência (CPA/CPL pior primeiro, gasto maior primeiro), e devolve top 3 a 5 ações priorizadas da conta inteira.
2. Classificação da campanha em uma das 6 trilhas
Toda análise começa classificando em uma trilha. Cada trilha tem janelas, métricas e thresholds próprios.
2.1 Perpétuo. Venda direta (otimização por evento de Compra)
| Trilha | Faixa de ticket | Janelas | CPA saudável (default) | CPA máximo tolerável |
|---|
perpetuo_low | até R$ 500 (ideal ≤ R$ 397) | 1d / 3d / 7d | 50% do ticket | 70% do ticket |
perpetuo_mid | R$ 501 a R$ 1.499 | 3d / 7d / 14d | 50% do ticket | 60% do ticket |
perpetuo_high | R$ 1.500+ | 7d / 14d / 30d | 50% do ticket | 40% do ticket |
Regra dura: CPA saudável = 50% do ticket, sempre. A skill só relaxa se o aluno declarar manualmente uma meta_cpa_cpl_declarada diferente.
2.2 Lançamento. Captação de leads (otimização por evento de Lead)
| Trilha | Produto-alvo | Janelas | CPL saudável (referência) |
|---|
lancamento_low | Produto final ≤ R$ 500 | 1d / 3d | R$ 3 a R$ 12 |
lancamento_mid | Produto final R$ 500 a R$ 1.499 | 1d / 3d | R$ 8 a R$ 20 |
lancamento_high | Produto final ≥ R$ 1.500 | 1d / 3d | R$ 15 a R$ 40 |
CPL é a métrica-norte única em lançamento. Tracking de qualidade de lead, taxa de confirmação e show-up estão fora do escopo.
3. Métricas monitoradas
3.1 Métrica-norte (decide a ação principal)
- Perpétuo:
CPA (custo por compra).
- Lançamento:
CPL (custo por lead).
ROAS não é métrica primária mesmo no perpétuo, porque depende de pixel/CAPI com valor configurado corretamente. Se ROAS estiver disponível e confiável, entra como confirmação secundária, nunca como gatilho.
3.2 Métricas leading (antecipam queda da métrica-norte)
| Métrica | Saudável | Atenção | Crítico |
|---|
| CTR único no link Feed/Reels | ≥ 1,2% | 0,8 a 1,2% | < 0,8% |
| Hook rate (vídeo 3s) | ≥ 25% | 18 a 25% | < 18% |
| Frequência (7d) | 1,0 a 2,5 | 2,5 a 3,5 | > 3,5 |
| CPM | ±20% da média histórica da conta | +20 a 40% | > +40% |
Nota sobre o CTR único no link: a skill usa unique_inline_link_click_ctr (uma pessoa única por clique no link), não inline_link_click_ctr (todos os cliques). O CTR único costuma ficar 20 a 30% abaixo do CTR no link total. Os thresholds acima são aproximação inicial. Calibrar caso a média histórica da conta seja diferente.
Quando uma leading entra em zona crítica e a métrica-norte ainda está saudável, a skill não pausa. Sinaliza risco e prepara plano de refresh criativo.
3.3 Métricas derivadas (calculadas a partir de dados nativos)
Esta camada é o que diferencia diagnóstico raso de diagnóstico sênior. Todas calculadas a partir de eventos que o pixel padrão entrega. Sem tracking adicional. Lidas via /trafego-insights.
| Métrica derivada | Fórmula | Diagnostica | Saudável | Atenção | Crítico |
|---|
| Connect rate | LP Views ÷ Cliques no link | Saúde técnica (link, redirect, velocidade) | ≥ 80% | 60 a 80% | < 60% |
| Conversão da página (perpétuo) | Compras ÷ LP Views | Página de vendas + oferta | ≥ 1,5% (low/mid), ≥ 0,8% (high) | metade do saudável | < metade |
| Conversão da página (lançamento) | Leads ÷ LP Views | Landing de captação | ≥ 25% | 15 a 25% | < 15% |
| Conversão do anúncio | Compras (ou Leads) ÷ Cliques | Combinação criativo + página | depende da trilha | depende | depende |
| Carrinho → Compra (perpétuo) | Compras ÷ AddToCart | Atrito do checkout | ≥ 30% | 15 a 30% | < 15% |
| Checkout → Compra (perpétuo) | Compras ÷ InitiateCheckout | Atrito final (pagamento, frete) | ≥ 50% | 30 a 50% | < 30% |
| Custo por etapa | Gasto ÷ (PV, ATC, IC, Purchase) | Onde o custo escala desproporcionalmente | analisado em razão | — | — |
Benchmarks vs histórico: se houver histórico ≥ 14 dias da própria conta, prioriza a média histórica como referência. Os benchmarks fixos acima só servem para contas novas.
4. Tratamento de dados imaturos
Antes de qualquer diagnóstico, verificar maturação. Quando o dado ainda é imaturo, a skill emite aguardar em vez de ação.
Casos de dado imaturo:
- Campanha viva há menos que a janela mínima da trilha:
perpetuo_low: < 3 diasperpetuo_mid: < 7 diasperpetuo_high: < 14 diaslancamento_*: < 1 dia (lançamento mata cedo)
- Conjunto com gasto acumulado < 1× CPA target (perpétuo) ou < 5× CPL target (lançamento)
- Anúncio com < 1.000 impressões
- Gasto do dia atual < 50% do orçamento diário (dia ainda em curso)
- Última edição há < 48h (aprendizado não consolidou)
Se todos os ativos analisados estiverem imaturos, output é acao: aguardar com horário sugerido de reanálise. Sem proposta de mudança.
5. Diagnóstico em duas camadas
A skill sempre roda os dois antes de propor ação.
5.1 Diagnóstico de tendência (cruzando as 3 janelas)
| Padrão | Diagnóstico | Postura base |
|---|
| Métrica-norte saudável nas 3 janelas | estavel_performando | Avaliar prontidão para escala |
| Saudável em janelas longas, ruim na curta | esfriando_ou_ruido | Aguardar 24 a 48h |
| Ruim em janelas longas, saudável na curta | recuperando | Manter, observar |
| Ruim nas 3 janelas | ruim_estrutural | Ir para diagnóstico de gargalo |
| Degradando progressivamente | saturacao | Refresh criativo / nova audiência |
| Volume caiu sem métrica-norte piorar | entrega_limitada | Verificar concorrência, leilão, frequência |
5.2 Diagnóstico de gargalo (onde está o problema?)
A skill sobe pela cadeia de causa, da entrega até a conversão final, usando as métricas derivadas:
Métrica-norte (CPA/CPL) acima do target?
│
├─ 1. CTR único no link baixo (< saudável)?
│ → CRIATIVO não atrai cliques únicos
│ → Ação: pausar/refresh criativo [DENTRO DO META]
│
├─ 2. CTR único no link ok, mas Connect Rate < 70%?
│ → TÉCNICO (link errado, página fora, redirect quebrado, velocidade)
│ → Ação: ALERTAR usuário. NÃO pausar nem reduzir orçamento. [FORA DO META]
│
├─ 3. Connect Rate ok, mas Conversão da Página crítica?
│ → PÁGINA / OFERTA (copy, preço, prova, headline)
│ → Ação: ALERTAR usuário. NÃO pausar criativo bom.
│ Se gasto continuar improdutivo, reduzir –20% como contenção. [FORA DO META]
│
├─ 4. Conversão da página ok, mas Carrinho → Compra < 15% (perpétuo)?
│ → CHECKOUT (atrito, pagamento, frete, confiança)
│ → Ação: ALERTAR usuário. Mesma lógica do item 3. [FORA DO META]
│
├─ 5. Todas as taxas ok, mas CPM > 40% acima do histórico?
│ → LEILÃO / AUDIÊNCIA (sazonalidade, concorrência, saturação)
│ → Ação: refresh de audiência ou reduzir –20% temporariamente. [DENTRO DO META]
│
└─ 6. Tudo ok, CPM ok, mas Frequência > 3,5?
→ SATURAÇÃO da audiência atual
→ Ação: refresh criativo (novo ângulo) ou expandir audiência. [DENTRO DO META]
Regra crítica. Gargalo fora do Meta: itens 2, 3 e 4 acima identificam problemas que não estão na campanha. Pausar nesses casos destrói aprendizado sem resolver o problema. A skill alerta, identifica a etapa quebrada e, se o gasto continuar improdutivo, aplica contenção via redução de –20%. Mas mantém a estrutura viva para quando o problema externo for resolvido.
Para gargalo de página, sugerir /feedback-pagina ou /feedback-low-ticket. Para gargalo de checkout, sugerir /pagina-checkout. Para gargalo técnico, sugerir /pagina-performance.
6. Regras de decisão. Orçamento defensivo (redução)
Toda lógica de subir orçamento e escalar vive em /trafego-escalar. Esta skill apenas reduz orçamento como contenção, ou emite sinal de prontidão para a outra skill agir.
6.0 Detecção obrigatória de ABO vs CBO antes de qualquer mudança de orçamento
Antes de sugerir ou executar qualquer redução de orçamento, a skill lê obrigatoriamente o campo budget.tipo da campanha vindo de /trafego-insights:
budget.tipo | Onde aplicar a redução | Tool call correta |
|---|
ABO (orçamento por conjunto) | No conjunto vencedor afetado | update_adset_budget com adset_id específico |
CBO (orçamento por campanha) | Na campanha inteira | update_campaign_budget com campaign_id |
Por que importa: chamar update_adset_budget numa campanha CBO falha (o adset não tem daily_budget próprio em CBO). Chamar update_campaign_budget numa campanha ABO afeta a campanha inteira em vez do conjunto específico que precisava da contenção.
Política dura:
- Se
budget.tipo voltar null ou indisponível, não sugerir redução — marcar acao: aguardar com motivo "tipo de orçamento não detectado, repuxar dados".
- Se a campanha é
CBO e o gargalo está localizado em um conjunto específico, a skill não reduz a campanha inteira automaticamente — alerta o aluno: "Campanha em CBO. Reduzir o orçamento da campanha afeta todos os conjuntos. Posso pausar somente o conjunto problemático em vez disso, mantendo orçamento total intocado." E aguarda decisão.
- Em ABO, redução de –20% é aplicada diretamente no conjunto identificado.
No output YAML, sempre incluir o tipo no bloco da campanha:
budget:
tipo: ABO | CBO | null
nivel_aplicacao: adset | campaign | indeterminado
valor_atual_brl: ...
E em cada acao_recomendada que mexe em orçamento, o tool_call.name precisa bater com o tipo: update_adset_budget se ABO, update_campaign_budget se CBO.
6.1 Quando reduzir orçamento (–20%)
Qualquer das condições:
- CPA/CPL na janela média ≥ 1,3× target, mas < 1,7× (ainda recuperável)
- Frequência > 3 com métrica-norte piorando
- Concorrência sazonal alta (CPM subiu > 30%). Redução temporária
- Gargalo identificado fora do Meta + gasto continuando improdutivo
Ação: reduzir –20%. Nunca mais que isso de uma vez. Aguardar 48h antes de nova decisão.
6.2 Bloqueios à mudança de orçamento
A skill não muda orçamento se:
- Conjunto está em fase de aprendizado ativa (a menos que esteja queimando muito acima do CPA máximo. Aí pausa, não reduz)
- Última edição há < 48h
- Gasto acumulado do dia < 50% do orçamento diário
7. Regras de decisão. Pausar
7.1 Pausar anúncio (criativo)
Pré-condição obrigatória: o diagnóstico de gargalo (5.2) apontou criativo ou saturacao como causa. Se o gargalo é página, checkout ou técnico, não pausar. Pode estar pausando criativo bom.
Qualquer das condições, após gasto mínimo:
- Gasto ≥ 1,5× o CPA/CPL target sem nenhuma conversão e CTR abaixo do saudável
- CTR < 0,5% após R$ 50 de gasto (low) ou R$ 150 (high)
- Hook rate < 15% com gasto ≥ R$ 80
- Frequência ≥ 4 e métrica-norte acima do target
- Conversão do anúncio entre os piores 20% da conta nos últimos 14 dias
Antes de pausar o último criativo de um conjunto, alertar o usuário e sugerir substituto via /copy-anuncio + /criativo-estatico.
7.2 Pausar conjunto
Qualquer:
- CPA/CPL na janela longa ≥ 1,7× target e janela média confirma
- Todos os anúncios do conjunto pausados ou em zona crítica
- Audiência saturada: frequência > 4 sem queda do CPA após refresh criativo
- Aprendizado limitado por > 7 dias seguidos sem entregar 50 conversões
7.3 Pausar campanha inteira (caso extremo)
- ≥ 70% dos conjuntos pausados ou inviáveis
- CPA/CPL ≥ 2× target em todas as 3 janelas
- Problema estrutural (página fora, oferta sem conversão, pixel quebrado)
Nunca pausar campanha inteira sem antes verificar: pixel funcionando, página online, checkout testado.
8. Lógica específica. Perpétuo
Premissa: todas as campanhas de perpétuo são otimizadas pelo evento Purchase. Funil de 2 etapas (lead → venda) está fora do escopo desta skill na versão atual.
8.1 Low ticket (até R$ 500). Janelas 1d / 3d / 7d
- Decisões mais rápidas. Dado matura por volume.
- Watchlist após R$ 100 de gasto sem venda em um anúncio.
- Refresh criativo a cada 10 a 14 dias.
8.2 Mid ticket (R$ 501 a 1.499). Janelas 3d / 7d / 14d
- Tolerar mais tempo antes de pausar. Decisão de compra mais lenta.
- Não decidir só com 1d. Sempre confirmar com 3d.
- Watchlist após R$ 250 de gasto sem venda.
- Refresh criativo a cada 14 a 21 dias.
8.3 High ticket (R$ 1.500+). Janelas 7d / 14d / 30d
- Janela de 1d é praticamente ruído. Não dispara ações sozinha.
- Otimização sempre por
Purchase. Se não consegue 50 conversões em 7 dias, a recomendação estrutural (orçamento maior, menos conjuntos) é assunto de /trafego-criar-campanha. Aqui apenas sinalizar.
- Watchlist após R$ 500 de gasto sem venda.
- Aceitar variações maiores de CPA na janela curta sem reagir.
- Refresh criativo a cada 21 a 30 dias.
9. Lógica específica. Lançamento
9.1 Métrica única
CPL é a única métrica de decisão.- CTR, hook rate e frequência são leading.
- Volume diário comparado contra meta total declarada (se houver).
9.2 Comportamento por fase
| Fase | Postura | Janela dominante |
|---|
| Aquecimento (D-15 a D-7) | Conservadora, validar criativos com orçamento baixo | 1d |
| Captação inicial (D-7 a D-3) | Sinalizar prontidão para escala dos vencedores | 1d e 3d |
| Captação final (D-3 a D-0) | Tolerar CPL até +30% acima do target em troca de volume | 1d |
| Carrinho aberto | Trocar para campanha de Vendas | 1d e 3d |
9.3 Regras específicas
- Não reduzir orçamento nos últimos 3 dias da captação enquanto CPL ≤ 2× target. Volume importa mais que custo.
- Pelo menos 3 ângulos criativos ativos por conjunto durante a captação.
- Janela de 1d tem peso muito maior que no perpétuo.
10. Hierarquia de ação (ordem ao otimizar)
Investigar e agir de baixo para cima:
- Anúncio (criativo). Diagnóstico mais comum.
- Conjunto (segmentação/orçamento). Se múltiplos criativos do mesmo conjunto estão ruins.
- Campanha (estrutura/objetivo). Último recurso.
Regra: nunca mudar dois níveis ao mesmo tempo no mesmo dia.
11. Proteções contra reset de aprendizado
Disparam reset:
- Mudança de orçamento > 20%
- Troca de evento de otimização
- Mudança de segmentação (audiência, posicionamento, idiomas)
- Pausar e reativar conjunto após 7+ dias
Quando a ação proposta dispara reset, a skill:
- Calcula custo aproximado de reaprendizado: 50 × CPA target (perpétuo) ou 50 × CPL target (lançamento).
- Compara com ganho esperado.
- Só executa se compensar. Caso contrário, sugere ação alternativa de menor impacto.
12. Sinal de prontidão para escala (handoff)
Esta seção é o bastão que /trafego-otimizar passa para /trafego-escalar.
A skill emite sinal_para_escala.pronta: true somente quando todas as condições abaixo são simultaneamente verdadeiras:
condicoes_de_handoff_para_escala:
metrica_norte:
janela_media_abaixo_target: true
janela_longa_abaixo_target: true
tendencia: "estavel_performando"
diagnostico_gargalo:
classificacao: "nenhum"
saude_estrutural:
frequencia: "<=2.5"
fora_de_aprendizado: true
pelo_menos_um_criativo_saudavel: true
prerequisitos_operacionais:
ultima_edicao_horas: ">=48"
historico_minimo_da_trilha_cumprido: true
sem_evento_sazonal_perturbador: true
backup:
criativos_saudaveis_no_conjunto: ">=2"
cooldown:
horas_desde_ultimo_handoff_de_descida: ">=168"
Se qualquer condição reprovar, emitir pronta: false com lista de critérios falhos.
12.1 Recebimento de handoff de descida da escala
Quando /trafego-escalar devolve uma campanha (freio total), a otimização recebe um payload e marca a campanha com vinda_da_escala: true. Isso ajusta a postura para o próximo ciclo:
- Tolerância menor a problemas (pausar mais cedo).
- Foco em recuperar margem de segurança antes de re-emitir prontidão.
- Cooldown obrigatório antes de novo handoff de subida.
13. Output esperado
O output ao usuário tem duas partes, sempre nessa ordem: primeiro o diagnóstico narrado em bullets (legível), depois o plano técnico estruturado em YAML (executável).
Parte 1. Diagnóstico narrado em bullets (visível, em português)
Sempre antes do YAML, imprimir o bloco abaixo em markdown. Substituir os {placeholders} pelos valores reais do diagnóstico.
## Diagnóstico
- **Trilha:** {trilha legível, ex: "Perpétuo médio (R$ 501 a R$ 1.499)"}
- **Métrica-norte:** {CPA | CPL} · meta R$ {target}
- **Tendência:** {frase em português a partir do diagnostico_tendencia}
- **Gargalo:** {frase em português a partir do diagnostico_gargalo} · {dentro do Meta | fora do Meta}
## O que está acontecendo
- {observação concreta 1 com número}
- {observação concreta 2 com número}
- {observação concreta 3 com número}
## Plano de ação
- {ação 1 com objeto e justificativa curta, em ordem de prioridade}
- {ação 2 com objeto e justificativa curta}
- {ação 3 com objeto e justificativa curta}
## Próximas observações
- {coisa para reanalisar em X horas}
## Está pronta para escalar?
{Sim → modo recomendado e velocidade sugerida | Não → 1 a 3 motivos curtos}
Tradução obrigatória dos enums (nunca imprimir o nome técnico em inglês ou snake_case na narrativa):
| Enum técnico | Frase em português |
|---|
estavel_performando | "estável e performando" |
esfriando_ou_ruido | "esfriando ou com ruído na janela curta" |
recuperando | "em recuperação" |
saturacao | "saturação" |
ruim_estrutural | "ruim estrutural" |
entrega_limitada | "entrega limitada" |
criativo | "criativo não atrai cliques únicos" |
tecnico | "técnico (link, redirect, velocidade da página)" |
pagina | "página de vendas / oferta" |
checkout | "atrito no checkout" |
leilao_audiencia | "leilão / audiência" |
nenhum | "nenhum gargalo identificado" |
Parte 2. Plano técnico estruturado (YAML)
Imediatamente após a Parte 1, prefixar com a linha "Plano técnico estruturado (para execução):" e entregar:
campaign_id: <id>
trilha: perpetuo_low | perpetuo_mid | perpetuo_high | lancamento_low | lancamento_mid | lancamento_high
metrica_norte: cpa | cpl
escopo: campanha_unica | campanhas_multiplas | conta_completa
vinda_da_escala: true | false
diagnostico_tendencia: estavel_performando | esfriando_ou_ruido | recuperando | saturacao | ruim_estrutural | entrega_limitada
diagnostico_gargalo: criativo | tecnico | pagina | checkout | leilao_audiencia | saturacao | nenhum
gargalo_dentro_do_meta:
{ }
[ ]
[ ]
Exceção
Se o aluno disser explicitamente "me dá só o YAML" ou "modo direto" na sessão, omitir a Parte 1.
13.1. Tabelas em português
TODA tabela markdown impressa para o usuário (antes ou depois do YAML técnico) deve usar cabeçalhos em português brasileiro. Os campos da Graph API entram em inglês mas são traduzidos no cabeçalho. Os identificadores de campo dentro do YAML técnico continuam em snake_case (vão para tool_calls).
Mapa obrigatório de tradução:
| Campo Graph API | Cabeçalho em português |
|---|
spend | Investimento |
impressions | Impressões |
reach | Alcance |
frequency | Frequência |
clicks | Cliques |
inline_link_clicks | Cliques no link |
unique_inline_link_clicks | Cliques únicos no link |
ctr | CTR geral |
inline_link_click_ctr | CTR no link |
unique_inline_link_click_ctr | CTR único no link |
cpc | CPC |
cpm | CPM |
cost_per_inline_link_click | Custo por clique no link |
purchases | Compras |
leads | Leads |
cpa | CPA |
cpl | CPL |
roas | ROAS |
connect_rate | Taxa de conexão |
conversao_pagina | Conversão da página |
conversao_anuncio | Conversão do anúncio |
taxa_carrinho_compra | Carrinho → Compra |
taxa_checkout_compra | Checkout → Compra |
campaign_name | Campanha |
adset_name | Conjunto |
ad_name | Anúncio |
date_start / date_stop |
14. Princípios que a skill nunca viola
- Mudanças graduais sempre. Orçamento move em ±20%, nunca mais.
- Aguardar maturação. Mínimo 48h entre ajustes no mesmo objeto.
- Diagnóstico antes de ação. Sempre rodar tendência + gargalo antes de propor.
- Verificar saúde técnica antes de pausar campanha inteira.
- Preservar aprendizado. Só aceitar reset quando ganho compensa.
- Métrica-norte é única por trilha. CPA em perpétuo, CPL em lançamento. ROAS apenas como confirmação.
- Bottom-up sempre. Criativo antes de conjunto, conjunto antes de campanha.
- Em lançamento na reta final, volume > custo (até o limite de 2× CPL target).
- Apenas dados nativos do Gerenciador. Se não vem do Gerenciador, não entra na decisão.
- Métricas derivadas sempre calculadas. Connect rate, conversão da página/anúncio, taxas de checkout são obrigatórias no diagnóstico (lidas via
/trafego-insights).
- Não pausar quando o gargalo está fora do Meta. Alertar o usuário e (se necessário) reduzir –20% como contenção, mas manter estrutura viva.
- Não escalar nesta skill. Quem sobe orçamento e duplica conjuntos é
/trafego-escalar. Aqui só emitir sinal de prontidão.
- Respeitar cooldown. Após handoff de descida da escala, aguardar 7d (perpétuo low/mid e lançamento) ou 14d (perpétuo high) antes de re-emitir prontidão.
- Detectar ABO vs CBO antes de qualquer mudança de orçamento. Ler
budget.tipo da campanha. Em ABO, mudança vai no adset (update_adset_budget); em CBO, vai na campanha (update_campaign_budget). Sem o tipo detectado, não sugerir redução — marcar acao: aguardar. Em CBO com gargalo localizado, oferecer pausar o conjunto específico em vez de reduzir a campanha inteira. Ver seção 6.0.
15. Ações em lote por filtro
Detalhes completos em sub-skills/acoes-lote.md.
Quando o aluno pede "pausa tudo com ROAS<1 nas últimas 2 semanas" ou "reduz 20% nos adsets com CPA > R$ 80", a skill aplica a ação em múltiplas entidades filtradas por critério.
Funções disponíveis:
pausar_em_lote(filtro). Pausa todas as entidades que batem o filtro.reduzir_budget_em_lote(filtro, percent). Reduz budget % nas entidades que batem.pausar_top_n_pior(metric, n). Pausa as N piores em uma métrica.
Critérios suportados: roas, cpa, cpl, ctr, frequency, cpm, spend, impressions, purchases, leads, cpc. Operadores: less_than, greater_than, between, equal. Períodos: today, last_3d, last_7d, last_14d, last_30d.
Sempre exige preview com lista de entidades afetadas + confirmação SIM antes de aplicar. Bloqueia automaticamente se mais de 50% dos adsets ativos da conta forem afetados (confirmação tripla).
