Platform
400-day server-side cookie
A server-side, signed first-party cookie that recognises a returning visitor for up to 400 days, even on browsers that otherwise cut memory to a week, with their first ad click still attached. It is the backbone of everything else DataCops does: it is what ties every event a person triggers into one journey, so a sale weeks later still gets credited to the ad that earned it.
What it is
The 400-day server-side cookie is how DataCops remembers a returning visitor for up to 400 days. The memory is set by your server, not by browser storage, so it is not wiped after seven days the way normal browser storage is. Every visitor is given one durable identity, signed for your site only, and every event they ever trigger is joined to it. Bots are never given one.Think of it as a stable name tag that DataCops assigns to each real visitor and quietly keeps alive. Everything else in the platform, the fraud check, the ad-click attribution, the events you send to Meta or Google, hangs off that one durable identity. Without it, every visit is a disconnected stranger. With it, a person is one person, across sessions, across devices, across the weeks between their first ad click and the day they finally buy.
What the 400-day cookie makes possible
This is the single capability the rest of DataCops is built on. A durable identity that survives for up to 400 days is what turns a pile of disconnected browser hits into a real customer journey, and it unlocks three things nothing built on browser storage can do:
- Attribution that survives the gap between click and purchase. Most sales do not happen on the first visit. Someone clicks your ad today, thinks about it, and buys two weeks later. Browser memory is long gone by then, so that sale looks like it came from nobody. The durable identity still knows it is the same person, and still holds the ad click from that first visit, so the sale is credited to the ad that actually earned it.
- One customer, not many strangers. The same shopper browsing on their phone, then buying on their laptop, then returning next month, is stitched into one identity instead of counted as three anonymous visitors. Your reporting, your audiences, and your frequency capping all work on real people.
- Clean data that stays clean over time. Because the identity is created and owned on the server and never handed to a bot, the history attached to it is real. When a conversion fires, it carries a trustworthy past, not a guess reconstructed from whatever the browser happened to keep.
That is why this is the headline capability, not a footnote. A no-code server-side tag manager is only as good as its memory, and DataCops gives it a 400-day one.
Why browser memory keeps breaking
Most tools remember people using storage the browser controls. Safari and iOS now erase that after about seven days, and after roughly a day when the visit came from an ad click, under a set of rules called ITP. Brave and ad blockers cut it further. So a shopper who comes back two weeks later looks brand new: the ad that first brought them gets no credit, their abandoned cart is forgotten, and you can end up paying to acquire the same customer twice.
The problem is not that memory is impossible, it is that memory kept in the browser is short-lived by design now. DataCops solves it by moving the memory to where the browser cannot wipe it: your server.
How DataCops makes it happen
DataCops sets the identity as a signed cookie from your own server, and keeps a copy in three places that repair one another. Because the cookie is written server-side and signed, the browser treats it as first-party data from your own site, not as third-party tracking it should cut short.The identity is kept in three stores, and they heal each other:
- A signed cookie set by your server. This is the primary store. A server-set first-party cookie is not subject to the same seven-day wipe a browser applies to storage it manages itself.
- The browser's own storage. A strong fallback on Chrome and Firefox, where storage lives longer.
- DataCops' own server record. The final source of truth. The id is created and owned on the server, so even if both browser stores are cleared, the identity can be re-established.
On each visit, whichever store is still alive puts the id back into the ones that were wiped, and an active visitor's cookie is refreshed every visit, so the 400-day clock only starts running down after a long stretch with no visits. Identity only truly resets if all three are lost at once. The id is signed with a cryptographic key so it cannot be forged or tampered with, and a visitor that fails the fraud check is never issued one, so the durable identity only ever belongs to a real person.
The backbone of the server-side tag manager
A server-side tag manager collects events on the server and forwards them to your ad platforms. But a tag manager on its own has no memory: it sees a stream of individual hits and forwards them one by one. If it cannot tell that today's purchase and last week's ad click belong to the same person, it forwards a purchase with nothing useful attached, and the ad platform cannot match it.
The durable identity is what gives the tag manager that memory. Every event that arrives is looked up against the 400-day identity and joined to the right person before anything is forwarded. So the server-side tag manager is not just relaying hits, it is assembling each event onto a real, continuous customer record. That is the difference between a server-side setup that technically works and one that actually recovers and attributes your sales.
Every event carries its context
Because every event is stamped with the durable identity the moment it is captured, no event is ever an orphan. A page view, an add to cart, a checkout, a signup, a purchase, each one is tied to the same person and inherits everything already known about them:
- Their first ad click. The Meta, Google, TikTok, or LinkedIn click ID from the visit that first brought them, carried forward onto every later event, so even a conversion with no click of its own goes out attributed.
- Their journey. The earlier sessions, pages, and actions that led here, joined into one timeline instead of scattered across anonymous visits.
- Their verified details. Once a person identifies themselves, by signing up or checking out, that is attached to the same identity, so a later anonymous visit is still recognised as them.
This is what lets a single event mean something. When a purchase fires, it is not a bare hit, it is a purchase by a known person with a known first click and a known history, ready to be delivered to your ad platforms and matched with confidence.
How we know who it is
On any visit, DataCops resolves identity in a fixed order, and one id always wins and is written back into all three stores, so there is never any drift:
- The signed cookie set by your server.
- The value the browser sent from its own storage.
- A match on the ad click captured at the edge.
- The email, once it is known.
- If none of those exist, a fresh signed id is created for a new visitor.
Yours only, never a supercookie
The id is signed with a cryptographic key that is unique to your site. So the same person on your site and on another DataCops merchant's site gets two completely unrelated ids that cannot be joined, not by policy but because the math makes it impossible. DataCops helps each merchant recognise their own returning customers, and never tracks people across the web.
You choose how long
Returning-visitor memory is a setting. You can turn it off, or set it to 30, 90, 180, or 400 days. 400 is the default and the longest a browser allows, and the longer windows are available on higher plans. How long it actually lasts can vary by browser, since each browser caps storage differently, which is why the honest claim is up to 400 days rather than a flat guarantee everywhere.