Server-side tracking for Drupal
Drupal gives you full PHP and a well-defined event system, so the money event belongs on the Commerce order state transition. That's immune to the caching layers, which is the main reason browser-side Drupal tracking is unreliable.
Free30 minutesNo obligation
Drupal server-side · what breaks
What goes wrong on Drupal
- 01
Aggressive caching
Page cache, dynamic page cache and BigPipe can each serve stale values.
- 02
Conversions come from Commerce or Webform
Not from Drupal itself.
- 03
Module overlap
Two modules sending the same event.
- 04
Complex configuration
Drupal's flexibility means undocumented setups are common.
Drupal server-side · the fix
What changes — Drupal server-side
Money events from order state transitions
Immune to caching.
Form submissions bound to Webform hooks
Not to navigation.
Caching accounted for
Rather than blamed on the tag.
Drupal server-side · architecture
What Drupal exposes to a server container
Server-side is the clean way around Drupal's caching.
- 1
Purchase from the Commerce order state transition
Cache-immune by construction.
- 2
Form events from Webform hooks
Server-side, not DOM-bound.
- 3
Order number as the deduplication key
Commerce's own reference.
- 4
Customer data from the order
Normalized then hashed.
- 5
Refund state transitions as reversals
Wired explicitly.
Drupal server-side · diagnose
Where Drupal 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
Compare two orders' data layer values
Identical means cache.
- 02
Identify which caching layers are active
Page, dynamic page, BigPipe.
- 03
List tracking-adjacent modules
The Drupal inventory step.
- 04
Check whether conversions come from Commerce or Webform
Different hooks entirely.
- 05
Reconcile against Commerce orders
For a closed week.
Drupal server-side · prove
The QA evidence — Drupal server-side
Run on Drupal specifically, on a live conversion rather than in preview mode.
Source of truth
your Drupal Commerce order records
- Two different orders confirmed carrying different values.
- Order state transition confirmed firing once per order.
- Webform submissions confirmed bound to the hook, not a navigation.
- Purchase count reconciled against Commerce for a closed week.
- A refund state transition tested and confirmed reversing.
- Reconciled over a fully closed window, matched per record rather than on totals.
- Re-checked 30 days later, and after any platform update.
Drupal server-side · free audit
What we check in the free audit
- Compare two orders' data layer values
- Identify which caching layers are active
- List tracking-adjacent modules
- Check whether conversions come from Commerce or Webform
- Reconcile against Commerce orders
Checked against
your Drupal Commerce order records
Free30 minutesNo obligation
Drupal server-side · when not to buy
When you don't need this on Drupal
Worth reading before you buy anything, from us or anyone.
- If two consecutive orders produce different, correct payloads and your counts reconcile, the caching problem isn't affecting you.
- This is standard Drupal development your team can do — the event system is well documented.
- If you're a content-only Drupal site with no Commerce, this is really a Webform tracking question and simpler than the page suggests.
- Reconcile before assuming. Drupal setups are often more correct than they look.
Drupal server-side · what we deliver
What the server-side build gives you on Drupal
Container on your own subdomain
Your domain, your certificate, hosting in an account you control.
Money events from Drupal Commerce orders
The Commerce order state transition, which fires from the order and is unaffected by Drupal's caching layers.
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 Drupal Commerce order 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
Drupal server-side questions, answered
It routes around the caching layers entirely, which is the main source of unreliable browser-side data here.
The Commerce order state transition.
The Commerce order number.
Webform hooks, server-side. Same principle, different hook.
Free · 30 min
Move Drupal events off the browser
WhatsAppFree30 minutesNo obligation
