Web & App Analytics

It depends on how much signal you are losing and what you do with it. If a meaningful share of your paid media budget is optimised against conversions that browsers are dropping, server-side collection usually pays for itself. If you are a low-volume B2B site with long sales cycles, the case is weaker. We quantify the loss during the audit so the decision is made on your numbers rather than on principle.

We fix it wherever fixing is cheaper and safer, which is most of the time. A rebuild is only warranted when the property structure itself is wrong — for example when three brands share one property with no clean way to separate them, or when historical data is already unusable. The audit tells us which situation you are in.

For a single-brand site with a reasonably clean Launch implementation, six to ten weeks including parallel-run validation. Multi-brand estates, heavy use of processing rules, or complex identity requirements push it further. We always parallel-run before decommissioning AppMeasurement so you can prove the numbers match.

Not if the data layer is specified and owned. We give engineering a data layer contract, add tracking checks to your release process, and set up monitoring that alerts when a key event stops firing. Drift is a process problem more than a technical one.

That is the normal arrangement. Most of our work is alongside an internal team — we take the implementation and architecture load, and hand over documentation and enablement so the team can run it afterwards.

Yes, within what consent allows. We implement Consent Mode v2 and CMP-aware firing rules so tags respect user choice, and we use consent-appropriate modelling and server-side collection to preserve as much legitimate signal as possible. That work is covered in detail on our Consent, Privacy & Data Governance page.