Como rastrear campanhas UTM de ponta a ponta sem um CDP

Já configurei rastreamento UTM de ponta a ponta em três empresas. Cada vez, as mesmas cinco coisas falharam na mesma ordem, e cada vez a correção foi a mesma: puxar a criação de templates para o nível da campanha, empurrar o encaminhamento de conversões para o servidor e colocar uma execução de teste entre os dois. Isso é a maior parte do que este artigo trata. O resto é a lista de verificação QA que apanha o que não pensou em verificar.

Não precisa de um Customer Data Platform para isto. Eventualmente precisará se o seu problema de atribuição se tornar "ligar quatro interações anónimas em três dispositivos numa única jornada de cliente", mas para o caso que vejo com mais frequência - "etiquetar todas as ligações de saída de forma consistente, capturar o clique, encaminhar a conversão para Meta e GA4 do lado do servidor, e sobreviver ao Safari" - um encurtador de URL com templates mais uma API de conversões faz o trabalho. Em baixo está a versão que funciona, com os modos de falha que já vi descritos.

O que corre mal com o rastreamento UTM#

Os marketers com quem trabalho não são maus no uso de UTMs. O problema é que as ferramentas por defeito facilitam a escrita de um UTM uma vez, dificultam a sua aplicação consistente numa organização e tornam impossível a correção após o lançamento. Quatro modos de falha aparecem repetidamente.

Desvio. Uma pessoa escreve utm_source=newsletter, outra escreve utm_source=Newsletter, uma terceira escreve utm_source=email. Seis meses depois, o seu canal "newsletter" está dividido por nove variantes de string no GA4. Limpar isso depois é um exercício de regex e esperança. O script original urchinTracker() que introduziu esta convenção - o produto de análise web Urchin pré-Analytics da Google, brevemente tornado código aberto em 2003 antes de ser absorvido - também não tinha uma camada de templates. A convenção sempre foi "escrever de forma consistente"; as ferramentas nunca o impuseram.

Etiquetagem manual em escala. Uma campanha de flyers com 80 ligações curtas em quatro lojas regionais representa 320 URLs que tem de escrever, colar numa folha de cálculo, copiar para o encurtador e torcer para que estejam corretas. Metade delas tem o utm_content errado. Ninguém repara até a campanha ter duas semanas.

Lacunas de conversão do lado do servidor. O pixel dispara na página de agradecimento, o GA4 capta-a, a Meta capta-a, e vai para casa. Depois o Safari lança outra versão do ITP, as instalações de bloqueadores de anúncios aumentam e as suas conversões reportadas caem um terço. As notas de lançamento do ITP 2.3 da Apple descrevem exatamente o mecanismo: a decoração de ligações é limitada, o document.referrer é removido, e qualquer fluxo de análise que dependa da execução de JS de terceiros no browser degrada silenciosamente. As conversões ainda estão a acontecer no seu servidor. Simplesmente não estão a chegar às plataformas de publicidade.

Sem execução de teste. A primeira conversão que flui pelo novo pipeline é o primeiro comprador real. Se algo está mal configurado, descobre três dias depois quando o algoritmo de otimização já retirou orçamento de uma campanha que estava efetivamente a funcionar.

Este artigo aborda os três primeiros com templates + importação em massa + encaminhamento do lado do servidor, e o quarto com uma etapa de verificação que é fácil de saltar e cara de saltar.

Templates UTM por workspace e campanha#

Os templates empurram o problema de consistência para cima na pilha. Define a sua convenção de etiquetagem uma vez ao nível do workspace, adiciona substituições por campanha onde justificado, e deixa todas as ligações herdar. Não há lugar para um erro de digitação existir.

Defina primeiro os padrões do workspace. Os valores literais fixam as variáveis que nunca mudam para a sua organização (utm_medium = email para campanhas de newsletter); os marcadores são preenchidos a partir do payload da ligação no momento da criação:

curl -X PUT \
  https://api.elido.app/v1/workspaces/1/utm-template \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -d '{
    "utm_source":   "{{ channel }}",
    "utm_medium":   "{{ medium }}",
    "utm_campaign": "{{ campaign }}",
    "utm_content":  "{{ creative }}",
    "utm_term":     "{{ audience.segment }}"
  }'

Alguns detalhes que importam aqui:

• Os marcadores são preenchidos no momento da criação da ligação, não no momento do clique. O que chega à sua ferramenta de análise é o que foi pretendido no momento em que a ligação foi criada - não o que o destino da ligação calculou no clique. Isso torna a reconstrução do registo de auditoria muito mais fácil quando algo parece errado seis meses depois.
• Os marcadores desconhecidos falham rapidamente. Se a sua importação em massa tem uma coluna creative em falta e o template do workspace referencia {{ creative }}, a API devolve um 422 com o nome da variável não resolvida. Sem aplicação parcial silenciosa.
• A referência completa do template, incluindo marcadores link.tag.<name> que leem a partir do array de tags da ligação (útil para agências multi-tenant que precisam de incorporar um identificador de cliente em cada URL), encontra-se no guia de documentação.

Depois adicione um template de campanha. As campanhas herdam do workspace e substituem o subconjunto específico da campanha:

curl -X POST \
  https://api.elido.app/v1/campaigns \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -d '{
    "name": "Spring 2026 - DACH",
    "utm_template": {
      "utm_campaign": "spring_2026_dach",
      "utm_term":     "{{ audience.locale }}"
    }
  }'

Qualquer coisa não definida na campanha passa para os padrões do workspace. A estrutura de dois níveis cobre a maioria das estruturas organizacionais reais: convenções partilhadas ao nível do workspace, substituições específicas de equipa ou de temporada ao nível da campanha. Se se encontrar a querer um terceiro nível de herança, isso é um sinal de alerta - geralmente significa que duas campanhas deviam ser uma campanha com valores de marcadores mais inteligentes.

O que as substituições por ligação cedem: uma substituição é aplicada independentemente do template. O que mantêm: a substituição é registada no registo de auditoria com ator + timestamp + o diff resolvido versus final. Daqui a seis meses, quando alguém perguntar por que uma ligação numa campanha de 200 ligações tem utm_term=manual_override, pode responder.

Importação em massa a partir de Sheets - o fluxo que a maioria dos marketers realmente usa#

Os marketers não passam o dia inteiro com curl. O briefing de campanha chega como uma folha de cálculo com URLs de destino e metadados de campanha, o prazo de lançamento é sexta-feira, e a questão é como essa folha de cálculo se torna 200 ligações curtas sem ninguém escrever a mesma string UTM 200 vezes.

Os nomes das colunas CSV correspondem aos nomes dos marcadores do seu template (sem distinção entre maiúsculas e minúsculas). As colunas que a Elido não reconhece são descartadas com um aviso em vez de copiadas silenciosamente - isso é deliberado. A cópia silenciosa é como se acaba com utm_brand_color a aparecer no GA4 porque alguém adicionou uma coluna para uma nota interna.

destination_url,channel,medium,creative
https://shop.example.com/de,newsletter,email,hero_a
https://shop.example.com/fr,newsletter,email,hero_a
https://shop.example.com/de,paid_social,meta,carousel_v2
https://shop.example.com/fr,paid_social,meta,carousel_v2

Faça POST como multipart:

curl -X POST \
  https://api.elido.app/v1/links/bulk \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -F "csv=@launch_q2.csv" \
  -F "campaign_id=cmp_8a2f"

Duas coisas que este fluxo de validação lhe dá que a UI de uma ligação de cada vez não dá:

• Confirmação tudo-ou-nada. Uma única linha má cancela todo o upload e devolve os números das linhas com problema mais o motivo - row 47: unresolved variable {{ creative }} é um erro muito melhor do que descobrir às 16h de sexta-feira que 47 das suas 200 ligações resolveram para uma string de marcador.
• Pré-visualização pré-lançamento. A linha de pré-visualização de importação em massa do dashboard mostra o URL resolvido, incluindo a query string utm_* renderizada, antes da confirmação. Olhe para a segunda ligação para se certificar de que o seu template fez o que esperava, depois olhe para a última ligação para se certificar de que as linhas mais abaixo no ficheiro não desviaram. Dois olhares, um minuto.

Se a sua folha de cálculo não tem uma forma estável - as ordens das colunas mudam, os cabeçalhos são renomeados - o endpoint de importação em massa vai ser desconfortável. A correção não está nas nossas ferramentas; a correção é comprometer-se com um schema CSV para os seus briefings de campanha e tratar o desvio de schema como um bug de processo. Discutimos o padrão mais amplo na página de soluções para marketers.

Encaminhamento de conversões do lado do servidor para Meta CAPI e GA4#

A atribuição exclusivamente por pixel perde 20-40% das conversões para o ITP do Safari, bloqueadores de anúncios e banners de consentimento. O número varia por setor - o comércio eletrónico DTC vê a extremidade alta do intervalo, o B2B SaaS a extremidade baixa - mas todas as medições que vi pós-iOS 14 colocam a fiabilidade dos pixels bem abaixo da marca dos 95% que as plataformas de publicidade assumem. O algoritmo de otimização recebe inputs mais ruidosos e o seu CPA parece pior do que é.

A documentação da API de Conversões da Meta é explícita sobre isto: os eventos do servidor são o que quer, o pixel do lado do browser é o suplemento. O Measurement Protocol do GA4 faz o mesmo argumento. Ambos os protocolos aceitam a mesma forma: um evento do lado do servidor com os detalhes da conversão, um event_id para deduplicação e, idealmente, identificadores de utilizadores com hash para que as plataformas possam associar a conversão a um visitante conhecido.

A canalização que fecha a lacuna é mecânica. Três etapas.

Etapa um - capturar o click_id. Cada resposta de redirecionamento da Elido carrega um cabeçalho X-Elido-Click-Id. Os SDKs em TS / Python / Go expõem-no no objeto de resposta de redirecionamento; o HTTP puro também funciona:

curl -sI https://elido.me/launch | grep -i click-id
# X-Elido-Click-Id: clk_01HYZ7T8WV6KQX3M

Guarde-o num cookie de primeira parte na página de destino (elido_click_id, TTL de 90 dias - tempo suficiente para cobrir uma avaliação SaaS típica, curto o suficiente para satisfazer as orientações de ePrivacidade). Leia-o de volta no checkout.

Etapa dois - configurar os destinos. Faça PUT das credenciais para as plataformas para as quais quer encaminhar. Qualquer subconjunto funciona; as plataformas em falta são ignoradas silenciosamente:

curl -X PUT \
  https://api.elido.app/v1/workspaces/1/conversion-forwarding \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -d '{
    "meta_capi": {
      "pixel_id": "1234567890",
      "access_token": "EAA…",
      "test_event_code": null
    },
    "ga4_mp": {
      "measurement_id": "G-ABC123",
      "api_secret": "abc_def_ghi"
    },
    "mixpanel": {
      "project_token": "pm_…",
      "service_account": "[email protected]"
    }
  }'

Etapa três - fazer POST da conversão. Quando o pedido é feito, envie o evento com o click_id e os detalhes do pedido. event_id é a sua chave de idempotência:

curl -X POST \
  https://api.elido.app/v1/conversions \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -d '{
    "click_id":   "clk_01HYZ7T8WV6KQX3M",
    "event_name": "purchase",
    "event_id":   "ord_98231",
    "value":      89.00,
    "currency":   "EUR",
    "user": {
      "email":  "[email protected]",
      "phone":  "+4915123456789",
      "external_id": "cust_5128"
    }
  }'

Os campos de identidade do utilizador são submetidos a hash SHA-256 antes de serem encaminhados para Meta e GA4 - é isso que ambas as plataformas exigem. O contexto UTM é extraído da linha de clique que corresponde ao click_id, por isso o evento encaminhado carrega a atribuição da campanha original mesmo que o utilizador tenha navegado pelo site durante uma hora antes do checkout. A mecânica completa, incluindo o tratamento de devoluções e o interruptor do modelo de atribuição multi-toque, está no guia de encaminhamento de conversões.

Isto fecha a maior parte da lacuna. Há um buraco residual - visitantes que bloqueiam o cookie click_id, ou chegam através de um caminho não-Elido - mas para as campanhas para as quais realmente dirige tráfego, passou de "60-80% de fiabilidade de pixel" para "95%+ de fiabilidade do servidor".

Três casos extremos que o registo de auditoria vai salvar-lhe#

Os templates e o encaminhamento tratam da via feliz. Os casos abaixo aparecem na semana três de qualquer campanha não trivial, e a resposta certa para todos eles está no registo de auditoria + no painel de conversões - não em tentar conceber um template mais elaborado.

Devoluções. Uma conversão de compra foi disparada, o cliente devolveu o artigo uma semana depois e a sua receita reportada está agora 8% mais alta. A correção é fazer POST do mesmo event_id com event_name: "refund". A Meta e o GA4 tratam isto como uma conversão negativa contra o original; o Mixpanel regista-o como um evento separado que subtrai no seu funil. O motivo pelo qual o event_id tem esta forma: a idempotência ao nível do event id significa que também não pode contar a devolução duas vezes. O padrão completo está documentado na secção de casos extremos do guia de encaminhamento de conversões - devoluções, devoluções parciais e crédito de loja têm cada um uma forma ligeiramente diferente.

Falhas de correspondência do click-id. Uma conversão é disparada com um click_id que não corresponde a nenhum clique conhecido - erro de digitação, expirado além da retenção, workspace errado. A conversão ainda é registada no workspace mas encaminhada sem contexto UTM. Isto é intencional: a atribuição genérica é mais útil do que descartar a conversão, e o flag click_id_unknown no registo de auditoria permite-lhe filtrar a fatia não atribuída nos relatórios. Se a fatia for maior do que 5% das conversões, algo está errado com a forma como persiste o click_id na página de destino - geralmente o atributo SameSite do cookie ou o âmbito do path.

Conversões que chegam tarde. Uma venda B2B SaaS fecha 47 dias após o clique original. A retenção de cliques padrão da Elido é de 30 dias, por isso quando a conversão é disparada, o clique já expirou e está no caso de falha de click-id acima. Duas correções, dependendo do seu ciclo de vendas: aumente a retenção para 90 dias no workspace (plano Pro e acima), ou capture o click_id num identificador de primeira parte de longa duração (a coluna original_click_id do seu registo de cliente) para que o possa ligar de volta no momento da conversão mesmo que o cookie tenha desaparecido. Já vimos ambos os padrões em produção.

O registo de auditoria mostra o diff UTM resolvido versus final por ligação, o código de resposta do encaminhamento por destino por conversão e o estado da junção click_id-para-conversão. Quando o algoritmo de otimização retira orçamento de uma campanha que parece ter mau desempenho, o registo de auditoria é o que lhe permite dizer "não, a campanha está bem; perdemos três dias de encaminhamento para um api_secret do GA4 rotacionado". Olhe para ele.

O QA pré-lançamento - execute um teste de todo o pipeline#

Não deixe que a primeira conversão que flua por isto seja um comprador real. O custo de uma execução de teste de 30 minutos recai inteiramente sobre si; o custo de um pipeline mal configurado recai sobre o algoritmo de otimização a retirar orçamento da sua melhor campanha durante dois dias antes de o notar. A assimetria é má.

Três etapas, por ordem.

Execução de teste de importação em massa. O endpoint de importação em massa aceita dry_run=true como parâmetro de query. Executa a validação, resolve os templates e devolve as ligações que seriam criadas sem confirmar. Abra a resposta em qualquer visualizador JSON; o URL resolvido de cada linha é visível. Verifique 3-5 linhas: a segunda ligação, a última ligação e quaisquer linhas que substituíram os padrões do workspace. Verifique se a query string utm_* é exatamente o que o seu briefing de campanha diz que deve ser.

Modo de teste de encaminhamento de conversões. O Meta CAPI aceita um parâmetro test_event_code, que encaminha o evento para o separador Test Events no Events Manager em vez de produção. Defina-o na configuração de encaminhamento do workspace, envie 10-20 conversões de exemplo e confirme que chegam. A mesma ideia para o GA4: defina debug_mode: true nos eventos e verifique no DebugView. Ambos são em tempo real. O objetivo não é verificar se a API funciona; o objetivo é apanhar um pixel_id mal configurado ou um api_secret que foi rotacionado e nunca atualizado.

Teste de fumo de ponta a ponta. Clique numa das suas ligações curtas reais a partir de uma sessão de browser limpa. Observe o clique no painel de cliques recentes do dashboard da Elido. Simule uma compra - faça POST de uma conversão purchase com esse click_id a partir do seu terminal. Confirme que a conversão aparece em Meta Test Events e GA4 DebugView com o contexto UTM correto anexado. Todo o ciclo é inferior a 10 minutos depois de o ter feito uma vez.

Depois de os três passarem, remova o test_event_code, defina debug_mode: false e lance. O primeiro comprador real terá um pipeline limpo à sua espera.

Quando realmente precisaria de um CDP#

Templates mais importação em massa mais encaminhamento do lado do servidor leva-o à maior parte do caminho. Há uma classe de problemas onde isso não é suficiente, e recorrer a um CDP é a decisão certa.

Ligação de identidade entre dispositivos. Um visitante clica numa ligação no telemóvel, não converte, regressa no computador, regista-se. Quer que ambas as interações sejam atribuídas à mesma pessoa. O rastreamento UTM + click_id é ao nível da interação; a camada de identidade do utilizador que torna as duas interações uma única jornada é para o que um CDP (Segment, mParticle, RudderStack) foi construído. A Elido armazena até 30 dias de cliques por visitante e suporta atribuição de último toque / primeiro toque / baseada em posição dentro dessa janela, mas a junção entre dispositivos precisa de um grafo de identidade que deliberadamente não operamos.

Personalização abaixo de 100ms. Se está a renderizar a página de destino com base nos toques anteriores do visitante em tempo real - a extrair o coorte de um feature store e a variar o título do hero - precisa da resolução de identidade próxima da renderização. Isso é território CDP ou, mais frequentemente, uma plataforma de experimentação como PostHog ou LaunchDarkly por cima.

Atribuição multi-toque em escala. O último toque é suficiente para a maioria das campanhas. Se o seu ciclo de vendas tem seis toques ao longo de quatro meses e genuinamente precisa de creditar cada um, está no território onde a atribuição por cadeia de Markov ou valor de Shapley começa a importar. A Elido faz último toque / primeiro toque / baseado em posição; qualquer coisa mais sofisticada quer uma ferramenta com um grafo de identidade adequado e uma camada de modelo.

Para tudo o resto - e "tudo o resto" é a maioria das equipas de marketing com quem trabalhei - o padrão de templates + importação em massa + encaminhamento do lado do servidor é suficiente. Configure o template do workspace uma vez, o template de campanha por lançamento, a configuração de encaminhamento uma vez por integração de plataforma e execute o teste antes de cada lançamento. Se fizer as quatro coisas, terá um pipeline UTM mais rigoroso do que 80% das equipas de marketing que já audiei.

Configure uma vez, execute o teste antes de cada lançamento e avance para a próxima campanha.

Relacionado no blog#

• Rastreamento do lado do servidor GA4 via camada de redirecionamento
• Atribuição sem cookies explicada: o que ainda funciona em 2026
• Importação em massa de ligações curtas a partir de uma Google Sheet (o fluxo real de campanha)
• Atribuição de cliques após ITP do Safari: o que ainda funciona em 2026