Playbook do VER Reporting

A plataforma que assinamos hoje faz três coisas: busca os dados nas plataformas de mídia, guarda esses dados, e desenha o relatório. Estamos pagando pelas três juntas. A proposta é separá-las e ficar donos da do meio.

O dado deixa de morar na ferramenta do fornecedor e passa a morar numa base nossa. A partir dela, a agência desenha o relatório onde quiser — no Looker Studio, numa interface própria, num PDF. Trocar de interface deixa de ser um projeto; vira uma decisão de fim de semana.

A demonstração está no mesmo endereço, em reporting.ver.ag. A página não é indexada por buscadores e os dados são simulados.

1. Quantos clientes justificam o esforço

O custo de construir é fixo; o custo da plataforma atual é por cliente. Faça a conta com o número real: se a mensalidade é X por cliente e temos N clientes, o gasto anual é 12 · X · N. Compare com uma estimativa honesta de horas de desenvolvimento mais o custo de nuvem da seção 6. Abaixo de uns 5 clientes, normalmente não fecha.

2. Quem sustenta isso daqui a um ano

Conector de API quebra. Meta muda versão da Marketing API periodicamente; o Google deprecia campos. Se a resposta para "quem arruma quando quebrar" for uma pessoa só, e essa pessoa for você, isso precisa entrar na decisão — não como impedimento, mas como risco declarado.

3. Qual é o primeiro cliente

Escolha um só para a Fase 1. De preferência um com Google Ads e Meta Ads rodando, site com formulário, e paciência se algum número sair errado na primeira semana. Um cliente em produção ensina mais que três no papel.

A ordem importa: cada fase entrega alguma coisa apresentável sozinha. Se o projeto parar no meio, o que já foi feito continua valendo.

Em dois papéis bem diferentes: como ferramenta de construção, enquanto vocês montam isso, e como peça do produto, rodando sozinho todo mês depois de pronto. O segundo é o que a plataforma atual não faz.

Como ferramenta de construção

Os conectores da Fase 2 e as views da Fase 3 são trabalho repetitivo e bem documentado — exatamente o tipo de código que o Claude Code escreve rápido. A diferença está em como o pedido é feito: peça o contrato, não "um script".

A frase que mais economiza retrabalho é "ser idempotente". Sem isso, um job que roda duas vezes dobra o investimento do dia no relatório — e você só descobre na reunião com o cliente.

Como peça do produto: o comentário do relatório

Este é o uso que muda a percepção do cliente. Todo mês, um job lê os números fechados do BigQuery e pede ao Claude um parágrafo de análise — o que mudou, por que provavelmente mudou, e o que olhar no mês seguinte. O texto entra no topo do Looker Studio, com a assinatura da agência.

Cloud Run job · TypeScript

// npm install @anthropic-ai/sdk @google-cloud/bigquery
import Anthropic from "@anthropic-ai/sdk";
import { BigQuery } from "@google-cloud/bigquery";

const client = new Anthropic();  // lê ANTHROPIC_API_KEY do ambiente
const bq = new BigQuery();

// 1. Os números fechados do mês, já agregados pelas views da Fase 3.
const [rows] = await bq.query({
  query: `SELECT * FROM \`ver_reporting.v_resumo_mensal\`
          WHERE client_id = @clientId AND mes = @mes`,
  params: { clientId, mes },
});

// 2. O Claude recebe SÓ números e escreve a leitura.
const response = await client.beta.messages.create({
  model: "claude-opus-5",
  max_tokens: 4000,
  thinking: { type: "adaptive" },
  // se o modelo recusar a tarefa, a API refaz num modelo alternativo
  betas: ["server-side-fallback-2026-07-01"],
  fallbacks: "default",
  system: `Você é analista de performance da Agência VER.
Escreva a leitura do mês para o cliente, em português do Brasil.
Regras:
- 3 parágrafos, no máximo 180 palavras no total.
- Cite sempre o número junto da afirmação.
- CPL e CPA subindo é resultado pior, mesmo que o volume tenha crescido.
- Não invente causa que os dados não sustentam; se a variação não tem
  explicação nos números, diga que precisa de investigação.
- Termine com a recomendação para o mês seguinte.`,
  messages: [{
    role: "user",
    content: `Dados do mês:\n${JSON.stringify(rows[0], null, 2)}`,
  }],
});

// 3. Grava de volta no BigQuery; o Looker Studio lê daqui.
const texto = response.content.find((b) => b.type === "text")?.text ?? "";

Outros dois usos que valem o esforço

Alerta de variação, todo dia de manhã

Um job diário compara os últimos 7 dias com os 7 anteriores. Se algum cliente cruzar um limiar — CPL 25% acima, investimento parado, leads em queda —, aí sim chama o Claude para escrever o alerta e manda no canal da equipe. O modelo só é acionado quando há o que dizer, o que mantém o custo perto de zero e evita que o alerta vire ruído.

Manutenção quando a API quebrar

Quando um conector falhar, o log de erro mais o arquivo do job colados no Claude Code costumam resolver em minutos. Vale guardar cada conector num repositório com um CLAUDE.md explicando o schema e as regras de idempotência — assim o contexto não precisa ser reconstruído a cada incidente.

O Looker Studio (o antigo Data Studio) deixa de ser a fonte dos dados e passa a ser uma das saídas. Ele lê a base da VER pelo conector nativo do BigQuery, que já vem pronto e é gratuito.

Um painel, todos os clientes

O erro clássico é duplicar o relatório por cliente e acabar com onze painéis ligeiramente diferentes. A alternativa é montar um painel e filtrar por client_id, de duas maneiras combinadas:

• Parâmetro na URL — o mesmo relatório abre já filtrado para o cliente certo, e cada cliente recebe o seu link.
• Fonte de dados parametrizada — a consulta ao BigQuery recebe o cliente como parâmetro e traz só as linhas dele, o que também reduz custo de consulta.

Ajuste de layout feito uma vez vale para a carteira inteira. É o mesmo princípio da interface própria: uma aplicação, N clientes.

O que o Looker Studio automatiza sozinho

• Envio agendado — PDF por e-mail, no dia e horário que você definir. Resolve o fechamento mensal sem ninguém exportar nada.
• Atualização — o painel lê a base a cada abertura; como a coleta é diária, o cliente vê o dado de ontem sem pedir.
• Cache — vale ativar o cache do relatório e, se as consultas ficarem lentas ou caras, avaliar o BI Engine do BigQuery.

O limite honesto da ferramenta

O Looker Studio é excelente para entregar ao cliente e limitado para operar a agência. Ele não faz alerta por variação, o controle de acesso é mais grosso do que gostaríamos, e desenhar nele qualquer coisa fora do padrão é lento. Por isso a interface própria existe em paralelo: Looker Studio para o cliente, VER Reporting para a operação — as duas lendo a mesma base, sem duplicar regra de cálculo.

Ordens de grandeza para uma carteira pequena, considerando volumes de agência — não de e-commerce grande. Confirme os preços atuais antes de levar a conta para a reunião; tabelas de nuvem mudam.

Se o comentário mensal sair caro em escala — não é o caso aqui —, a mesma chamada roda em Claude Sonnet 5 (US$ 2 / US$ 10 por milhão) ou Haiku 4.5 (US$ 1 / US$ 5). Para um parágrafo por cliente por mês, a diferença é irrelevante e não vale abrir mão da qualidade da análise.

Os quatro riscos reais, na ordem em que costumam aparecer:

Número que não bate com a plataforma

Vai acontecer, e quase sempre por um destes três motivos: fuso horário (a plataforma usa o fuso da conta, o BigQuery grava em UTC), janela de atribuição diferente, ou revisão retroativa que o nosso job não reprocessou. Por isso a Fase 2 puxa 7 dias, e por isso a operação em paralelo existe.

Conector que quebra em silêncio

O pior cenário não é o job falhar — é ele rodar e trazer zero. Cada job precisa gravar um registro de execução, e o alerta diário deve disparar quando um cliente amanhece com investimento zerado sem motivo.

Dependência de uma pessoa só

Se só uma pessoa sabe onde as coisas estão, a agência trocou uma dependência de fornecedor por uma dependência interna — que é pior, porque não tem contrato. Código em repositório, credenciais no Secret Manager, e o CLAUDE.md de cada conector explicando o schema reduzem bastante isso.

Escopo que cresce sozinho

Assim que o primeiro painel funcionar, vão pedir TikTok, LinkedIn, atribuição multi-toque e previsão de investimento. O modelo de dados aguenta — novas plataformas entram na mesma tabela campaign_metrics —, mas cada uma é mais um conector para manter. Vale combinar antes que canal novo só entra com demanda de cliente que justifique.

Nenhum destes passos exige decisão definitiva nem cancelamento de nada. São todos reversíveis, e juntos dão um mês de dado real para decidir com base em algo além de estimativa.

• Criar o projeto no Google Cloud e o dataset ver_reporting no BigQuery.
• Escolher o cliente-piloto e conferir se temos acesso de leitura às contas dele.
• Ligar o Data Transfer do Google Ads para esse cliente.
• Ativar o export do GA4 e a exportação em massa do Search Console.
• Esperar 48 horas e conferir se as tabelas apareceram.
• Levantar a mensalidade real da plataforma atual, por cliente e no ano.
• Mostrar a demonstração ao sócio e fechar a decisão da seção 2.