Como separar o tracking de vários clientes sem misturar dados (nem contas)

Toda agência começa com uma conta só e uma planilha. O problema aparece no quarto ou quinto cliente, quando a convenção que funcionava — prefixo no nome da campanha, uma aba por conta, um filtro salvo no relatório — passa a depender de ninguém errar nunca. E alguém erra.

O custo do erro não é proporcional ao tamanho dele. Mandar para um cliente um relatório que contém três linhas de campanha de outro cliente é um incidente de confidencialidade, não um typo. Este artigo trata de como montar a separação para que o erro não seja possível, e não apenas improvável.

Por que convenção de nome não é isolamento

Separar por nomenclatura significa que todo dado dos seus clientes vive no mesmo conjunto e é distinguido por uma string. Isso falha em pelo menos cinco situações previsíveis:

• Export sem filtro. Alguém abre o relatório, exporta e manda. O filtro salvo não vai junto do arquivo.
• Relatório agregado. Qualquer visão "total da conta" soma tudo. O número fica errado e ninguém percebe porque parece plausível.
• Postback apontado errado. Um merchant configurado com o token da conta inteira entrega conversão sem saber a que cliente pertence.
• Entrada de pessoa nova. O membro novo do time não conhece a convenção e cria a campanha sem prefixo. A partir daí, o filtro por prefixo exclui silenciosamente o dado dele.
• Renomeação. Alguém padroniza nomes num sábado e quebra todos os filtros salvos.

Nenhuma dessas é hipótese exótica. São as quatro ou cinco coisas que acontecem em qualquer agência num semestre.

A arquitetura que funciona: workspace por cliente

O modelo correto é um workspace isolado por contrato. Cada workspace tem seus próprios links, cliques, conversões, relatórios e token de postback. Dado de um não aparece no outro — não por filtro, por escopo.

O que isso resolve concretamente:

A recomendação prática é criar o workspace antes de criar qualquer link. Migrar dado depois é possível, mas o histórico de cliques já registrado fica no lugar antigo, e histórico partido atrapalha comparação mês a mês. A visão geral de escopos e permissões está em como a plataforma organiza contas e workspaces.

Um workspace por contrato, não por anunciante

A unidade de separação é o contrato, não a marca. Dois motivos:

1. Se você atende o mesmo anunciante por dois contratos diferentes (por exemplo, uma agência parceira que sub-contrata você), cada contrato tem seu próprio faturamento, sua própria régua e seu próprio relatório.
2. Se o cliente troca de marca ou adiciona uma segunda, faz mais sentido um workspace por relação comercial do que uma explosão de workspaces por produto.

Dentro do workspace, a separação por marca ou produto é feita com campanha e sub-parâmetro — que é exatamente o nível em que convenção de nome funciona bem, porque o dano de um erro fica contido.

Token de postback: o ponto de falha mais comum

O token é o que identifica onde a conversão deve cair. Em estrutura multi-cliente, ele é o mecanismo de isolamento do lado de entrada.

Cada workspace tem seu próprio token. Quando você configura o postback na plataforma do anunciante, aquele token amarra o evento àquele escopo. Se o token estiver errado, o evento não entra silenciosamente no lugar errado: ele aparece no log como inválido — o que é infinitamente melhor do que cair no relatório de outro cliente.

Três regras operacionais:

• Nunca reutilize token entre workspaces. Parece conveniente na configuração e é o começo de um problema difícil de diagnosticar.
• Guarde qual token foi entregue a qual merchant. Quando um merchant para de enviar, você precisa saber o que foi configurado lá sem depender da memória de quem fez.
• Valide com evento de teste antes de subir verba. Um postback de teste que aparece como casado no log vale mais que qualquer confirmação por e-mail. O funcionamento do envio e do mapeamento está descrito em postback server-side.

O mapeamento por merchant também é por workspace: evento, valor e id da transação são configurados no escopo do cliente. Isso importa porque o mesmo merchant pode mandar payloads diferentes para contratos diferentes, e forçar um mapeamento global quebraria um dos dois.

Deduplicação e isolamento andam juntos

A deduplicação por transação funciona dentro do workspace. Isso é o comportamento desejado: se dois clientes distintos promovem o mesmo merchant e ambos geram uma venda com ids de transação vindos do mesmo sistema, as transações são diferentes e cada uma pertence a um clique diferente. Cruzar deduplicação entre workspaces descartaria conversão legítima.

Domínio de tracking por cliente

O isolamento de dados resolve o relatório. O isolamento de URL resolve a percepção.

Com domínio de tracking personalizado — CNAME apontado e certificado Let's Encrypt emitido automaticamente —, o link de redirect roda sob um domínio ligado à operação, e é possível manter o tracking no domínio do próprio cliente quando ele disponibiliza um subdomínio.

Por que isso importa numa agência:

• Coerência de marca. O usuário que clica num anúncio do cliente e passa por um domínio genérico percebe a transição. Sob subdomínio da marca, não.
• Separação de reputação. Um domínio compartilhado entre muitos anunciantes concentra risco: qualquer problema com um afeta a entrega de todos.
• Continuidade contratual. Se o cliente tem o domínio, o ativo é dele — o que é um argumento comercial honesto em negociação de longo prazo, e reduz o atrito da conversa sobre propriedade de dados.

A contrapartida: um registro DNS por cliente e um item a mais no onboarding. Na prática são cinco minutos por conta e o certificado é resolvido automaticamente.

A camada que continua sendo sua: convenção dentro do workspace

Isolamento estrutural resolve o vazamento entre clientes. Dentro de cada workspace, você ainda precisa de disciplina para que o relatório seja legível.

Um padrão que aguenta escala:

• Campanha — canal + objetivo + mês. Exemplo: meta-aquisicao-2026-09.
• Fonte — plataforma de origem, preenchida sempre no mesmo campo.
• sub1 — criativo ou anúncio
• sub2 — público / segmentação
• sub3 — landing page ou variação
• sub4 — squad ou responsável interno
• sub5 — campo livre do teste do mês

O ganho aparece no fechamento: a abertura por sub-parâmetro em relatórios mostra quais criativos sustentam o resultado sem exigir que alguém cruze planilha. Os parâmetros capturados no clique — utm, identificadores de plataforma, país, dispositivo — estão detalhados em como gclid, fbclid e ttclid funcionam.

Uma regra que economiza retrabalho: defina os cinco campos no primeiro dia do cliente e escreva num documento. Mudar o significado de sub2 no mês três torna a comparação com os meses um e dois impossível.

Custo por cliente, sem planilha paralela

Cada workspace mantém seu próprio custo. Duas formas, conforme o tipo de compra:

• Modelo na campanha — CPC, CPM ou CPA fixo, com o custo calculado sobre o volume rastreado. Encaixa bem em compra de mídia com preço acertado e em tráfego adquirido de parceiros.
• Custo manual por dia — lançamento do gasto real por campanha, dia a dia.

Não há importação automática de gasto das plataformas de anúncio. Para agência com muitas contas, a rotina que funciona é um bloco fixo de manhã lançando o gasto do dia anterior de todas as contas — dez a quinze minutos para uma carteira média — o que mantém CPA e ROI corretos em todos os workspaces sem planilha externa. Os detalhes por plataforma estão em Meta Ads e Google Ads.

Onboarding de cliente novo: a sequência que não deixa buraco

1. Criar o workspace do contrato, antes de qualquer link.
2. Configurar o domínio de tracking (CNAME + certificado automático).
3. Definir a convenção de campanha, fonte e sub1..sub5, por escrito.
4. Cadastrar os merchants com o mapeamento de evento, valor e id de transação.
5. Entregar o token de postback e registrar em qual merchant ele foi configurado.
6. Rodar um evento de teste e confirmar no log que ele aparece como casado.
7. Criar os links /r/{slug} com os parâmetros da convenção.
8. Definir o modelo de custo ou agendar a rotina de lançamento manual.
9. Fixar a régua do relatório — modelo de atribuição, janela e fuso — e escrever no rodapé do modelo de documento.

O passo 6 é o que mais se pula e o que mais custa. Descobrir no dia 20 que o postback nunca chegou significa um mês de tráfego sem conversão rastreada e uma conversa desagradável. O que fazer quando o rastro se perde no meio do caminho está em atribuição quebrada.

O que não dá para fazer hoje — e como contornar

Ser honesto sobre limites evita promessa que vira atrito no mês dois.

Não existe hoje:

• Painel white-label completo. Você não coloca o painel sob sua marca com a identidade da agência.
• Login de cliente com permissão granular por usuário. Não há um usuário "cliente" que enxerga apenas o workspace dele com permissões finas.
• Dashboard embutido em iframe no site da agência.
• Importação automática de gasto das plataformas de anúncio.

O que funciona no lugar:

• Para visibilidade do cliente: workspace isolado + relatório exportado com periodicidade combinada. O isolamento garante que o arquivo enviado contém apenas o escopo daquele cliente — que é o requisito real por trás do pedido de acesso.
• Para identidade visual: domínio de tracking sob a marca do cliente, que é o ponto de contato que o usuário final realmente vê.
• Para custo: modelo por campanha ou lançamento diário.

Essa combinação cobre a maior parte dos casos de agência. Onde não cobrir, é melhor dizer antes de assinar. A comparação entre abordagens está em comparativos e o material específico para o cenário de múltiplas contas em Affilitrack para agências.

Repasse para parceiro sem quebrar o isolamento

Agência que trabalha com sub-afiliados ou parceiros de mídia precisa devolver a conversão para quem trouxe o tráfego. O repasse automático faz isso: ao receber uma conversão, dispara um postback para o parceiro com o valor definido por merchant e evento.

Dois cuidados em ambiente multi-cliente:

• O repasse é configurado dentro do workspace. O parceiro de um cliente não recebe evento de outro.
• O valor repassado não é necessariamente o valor da conversão. Ele é definido por merchant e evento, o que permite repassar a comissão acordada sem expor o valor cheio da transação do anunciante.

Esse segundo ponto é de confidencialidade, não de configuração: o parceiro precisa saber quanto vai receber, não quanto o anunciante fatura. Quem opera do lado do parceiro encontra a leitura complementar em Affilitrack para afiliados.

Auditoria: como saber que o isolamento está funcionando

Uma verificação trimestral de dez minutos evita surpresa:

• [ ] Cada contrato ativo tem um workspace e apenas um.
• [ ] Nenhum token de postback aparece em dois workspaces.
• [ ] Todos os merchants ativos têm mapeamento completo (evento, valor, id de transação).
• [ ] Log de postbacks sem acúmulo de inválidos — inválido recorrente indica token errado em algum lugar.
• [ ] Órfãos investigados: conversão sem clique pode significar tráfego fora do link de redirect.
• [ ] Domínio de tracking ativo e certificado válido em cada conta que usa domínio próprio.
• [ ] Convenção de sub-parâmetros documentada e igual à que está sendo usada.

O objetivo da arquitetura multi-cliente não é elegância. É que o pior erro possível de um dia ruim seja um relatório atrasado, e nunca um dado de cliente na mão de outro. Quem quiser aprofundar a base conceitual encontra os termos no glossário, as dúvidas frequentes no FAQ, a lógica de posse do dado em dados próprios e as condições por volume de contas em planos.