Múltiplas contas no Google Ads com navegador isolado

O Google é agressivo com ambiente suspeito, mas o erro mais comum da agência ainda é mundano: todo mundo logado no mesmo browser. Isolar perfis é o mínimo. Política de anúncio, conversão e forma de pagamento são o máximo. Um perfil por identidade de risco — não por capricho de aba.

Como a plataforma correlaciona contas

• Mesmo Chrome para contas Ads “não relacionadas” e para o Gmail pessoal do gestor
• Automação visível, extensão de RPA ou script no mesmo perfil de produção
• Pagamento compartilhado de forma tosca entre contas que o contrato diz distintas
• Conta nova nascida no mesmo IP de escritório minutos após uma suspensão
• WebRTC ou DNS vazando o IP real no login do ads.google.com
• Cookie de MCC colado em ambiente com UA e tela diferentes
• Teste de criativo duvidoso no mesmo jar da conta que ainda gasta bem

Faça

• Regra escrita: perfil por cliente ou por MCC, conforme a identidade de risco
• Proxy coerente e sticky; teste de vazamento antes do login
• Separar conta sandbox da conta que paga mídia
• Manter fingerprint estável; não sortear ambiente a cada abertura da MCC
• Permissões de time no perfil, com log e 2FA no painel
• Tratar conversão, pixel/GA4 e pagamento como eixos à parte do browser

Não faça

• Usar o perfil do dono da agência para testar conta nova de cliente
• Misturar MCC da agência com CNPJ próprio do cliente no mesmo jar
• Nascer conta Ads no mesmo cartão e no mesmo Chrome da conta suspensa
• Rodar RPA pesado no perfil humano de produção
• Achar que AdSafe lava política de anúncio ou destino enganoso
• Mandar cookie da MCC no Slack como arquivo de migração casual

Onde o Lauth encaixa

Lauth e AdSafe existem para esse fluxo: um perfil por identidade de anúncio, proxy residencial incluso ou HTTPS/SOCKS5 de terceiro, pastas de cliente, permissão, log e 2FA. Time sincroniza a MCC sem o Chrome da casa. Plus traz ações em massa. Starter ~10, Premium 50, Plus 300, Max 1.000. Trial de 7 dias sem cartão numa conta sandbox; depois as que pagam mídia. Isolamento de sessão — não waiver de política do Google.

Como o Google Ads correlaciona contas

O Google Ads lê a Conta Google, o cookie do ads.google.com, o fingerprint do processo, o IP, o histórico de pagamento, o domínio de conversão e o comportamento da conta. MCC, conta de cliente e login pessoal no mesmo Chrome é o cluster mais comum da agência brasileira — mundano, barato de detectar, raro de admitir.

A plataforma não precisa de uma confissão. Contas “não relacionadas” que nascem no mesmo ASN, no mesmo horário, com o mesmo cartão e o mesmo user-agent formam um grafo. Suspensão recente seguida de conta nova no mesmo jar é o capítulo que o time chama de “recomeço” e o Google chama de evasão. O artigo de Facebook Ads desativado é Meta, mas a lição de eixos (política, pagamento, ambiente) vale no Google: trocar só o browser trata um eixo.

Há a MCC. A MCC da agência é uma identidade de trabalho. As contas dentro dela, se são do mesmo time e da mesma empresa, não pedem dez browsers. O CNPJ próprio do cliente, a conta que o contrato trata como anunciante separado, pede perfil próprio. Organizar dezenas de contas é exatamente essa regra escrita: identidade de risco, não aba.

Automação visível — extensão de RPA, script de pause/enable em loop, user-agent de headless — é sinal próprio. Isolar fingerprint e continuar com ritmo de máquina só muda o palco. Impressão digital e cookie versus fingerprint separam sessão de dispositivo. WebRTC separa o IP que você anunciou do IP que o browser entregou.

Há ainda o eixo de conversão. Tag, GA4, Enhanced Conversions e domínio verificado ligam propriedades que o time uniu de propósito. Isolar o login da MCC não desfaz um GA4 compartilhado. Isolar evita o vazamento acidental: o gestor testando landing duvidosa no mesmo jar da conta que ainda converte. Agência de tráfego pago que mistura sandbox e produção no mesmo Chrome está pagando para aprender isso tarde.

O que um perfil dedicado muda na MCC

Muda o molho de chaves. O gestor para de abrir a conta pessoal, a MCC da agência e o teste do cliente no mesmo processo. Cookie e desafio de login passam a ser da identidade. Fingerprint consistente + proxy sticky reduz o recaptcha de “fazenda”. Como ler testes de fingerprint e qualidade de IP entram no entrada, não no pânico.

Muda o time. Permissão no perfil, log de quem pausou campanha, desligamento com revogação. Senha da MCC no grupo é incidente. Pasta por cliente é UX; isolamento é outro processo de browser.

Não muda política de anúncio. Não muda qualidade da landing. Não muda o cartão. Não muda o fato de conversões e GA4 poderem ligar propriedades que você uniu de propósito. Isolamento evita o Chrome único. Não é um certificado de conformidade. Muda o plantão: quem cobre o sábado entra no perfil da identidade, com permissão já concedida, em vez de nascer conta nova no Chrome da casa porque “a MCC caiu”. Pasta de favoritos não entrega isso. Outro processo de browser entrega. Fingerprint sorteado a cada abertura da MCC, no mesmo cartão, parece evasão. Consistência vence teatro.

O que o Lauth faz no Google Ads

Cada identidade de anúncio vira um perfil Lauth. AdSafe no ambiente. Proxy residencial incluso, ou o HTTPS/SOCKS5 que a operação já comprou. Pastas, permissões, log de atividade, 2FA. Time sincroniza sem clonar o disco da agência. No Plus, ações em massa na operação. Planos Starter ~10, Premium 50, Plus 300, Max 1.000 perfis. Trial de 7 dias sem cartão para a sandbox.

O produto nasceu perto de tráfego pago: menos fingerprint frágil, mais perfil que o gestor usa de verdade. Se você ainda está escolhendo ferramenta, como escolher navegador antidetect e comparativos. Se já sabe o tamanho da operação, planos. 2FA no painel reduz o roubo da MCC inteira quando um laptop some. Log responde quem pausou o gasto. Permissão revogável substitui a senha no grupo do WhatsApp. Nada disso é waiver de política. Tudo isso substitui o Chrome compartilhado da agência de publicidade.

O que a ferramenta não resolve

Não resolve suspensão por política, destino enganoso, trademark ou pagamento. Não substitui o telefone. Não lava conta nascida no mesmo cartão. Cookie de MCC importado em outro UA/tela/IP queima o login. Não autoriza cloaker, farm de contas Ads nem evasão de restrição.

Quem opera no limite da política deve ser honesto: isolamento reduz correlação de sessão da agência. Não é waiver. O hub múltiplas contas e a landing de agência descrevem o trabalho. ToS do Google descreve o resto. Cookie de MCC no Slack, com outro UA e outro IP no destino, queima a sessão e aciona desafio. Trate cookie como sessão viva. Importar não é nascer. RPA no perfil humano de produção continua sendo o que o Google caça, isolado ou não.

Como rodar um piloto no Google Ads

Uma identidade sandbox — conta de teste, não a que fatura. Perfil novo. Proxy sticky coerente com a geo da conta. Teste de IP, DNS, WebRTC. Login em ads.google.com. Navegue campanhas como o time já navega. Não mude tracking, cartão e criativo no mesmo dia da troca de ambiente: você não saberá o que quebrou. Convide um segundo gestor no perfil, com papel de operar, não com a senha mestra. Uma semana com log ligado. Se o time não consegue trabalhar sem o Chrome da máquina, o piloto falhou de processo. Só então a conta de produção. MCC da agência pode permanecer um perfil; CNPJ do cliente, outro. Escreva a regra. Se só está na cabeça do coordenador, o estagiário loga a conta nova no Chrome da casa. Infoproduto que também roda Ads mistura este roteiro com o da plataforma de pagamento — separe mídia de checkout, como em produtos digitais.