Tracking and consent updates
Consent Mode, enhanced conversions and server-side tracking are not checkbox projects. They only matter when the implementation preserves useful conversion truth.
Published: 31 May 2026 | Updated: 31 May 2026
The mistake
The common mistake is treating tracking updates as tag deployment work. Add a CMP, add a few consent signals, tick enhanced conversions, then hope the reporting recovers.
That is backwards. Start with the business journey and work down to the tags.
The useful order
- Map the conversion journey from ad click to commercial outcome.
- Identify which identifiers can be captured lawfully and reliably.
- Decide which events should be primary conversion goals.
- Set consent behaviour before tags fire.
- Implement enhanced conversions where eligible first-party data exists.
- Use offline imports when the valuable outcome happens after the website visit.
- QA the result in browser tools, platform diagnostics and backend logs.
What should be checked
- Consent state is set before Google tags need it.
- Enhanced conversion fields are normalised and hashed as required.
- Click IDs survive form submission and CRM routing.
- Qualified leads can be uploaded later with stable identifiers.
- Rejected leads, duplicate leads and refunds can be corrected.
- Reporting uses business outcomes, not just browser-visible events.
What server-side tracking can and cannot fix
Server-side tracking can improve control, routing and data quality. It does not remove the need for consent design, backend capture, lead state and conversion governance.
If the valuable event happens days later in a CRM, the answer is usually an offline conversion pipeline, not another web tag.