Business Manager compartilhada: riscos de time e de cliente

Parceiro com acesso de admin na Business Manager do cliente não é colaboração. É copropriedade acidental. O coordenador chama de confiança. O jurídico, quando aparece, chama de acesso sem dono. A plataforma chama de mais um administrador no grafo.

A BM compartilhada nasce por pressa. Cliente sem BM, agência “empresta” a própria. Dois anunciantes no mesmo nicho, um container pra “não duplicar pixel”. Freelancer vira admin porque o convite de funcionário “era mais rápido”. Sócio da agência usa o Facebook pessoal como raiz. Nenhum desses atalhos é teórico. Todos aparecem na mesa de agência de publicidade no primeiro trimestre de crescimento.

Este texto separa risco de time e risco de cliente. Não reescreve política do Meta. Não ensina a nascer BM gêmea. O job é nomear quem é dono, quem é parceiro, o que o log precisa guardar, e quando uma BM única é o erro estrutural — não o erro de criativo.

O que uma BM realmente compartilha

Business Manager não é pasta. É o container de Pages, ad accounts, pixels, catálogos, pessoas e parceiros. Quem é admin vê o mapa. Quem é admin demais leva o mapa embora.

Compartilhar BM é compartilhar, no mínimo: o grafo de ativos, o histórico de quem entrou, a reputação de pagamento ligada àquele container, o pixel se ele mora ali, a Page se ela mora ali. Isolar o browser da sessão não desfaz o container. São eixos diferentes. Conta pessoal e BM no mesmo computador trata o eixo sessão. Aqui o eixo é titularidade.

Três desenhos tóxicos se repetem.

A BM da agência com ad accounts de vários clientes. Relatório fácil. Risco único. Um anunciante com prática ruim visita o vizinho. Saída vira extração de ativo que “mora” na agência.

A BM do cliente com dez admins da agência, dois freelancers e o estagiário de férias. Ninguém revoga. O histórico de pessoas da BM vira currículo de quem já passou. A plataforma vê rotatividade de dispositivo e de usuário. O cliente vê “o time”.

A BM “do sócio”, Facebook pessoal na raiz, clientes como Pages penduradas. Já foi coberta no texto de conta pessoal. Continua sendo o pior dos três: identidade física, identidade da agência e identidade do anunciante no mesmo login.

O desenho menos ruim: uma BM por anunciante (ou por grupo econômico que o jurídico confirma), cliente como admin, agência como parceiro com papel, pessoas com recorte, log fora da memória do coordenador.

Parceiro versus admin: a diferença que o Slack apaga

No Meta, parceiro é outra BM convidada, com permissões sobre ativos. Funcionário é pessoa adicionada na BM. Admin é quem manda no container. O Slack trata os três como “manda o acesso”.

Agência séria escolhe parceiro com recorte. Opera campanha, vê pixel, não transfere a BM, não troca o admin raiz, não convida gente nova sem o dono. Cliente permanece dono. Fim de contrato é remover o parceiro, não discutir quem ficou com a Page.

Admin da agência na BM do cliente só faz sentido se o contrato disser e se a saída estiver escrita. Mesmo assim, um admin da agência, não oito. O oitavo é o freelancer de criativo que nunca deveria ter visto o gerenciador.

Funcionário da BM do cliente pra gente da agência é o atalho que parece educação. A pessoa ganha e-mail no container. Quando sai da agência, alguém precisa lembrar de tirá-la da BM. Quase ninguém lembra. Convite de parceiro com usuário nominado ainda exige revogação. Exige menos teatro: a BM da agência perde o ativo, a pessoa perde o caminho.

Estagiário não é admin. Não é funcionário da BM do cliente. É operador com papel limitado, se o checklist de permissões por papel existir. Se não existir, o estagiário herda o Facebook de alguém. Isso não é entrada. É incidente com data futura.

Risco de time: senha, 2FA e o admin que viaja

O time quebra a BM de três jeitos, nenhum deles é fingerprint.

Senha do Facebook raiz no grupo. Quem entra no grupo entra na BM. Quem sai continua com o print. Parceiro e papel existem pra isso não ser necessário.

2FA no celular de uma pessoa. Férias, desligamento, telefone quebrado. A BM fica refém. Autenticador no cofre da operação, não SMS no WhatsApp do gestor.

Admin que leva o laptop embora. Sessão viva, cookie exportado “por precaução”, extensão de proxy ainda logada. Saída que só remove o e-mail na BM e esquece o perfil de browser deixa a sessão no mundo.

Há um quarto jeito, mais quieto: todo mundo admin “pra não travar o fim de semana”. Plantão precisa de operador, não de admin. Admin no sábado cria parceiro, troca pixel, aceita convite de BM desconhecida. Segunda-feira ninguém sabe o que mudou.

Histórico de atividades da operação — quem abriu o perfil, quem convidou, quem trocou proxy — não substitui o log do Meta. Complementa. O Meta não registra o Chrome. A agência precisa. Sem isso, a reunião de incidente vira achismo: “foi o João”. João jura que não. O arquivo não existe.

Freelancer de criativo quase nunca precisa da BM. Precisa de preview, de pasta de asset, de um responsável que publica. Acesso de admin “só pra subir o anúncio” é o custo escondido do job de três semanas.

Risco de cliente: pixel, Page e concorrência no mesmo container

Dois clientes na mesma BM é o erro que o comercial minimiza e o jurídico, se vir, não assina.

Pixel compartilhado mistura evento. Audiência de um vaza no aprendizado do outro, mesmo sem má fé. Relatório de conversão vira discussão de contrato. CAPI no mesmo dataset piora. Higiene de pixel é outro texto; aqui basta: BM compartilhada empurra o pixel pro mesmo destino.

Page no container errado. A Page do cliente A “temporariamente” na BM da agência. Seis meses depois, ninguém transfere. A agência vira dona de ativo de mídia que não é dela. Na troca de agência, a briga é a Page, não o ROAS.

Concorrentes no mesmo container. Mesmo nicho, duas lojas, um coordenador “eficiente”. Além do grafo, há quebra de confidencialidade: lance, criativo, público. Isolamento de browser não tapa olho de admin.

Cliente que pede “usa a BM de vocês que a nossa está suja”. A BM da agência não é lavação. Se a do cliente está restrita, a fila é política, pagamento ou ambiente — não empréstimo de container. Emprestar cola o problema no grafo da agência.

Como desenhar o compartilhamento sem fingir que não existe

Compartilhar pessoas, não o container.

Uma BM por anunciante. Cliente admin. Agência parceiro. Lista nominada de quem opera, com papel. Revisão mensal de pessoas: quem saiu, quem ainda aparece. Perfil de browser por identidade, não um Chrome da agência com doze BMs.

Quando o cliente não tem BM e a agência cria: o cliente vira admin no mesmo dia do go-live, não “depois da campanha estabilizar”. Estabilizar dura eternidade. A BM criada pela agência e esquecida no admin da agência é ativo órfão.

Quando há holding e várias marcas: o critério é o mesmo da MCC. Mesmo anunciante, um container pode bastar. Empresas distintas, containers distintos. O slide de “casas” não decide. CNPJ, cartão e contrato decidem.

Quando a agência usa BM própria pra Page da agência e pra leads próprios: essa BM não recebe cliente. Produção da casa e produção de terceiro não se visitam. O comercial quer um login. O grafo não quer.

O rito de convite e o rito de revogação

Convite não é recado. Tem dono, papel, data, registro.

Quem autoriza o convite: o admin do cliente ou o papel administrar da agência, conforme o contrato. Quem executa: uma pessoa, não o grupo. O que entra no log da operação: ativo, pessoa, papel, data. O que não entra: senha.

Revogação no anúncio da saída, não no último café. Remova parceiro, funcionário, dispositivo. Invalide sessão no perfil isolado. Troque 2FA se a pessoa era o fator. Tire do grupo do WhatsApp depois, não antes — senão ela ainda opera enquanto discute a festa.

Fim de contrato com o cliente replica o rito. Extraia o que é do cliente (Page, pixel, ad account) antes de remover o parceiro, se a agência ainda for o caminho. Checklist de entrega existe pra isso. Não improvise na call de encerramento.

Auditoria trimestral: exportar a lista de pessoas da BM, cruzar com o inventário de time. Nome que não existe mais na folha e existe na BM é incidente atrasado. Nome de agência concorrente ainda como parceiro é o clássico da troca mal feita.

O que o log precisa guardar (e o que não)

Guarde o que reconstitui uma semana: abertura de perfil, convite, revogação, troca de proxy, export de cookie, criação de perfil, incidente de restrição. Histórico de atividades no recorte de operação serve a isso. Não publique token, senha, cookie cru.

Não espere o log do Meta pra saber quem mexeu no Chrome. Não espere o ROAS pra descobrir que o freelancer ainda é admin.

Quando o cliente pergunta “quem pausou ontem”, a resposta é horário e pessoa. Palpite no grupo queima confiança mais rápido que um lance ruim.

Pixel, catálogo e o container emprestado

O comercial promete “a gente sobe o catálogo na BM da agência pra ir mais rápido”. O catálogo fica. O pixel fica. Seis meses depois, o cliente pede a BM dele. Extrair catálogo e pixel de um container que nunca foi dele é trabalho de migração, não de clique.

Se o cliente ainda não tem BM no kickoff, crie a dele no mesmo dia. Convide a agência como parceiro. Suba o catálogo lá. Pixel lá. A pressa de usar o container da casa é a mesma pressa da MCC da agência pra todo mundo: eficiência de setup, copropriedade na saída.

Catálogo compartilhado entre dois anunciantes é o erro que parece técnico e é contratual. Feed de produto, preço, estoque. Admin da BM A vê o SKU da BM B. Isolamento de browser não tapa isso. Container separado tapa.

Pixel no container da agência “temporário” gera evento com dono errado. CAPI no token da agência piora. Quando a conta cai, o recurso fala em ativo que não está no nome do anunciante. A fila já era difícil. O dono errado torna pior.

Dois times parceiros na mesma BM

Não é só agência e cliente. É agência de mídia e agência de performance. É in-house e casa externa. É o freelancer de criativo com admin “porque o Meta não deixava publicar”.

Desenhe o mapa de parceiros. Um parceiro, um recorte, uma data de revisão. Dois parceiros com admin pleno é duas empresas donas. Na briga de atribuição, os dois pausam. Na restrição, os dois aparecem no grafo.

In-house que chama agência pra “um canal” deve convidar canal, não o container. Se a agência precisa de Meta e o in-house fica com Google, isso ainda são dois parceiros em ativos distintos — não uma BM com todo mundo admin.

O histórico de atividades da operação registra o convite do parceiro. O Meta registra o parceiro. Os dois juntos reconstituem a semana. Um só, não.

Checklist mensal de pessoas

Primeira segunda-feira do mês: exportar pessoas da BM. Cruzar com folha e com lista de freelancers ativos. Nome que não bate, revoga. Papel que é admin e deveria ser operador, reduz. Parceiro com data de contrato vencida, remove.

Não é polícia. É higiene. BM com trinta pessoas e oito admins é o retrato que a plataforma lê como rotatividade. Rotatividade de admin não é fingerprint. É sinal. O time pode explicar. Melhor não precisar.

O mesmo rito vale pra Pages e pra ad accounts dentro da BM. Ativo órfão, pessoa órfã. Arquive o que não gasta. Não deixe campanha zumbi com admin zumbi.

Fechar o container

BM compartilhada demais une time e cliente no mesmo grafo. Parceiro com recorte, admin raiz no anunciante, log de convite, revogação no dia. A ferramenta de perfil isola sessão. Não escolhe o dono da BM. Essa escolha é contrato. Sem contrato, o Slack escolhe — e escolhe admin pra todo mundo.