Ver todas as integrações
FAQ do ClickTrail

Respostas antes de instalar

As respostas estão organizadas pelas decisões que donos de sites e implementadores realmente precisam tomar: onde a atribuição é armazenada, quais superfícies de conversão exigem configuração, o que muda em um setup sGTM e o que ainda precisa de verificação em runtime. ClickTrail é um plugin WordPress, não um substituto para sua stack de analytics ou consentimento.

Cluster 1

Atribuição no WooCommerce e eventos da loja

Use este cluster quando a conversão é um pedido e você precisa separar a atribuição armazenada dos sinais de analytics no navegador.

Onde aparece a atribuição do WooCommerce?

O ClickTrail armazena a atribuição no pedido WooCommerce. Telas administrativas compatíveis podem exibir o contexto, enquanto eventos de compra podem levá-lo ao dataLayer e à entrega opcional.

O registro da conversão é o pedido WooCommerce: o README do código descreve a retenção da atribuição first-touch e last-touch no momento em que o pedido é criado. Esse é o local para investigar quando um pedido pago aparece como direto — não uma promessa de que todo relatório de analytics será corrigido automaticamente.

O ClickTrail também possui telas administrativas do WooCommerce quando suportadas. Separadamente, o caminho de compra pode levar o contexto de campanha ao dataLayer do navegador, e a capacidade opcional de Entrega pode encaminhar um payload habilitado para um destino configurado. Dados do pedido, eventos do navegador e entrega remota são superfícies diferentes.

Em uma implementação real, faça uma visita de teste com uma campanha exclusiva, crie um pedido de teste, inspecione o pedido no WooCommerce e depois confira o preview do GTM ou o dataLayer. Se a Entrega estiver ativa, valide requisição, resposta, consentimento e trace de diagnóstico em vez de inferir sucesso pela tela do pedido.

Valide no site de destino

  • Use uma campanha de teste exclusiva e registre as expectativas de first-touch e last-touch.
  • Confirme os valores no pedido depois do checkout e após recarregar o admin.
  • Confira os campos do evento de compra no preview do GTM ou no dataLayer.
  • Teste a Entrega separadamente quando houver coletor ou endpoint configurado.

Limite da evidência: Os caminhos de atribuição do pedido e de eventos estão presentes no código revisado; armazenamento WooCommerce, transições de consentimento, aceite do provedor e apagamento em runtime ainda exigem teste no site de destino.

Fontes e verificaçãoClickTrail READMEIntegration evidence
O ClickTrail suporta HPOS do WooCommerce?

O plugin declara compatibilidade com tabelas customizadas de pedidos do WooCommerce (HPOS) e usa APIs de pedidos do WooCommerce nos caminhos documentados, mas a loja precisa de um teste próprio.

HPOS altera o local onde o WooCommerce mantém os dados do pedido. O bootstrap do ClickTrail declara compatibilidade com tabelas customizadas de pedidos, e a integração usa APIs de pedidos do WooCommerce em vez de presumir que todo pedido é um post WordPress convencional.

Essa declaração é um sinal de implementação, não uma certificação end-to-end para todo tema, extensão de checkout, hook customizado ou estado de migração. Uma loja pode ter HPOS ativo enquanto uma extensão ainda lê o armazenamento legado ou altera o ciclo de checkout.

Ative HPOS em uma cópia de staging, faça um pedido de teste com campanha, confira atribuição e evento de compra e repita depois de qualquer migração ou mudança em extensões. Mantenha um pedido de controle sem parâmetros para separar falha de captura de problema de armazenamento HPOS.

Valide no site de destino

  • Registre as versões de WooCommerce e ClickTrail usadas no teste.
  • Confirme se HPOS é a fonte principal, compatível ou está em migração.
  • Crie um pedido identificado e confira atribuição no admin e saída de eventos.
  • Verifique se extensões de checkout e status ainda presumem armazenamento legado.

Limite da evidência: A compatibilidade com HPOS está declarada no código e no readme público; checkout HPOS, migração, combinação de extensões e apagamento em runtime não foram testados nesta revisão.

Fontes e verificaçãoClickTrail READMEIntegration evidence
O que fazem os eventos de storefront do WooCommerce?

Quando habilitado, o ClickTrail emite view_item, view_item_list, view_cart, add_to_cart, remove_from_cart e begin_checkout pelo layer de eventos do navegador; são opcionais e ficam desligados por padrão em upgrades.

Eventos de storefront descrevem a jornada antes da compra. Eles são úteis quando o time quer sinais de produto e checkout no dataLayer, não apenas o pedido final. Ativar a opção não cria por si só uma propriedade GA4, uma tag GTM ou uma conversão no provedor.

Os nomes documentados são view_item, view_item_list, view_cart, add_to_cart, remove_from_cart e begin_checkout. O readme informa que a configuração fica desligada por padrão em upgrades, evitando adicionar volume de eventos sem uma decisão explícita.

Trate nomes e campos dos eventos como um contrato de integração. Habilite em staging, inspecione uma jornada no preview do GTM ou dataLayer, teste o caminho sem consentimento e procure eventos duplicados causados por tema, extensão WooCommerce ou outra implementação de analytics.

Valide no site de destino

  • Habilite somente os eventos que o plano de mensuração realmente consome.
  • Inspecione nomes e campos de ecommerce em uma jornada de navegador limpa.
  • Valide consentimento, cache e duplicidade antes de publicar tags.
  • Documente qual consumidor é responsável por cada evento: GTM, GA4 ou outro destino.

Limite da evidência: A lista de eventos e o comportamento opcional estão documentados no readme público; payloads do navegador, bloqueio por consentimento e aceite downstream continuam sendo verificações de runtime.

Fontes e verificaçãoWordPress.org FAQClickTrail README
Cluster 2

Formulários, cache e atribuição no WordPress

Use este cluster quando o contexto da campanha desaparece entre a landing page e o formulário, especialmente em páginas em cache ou renderizadas dinamicamente.

O ClickTrail funciona apenas com WooCommerce?

Não. WooCommerce é uma superfície de conversão; o ClickTrail também cobre captura de atribuição, formulários suportados, eventos do navegador e caminhos de webhook ou entrega configurada.

Um site WordPress não precisa vender produtos para usar a camada de captura. As superfícies documentadas incluem formulários de lead, eventos do navegador, intake de webhooks externos e entrega opcional para endpoint configurado. WooCommerce adiciona armazenamento específico de pedidos e eventos de comércio; não é requisito para a captura básica.

O comportamento varia por integração de formulário. Alguns adapters podem adicionar campos ocultos automaticamente, enquanto outros esperam que os campos existam ou usam hooks de envio. Um webhook ou caminho de entrega genérico também exige validação própria de payload, autenticação, consentimento, retentativas e retenção.

Escolha o registro que realmente representa a conversão: envio de formulário, pedido ou webhook aceito. Habilite apenas a integração correspondente e teste a passagem. Não descreva um conector como suporte universal a provedor quando a evidência só estabelece um caminho de código ou endpoint genérico.

Valide no site de destino

  • Defina qual registro WordPress representa a conversão.
  • Habilite somente o caminho de formulário, WooCommerce, evento ou webhook usado.
  • Valide em staging o campo ou hook específico do plugin.
  • Confirme autenticação e aceite do destino separadamente do armazenamento local.

Limite da evidência: O readme público lista formulários, webhooks, eventos do navegador e WooCommerce; conectores e provedores individuais continuam sujeitos a evidência de runtime.

Fontes e verificaçãoWordPress.org FAQIntegration evidence
O que acontece se meu site usa cache agressivo?

O ClickTrail inclui fallback no cliente e suporte a conteúdo dinâmico em fluxos de formulário suportados, mas cache e otimização ainda precisam de validação específica no site.

O cache pode servir HTML gerado antes da chegada do visitante, atrasar ou adiar JavaScript e substituir um formulário depois do carregamento inicial. Por isso o ClickTrail documenta fallback no cliente e suporte a conteúdo dinâmico, em vez de depender apenas de campos ocultos renderizados no servidor.

Fallback não é garantia de que todo plugin de cache, CDN, banner de consentimento ou renderizador de formulário preservará a atribuição. Ferramentas de otimização podem reordenar scripts, remover parâmetros ou adiar o código até depois do envio. Diagnósticos e exclusões de cache são pontos de partida, não prova de um lead bem atribuído.

Teste o caminho real: visita sem cache com UTM exclusiva, visita com cache, formulário inserido dinamicamente e registro final. Compare captura no navegador, valores no envio e conversão armazenada. Se falhar, preserve HTML e timing dos scripts antes de alterar configurações.

Valide no site de destino

  • Teste uma página fria e uma página em cache com valores de campanha diferentes.
  • Abra formulários depois do carregamento inicial e envie após um intervalo realista.
  • Confirme que ferramentas de otimização não adiam ou reescrevem os scripts do ClickTrail.
  • Compare valores capturados, enviados e armazenados em cada limite.

Limite da evidência: Fallback no cliente, caminhos de formulário dinâmico e diagnósticos de conflito de cache estão presentes no código revisado; CDN, plugin de cache, banner e renderizador do site de destino não foram testados aqui.

Fontes e verificaçãoWordPress.org FAQIntegration evidence
Preciso adicionar campos ocultos a todos os formulários?

Não. A resposta depende do plugin: Contact Form 7 e Fluent Forms podem receber campos automaticamente, enquanto Gravity Forms e WPForms normalmente precisam dos campos ct_* correspondentes adicionados ao formulário.

O ClickTrail não trata todos os construtores de formulário como equivalentes. O comportamento documentado é enriquecimento automático para Contact Form 7 e Fluent Forms; Gravity Forms e WPForms trabalham normalmente com campos ocultos correspondentes que você adiciona e decide armazenar ou exportar.

Elementor Forms Pro e Ninja Forms usam os hooks de envio disponíveis e caminhos de atribuição armazenados, não o mesmo modelo de injeção automática. A pergunta não é apenas “o ClickTrail carregou?”, mas “qual adapter grava o registro de conversão que o site usa?”.

Adicione somente os campos necessários ao contrato do CRM ou report. Em staging, envie um formulário com visita identificada, inspecione o campo na renderização e no envio e compare o registro final. Não adicione dados sensíveis só porque existe um campo no schema do plugin.

Valide no site de destino

  • Identifique o plugin e o registro ou webhook que recebe o envio.
  • Em Gravity Forms ou WPForms, adicione os campos ct_* exigidos pelo contrato.
  • Teste estados de formulário dinâmico e sem consentimento.
  • Confirme que o payload final contém apenas campos de atribuição aprovados.

Limite da evidência: O código documenta comportamentos diferentes por plugin; execução de hooks, preenchimento, transições de consentimento e retenção em terceiros exigem teste ao vivo.

Fontes e verificaçãoWordPress.org FAQIntegration evidence
Cluster 3

GA4, GTM, sGTM e entrega server-side

Use este cluster para escolher o rollout confiável mais simples, sem ativar entrega antes de existir um coletor ou consumidor de analytics pronto.

O que o modo sGTM muda?

O modo sGTM altera como o ClickTrail carrega ou valida um setup GTM-first, incluindo URL do tagging server, caminho de loader first-party ou customizado e checagens de preview; não prova aceite do destino.

O modo trata do carregamento e da validação do GTM. As configurações documentadas podem incluir URL do tagging server, entrega de script first-party ou loader customizado, seguidas de checagens de preview na área de Eventos. É um formato diferente de apenas enviar eventos do navegador para um container web normal.

Isso não transforma um endpoint sem configuração em uma stack server-side funcional. O tagging server precisa existir, o container precisa ter clients e tags esperados, regras de consentimento devem estar alinhadas e cada destino downstream exige autenticação e teste de aceite próprios.

Se o site já injeta GTM pelo tema, CMP ou outro plugin, não adicione o mesmo container novamente no ClickTrail. Comece no preview, escolha um evento de teste, confirme o caminho da requisição e só então altere o adapter de Entrega ou o loader de produção.

Valide no site de destino

  • Registre quem atualmente carrega o container web do GTM.
  • Configure um único caminho de tagging server ou loader e teste no preview.
  • Valide consentimento, roteamento, seleção de client e duplicidade de eventos.
  • Teste autenticação do provedor separadamente do sucesso do preview do GTM.

Limite da evidência: O modo de compatibilidade sGTM e as configurações de preview estão presentes no código/readme; tagging server, container, consentimento e aceite de provedor não foram verificados em runtime.

Fontes e verificaçãoWordPress.org FAQClickTrail READMEIntegration evidence
O ClickTrail substitui GA4 ou Google Tag Manager?

Não. O ClickTrail preserva a atribuição no WordPress e pode enviar eventos ou payloads configurados; GA4 e GTM continuam sendo os consumidores de analytics e gerenciamento de tags.

Pense no ClickTrail como a camada de atribuição e conversão do WordPress. Ele mantém o contexto da campanha quando um formulário ou pedido é criado e pode publicar eventos no dataLayer. O GTM pode consumir esses eventos, enquanto o GA4 recebe as tags e parâmetros definidos pelo plano de mensuração.

A capacidade opcional de Entrega é outro caminho de transporte, não substituto de uma propriedade de report. Um adapter configurado não significa automaticamente que GA4, Google Ads, Meta ou outro provedor autenticou, aceitou, deduplicou ou reportou o payload.

Defina qual sistema é responsável por captura, nomes de eventos, consentimento e report antes de ativar uma tag GTM e um adapter de entrega para a mesma conversão. Use preview e um pedido ou formulário de teste para detectar eventos duplicados.

Valide no site de destino

  • Defina a fonte de verdade da atribuição e a fonte de verdade do report.
  • Mapeie campos do dataLayer para variáveis GTM e parâmetros GA4 realmente usados.
  • Escolha um caminho de entrega por conversão, salvo se a deduplicação estiver documentada.
  • Valide o evento no provedor final, não apenas o push no navegador.

Limite da evidência: A documentação pública descreve o ClickTrail como complementar ao GTM e GA4; report e aceite do provedor ainda exigem destino configurado e testado.

Fontes e verificaçãoWordPress.org FAQClickTrail README
Posso usar o ClickTrail sem entrega server-side?

Sim. Captura, formulários suportados, atribuição de pedidos WooCommerce e eventos do navegador podem ser usados sem habilitar a capacidade opcional de Entrega.

O primeiro rollout pode terminar no registro de conversão do WordPress. A Captura retém atribuição, formulários podem enriquecer envios suportados, WooCommerce pode armazenar contexto do pedido e eventos do navegador podem ir para o dataLayer sem adapter remoto.

Esse limite costuma ser mais seguro do que habilitar destino antes de existir endpoint, contrato de consentimento, autenticação e comportamento de retentativa definidos. Entrega só é útil quando há coletor, tagging server ou endpoint de anúncio com dono e verificação.

Deixe Entrega desligada no primeiro teste, confirme atribuição local e caminho de evento do navegador e depois adicione um destino por vez. Ao habilitar, inspecione requisição, resposta, fila e diagnósticos; URL salva não prova aceite do provedor.

Valide no site de destino

  • Comece com Captura e a integração de formulário ou WooCommerce usada.
  • Confirme o registro local antes de adicionar transporte remoto.
  • Adicione um destino com responsável, regra de consentimento, timeout e plano de retentativa.
  • Mantenha rollback que desabilite Entrega sem apagar a atribuição local.

Limite da evidência: O readme público descreve setup básico de formulário ou WooCommerce sem entrega server-side; comportamento de endpoint e aceite do provedor continuam sendo verificações de runtime.

Fontes e verificaçãoWordPress.org FAQClickTrail READMESecurity and privacy guide
Cluster 4

Consent mode e CMPs existentes

Use este cluster quando o site já tem um banner de consentimento ou quando você precisa testar a jornada com consentimento negado antes de confiar na atribuição.

O consent mode é obrigatório?

Não. Consent mode é uma função opcional do ClickTrail, mas não habilitá-la não responde sozinho às obrigações legais ou de consentimento do site.

O ClickTrail pode rodar uma captura first-party e um caminho de conversão básico sem a função Consent Mode. Quando habilitado, o plugin pode controlar atribuição e eventos conforme o comportamento e a fonte configurados.

A configuração não decide se o site precisa de consentimento. Isso depende de jurisdições, finalidades, destinos de dados, orientação jurídica e plataforma de gestão de consentimento. Um site pode desligar o modo do ClickTrail e ainda ter obrigações de outras tags, cookies ou destinos.

Teste o caminho negativo com a mesma atenção: abra uma sessão limpa, negue consentimento opcional, navegue, envie formulário ou pedido e depois conceda ou altere o consentimento quando o CMP permitir. Registre o que deve ficar ausente para não confundir atribuição vazia com UTM quebrada.

Valide no site de destino

  • Defina autoridade, finalidades e estado padrão do consentimento antes de configurar.
  • Teste concessão, recusa e alteração ou retirada em navegador limpo.
  • Confira captura, formulário ou pedido, eventos e Entrega separadamente.
  • Registre versões do CMP e ClickTrail usadas no teste de aceite.

Limite da evidência: Consent Mode é documentado como opcional e o código contém gates de consentimento; conformidade legal, correção do CMP e transições ao vivo não foram estabelecidas nesta revisão.

Fontes e verificaçãoWordPress.org FAQSecurity and privacy guide
Posso continuar usando minha plataforma de consentimento atual?

Sim. O ClickTrail documenta banner próprio, Cookiebot, OneTrust, Complianz, GTM e fonte customizada; use uma única fonte de verdade claramente definida no caminho testado.

Substituir um CMP que funciona não é requisito para usar o ClickTrail. A lista de fontes suportadas permite conectar o estado que o site já gerencia, incluindo Cookiebot, OneTrust, Complianz, GTM ou fonte customizada documentada.

O trabalho importante é mapear a passagem: qual evento ou cookie representa cada finalidade, qual é o estado padrão, quando concessão ou recusa dispara e como chega à captura, formulários, eventos e Entrega. Ter um conector disponível não prova que o banner real emite o sinal esperado.

Evite autoridades concorrentes. Se CMP, GTM e ClickTrail tomarem decisões independentes, uma camada pode liberar evento no navegador enquanto outra bloqueia entrega remota. Escolha um responsável, teste transições e guarde evidência do banner e versão usados.

Valide no site de destino

  • Documente CMP atual, categorias, cookies e contrato de eventos de consentimento.
  • Selecione uma fonte de verdade no ClickTrail e remova duplicidades acidentais.
  • Teste carregamento, concessão, recusa e retirada ou alteração quando suportado.
  • Confirme que tags GTM e Entrega downstream seguem o mesmo estado.

Limite da evidência: O readme público lista as fontes de consentimento suportadas; contrato de eventos do CMP, propagação de estado e comportamento downstream exigem validação no site de destino.

Fontes e verificaçãoWordPress.org FAQSecurity and privacy guide