Glossário de Marketing Digital, SEO, Ads & Desenvolvimento

• Pode gastar até 2x o budget diário em dias de alta demanda (compensa em dias fracos no mesmo mês).
• Nunca ultrapassa 30,4 × budget diário no mês (média mensal protegida).
• Em Performance Max com budget de campanha, gasta proporcionalmente até o fim da janela definida.

• Search Lost IS (Budget) > 10% → orçamento está limitando impressões
• Conversões concentradas nas primeiras horas do dia (acabou orçamento cedo)
• ROAS alto + volume baixo → sinal clássico de que o cap trava escala

IS = Impressões recebidas ÷ Impressões elegíveis

• Search IS — parcela nos resultados de busca (ideal: 80%+ em marca, 40-60% em genéricos).
• Search Lost IS (Budget) — % de impressões perdidas por orçamento insuficiente. Solução: aumentar Budget Cap.
• Search Lost IS (Rank) — % perdidas por Ad Rank baixo (lance, Quality Score, extensões). Solução: lance mais alto, melhorar relevância ou landing page.
• Search Top IS / Abs. Top IS — parcela em que você aparece no topo / absoluto topo da SERP. Crítico em keywords de marca: abs. top < 80% significa concorrente está roubando tráfego da sua marca.
• Click Share — mesma lógica aplicada a cliques em vez de impressões (disponível em Shopping e Performance Max).

• Lost IS (Budget) > Lost IS (Rank) → você perde por dinheiro, escalar orçamento é alavanca #1.
• Lost IS (Rank) > Lost IS (Budget) → você perde por leilão, trabalhar Quality Score, copy e landing é prioridade.
• Em campanhas de marca, Abs. Top IS < 90% é bandeira vermelha — concorrente faz bidding no seu nome.

1. Local / reversível — editar um arquivo, criar branch, rodar teste. Você quebra, você conserta, ninguém vê.
2. Sessão atual — restart do dev server, drop de banco local, perda de stash. Custo: minutos do seu tempo.
3. Repositório / time — push para branch compartilhada, edit em main de docs, merge de PR. Outros desenvolvedores são afetados.
4. Staging / ambiente compartilhado — deploy em staging, seed em banco de QA. Afeta testers e QA até reverter.
5. Produção — wrangler deploy, migration aplicada, secret rotacionado. Clientes reais são afetados em segundos.
6. Produção + dados — DROP TABLE, git push --force em main, DELETE FROM ... WHERE errado. Perda permanente, recuperação via backup (se houver).
7. Multi-sistema / cross-org — DNS de domínio raiz alterado, certificado SSL expirado, credencial de pagamento revogada. Cliente, parceiros, integrações — todos caem juntos.

• Quem é afetado? — só eu, meu time, todo o time, clientes pagantes, todos os usuários?
• Por quanto tempo? — segundos (rollback automático), minutos (rollback manual), horas (recuperar de backup), permanente (sem recuperação)?
• É reversível? — rollback de 1 comando? Migration reversível? Backup recente disponível? Ou só "comprar passagem para Maceió"?
• Existe blast shield? — feature flag, canary deploy, soft launch, rollout % gradual? Ou é all-or-nothing?
• Qual o sinal de "deu errado"? — error rate, alarme em logs, ticket de suporte, queda de receita? Quanto tempo até detectar?

• Canary deploy — releasing para 1%, depois 10%, depois 100% — bug afeta 1% dos usuários, não todos.
• Feature flag — código em produção mas desligado para 99%; liga gradualmente, kill switch instantâneo.
• Migrations forward-compatible — schema novo coexiste com código antigo; rollback de código não exige rollback de schema.
• Backups + ponto de restauração — Cloudflare D1 tem Time Travel (até 30 dias), Postgres tem PITR, S3 tem versionamento. Antes de DELETE grande, verificar.
• Dry-run primeiro — wrangler deploy --dry-run, terraform plan, git push --dry-run. Vê o efeito sem causar o efeito.
• Defense-in-depth — duas camadas (CF Rule + middleware) impedem que falha em uma derrube tudo.

• Comando contém --force ou --no-verify.
• rm -rf, DROP, DELETE sem WHERE, git reset --hard, git push --force.
• Mudança em DNS raiz (apex), certificado SSL, credencial de pagamento, secret de produção.
• Edit direto em produção sem passar por staging/PR/code review.
• Sexta-feira 18h — alto blast radius temporal: equipe está saindo, recuperação acontece no fim de semana.

Quanto maior o blast radius, mais alto o custo de errar e mais alta deve ser a barreira de execução: code review, dois aprovadores, janela de manutenção anunciada, rollback testado. Engenharia sênior se distingue de júnior pela consciência do blast radius antes de digitar Enter.

• Apex: otimiza.pro e otimizapro.com
• Subdomínios: plataforma.otimiza.pro, nr1.otimizapro.com, crm.otimizapro.com, etc.

HTTP/1.1 410 Gone
Content-Type: text/html; charset=utf-8
Cache-Control: public, max-age=86400
Content-Length: <n>

• Cache-Control obrigatório — 410 deve ser cacheável (economiza hits e acelera deindex no Google).
• Content-Type: text/html com corpo amigável explicando a remoção ao usuário humano.
• Não enviar Location: (isso é redirect 301/302/308).
• Não enviar Retry-After: (só faz sentido em 429/503).
• X-Robots-Tag: noindex é redundante — Google já interpreta 410 como sinal de deindex.

• Retornar 200 OK com página "conteúdo removido" → soft 404 (Google ignora e mantém indexada).
• Usar 301 para home quando o conteúdo realmente morreu → dilui autoridade e confunde Search Console.
• Esquecer Cache-Control → edge/CDN revalida a cada hit e você paga por tráfego que deveria estar em cache.

• Produto descontinuado permanentemente → 410
• Blog post deletado e não será republicado → 410
• URL digitada errada / rota inexistente → 404
• Página que voltará em breve → 503 com Retry-After

• Regra de bloqueio de bot aplicando challenge em usuários legítimos → expression muito genérica.
• Cache Rule entregando HTML antigo de /admin/* → padrão de path englobando rotas dinâmicas.
• Redirect Rule 301 disparando em query strings ou subrotas não previstas (bug clássico de migração de URL).
• Transform Rule de cabeçalho afetando /api/* quando só deveria afetar assets.

# Amplo (errado — casa /admin, /admin-old, /administrador)
(http.request.uri.path contains "/admin")

# Estrito (correto — casa exatamente /admin e /admin/*)
(http.request.uri.path eq "/admin"
 or starts_with(http.request.uri.path, "/admin/"))

# Ainda mais estrito (só método GET, só em produção)
(http.request.uri.path eq "/admin"
 and http.request.method eq "GET"
 and http.host eq "otimizapro.com")

• eq — igualdade exata (use em vez de contains sempre que possível).
• starts_with(path, "/x/") — prefixo com barra final força subrota, evita colisão com /xy.
• matches "^/produto/[0-9]+$" — regex PCRE para validar formato (só números após /produto/).
• in {"GET" "HEAD"} — restringir por método HTTP.
• and http.host eq "dominio.com" — escopar ao host exato, evita vazamento entre subdomínios.

• Trocar contains por eq ou starts_with.
• Escopar ao http.host para não vazar entre zones.
• Restringir http.request.method se a regra só faz sentido em GET/POST.
• Testar em modo Log antes de promover para Block/Challenge (WAF tem modo simulação).
• Versionar a expressão em commit — regra sem histórico é bug futuro garantido.

Cliente → Cloudflare Rule → Worker/Middleware → Handler
            ↑                    ↑
         regra A              regra B
         (path contém /admin) (path === /admin/)

→ /admin/users bloqueia em A, passa em B   ❌ assimetria
→ /admin     passa em A, bloqueia em B   ❌ assimetria
→ matcher idêntico em A e B              ✅ simetria perfeita

• Rota funciona em localhost (só middleware roda) mas dá 403 em produção (CF bloqueia antes).
• Cache Hit retornando 200 enquanto a rota deveria exigir login — CF cacheou antes do middleware validar sessão.
• Log do Worker mostra 500 mas usuário vê página do Cloudflare Challenge (WAF interceptou).
• Redirect funciona só em alguns hits: Page Rule 301 + middleware 308 em conflito, ordem não determinística.

• Path matcher idêntico em CF Rule expression e no matcher do middleware. Se a CF usa starts_with(path, "/admin/"), o middleware deve usar /admin/.* — não /admin sem barra.
• Exclusões espelhadas — assets estáticos excluídos em ambas as camadas (/_next/static, /assets/*, favicon.ico).
• Host scopado — http.host eq "otimizapro.com" na CF == request.headers.host === "otimizapro.com" no middleware.
• Um dono por responsabilidade — redirect de marketing na CF (mais rápido, sem cold start); auth no middleware (precisa de contexto de sessão); cache na CF (default); bot-block na CF quando genérico, no middleware quando baseado em payload.
• Testes de espelhamento — script que bate N URLs críticas e compara response status com e sem CF na frente (usando *.workers.dev bypass vs zone).
• Versionar em repositório único — wrangler.toml + CF Rules exportadas via API + middleware no mesmo repo. Regra fora do git é bug esperando para acontecer.

• Só CF — block de ASN/país, rate-limit genérico, cache de assets, SSL enforcement, HSTS, redirect www → apex.
• Só Middleware — auth com JWT, feature flags por usuário, A/B test com cookie, logging estruturado de requisições.
• Simétrica em ambos — path matching de rotas protegidas (defense-in-depth), host scoping, exclusão de assets, User-Agent blocking de bots conhecidos.

• CF Rule e middleware usam a mesma lista de paths legíveis definida em worker/router.js — middleware importa, CF Rule é gerada por script a partir do mesmo array.
• /admin/* → CF bloqueia sem ADMIN_API_KEY cookie + middleware valida o mesmo cookie no handler. Defense-in-depth, zero divergência.
• Bot-block User-Agent ~ /bot|crawler/i idêntico em CF expression e em request.headers.get("user-agent").

1. Lê wrangler.toml (ou wrangler.jsonc) — pega name, entry point, routes, bindings, vars, compatibility_date.
2. Executa o build se houver [build] section (ex.: esbuild, vite build, npm run build).
3. Faz diff dos assets estáticos (pasta assets.directory) contra o que já está no edge — só envia arquivos novos ou modificados.
4. Valida sintaticamente o código (esbuild interno), checa limites (1 MiB no Free / 10 MiB no Paid após compressão).
5. Registra a nova versão no Cloudflare, gera Version ID (UUID) e promove para produção imediatamente (a menos que use --dry-run ou wrangler versions upload).
6. Rede edge propaga em todos os 300+ datacenters — tipicamente < 30 segundos globalmente.

• --env production — usa o bloco [env.production] do wrangler.toml (routes, vars e bindings específicos do ambiente).
• --dry-run — valida e faz bundle sem publicar; útil em CI para PR checks.
• --outdir dist/ — salva o bundle final em disco (útil para debug de tamanho / source map).
• --keep-vars — preserva vars existentes que foram definidas via dashboard/API (importante em contas com secrets gerenciados fora do wrangler.toml).
• --minify — minifica o bundle (default em produção).
• --compatibility-date 2026-04-17 — força uma data de compatibilidade específica (senão lê do toml).

name = "otimizapro"
main = "worker/index.js"
compatibility_date = "2026-04-17"

[assets]
directory = "."
binding = "ASSETS"

[[d1_databases]]
binding = "DB"
database_name = "otimizapro-crm"
database_id = "0a4a1840-31e5-4845-9684-b65e3da8c0c4"

[[routes]]
pattern = "otimizapro.com/*"
zone_name = "otimizapro.com"

[triggers]
crons = ["*/1 * * * *"]

• npm run lint — ESLint limpo. Bug trivial capturado no linter não derruba produção.
• npm run format — Prettier aplicado. Evita diff de formatação que polui PRs.
• wrangler d1 migrations list otimizapro-crm — checar se há migration nova não aplicada. Deploy com schema dessincronizado quebra em runtime.
• wrangler deploy --dry-run — validação sem publicar.
• git status limpo e branch == master. Deploy de branch errado acontece mais do que se admite.

• Smoke test — curl -I nas 5 URLs críticas (home, admin, API principal, um artigo, um formulário) esperando 200/302.
• Purge de cache se você alterou HTML/CSS/JS que estava no edge cache (wrangler não purga automaticamente — é responsabilidade sua).
• Verificar wrangler tail por 2-3 minutos procurando exceptions.
• Anotar o Version ID retornado. Rollback rápido: wrangler rollback <version-id>.

# listar versões recentes
wrangler deployments list

# voltar para versão anterior (propagação < 30s)
wrangler rollback <version-id>

• Bundle > 1 MiB (Free) / 10 MiB (Paid) → deploy falha. Use --outdir para inspecionar e remover deps pesadas (moment.js, lodash completo etc.).
• Secrets commitados em wrangler.toml → nunca. Use wrangler secret put KEY. Secrets no toml vazam em build logs, screenshots, git.
• compatibility_date desatualizada → APIs antigas do runtime; novas features ignoradas. Atualize a cada trimestre.
• Deploy sem d1 migrations apply prévio → no such column em produção, 500 em loop.
• Routes conflitando entre dois Workers no mesmo host (ex.: otimizapro.com/* em dois workers) → comportamento não determinístico, depende da ordem de deploy. Cloudflare rejeita atualmente, mas zonas antigas podem ter esse fantasma.
• Esquecer --env production em ambiente multi-env → deploy de dev vai para produção por acidente.

• Tabelas — as entidades (leads, deals, campaigns, contacts).
• Colunas + tipos — INTEGER, TEXT, REAL, BLOB, BOOLEAN, TIMESTAMP, JSON. Tipo errado é bug esperando o bug ficar caro.
• Primary Key — identificador único da linha, quase sempre id INTEGER PRIMARY KEY AUTOINCREMENT.
• Foreign Keys — lead_id REFERENCES leads(id). Garantem que relação existe; ON DELETE CASCADE / ON DELETE SET NULL definem o que acontece quando o pai some.
• Índices — não são parte do shape dos dados, mas do schema operacional. Índice em coluna buscada = query 100x mais rápida.
• Constraints — NOT NULL, UNIQUE, CHECK. Regras que o banco impõe antes de aceitar a linha.
• Views / Triggers — schema dinâmico; views são queries nomeadas, triggers reagem a mudanças.

CREATE TABLE leads (
  id          INTEGER PRIMARY KEY AUTOINCREMENT,
  email       TEXT    NOT NULL UNIQUE,
  name        TEXT,
  score       INTEGER DEFAULT 0 CHECK (score BETWEEN 0 AND 100),
  segment_id  INTEGER REFERENCES segments(id) ON DELETE SET NULL,
  created_at  INTEGER NOT NULL DEFAULT (unixepoch()),
  updated_at  INTEGER NOT NULL DEFAULT (unixepoch())
);

CREATE INDEX idx_leads_email      ON leads(email);
CREATE INDEX idx_leads_score_desc ON leads(score DESC);
CREATE INDEX idx_leads_segment    ON leads(segment_id) WHERE segment_id IS NOT NULL;

• Schema-first (SQL: Postgres, MySQL, SQLite, D1) — estrutura validada no insert; bugs aparecem cedo, queries são rápidas e previsíveis.
• Schemaless (Mongo, DynamoDB em modo flexível) — aceita qualquer forma; bugs aparecem em produção quando a aplicação lê dados inesperados.
• Schema-on-read (Data Lakes, S3 + parquet) — dado bruto fica salvo, schema aplicado só na hora da leitura. Flexível para analytics, ruim para OLTP.

Schema de produção nunca é alterado com ALTER TABLE direto — sempre via migration versionada (ver termo Migration). Schema-as-code: o estado atual do schema é derivado da soma das migrations aplicadas.

Ferramentas modernas como Drizzle ORM invertem o fluxo: você define o schema em TypeScript, a ferramenta gera o SQL + tipagem end-to-end. Mudou o schema? Autocomplete quebra no VS Code antes do bug chegar em produção.

• SELECT — lê dados. 80% das queries em apps de leitura intensiva.
• INSERT — cria linha.
• UPDATE — altera linha(s) existentes. Sempre com WHERE — esquecer é como rm -rf da tabela.
• DELETE — remove linha(s). Mesmo conselho: WHERE é obrigatório.
• UPSERT — "insere se não existe, atualiza se existe" (INSERT ... ON CONFLICT ... DO UPDATE). Operação atômica favorita de sistemas de sincronização.
• AGGREGATE — COUNT, SUM, AVG, MAX, MIN com GROUP BY. Coração de dashboards e relatórios.

SELECT
  s.name          AS segmento,
  COUNT(*)        AS total_leads,
  AVG(l.score)    AS score_medio,
  MAX(l.created_at) AS ultimo_lead
FROM leads l
JOIN segments s ON s.id = l.segment_id
WHERE l.created_at > unixepoch() - 30*86400
  AND l.score >= 50
GROUP BY s.id, s.name
HAVING COUNT(*) > 10
ORDER BY total_leads DESC
LIMIT 20;

1. FROM + JOIN — monta o conjunto de trabalho.
2. WHERE — filtra linhas individuais.
3. GROUP BY — agrupa em buckets.
4. HAVING — filtra os buckets (diferente de WHERE: opera pós-agregação).
5. SELECT — projeta as colunas finais.
6. ORDER BY — ordena.
7. LIMIT / OFFSET — recorta a janela.

Saber dessa ordem resolve 70% dos "por que essa query retorna o que retorna?".

• GraphQL query — cliente descreve o shape do retorno; servidor resolve campo a campo.
• Query string de URL — ?q=vt&cidade=sp; params depois do ?.
• Search query (Google) — a string que o usuário digita na busca. Termos keyword research, search intent e long-tail são todos sobre isso.
• Media query (CSS) — regras condicionais por tamanho de tela (@media (max-width: 640px)).

• EXPLAIN QUERY PLAN — comando que revela se sua query usa índice ou faz full-table-scan. Primeira ferramenta de debug.
• Índices corretos — WHERE score >= 50 sem índice em score = varredura linear.
• N+1 query problem — loop em código que faz 1 query por item. Troca por 1 join ou 1 WHERE IN (...).
• SELECT * é inimigo — transfere colunas grandes (blobs, JSON) que você não usa; quebra cache; vaza dados.
• Parâmetros bound — WHERE email = ? com parâmetro, nunca concatenação de string. Segurança (anti-SQL-injection) e performance (plan cache).

// Cloudflare D1 — bind de parâmetros, anti-injection
const { results } = await env.DB
  .prepare('SELECT id, email, score FROM leads WHERE score >= ? LIMIT ?')
  .bind(75, 20)
  .all();

• Nome numerado (097_add_pending_enrollment.sql) — ordem lexicográfica = ordem de execução, sem ambiguidade.
• Up — o que a migration aplica (CREATE TABLE, ALTER, INSERT de seed).
• Down — o rollback correspondente (DROP, ALTER reverso). Nem toda ferramenta exige, mas é boa prática.
• Transacional — executada em BEGIN...COMMIT para que falha no meio não deixe o banco em estado parcial.

-- functions/db/097_add_pending_enrollment.sql
ALTER TABLE drip_enrollments
  ADD COLUMN pending_enrollment_at INTEGER;

CREATE INDEX IF NOT EXISTS idx_drip_pending
  ON drip_enrollments(pending_enrollment_at)
  WHERE pending_enrollment_at IS NOT NULL;

• Nunca editar migration já aplicada em produção — crie uma nova que corrige. A migration aplicada é história, imutável.
• Forward-compatible primeiro — deploy adiciona coluna/tabela nova antes do código que a usa; remove só depois de todo código parar de referenciar.
• Backfill assíncrono para colunas NOT NULL em tabelas grandes: 1) adiciona coluna nullable; 2) backfill em lotes via cron; 3) migration final adiciona NOT NULL.
• Índices com CONCURRENTLY (Postgres) ou offline (SQLite/D1) — índice bloqueante em tabela de 50M linhas derruba produção.
• Testar em dump de produção, não em banco vazio — migration que demora 3s em 1.000 linhas pode demorar 40 min em 10M.
• Sem DROP COLUMN irrecuperável sem backup explícito. Renomeie para _deprecated_colname antes.

• Cloudflare D1 — migrations SQL em pastas numeradas, aplicadas via wrangler d1 migrations apply.
• Drizzle — drizzle-kit generate deriva SQL do schema TypeScript.
• Prisma — prisma migrate gera migration.sql + mantém histórico em _prisma_migrations.
• Postgres puro — sqitch, flyway, goose ou dbmate.
• Django — python manage.py makemigrations + migrate (autogerada a partir dos models).

• Gaps na numeração (095, 097, pulou 096) → dois devs fizeram merge paralelo. Renumere antes de commitar.
• Migration idempotente (IF NOT EXISTS) é amiga de ambiente de dev, mas esconde bugs em produção onde deveria falhar se já aplicada.
• ALTER TABLE ... DROP COLUMN em SQLite antigo (< 3.35) não existe — precisa recriar a tabela. D1 atual suporta.
• Seeds dentro de migration: não. Seeds vão em script separado, porque são dados, não schema.

export const config = {
  matcher: [
    // regex negativo: rodar em TUDO exceto assets e API
    '/((?!_next/static|_next/image|favicon.ico|api/).*)',
  ],
};

• Middleware roda em cada requisição — matcher mal escrito vira gargalo de performance (ex.: processar .png, .css, .js à toa).
• Regex lookahead negativo (?!...) é padrão para excluir rotas: "tudo que não começa com X".
• Em Cloudflare Workers, o matcher equivalente é o routes no wrangler.toml usando padrões glob — mas dentro do Worker você ainda usa regex no URL.pathname.

• ^/admin(/.*)?$ — /admin e qualquer subrota (protege área logada).
• \\.(jpe?g|png|gif|webp|avif|css|js|woff2?|svg)$ — assets estáticos (geralmente excluir).
• ^/api/(?!public/) — APIs privadas (/api/* exceto /api/public/*).
• ^/(pt|en|es)(/|$) — captura locale para i18n antes de rotear.

• Esquecer de escapar . em regex de extensão → casa com qualquer caractere.
• Matcher amplo (/.*) sem exclusões → middleware roda em 100% das assets, consome CPU time da edge (custo real no Cloudflare Workers).
• Ordem de middlewares importa: auth antes de rate-limit antes de logging.

• vs Prisma — Drizzle é mais próximo de SQL cru, sem runtime pesado; ideal para edge. Prisma é mais abstrato e DX-friendly, mas com engine binário que não roda em todos runtimes.
• vs Kysely — Kysely é puro query builder; Drizzle adiciona schema declarativo, migrations versionadas e relational queries.
• vs SQL cru — Drizzle mantém SQL legível, mas ganha tipagem automática a partir do schema (autocomplete + erro em compile-time para colunas inexistentes).

• PostgreSQL (node-postgres, Neon, Supabase, Vercel Postgres)
• MySQL / PlanetScale
• SQLite (better-sqlite3, Cloudflare D1, Turso, Bun SQLite)

// schema.ts
export const leads = sqliteTable('leads', {
  id: integer('id').primaryKey(),
  email: text('email').notNull().unique(),
  score: integer('score').default(0),
  createdAt: integer('created_at', { mode: 'timestamp' }),
});

// query
const hotLeads = await db.select()
  .from(leads)
  .where(gt(leads.score, 75))
  .orderBy(desc(leads.createdAt))
  .limit(20);

• Roda nativo em Cloudflare Workers + D1 (nossa stack) — zero cold start de engine.
• drizzle-kit gera migrations SQL reversíveis a partir do schema TypeScript.
• Tipagem end-to-end: o retorno de .select() é tipado pelo schema — pega bug em CI antes de chegar ao usuário.
• Bundle pequeno (~10kb gzipped) — importante em Workers com limite de 1MB no plano Paid.