Server-side tracking for WordPress
WordPress is PHP you control, so a server container has a clean source: the form plugin's submission hook, or the CRM the lead lands in. That removes the dependency on a browser-side event surviving a page builder, a caching plugin and an optimisation plugin that defers JavaScript.
Free30 minutesNo obligation
WordPress server-side · what breaks
What goes wrong on WordPress
- 01
Forms submitting over AJAX
No navigation, so a thank-you-page trigger can never fire.
- 02
Caching plugins serving stale pages
Including a stale data layer, which looks exactly like a broken tag.
- 03
Optimisation plugins deferring the container
So it loads after the event it was supposed to catch.
- 04
Several pixels from several sources
Theme, plugin, builder field, pasted widget.
WordPress server-side · the fix
What changes — WordPress server-side
Events bound to the plugin's real success hook
Not to a navigation that doesn't happen.
One tracking path
After a full inventory of what's installed.
Caching and deferral accounted for
Rather than blamed on the tag.
WordPress server-side · architecture
What WordPress exposes to a server container
The value on WordPress is escaping the plugin lottery, not just cookie durability.
- 1
Events from the form plugin's server hook
PHP-side, so caching and JavaScript deferral are irrelevant.
- 2
A lead ID generated server-side
Written to both the event and the CRM record, so the two can be joined.
- 3
Click IDs from hidden fields
Captured on landing, submitted with the form, available to PHP.
- 4
Container on your own subdomain
Unaffected by whatever the optimisation plugin does to scripts.
- 5
Qualified outcomes from the CRM
The event that actually matters for bidding.
WordPress server-side · diagnose
Where WordPress tracking breaks, in diagnostic order
Each check rules out a class of cause, so by the last one there is usually a single explanation standing.
- 01
Submit a form and watch the URL
No change means a page-view trigger can never fire.
- 02
List every plugin with a tracking field
Including SEO, security and builder plugins.
- 03
Disable optimisation temporarily and retest
Deferred JavaScript is a common invisible cause.
- 04
Check whether the confirmation page is cached
A cached page can carry another visitor's values.
- 05
Reconcile submissions against CRM records
For a closed month.
WordPress server-side · prove
The QA evidence — WordPress server-side
Run on WordPress specifically, on a live conversion rather than in preview mode.
Source of truth
your CRM or form submission records
- A live form submission captured with the payload read, not previewed.
- Trigger confirmed firing on the form's real success state.
- Only one pixel path confirmed active after inventory.
- Click identifiers confirmed present in the submitted data.
- Submissions reconciled against CRM records for a closed month.
- Reconciled over a fully closed window, matched per record rather than on totals.
- Re-checked 30 days later, and after any platform update.
WordPress server-side · free audit
What we check in the free audit
- Submit a form and watch the URL
- List every plugin with a tracking field
- Disable optimisation temporarily and retest
- Check whether the confirmation page is cached
- Reconcile submissions against CRM records
Checked against
your CRM or form submission records
Free30 minutesNo obligation
WordPress server-side · when not to buy
When you don't need this on WordPress
Worth reading before you buy anything, from us or anyone.
- If your form conversions fire reliably and your counts reconcile against your CRM, the WordPress plugin lottery hasn't bitten you and there's nothing here to buy.
- Most of this is inventory work you can do yourself in an afternoon: list the plugins, submit a test form, watch what fires.
- If you run WooCommerce, the ecommerce side has its own page and different failure modes — this one is about WordPress as a lead-generation site.
- Server-side matters most here when caching or optimisation plugins are interfering. If neither is installed, browser-side may be perfectly adequate.
WordPress server-side · what we deliver
What the server-side build gives you on WordPress
Container on your own subdomain
Your domain, your certificate, hosting in an account you control.
Money events from your own lead records
The form plugin's server-side submission hook, which fires regardless of caching or JavaScript deferral.
Deduplicated at every destination
On a shared event ID, verified before any existing path is removed.
Consent enforced before dispatch
A denied destination receives nothing, verified by capture rather than configuration.
Written guarantee
95%+ tracking accuracy
Measured against your CRM or form submission records. Miss it and we keep working at no cost.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Repairs and verifies the browser-side setup you already have, on a live conversion. Honest about its ceiling on this platform.
- Root cause fixed, not worked around
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, so the browser can no longer lose them.
- First-party server container on your own subdomain
- Money events from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, with monitoring so the next break surfaces in days.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring on every destination
FAQ
WordPress server-side questions, answered
It escapes the plugin lottery. A PHP submission hook fires regardless of caching, deferral or whatever the optimisation plugin did to your scripts.
Whichever your form plugin exposes — they all have one, and they all differ. That's why the inventory comes first.
For the PHP hook, ideally. It's straightforward WordPress development and any competent WP developer can do it.
No — that's an inventory problem. Remove the extra paths first, then build.
Free · 30 min
Move WordPress events off the browser
WhatsAppFree30 minutesNo obligation
