The short answer
A meaningful share of visitors block browser tags, and browsers increasingly limit them regardless. Sending the conversion from your server, where you already know the enquiry happened, recovers most of that.
It changes where the event comes from, not whether you need consent to send it.
What gets lost in the browser
- Ad blockers removing the tag entirely
- Browser restrictions on cross-site tracking
- Consent tooling correctly withholding tags
- Scripts failing on slow connections before they fire
- Users leaving before the tag loads
The consent one is worth stating plainly. That data is not lost to a technical fault, and recovering it server-side without consent would not be a fix.
What server-side recovers
| Event | Browser tag | Server side |
|---|---|---|
| Form submission | Often blocked | Reliable, you own the event |
| Phone enquiry | Invisible | Capturable if you record it |
| Qualified lead | Not visible at all | Yes, later, when you know |
| Closed sale | No | Yes, which is the valuable one |
The bottom two rows are the real prize. Sending back which leads actually qualified or closed lets the platform optimise towards revenue rather than towards form fills.
Avoid double counting
Running browser and server events together without deduplication counts conversions twice, which inflates results and misleads optimisation.
Send a shared event identifier from both paths so the platform can match them. This is standard, documented by the platforms, and routinely omitted.
The obligations do not change
- Consent requirements apply to the data, not to the transport.
- Your privacy notice should describe what you send and to whom.
- Honour a refusal server-side as you would in the browser.
- Be careful what identifiers you send; more is not better.
- Keep a record of what you send and why.
Server-side measurement is sometimes presented as a way around consent. It is not, and treating it that way creates a compliance problem rather than a measurement improvement.