Um guia prático de Rastreamento de atribuição em subdomínios

Na prática, o rastreamento de atribuição fica confuso quando um usuário passa de www.example.com para app.example.com, docs.example.com, checkout.example.com, ou um microsite de marketing separado. A pessoa vê uma marca. Sua stack de analytics pode ver várias visitas desconectadas.

Essa desconexão pode fazer a busca orgânica parecer fraca, as campanhas pagas parecerem melhores ou piores do que realmente são, e a ativação do produto parecer desconectada da landing page que a causou.

O objetivo é preservar o contexto da origem ao longo da jornada sem transformar a atribuição em rastreamento invasivo.

Problemas comuns entre subdomínios

Subdomínios criam lacunas de atribuição de maneiras previsíveis:

• O site de marketing e o aplicativo usam propriedades de analytics diferentes.
• Um formulário de cadastro redireciona por um provedor de autenticação.
• Os parâmetros UTM se perdem antes do evento de conversão.
• As exclusões de referência estão configuradas incorretamente.
• Os cookies são restritos a um host em vez do domínio pai.
• Um aplicativo single-page muda de rota sem registrar pageviews.
• O aplicativo de produto registra a ativação, mas o site de marketing registra a aquisição.

O resultado costuma ser um relatório em que as conversões aparecem como tráfego direto, autorreferências, referências de autenticação ou "desconhecido".

Defina a jornada antes de configurar as ferramentas

Comece pelo caminho real do usuário. Para uma empresa SaaS, esse caminho é assim:

1. O visitante chega a www.example.com/blog/... pela busca orgânica.
2. O visitante clica em "Start free trial."
3. O navegador abre app.example.com/signup.
4. O usuário verifica o e-mail por meio de um serviço de autenticação.
5. O usuário cria um workspace.
6. O usuário conecta uma integração.

Agora decida quais eventos importam:

• Visualização da landing page
• Início do cadastro
• Cadastro concluído
• Workspace criado
• Primeira integração conectada
• Primeiro relatório visualizado

Cada evento deve ter um responsável e uma definição. Se "signup" significar início do formulário em uma ferramenta e conta verificada em outra, os relatórios de atribuição não serão confiáveis.

Use UTMs de forma consistente

UTMs continuam sendo a forma mais simples de preservar o contexto da campanha. Use-as em anúncios pagos, e-mail, parcerias, posts em redes sociais, links de afiliados e QR codes offline. Mantenha os valores em minúsculas, previsíveis e livres de dados pessoais.

Bom:

?utm_source=linkedin&utm_medium=paid-social&utm_campaign=q2-demo

Ruim:

?utm_source=linkedin&utm_campaign=jane.smith@example.com-demo

A documentação de UTM do Google continua sendo uma referência útil para o significado dos parâmetros, mesmo que você use outro produto de analytics (Central de Ajuda do Google Analytics).

Mantenha a atribuição first-party sempre que possível

Para jornadas entre subdomínios, a medição first-party é suficiente. Você pode usar o mesmo script e projeto de analytics em subdomínios relacionados, armazenando apenas o contexto mínimo de origem necessário para relatórios agregados.

Em uma implementação privacy-first:

• Não armazene endereços IP completos.
• Não construa perfis entre sites em domínios não relacionados.
• Evite fingerprinting como alternativa às limitações de cookies.
• Não passe e-mails ou IDs de clientes em URLs.
• Remova parâmetros de consulta sensíveis antes da coleta de analytics.
• Use retenção curta para dados brutos de eventos.

Se você usar cookies, preste atenção ao consentimento e ao escopo do cookie. Um cookie com escopo .example.com pode ser lido pelos subdomínios, mas ainda é uma tecnologia de rastreamento e pode exigir consentimento dependendo da finalidade e da jurisdição. As diretrizes do ICO do Reino Unido deixam claro que cookies não essenciais e tecnologias semelhantes exigem controle do usuário (ICO).

Lidando com Autenticação e Redirecionamentos de Checkout

Provedores de autenticação e processadores de pagamento interrompem a atribuição. Se um usuário passa por auth.vendor.com ou checkout.vendor.com, sua ferramenta de analytics trata o retorno como uma nova indicação.

Use estas proteções:

• Adicione domínios conhecidos de autenticação e pagamento às exclusões de referência, quando sua ferramenta permitir.
• Armazene o contexto da campanha antes de redirecionar.
• Dispare eventos de conversão depois que o usuário retornar ao seu domínio.
• Concilie as conversões do analytics com os registros do backend.
• Teste os fluxos em navegação privada e com o consentimento recusado.

Para conversões de alto valor, registre a conversão no servidor também. O analytics do lado do navegador é bom para o contexto de marketing, mas seu backend deve continuar sendo a fonte da verdade para contas criadas, assinaturas pagas e faturas.

Atribua a Ativação, Não Apenas o Cadastro

Muitas equipes de SaaS param no "teste iniciado". Isso recompensa campanhas que geram curiosidade, não necessariamente clientes. Relatórios melhores conectam a origem de aquisição a marcos de ativação.

Exemplos:

• Visitantes de busca orgânica criam menos contas, mas ativam a uma taxa maior.
• Anúncios em redes sociais geram muitos cadastros, mas poucas conexões de integração.
• Indicações de parceiros geram menos testes, mas mais upgrades pagos.
• O tráfego de documentação converte devagar, mas produz usuários com alta retenção.

Você não precisa de vigilância por pessoa para isso. Coortes agregadas por origem, campanha, página de destino e evento de ativação já podem bastar.

Uma Checklist de Atribuição Entre Subdomínios

Antes de confiar nos números, teste a jornada completa:

• Mesmo projeto de analytics ou relatórios claramente unidos entre subdomínios.
• Pageviews registradas para mudanças de rota do lado do cliente.
• UTMs preservados ou capturados antes dos redirecionamentos.
• Domínios de autenticação e pagamento tratados de forma intencional.
• Eventos de conversão definidos uma única vez.
• Registros do backend conciliados com as contagens do analytics.
• Parâmetros sensíveis removidos da URL.
• Comportamento de consentimento testado em mercados regulados.
• Tráfego de bots e interno filtrado.

A atribuição entre subdomínios deve tornar as decisões mais claras, não criar um grafo de identidade paralelo. Meça o caminho da origem ao resultado, mantenha os dados first-party e mínimos, e use a verdade do backend para eventos que afetam receita ou conformidade.

Verificações Finais de Atribuição

Antes de confiar na atribuição entre subdomínios, comprove três coisas: o contexto da campanha sobrevive à jornada, a conversão existe no seu sistema de backend e os dados sensíveis da URL são removidos antes de chegar ao analytics.

Use o analytics para responder perguntas operacionais, como qual canal trouxe visitantes qualificados, qual página de destino converteu e onde o funil teve queda. Mantenha dados pessoais fora dos parâmetros de campanha, evite o fingerprinting como atalho e concilie resultados de alto valor com registros first-party.

Checklist de Validação

Antes de confiar na atribuição entre subdomínios, execute cinco jornadas de ponta a ponta: visita direta, visita por campanha UTM, cadastro do blog para o app, redirecionamento de autenticação e redirecionamento de checkout. Confirme que a campanha original sobrevive a redirecionamentos legítimos, mas não se sobrescreve em links internos. UTMs devem descrever links de aquisição vindos de fora da propriedade; usá-los em navegação interna pode corromper a fonte da verdade.

Em seguida, inspecione os payloads. O contexto da campanha deve incluir origem, meio, campanha, conteúdo e, às vezes, utm_id, não e-mails, IDs de conta ou tokens de usuário avulsos. A documentação do URL builder do Google recomenda definir os parâmetros UTM relevantes, especialmente origem, meio, campanha, ID e plataforma de origem quando aplicável, o que é suficiente para a maioria dos relatórios de campanha (Google Analytics URL builder).

Por fim, concilie os totais de conversão com os registros do backend. A atribuição explica de onde vieram as conversões; ela não deve se tornar a fonte da verdade sobre se uma conversão aconteceu.

Perguntas Frequentes

Por que o mesmo visitante aparece como várias sessões em subdomínios diferentes?

Porque cada subdomínio geralmente roda sua própria propriedade de analytics ou restringe cookies a um único host, então app.example.com e www.example.com nunca compartilham o mesmo id de visita. Parâmetros UTM e dados de referência se perdem em um redirecionamento de cadastro ou em uma transferência de autenticação, então a mesma pessoa acaba sendo contada duas vezes como tráfego direto ou como autorreferência.

Qual é o primeiro passo para corrigir a atribuição entre subdomínios?

Escreva o caminho real do usuário antes de mexer em qualquer ferramenta, desde a página de destino orgânica até o cadastro, verificação de email, criação do workspace e a primeira integração. Depois atribua um responsável e uma definição a cada evento, já que uma definição incompatível de "cadastro" entre duas ferramentas é o que quebra o relatório mais tarde.

Devo colocar parâmetros UTM em links internos entre meus próprios subdomínios?

Não. UTMs descrevem um link de aquisição que começa fora da propriedade, e usá-los em um link de www.example.com para app.example.com vai sobrescrever a origem real por uma interna. Reserve UTMs para anúncios pagos, email, parcerias, posts em redes sociais, links de afiliados e QR codes offline.

Preciso de um cookie separado para cada subdomínio?

Não, se os subdomínios compartilham o mesmo domínio pai. Um cookie restrito a .example.com pode ser lido por www, app, docs e checkout igualmente, embora ainda conte como uma tecnologia de rastreamento e exija consentimento dependendo da finalidade e da jurisdição.

Como evito que redirecionamentos de autenticação quebrem a atribuição?

Adicione os domínios de autenticação e pagamento à lista de exclusão de referência da sua ferramenta de analytics e depois armazene o contexto da campanha antes do redirecionamento começar. Dispare o evento de conversão somente depois que o usuário voltar ao seu domínio. Teste o fluxo em navegação privada e com o consentimento recusado, para pegar casos que a lista de exclusão não cobre.

Por que a busca orgânica parece fraca em alguns relatórios de atribuição?

Uma desconexão entre o site institucional e o aplicativo é uma causa comum. Sessões que começam com busca orgânica em www.example.com são interrompidas no redirecionamento de cadastro, então app.example.com registra a ativação sem origem visível, e o relatório subestima o orgânico.

A atribuição deve parar no cadastro ou ir além?

Acompanhe até a ativação. O cadastro sozinho recompensa campanhas que geram curiosidade em vez de clientes, enquanto observar a criação do workspace e a primeira integração conectada pode mostrar que a busca orgânica ou o tráfego de documentação ativa a uma taxa maior, mesmo com menos cadastros brutos.

Analytics do lado do navegador é suficiente para conversões de alto valor?

Não, sozinho não. Analytics do lado do navegador é bom para contexto de marketing, mas assinaturas pagas e faturas precisam de um registro no backend como fonte da verdade, seguido de uma etapa de reconciliação entre os dois, para que a atribuição nunca vire o fator decisivo sobre se uma conversão aconteceu.

O que deve ser removido de uma URL antes que o analytics a colete?

Emails, IDs de clientes e outros dados pessoais não têm lugar em uma query string. Remova parâmetros sensíveis antes da coleta, evite armazenar IPs completos, não use fingerprinting como alternativa às limitações de cookies, e mantenha curta a retenção de eventos brutos.

Como sei se um aplicativo de página única está quebrando o rastreamento de pageviews?

Verifique se as mudanças de rota dentro de app.example.com disparam um evento de pageview, já que SPAs que atualizam a URL do lado do cliente costumam pular a chamada de analytics que um carregamento de página completo dispararia. Pageviews ausentes nas mudanças de rota é um dos problemas listados entre subdomínios e aparece como uma jornada incompleta entre cadastro e ativação.