Attribution usually breaks somewhere between the ad click and the conversion. ClickTrail keeps campaign context alive through cached pages, dynamic forms, cross-domain journeys, repeat visits, and configured consent rules.
ClickTrail keeps the source of the visit, not a profile of the visitor — first-party capture with consent controls. It is a WordPress capture-and-controlled-delivery layer, not an attribution dashboard, hosting platform, lead manager, or ad optimizer. The current security-status blockers and verification boundary are documented in Security and Privacy.
Read in English
Leia em Portugues (Brasil)
Contributor Guide
Guia de Contribuicao
Technical Docs
WordPress Readme
Integration evidence: Source presence alone does not prove production provider support. Current form, WooCommerce, GTM, and delivery status lives in the integration reference and machine-readable ledger.
- Keeps campaign context available for WooCommerce orders when the configured path captures it.
- Persists UTMs and click IDs across the configured attribution journey.
- Provides client-side fallback paths for cached or dynamic forms.
- Provides approved cross-domain continuity paths with documented limitations.
- Consent controls and optional server-side delivery live in one plugin; end-to-end consent/revocation behavior remains under the release gates.
ClickTrail is designed to keep first-touch and last-touch context alive until the point where WordPress actually needs it: WooCommerce orders, form submissions, browser events, and optional downstream delivery.
- Capture: first-touch and last-touch attribution, referrers, classic and extended UTMs, click IDs, browser identifiers, retention, and cross-domain continuity.
- WooCommerce: order attribution, enriched purchase payloads, thank-you page purchase pushes, optional list-view and cart storefront events, richer Woo
dataLayersupport, and post-purchase milestones. - Forms: automatic hidden-field enrichment for Contact Form 7 and Fluent Forms, compatible hidden-field population for Gravity Forms and WPForms, cached-page fallback, dynamic-content support, and WhatsApp continuity.
- Events: browser collection,
dataLayerpushes, sGTM compatibility mode, webhook intake, lifecycle updates, and optional Woo storefront signals. - Delivery: optional server-side transport, retries, diagnostics, conflict scanning, backup/restore, and a consent gate whose end-to-end edge cases are documented for the next release.
The release badge above tracks the current GitHub release. See changelog.txt for the full history and readme.txt for the public WordPress.org stable release.
- GitHub visitors: start with README.en.md or README.pt-BR.md.
- Contributors and reviewers: use CONTRIBUTING.md or CONTRIBUTING.pt-BR.md.
- Engineers and agents: use docs/README.md and AGENTS.md.
- Implementation teams: start with use cases and the tutorial index.
- docs/README.md: engineering index by task and subsystem
- docs/guides/IMPLEMENTATION-PLAYBOOK.md: practical rollout guide for lead-gen, WooCommerce, cross-domain, consent-aware, and server-side setups
- docs/architecture/PLUGIN-OVERVIEW.md: runtime architecture and module map
- docs/reference/INTEGRATIONS.md: evidence-labelled forms, commerce, consent, webhook, GTM, platform, and delivery paths
- docs/reference/integration-capabilities.json: machine-readable integration status and evidence ledger
- docs/guides/RELEASE-PHASING-AND-INTEGRATION-DOCS.md: separately gated release plan
- docs/guides/COMPETITIVE-POSITIONING-AND-ACQUISITION-ROADMAP-2026-08-22.md: proposition, copy, and client-acquisition roadmap
- docs/guides/SETTINGS-AND-ADMIN.md: current admin IA and option mapping
- changelog.txt: full plain-English release history aligned with the WordPress readme
- .github/PULL_REQUEST_TEMPLATE.md: PR checklist for repo changes
- Read CONTRIBUTING.md.
- Use docs/README.md to find the canonical doc for the area you will change.
- Keep product docs, technical docs, and changelog entries aligned with the implementation.
- WordPress 6.5+
- PHP 8.1+
GPL-2.0-or-later. See LICENSE.