Most people think of their analytics as either working or broken. The truth is stranger. It doesn't break. It decays. The numbers you trusted last month are a little less true this month, and a little less true the month after that, and nothing on your screen tells you it's happening.
You can spot the symptoms once you know to look. Customers who've visited before start showing up as brand-new strangers. More and more of your traffic gets filed under "Direct," as if everyone suddenly typed your address from memory. The ads you pay for seem to stop producing results a few days after the click. None of this is a glitch. It's the slow erosion of the data underneath, and it has an exact cause and an exact moment when it begins.
Where the decay begins
Here's the moment. Almost everything your analytics and ad tools rely on is stored in a small cookie that's created by JavaScript in the visitor's browser. Safari and Firefox now delete those cookies after seven days. And when someone arrives by clicking an ad, the clock is even shorter — just twenty-four hours. So the decay isn't gradual wear. It's a hard cliff. Up to day seven your data is mostly fine; after it, returning visitors quietly turn back into strangers and the trail goes cold. Multiply that across all the people who don't come back within a week, and across every ad click that doesn't convert within a day, and you get a measurement that's wrong in a steady, invisible way.
This wasn't done to hurt you
This wasn't done to hurt you. The browsers were aiming at something else entirely: the kind of tracking that follows a person from one website to the next, building a profile as they go — the reason you glance at a pair of shoes once and then see them advertised everywhere for a week. Cutting that down is a fair goal, and most people are glad someone finally did it.
The problem is that your analytics got caught in the same net. The cookie that lets an ad network follow you across the whole internet and the cookie that lets one website remember you've been there before are the same kind of thing, made the same way. Your Google Analytics cookie never leaves your site. It doesn't follow anyone anywhere. It just helps your own site recognise a returning visitor. But it's built on the same technology as the tracking the browsers are hunting, so when they cut that technology short, your harmless cookie dies right alongside the one they meant to kill.
You'd think the browsers could simply tell the two apart — spare the honest analytics, kill the creepy tracking. They could. They don't, because any rule like that gets gamed. The moment "first-party analytics is allowed" becomes the rule, trackers disguise themselves as first-party analytics to slip through it. That already happened, and the browsers had to scramble to shut it down. So they stopped trying to sort the good from the bad and just cut the whole category, because every careful exception turns into a back door. Your analytics is collateral damage — not by accident, but because the browser chose a blunt tool over a precise one it couldn't keep safe.
The fix the market found is a monster
So measurement starts decaying, and the market goes looking for a fix. The fix it found is a monster.
The known way to stop the decay is to set those cookies from your own server instead of from the browser. When a cookie comes from your server, the browser trusts it and keeps it for its full life. That part is genuinely simple. But the standard way to do it — a setup called server-side Google Tag Manager — is anything but. It wants a separate, always-on server. A custom subdomain. An SSL certificate. A monthly bill. A diagram with a dozen boxes in it. People stand up an entire piece of cloud infrastructure to accomplish what is, underneath, one small instruction to the browser.
It's worth asking why something so heavy exists for something so light. The answer is that the monster isn't really solving a technical problem. It's solving a distribution one. Server-side Google Tag Manager is built for people who don't have a server of their own to work with, so the whole apparatus — the extra box, the subdomain, the subscription — is there to give them one. If you don't already have a backend, you need the monster. But a WordPress site already has a backend. It runs your own code on every visit, on a server you already pay for. For a site like that, the monster is solving a problem you don't have, at the price of a second server you don't need.
The simple way: the server you already have
Which means the cookie can be set the simple way: from the server you already have, with one line of instruction, at the moment the page loads. No second server. No subdomain. No subscription. Just the small instruction, in the place that was always capable of giving it.
That's exactly what Zen Cookie Keeper does. It's a free, open-source WordPress plugin that performs that server-side cookie write from inside the WordPress site you already run.
It keeps your cookies alive in three ways. For ad-click cookies, like Google Ads and Meta click IDs, it rebuilds them on your server straight from the click information already sitting in the visitor's landing-page link — so the brutal twenty-four-hour ad-click limit never gets a chance to bite. For cookies whose value is created in the browser, like the Google Analytics visitor ID, it reads the value the tracking tag already made and re-sets it from your server. And whenever the browser has dropped a cookie, it simply puts it back, for as long as you've chosen to keep it. A single secure anchor cookie holds it all together; it carries no marketing data of its own and is never touched by JavaScript, which is what keeps it safe from the very limits we've been describing.
It also puts consent first, which matters, because none of this is about getting around anyone's wishes. Nothing is set until the visitor agrees. Analytics and advertising are handled separately, and the plugin reads consent straight from your existing cookie banner, so it works with Cookiebot, Complianz, Borlabs and the rest, with enforcement on by default. Your data never leaves your site — the plugin makes no outside connections at all. And it's honest about what it won't do: it doesn't send your data to ad platforms, it doesn't hide your analytics from ad blockers, and it doesn't claim to fix bot traffic. It does one job — keep your first-party cookies alive — on your own domain, on your own terms. It's free, under the GPL, because the point is to put the simple fix back within reach of the people who were quietly losing their data without ever being told.
Your analytics doesn't have to keep decaying. The browsers drew a blunt line, and your honest measurement fell on the wrong side of it. Putting it back — on your own site, with your visitor's consent — turns out to be the simple part. It was only ever made to look complicated.
Zen Cookie Keeper is built and maintained by Zen Republic Agency. If you'd like help getting your analytics and ad measurement back to full accuracy, reach out for a free audit.
