Centros de Comando de Anúncios

Construindo Centros de Comando de Anúncios

Objetivo

Construir um cockpit publicitário confiável para Google Ads e Meta Ads. Preservar a proveniência dos números, as diferenças entre plataformas, o isolamento das organizações e a segurança das ações enviadas às plataformas.

Classificar o produto antes de construir

• Reporting: conexão, sincronização e somente leitura.
• Pilotagem assistida: recomendações, pré-visualização e validação humana de orçamentos, pausas e retomadas.
• SaaS de autoatendimento: OAuth multi-usuário, seleção de contas, gestão de direitos, faturamento, conformidade e suporte.

Não prometer o terceiro nível se apenas uma conexão de administrador e testes simulados existirem.

Começar pelo contexto real

Inspecionar o repositório e a infraestrutura existentes antes de escolher uma stack. Levantar os usuários-alvo, o número de contas, a frequência de atualização, o histórico esperado, a fonte de verdade das conversões, as moedas, os fusos horários, a hospedagem e as restrições de conformidade.

Dimensionar a solução ao nível escolhido. Para uma ferramenta interna mono-organização somente leitura, uma organização única, papéis simples e um monólito são suficientes. Não impor OAuth de autoatendimento, microsserviços, faturamento ou fluxo de aprovação sem necessidade correspondente.

Carregar as referências úteis

• Sempre ler architecture-data-sync.md.
• Para Google Ads, ler google-ads.md.
• Para Meta Ads, ler meta-ads.md.
• Antes de qualquer escrita externa ou implantação em produção, ler production-safety.md.
• Antes de declarar o sistema concluído, aplicar as seções relevantes de acceptance-checklist.md.

As versões das APIs, permissões, procedimentos de revisão e cotas mudam. Verificar as documentações oficiais no momento da implementação.

Fluxo de trabalho

1. Estabelecer uma matriz de capacidades: plataforma, leitura/escrita, fonte, status comprovado e limites.
2. Projetar organizações, membros, papéis, conexões, contas de anúncios e registro de auditoria.
3. Implementar primeiro os conectores somente leitura e preservar a proveniência bruta.
4. Sincronizar por tarefas idempotentes para um banco normalizado. Exibir atualização, erros, cobertura e contexto de atribuição.
5. Reconciliar uma amostra em um período encerrado com as interfaces nativas do Google e Meta.
6. Produzir as recomendações por regras e cálculos determinísticos. Usar um LLM apenas para explicar ou reformular.
7. Adicionar cada escrita separadamente com pré-visualização, autorização, limites, idempotência, auditoria, releitura remota e procedimento de rollback.
8. Testar o isolamento entre organizações, expiração OAuth, cotas, retomada de tarefas e métricas ausentes.

Invariantes

• Nenhum segredo no repositório, navegador, logs, capturas de tela, exportações ou prompts.
• Nunca somar ingenuamente as conversões do Google e Meta: manter plataforma, ação, janela e modelo de atribuição.
• Uma sincronização agendada não é tempo real.
• Nunca testar uma mutação em uma conta de produção sem autorização explícita e escopo preciso.
• Qualificar cada capacidade: implementada, testada em sandbox, validada em produção ou parcial.

Entrega esperada

Fornecer a arquitetura e suas hipóteses, o esquema de dados, os fluxos de conexão Google e Meta, a estratégia de sincronização, a matriz de permissões, os guardrails de escrita, os testes de reconciliação e o runbook de operação. Separar claramente o que está realizado do que ainda precisa ser validado.