Case study
Server-side tracking, migrated without breaking the numbers
Asee Boutique is a financial planning practice, led by Haim Natan, serving clients across Israel. It is an expensive, considered category: clicks cost a lot and decisions take weeks, so the measurement has to be right. This is how we moved the account to server-side tracking without the silent double counting that quietly ruins most migrations.
What the account actually looked like
- 2
- directions verified that new events record, and retired ones genuinely stopped
- 0
- double counting the silent failure that ruins most migrations
Why move to server-side at all
Conventional tracking asks the visitor's browser to report what happened. Browsers are increasingly unwilling: ad blockers, privacy settings and Safari's restrictions all interrupt those reports, and the gap is not evenly distributed, so it distorts as well as reduces. Server-side tracking moves the reporting to infrastructure you control. The event is recorded once, reliably, and forwarded from there, which means more complete data and more control over what leaves your site.
Silent double counting
In a migration the old browser tags and the new server-side path are briefly live together. Switch the new one on without properly retiring the old one and every conversion gets reported twice. Nothing visibly breaks. The dashboard simply looks better than reality, the bidding algorithm is trained on inflated data, and the error can survive for months because the failure mode is flattering rather than alarming. We treat this as the single biggest risk in any tracking migration.
Migrate, then verify twice
We snapshot the existing setup, stand up the server-side path alongside it, confirm the new events arrive correctly, and then pause the client-side tags rather than leaving them quietly running. Verification runs in both directions: positively, that the events we expect are being recorded, and negatively, that the ones we retired have genuinely stopped. Our own portfolio-wide tracking audit later confirmed this account as a clean migration, with client-side tags paused and no duplication.
Each channel teaches the other
Paid search shows which language actually produces enquiries, and that shapes what is worth writing organically. Watching Search Console at term level, one core positioning phrase moved from 18 impressions at an average position near 29 to 354 impressions at around position 18 within a month. That is not a win in itself, but it is a signal: real demand was forming around a question the site answered only in passing, which made it worth a dedicated explainer rather than another service page.
SEO and AI searchHow we judge it
By whether the enquiries are people who genuinely want financial planning, and whether the numbers we optimise against are numbers we can defend. We do not publish clients' commercial performance data, and we would treat yours the same way. What is fair to say is that this is an ongoing, weekly-managed engagement covering paid search, tracking infrastructure, and organic content.
Frequently asked questions
What is server-side tracking, in plain terms?
Normally your website asks the visitor's browser to report what happened to Google, Meta and everyone else. Browsers increasingly refuse: ad blockers, privacy settings, and Safari's restrictions all interrupt those reports. Server-side tracking moves the reporting to a server you control, so the event is recorded once, reliably, and sent onward from there. You get more complete data and more control over what leaves your site.
What is the main risk when migrating to server-side?
Silent double counting. During a migration both the old browser tags and the new server-side ones are briefly live, and if you switch on the new path without properly pausing the old one, every conversion is reported twice. Nothing breaks visibly. The numbers simply look better, the bidding algorithm is trained on fiction, and it can take months before anyone realises the reports were wrong.
How do you avoid that?
By treating it as a controlled migration rather than a switch. Snapshot the existing setup, stand up the server-side path, verify the new events are arriving correctly, pause the old client-side tags rather than leaving them running, and then verify twice: positively, that the events you expect are recorded, and negatively, that the events you retired have actually stopped. Our own audit of this account confirmed the migration was clean, with the client-side tags paused and no duplication.
Why does this matter for a financial planner specifically?
Because the traffic is expensive and considered. In this category a single click can cost a great deal and the buying decision takes weeks, so a small proportion of misreported conversions distorts the picture badly. When each enquiry is worth a lot, you need to know precisely which ones were real.
Do you do SEO for this client as well as ads?
Yes, and they inform each other. The paid data shows which language actually converts, which then shapes the organic content. We track term-level movement in Search Console: one core positioning term went from 18 impressions at an average position around 29 to 354 impressions at around position 18 within a month, which told us the topic was worth a dedicated explainer rather than another service page.
Thinking about server-side tracking?
It is worth doing, and worth doing carefully. We will look at your current setup, tell you whether server-side would actually help you, and if it would, migrate it without breaking the numbers you already rely on.