Case Files

Cada case conta só três coisas: onde travava, o que fizemos, como os números mudaram.

História de sucesso sem método e sem evidência, nem a gente acredita. Todos os números abaixo vêm de registros de sistema e painéis de plataforma auditáveis; clientes sempre anonimizados — citamos só o segmento.

GROUP A

Sistemas de automação

AutomationiGaming / CRM de jogadores

Bot de LINE para jogadores: check-in, payout, vinculação de conta e sorteio, tudo automático

A operação de jogadores rodava toda na mão: check-in anotado em planilha, payout conferido item a item pelo suporte, identidade do LINE que não batia com a conta do jogo — bastava acumular campanhas para começar a vazar e errar.

  • LINE vinculado à conta do jogo: vincula uma vez e a titularidade está resolvida — daí em diante toda interação já cai na identidade certa do jogador
  • Check-in diário com prêmio, sorteios com apuração automática e payout automático — crédito na conta dispara push na hora, zero conferência manual
  • Broadcast de campanhas e consultas por comando (promoções, progresso); o suporte só cuida das exceções
  • Deploy em VM no GCP: systemd com boot automático + auto-restart em crash, alerta externo de queda e backup off-site do banco a cada 6 horas
Check-in / payout / vinculação / sorteio: 4 funções 100% automáticas Backup off-site do banco a cada 6 horas 24/7 alerta de queda + auto-recuperação

Fonte: registros de deploy e execução do sistema (na nuvem desde 2026-05)

AutomationiGaming / Operação de comunidade

Bot de aquecimento de grupo: várias personas conversando no automático, sem cara de robô

Grupo sem conversa é grupo morto; escalar gente por turno para animar sai caro e é difícil de gerenciar: o discurso desalinha, a escala nunca fecha e ninguém lembra o que já foi dito.

  • Personas fixas, cada uma com personalidade e memória de longo prazo: o que indicou ontem e o histórico de green/red ficam no ledger; no dia seguinte elas mesmas revisam o resultado e puxam papo entre si, sem quebrar o personagem
  • Conteúdo 100% de dados reais: calendário, odds e resultados vêm de fontes reais, inventar é proibido — errar um jogo mata a confiança do grupo
  • Ritmo de envio humanizado: contas alternadas, intervalo aleatório de 10–15 minutos, como gente real cada um na sua — não robô floodando em fila
  • Cada mensagem enviada gera screenshot de prova e verificação de que entrou mesmo no grupo-alvo; saiu ou não saiu, tem registro
4 personas fixas com ledger de memória de longo prazo Intervalo de 10–15 min aleatório e humanizado Cada envio verificado com screenshot dentro do grupo

Fonte: registros de execução do sistema de envio e screenshot de cada mensagem

AutomationDados esportivos / Mídia de conteúdo

Site de conteúdo esportivo com 400+ páginas, pipeline de atualização inteiro no automático

Mais de 400 páginas de conteúdo esportivo mudando todo dia; atualizar classificação, placar e calendário na mão todos os dias simplesmente não se sustenta.

  • Site inteiro numa VM no GCP; o ciclo "coletar dados → validar → compor → rebuild → deploy" roda sozinho 4 vezes por dia
  • Guarda numérica embutida: pontos, saldo e número de jogos são checados por consistência interna; não bateu, aborta — dado errado nunca sobe
  • Fonte externa caiu? Retry automático com backoff exponencial (15/30/60s); persistiu a falha, mantém a versão anterior e dispara alerta
402 páginas geradas automaticamente 4x por dia atualização automática 0 dados errados publicados (guarda que aborta)

Fonte: registros de execução e de deploy do sistema

AutomationOperação de dados

Backup off-site diário dos dados críticos, com três defesas contra o espelho que replica o estrago

O maior medo do backup não é faltar backup: é a origem corromper e o espelhamento apagar junto os dados bons.

  • Backup incremental diário agendado para storage off-site; reconhece o destino por arquivo-marcador, não por letra de unidade — trocou de porta, continua achando
  • Proteção anti-colapso: queda anômala no número de arquivos da origem rejeita a rodada inteira; deleção vira soft delete com 30 dias de retenção; 30 snapshots preservados
  • Alerta de três estados no Telegram (abortou / falhou / recuperou); em dia normal, nenhum spam
283 arquivos comparados um a um por SHA256, 0 faltando ~1.3s para fechar o backup incremental 8/8 testes negativos das defesas aprovados

Fonte: registros de execução e validação do sistema de backup

AutomationMídia de conteúdo / Dados esportivos

CMS que publica pelo celular: um toque, 10 segundos e está no ar

O time de conteúdo precisava publicar rápido pelo celular, subir com um clique — e sem nunca encostar em código ou comando de deploy.

  • Painel minimalista: login com anti-brute-force, CSRF em todos os formulários, snapshot de versões, imagens convertidas para WebP com EXIF removido
  • VM no GCP + systemd com boot automático e auto-restart em crash; falhou, alerta automático no Telegram
  • Publicação de verdade em um clique: apertou → exporta → rebuild → deploy, ponta a ponta sem intervenção
Publicação ponta a ponta em ~10s Processo morto se recupera em ~6s Testes negativos de segurança 100% aprovados

Fonte: medições reais do sistema e registros dos testes de segurança

AutomationConsumo / Marketing de eventos

Página de inscrição de sorteio à prova de flood, com a lista real reconstruída depois

O terror de toda página de inscrição: bot e a mesma pessoa inflando o número, e depois ninguém consegue dizer quem é gente de verdade.

  • Cinco camadas anti-flood: bloqueio de duplicado, rate limit por IP, chave única, hash de fingerprint e verificação anti-bot
  • Limpeza multidimensional: padrão do número, colisão de nome, distância entre números, cluster por prefixo IPv6 e por fingerprint, tudo cruzado
  • Cruzando cortes de tempo e seeds de teste, o total de inscrições foi reconstruído numa lista confiável
142 inscrições no total ~118 reais depois da auditoria

Fonte: banco do sistema de inscrição e registros da auditoria de limpeza

GROUP B

Mídia paga e tracking

Paid MediaE-commerce / Hortifrúti

A venda fecha fora do site — o CAPI traz o Purchase de volta

O cliente entra pelo anúncio, mas a compra acontece numa página de pedido de terceiros, fora do site: o Pixel não enxerga a conversão e o algoritmo nunca aprende quem é o comprador real.

  • Endpoint próprio de Meta CAPI; Pixel no front e servidor mandam o mesmo event_id em envio duplo, com deduplicação automática
  • Venda de fora do site volta como Purchase; chaves de correspondência 100% normalizadas + hasheadas no servidor, valor ruim é descartado sozinho
  • Evento offline vai sem IP/UA, para sinal falso não derrubar a qualidade de correspondência
Deduplicação por event_id aprovada em teste real EMQ (qualidade de correspondência) ~6–7 7 vendas de fora do site retroalimentadas

Fonte: teste real no Gerenciador de Eventos da Meta e registros de retroalimentação

Paid MediaAquisição de tráfego / nicho ultracompetitivo

Sem engolir o painel da plataforma — contagem própria de tráfego, cada conversão com origem separada

A plataforma de anúncio conta como resultado até conversão que não veio de anúncio, e o cadastro do backoffice não tem campo de origem — impossível separar pago, orgânico e social.

  • Cloudflare Worker registra cada impressão e clique de CTA, sem passar pela plataforma de anúncio e imune a bloqueador
  • Atribuição privacy-first: guarda só hash, nunca IP bruto; cadastro novo é cruzado de volta com o histórico de cliques
  • Relatório diário + boletim a cada 2 horas, empurrados sozinhos no Telegram
Comprovado: 3 cadastros num dia — 2 de anúncio / 1 fora de anúncio Consistência de hash entre sistemas validada Testes unitários 11/11

Fonte: banco de contagem próprio e registros de cruzamento

GROUP C

Sites e SEO

Web / SEOE-commerce / Hortifrúti

Site de marca de produtor local: sem mexer no pagamento, só cobrindo o gap de confiança

O produtor já tinha sistema de pedidos e LINE; faltava um site de marca para ser visto e passar confiança — e sem montar gateway de pagamento próprio.

  • One-page de marca feito à mão no Cloudflare Pages; pedido continua no sistema atual, integração de pagamento economizada
  • Fotos reais 100% em WebP; dados estruturados, sitemap e canonical resolvidos de uma vez
  • Perfil da Empresa no Google apontando para o site, catálogo de produtos no ar, verificação e envio no GSC
Imagens de 38MB → 2.3MB (−94%) CTR de 9% em 28 dias no ar Posição média 10.1

Fonte: Google Search Console (coleta 2026-07) e registros de implementação

Web / SEOAquisição de tráfego / nicho ultracompetitivo

Site novo em mercado ultracompetitivo: orgânico crescendo do zero

Num único mercado de competição altíssima, fazer o tráfego de busca orgânica de um site novo sair do zero.

  • Site estático no Cloudflare Pages, GA4 + GSC ligados de ponta a ponta, conversão reconhecida por evento de clique externo
  • Produção de conteúdo long-tail em escala + balanceamento de links internos, remédio direto para o "Descoberta — não indexada"; template deduplicado para não ser julgado redundante
  • Comparativo semanal de desempenho enviado sozinho no Telegram
Impressões em 28 dias: 724 → 4,730 (~6.5x) Cliques: 68 → 191 (~2.8x) Taxa de indexação ~88% (153/173 páginas)

Fonte: Google Search Console (coleta 2026-07, contra maio do mesmo ano)

Web / SEOAquisição de tráfego / nicho ultracompetitivo

Cirurgia de canibalização de keyword: 35 termos brigando em 6 páginas viram um termo por página

O mesmo conjunto de keywords núcleo espalhado por 6 páginas disputando posição: o termo head rankeava em 23.7 sem nenhuma página dedicada a ele; a página com mais âncoras (33 links internos) tinha só 8 impressões e posição 37 — porque o título nem carregava o termo.

  • Mapa de canibalização desenhado com query×page real das últimas 4 semanas de GSC; papéis redistribuídos: termo head, termos vencedores e termos de simulação, um por página — sem invadir o território da página que dá dinheiro
  • Alavanca de âncora interna encontrada: o texto-âncora dos cards de artigos relacionados = título da página, então mudar 1 título = consertar 26 âncoras de uma vez (0 → 26/26 com o termo-alvo)
  • Estratégia de lastmod honesto: campo updatedAt novo, só página realmente alterada ganha data nova — nada de refrescar o site inteiro para enganar o Google
  • Balanceamento de páginas órfãs: página com posição mas 0 citações foi de 1 → 11 links de entrada; termo de marca com 7 páginas brigando (3,088 impressões por míseros 6 cliques) reorganizado por intenção
Âncoras internas 0 → 26/26 com o termo-alvo Links de entrada da página órfã 1 → 11 Auditoria de 174 páginas: 0 título duplicado / canonical faltando

Fonte: Google Search Console (coleta 2026-08) e medição real do que foi implementado

Web / SEOSite de reviews / nicho ultracompetitivo

SEO técnico num site de reviews de 61 operadores: do crawl desperdiçado ao site inteiro indexável

Conteúdo tinha de sobra, mas a parte técnica vazava por todo lado: URL quebrada respondia 200 + a home inteira (soft 404) queimando crawl budget à toa, o lastmod do sitemap renovava o site todo dia e o Google ignorava, e os links internos estavam monopolizados pelas páginas-template do rodapé.

  • Soft 404 curado na raiz: URL quebrada saiu de "200 + home de 87KB" para 404 correto; crawl budget concentrado nas páginas reais
  • lastmod do sitemap virou máquina de estados por hash de conteúdo: a data só muda quando o conteúdo muda de verdade — o Google volta a confiar no sinal de crawl
  • Redistribuição de links internos: mediana de links de entrada das reviews 5 → 12, mínimo 3 → 7; monopólio de 66 links das páginas-template desfeito
  • 27 títulos estouravam o corte de truncamento da SERP em chinês tradicional (~30 caracteres full-width) → todos comprimidos, 0 página acima; e mais um gate de link morto: antes do deploy, cada link interno é varrido — não resolve, bloqueia (teste negativo provou que bloqueia)
  • Posicionamento GEO / busca por IA: llms.txt gerado automaticamente, rebuild automático a cada atualização de conteúdo
URL quebrada 200 → 404 (crawl budget poupado) Mediana de links internos 5 → 12 Título estourado: 27 → 0 páginas

Fonte: implementação e medições em produção (2026-08)

Web / SEOSnapshots de correção técnica · vários sites

Diário de quick fixes de SEO: cada uma dessas armadilhas a gente já desarmou na prática

Muito site não sofre por conteúdo fraco, e sim por um problema técnico invisível travando tudo. Abaixo é tudo caso real, cada linha com medição de antes e depois.

  • Site novo com zero página indexada → canonical e sitemap brigando no formato da URL (.html vs sem extensão, loop de 308); alinhados os quatro pontos + sitemap reenviado, destravou
  • 404 fantasma no GSC (/cdn-cgi/email-protection) → reescrita da ofuscação de e-mail do Cloudflare; anotação email_off no código-fonte curou na raiz, varredura nas 67 páginas com 0 resíduo
  • Páginas duplicadas se canibalizando → a mesma marca escrita em duas páginas com notas contraditórias; 301 + conteúdo fundido, keywords pararam de brigar entre si
  • Link em área colapsada rebaixado → índice em texto puro do site inteiro adicionado na home, cobrindo todas as 16 "URLs não reconhecidas"
  • Alarme falso de despenque de tráfego → SOP de verificação de queda com 11 exclusões: olhar a semana, não o dia; oscilação normal de CTR não vira diagnóstico errado

Fonte: GSC de cada site e medições antes/depois das correções (2026)

Todos os clientes dos cases foram anonimizados; fica só o segmento e os indicadores técnicos auditáveis.
Quer saber se o seu problema tem solução aqui? Descreva o cenário e a gente responde direto: dá ou não dá.

Your Case Next

O seu cenário provavelmente a gente já resolveu

Descreva onde você travou e a gente responde: como um caso parecido foi resolvido e o que merece atenção no seu.

Falar no Telegram
Avaliação e orçamento sem custo · Quem responde é o próprio engenheiro
Falar no Telegram