- Quatro padrões que a notificação esconde
- Política: o criativo e a landing, não o user-agent
- Pagamento e identidade: o grafo que o Chrome não apaga
- Velocidade: o ritmo que parece fazenda
- O que “mesmo dispositivo” significa na prática
- BM, perfil pessoal e conta de anúncio não são a mesma coisa
- Como receber a BM do cliente sem o Chrome da agência
- O que registrar depois de uma desativação
- Isolamento é higiene, não atalho para política
- As próximas 24 horas — e o trabalho de tráfego
A notificação de conta desativada chega como se fosse um único evento. Na agência, quase nunca é. Ads Manager, Business Manager e perfil pessoal podem cair por razões diferentes no mesmo dia, e o time trata tudo como “o Facebook pegou o dispositivo”. Aí nasce o reflexo mais caro: abrir outra identidade no mesmo Chrome, no mesmo IP, com o mesmo cartão, no mesmo ritmo — e chamar isso de recuperação.
Um navegador isolado não sobrescreve política do Meta. Não limpa Business Manager comprada, emprestada ou de origem duvidosa. Não conserta criativo recusado, landing furada nem claim. O que o ambiente separado faz é reduzir a chance de a próxima conta nascer já abraçada na anterior. Isso é higiene. Não é atalho para os termos de uso.
O resto do texto nomeia as quatro filas, separa BM de perfil e de ad account, descreve a entrada sem o Chrome da casa e o que registrar depois — para aprender, não para contornar regra.
Quatro padrões que a notificação esconde
Quando o time diz “desativaram a conta”, costuma estar falando de um destes quatro padrões. Eles podem coexistir. O erro é tratar os quatro com a mesma ferramenta.
O primeiro é política de anúncio e de conteúdo. Landing que promete o que o criativo não entrega, nicho restrito sem documentação, atalho agressivo para WhatsApp, claim médico, imitação de interface de banco. O recurso existe. A fila é de revisão. Trocar o navegador não muda o PDF que o revisor vai ler.
O segundo é pagamento e identidade. Cartão recusado em loop, CNPJ que já apareceu em BM queimada, mesmo administrador em dezenas de contas, mesmo pixel disparando de “empresas” que no papel não se conhecem. O Meta liga pessoa, documento, forma de pagamento e grafo de parceiros melhor do que a maior parte dos times admite. Isolar cookie não apaga o admin.
O terceiro é velocidade. Conta nova, pixel no ar, cinco campanhas, vinte conjuntos, cem criativos, gasto subindo em curva de fazenda. Contas maduras também queimam por rajada: clone de campanha em massa, troca de BM no mesmo dia, login de cinco pessoas no mesmo horário. Ritmo de software, reputação de software.
O quarto é ambiente. Chrome da agência com doze BMs, WebRTC vazando o escritório, fingerprint idêntico, cookie viajando entre clientes. Isolamento de sessão importa como higiene: evita o atalho óbvio de correlação. Não autoriza política ruim.
Política: o criativo e a landing, não o user-agent
A maior parte das desativações que a agência chama de “ban de dispositivo” começa em anúncio. O revisor não pergunta se o Canvas é estável. Pergunta se a oferta é o que parece.
Antes de abrir outra conta, abra o histórico de rejeições. Quantos anúncios cairam na mesma semana? Qual o motivo textual? A landing muda de URL a cada rejeição, ou é a mesma página com outro UTM? Há claim de resultado garantido, antes-e-depois de corpo, linguagem de jogo em produto que não é jogo?
Nicho sensível existe. Operar nele sem documentação é escolha, não azar. O navegador não muda essa escolha.
O recurso oficial é o caminho. Não é rápido. É o único que conversa com a política. Criar outra BM “enquanto o recurso anda” mistura as filas: a conta nova herda o mesmo criativo, a mesma landing e, muitas vezes, o mesmo ambiente. Se a fila era política, você só duplicou o problema.
Há um teste simples. Se o mesmo anúncio, na mesma landing, rodaria mal em uma conta velha e saudável do mesmo cliente, o problema não é fingerprint. É oferta. Mande isso para o time de mídia, não para o time de setup de perfil.
Pagamento e identidade: o grafo que o Chrome não apaga
O Meta não precisa do seu Canvas para saber que duas empresas compartilham cartão, PIX, administrador ou e-mail de recuperação. Esses sinais estão no grafo da conta, não no navegador.
Na agência brasileira o padrão clássico é: um cartão da casa “só para não atrasar o cliente”, um e-mail genérico, um sócio que é admin de tudo, um pixel da agência colado em cinco anunciantes. Quando uma BM cai, as outras já estavam no mesmo retrato.
Mesmo cartão em conta nova é o atalho mais curto para o grafo. Não faça. Mesmo documento, outra BM, também. Perfil pessoal do gestor logado como admin em BM de cliente, no mesmo Chrome da conta que anunciava produto próprio, é outro clássico.
Isolar sessão ajuda a não misturar cookies. Não desfaz o admin. Tire pessoas da BM. Separe pagamento. Quem vende “desbanir com browser novo” está vendendo outra coisa.
Se a BM tem origem duvidosa — comprada, alugada, “emprestada por um parceiro” — o navegador não lava isso. Conta de terceiros e revenda de acesso violam termos. Este artigo não ensina a operar isso. Ensina a não fingir que o problema era o Chrome.
Velocidade: o ritmo que parece fazenda
Conta recém-criada que gasta como conta de três anos chama atenção. Conta que cria dezenas de anúncios em uma tarde, todos com o mesmo template, também. Conta que troca de BM, de pixel e de URL no mesmo dia, também.
Velocidade não é só gasto alto. É densidade de ação em pouco tempo, com pouca história. O Ads Manager registra isso. O time sente como urgência do cliente. A plataforma sente como padrão de abuso.
Depois de uma desativação, o reflexo de “voltar a gastar hoje” é exatamente o padrão que a fila de risco espera. Se a conta boa ainda existe, proteja o ritmo dela. Não clone o setup da conta morta para a viva no mesmo dia.
Há um meio-termo: campanha de teste, orçamento pequeno, horário comercial do fuso da conta. Não é mágica. É deixar de parecer script.
O navegador não regula velocity. O roteiro regula. Se o time não tem roteiro, o perfil isolado vira palco para a mesma rajada, só que com fingerprint diferente. A plataforma ainda vê a rajada.
O que “mesmo dispositivo” significa na prática
“Mesmo dispositivo” no discurso de fórum é um ID místico. Na prática, é um cesto de sinais fracos que, juntos, dizem: isso parece a mesma sessão de trabalho.
No computador, o cesto inclui cookies e storage da sessão; fingerprint do navegador (tela, fuso, GPU, fontes, Canvas, áudio); IP e ASN; vazamento de WebRTC; extensões; horário de login; a sequência de contas abertas no mesmo perfil de Chrome. Nenhum desses sinais prova fraude sozinho. O Chrome da agência com doze BMs empilha todos ao mesmo tempo.
Limpar o cookie resolve a camada de sessão. Não resolve fingerprint, IP, horário nem o admin. Trocar o IP resolve a vizinhança de rede se o novo endereço for coerente e estável — e piora se o WebRTC continuar vazando o escritório, ou se o IP for datacenter barulhento. Há um texto à parte sobre qualidade de IP na prática: score de vendor não é reputação no Meta.
No celular, “mesmo dispositivo” pesa de outro jeito: identificador de aparelho, apps instalados, conta da loja, backup, chip. Isolar o Chrome no computador não desfaz o iPhone da agência onde o gestor entra em cinco Instagram e três Facebook no mesmo Safari. São canais diferentes. Trate como canais diferentes.
Clonar um perfil de navegador e só mudar o nome é, para a plataforma, quase o mesmo dispositivo. O retrato continua. O que muda o retrato é um perfil nascido limpo, coerente com o proxy (país, idioma, fuso), estável ao longo dos dias — não um gerador que randomiza GPU a cada refresh.
BM, perfil pessoal e conta de anúncio não são a mesma coisa
Misturar os três nomes na planilha é como misturar as filas de desativação.
O perfil pessoal é uma pessoa. Tem amigos, fotos, histórico, confirmação de identidade. Usá-lo como motor de várias BMs de cliente é conveniente e correlaciona tudo. Quando o perfil cai, cai o acesso.
O Business Manager é a empresa no Meta. Tem admins, linhas de crédito, pixels, catálogos, parcerias. Uma BM desativada não nasce de novo com outro e-mail no mesmo grafo. Recurso, documentação, origem limpa. Perfil de navegador novo recupera isolamento, não a BM.
A conta de anúncio é o veículo de gasto. Pode estar saudável dentro de uma BM doente, ou doente dentro de uma BM saudável. Restrição de pagamento não é restrição de criativo. Conta desativada por política de anúncio não se resolve trocando o cartão — e vice-versa.
Na operação, escreva os três na mesma linha do inventário: cliente, identidade (CNPJ ou pessoa), BM, ad account, perfil de browser, proxy, dono. Sem isso, o time “abre outra conta” sem saber o que abriu. O texto sobre organizar dezenas de contas na agência detalha o inventário; aqui o ponto é só este: não trate BM, perfil e ad account como sinônimos no pós-ban.
O modelo de um perfil por identidade no Facebook está no hub de múltiplas contas no Facebook. Este artigo não reescreve esse hub. Usa a distinção para o dia em que a notificação chega.
Como receber a BM do cliente sem o Chrome da agência
O fluxo clássico é um convite por e-mail e um “entra aqui no nosso Chrome que é mais rápido”. O Chrome da agência já tem as outras BMs, o pixel da casa, a extensão de captura, o login do gestor, às vezes a conta pessoal de alguém. A BM nova nasce dentro desse cesto.
O fluxo menos pior é o inverso. Perfil de browser vazio, pensado para aquela identidade. Proxy estável e coerente com o país da conta — não um residencial que muda de estado a cada request. Teste de vazamento (WebRTC, DNS) antes do primeiro login. Só então o convite. O cliente não precisa passar a senha no WhatsApp. Precisa adicionar o admin certo, na BM certa, no perfil certo.
Se o cliente já opera no próprio computador, não importe o cookie da máquina dele para o Chrome da agência “para ganhar tempo”. Cookie é sessão emprestada. Se o ambiente não parece com o da sessão original, a plataforma trata como sequestro. Aqueça o perfil, alinhe fuso, não troque o IP a cada clique.
Estagiário no perfil do cliente só com permissão e log. Na saída: revogar admin, não “a gente desloga depois”.
Nada disso desfaz uma BM que já chegou queimada. Se o cliente entrega uma BM com histórico de restrição, o trabalho é recurso e transparência, não maquiagem de fingerprint.
O que registrar depois de uma desativação
Registrar não é montar um kit para contornar os termos. É aprender qual fila queimou, para não repetir o mesmo rito na conta que ainda está de pé.
Anote, com data: qual ativo caiu (perfil, BM, ad account); o texto da notificação; rejeições de anúncio nas 72 horas anteriores; landing e criativo em veiculação; forma de pagamento; admins; pixel; perfil de browser; proxy e ASN; se o WebRTC batia com o IP que você achava usar; quem logou, de onde, em qual horário; se houve rajada de criação de campanha; se o mesmo cartão ou admin existe em outra identidade da casa.
Não anote isso para clonar o setup e jogar na conta nova amanhã. Anote para responder: era política, pagamento, velocidade ou ambiente? Se era política, o log serve para o time de mídia. Se era pagamento, serve para financeiro e para o cliente. Se era velocidade, serve para o tráfego. Se era ambiente, serve para o roteiro de perfil — e só então faz sentido falar de isolamento.
Compartilhar esse log internamente é higiene. Transformá-lo em tutorial de “como voltar no ar sem recurso” não é o trabalho deste texto nem da agência que quer durar.
Isolamento é higiene, não atalho para política
Um perfil por identidade reduz o atalho óbvio: doze BMs no mesmo Chrome, cookie cruzado, fingerprint idêntico, IP de escritório vazando. Isso diminui a chance de a conta nova nascer colada na velha. Não diminui a chance de o mesmo criativo recusado ser recusado de novo.
Se o time precisa desse isolamento sem compartilhar o Chrome da máquina, o Lauth entra nessa camada operacional — perfil por identidade, proxy documentado, acesso do time com permissão em vez de senha no grupo. Não entra como desbanimento. Quem precisa de nuvem de celular ou de um painel com dezenas de flags de fingerprint está em outro corredor de ferramenta; force encaixe e o roteiro quebra do mesmo jeito.
Higiene, na prática: não clonar perfil queimado; não randomizar GPU a cada sessão; não misturar BM de cliente no login pessoal; não usar a conta boa para testar o proxy novo. A que fatura entra depois do teste de leak, com dono claro.
Isolamento também não autoriza identidade falsa, BM de origem ilícita nem volume de spam. Os termos de uso continuam no ar. O browser não os revoga.
As próximas 24 horas — e o trabalho de tráfego
Nas primeiras 24 horas, a ordem é chata e é a que preserva o que ainda está vivo.
Recurso na conta que caiu, com o texto real da notificação, sem inventar “foi o dispositivo” se a rejeição era de criativo. Não criar BM, ad account nem perfil de emergência no mesmo Chrome. Separar pagamento e admins que não deveriam estar juntos. Se for testar ambiente, teste em conta que pode morrer. A conta boa só recebe campanha depois que a fila estiver nomeada.
Se o job do time é anúncio no Brasil, a landing de tráfego pago continua sendo o encaixe de persona — gestor, agência, rotina de veiculação. Este artigo não a reescreve. Só lembra que desativação não é um problema só de browser: é política, dinheiro, ritmo e, por último, ambiente. Tratar as quatro filas como uma só é trocar o pneu quando o problema é o motor.
FAQ
Perguntas frequentes
Não. Recupera isolamento de sessão. BM segue recurso, origem e política.
Cesto de sinais: cookie, fingerprint, IP, WebRTC, horário e sequência de logins — não um ID místico.
É o atalho mais curto no grafo de pagamento. Não faça.
Não. Pessoa, empresa e veículo de gasto caem por filas diferentes.
Ativo, texto da notificação, criativo, pagamento, admins, perfil, proxy e ritmo — para nomear a fila, não para contornar termos.
Não. Evita correlação óbvia de Chrome compartilhado. Criativo e landing continuam no revisor.
Continue lendo
