Google spent six years threatening to kill the third-party cookie. In April 2025 it quit. Meanwhile most companies are killing their own first-party data by accident.
This is Post 3 of a three-part series on data decay. Post 1 made the case that your customer data is rotting right now. Post 2 showed the operational fix. This final post is more uncomfortable: half the decay is self-inflicted.
Your governance rules. Your capture forms. Your cookie settings. Your identity architecture. Each one is a design choice. And many of those choices throw away data that was yours to keep.
Capture data that does not decay
A customer tells you they are 34. Next year they are 35, and that field is wrong. You captured a depreciating fact instead of a durable one.
Store date of birth, not age. Store date of signup, not “tenure.” Store the timestamp of the event, not just the computed value.
The same logic applies everywhere. Median US job tenure is 3.9 years (Bureau of Labor Statistics). So “job title” captured without a date becomes stale within four years. But “VP Marketing as of June 2026” stays useful indefinitely. It tells you something even after they change roles.
The rule: capture the durable version of every fact. If a field can go stale by definition, store the version that stays true.
Timestamp everything
You cannot manage decay you do not measure. If a record has no “captured at” or “last confirmed” field, you have no way to know whether it was fresh yesterday or five years ago.
Every field that matters should carry two dates: when it was first captured, and when it was last validated. A phone number captured in 2019 and never confirmed since is not the same quality as one verified last month.
This is cheap to implement. It costs one extra column. But without it, your entire database is one undifferentiated mass of “probably fine.”
Stop over-governing your cookies
Here is where companies hurt themselves most visibly.
A 30-day first-party cookie is lawful in most jurisdictions with appropriate consent. PDPA in Singapore does not mandate a specific cookie duration. GDPR in the EU/UK does not either. The ICO’s guidance permits cookies “for as long as they are needed” for their stated purpose.
Yet many companies default to a 7-day window. Why? Because someone in legal or IT saw Apple’s ITP limit and assumed it was a regulation. It is not. It is a browser vendor’s technical choice.
When you force a 7-day expiry on a first-party cookie that could lawfully persist for 30 days, you discard 23 days of signal. You lose the ability to attribute a conversion that happens on day 12. You lose returning-visitor recognition. You lose the data that ties a second visit to a first.
None of this is the regulator’s fault. It is a design choice you made, and you can reverse it.
This is not legal advice. Verify retention windows and consent rules against your jurisdiction. PDPA in Singapore, GDPR in the EU/UK.
The cookie reality: what actually happened
Here is the timeline that most teams missed.
Google announced it would kill third-party cookies in Chrome. The industry panicked. Companies invested millions in “cookieless futures.” Then in July 2024, Google reversed course. In April 2025, it confirmed: third-party cookies stay in Chrome.
But that reversal did not fix the real problem. Safari blocks third-party cookies by default via ITP. Firefox does the same. Together they represent roughly 30% of users who are already cookieless (Statista, 2024). For those users, third-party tracking has been dead for years.
The lesson was always the same: build on first-party data. Own the relationship. Set your own cookies.
But here is the trap within the trap. Safari’s ITP also caps JavaScript-set first-party cookies at approximately 7 days. If your analytics or identity cookie is set via JavaScript (as most tag managers do), Safari users lose their identity weekly. The fix: set cookies server-side via HTTP response headers. Server-set first-party cookies are not subject to the ITP cap.
This is not a workaround. It is how cookies were designed to work. Client-side cookie setting was always the shortcut. The shortcut now has a cost.
Resolve identity early
You have a phone number. You have an email address. They belong to the same person. But they sit in two different systems, never linked.
That is two half-value identities. Neither is complete enough to personalize well. Neither triggers the right campaign. The person gets duplicate communications, or worse, contradictory ones.
Identity resolution is not a nice-to-have for later. It is a capture-time decision. When someone gives you a phone number on a call and an email on a form, link them at the point of capture. Do not store them as separate records and hope a quarterly deduplication run catches it.
The cost of late resolution compounds. Every campaign that runs against fragmented identities is either wasted (sent to a duplicate) or wrong (missing context that exists in the other record).
Plan the campaign before you collect
This was the thesis of Post 1 in this series, but it bears repeating here because it is the root cause of most over-collection.
Companies capture data because they might need it. Then governance tightens. Retention windows shrink. And the field expires before anyone builds the campaign that would have used it.
Flip the sequence. Plan the campaign. Define what data it needs. Capture exactly that. Now you have a reason to retain it, a consent basis that holds up, and a use case that fires before the data decays.
Data without a planned use is not an asset. It is a liability with a countdown.
B2B special: self-reported attribution
If you sell to businesses, there is one field most companies forget to collect, and it costs nothing.
“How did you hear about us?”
A free-text field on every form. Not a dropdown (those constrain the answer). Not optional (you will get 60% response rates on a required field placed after email).
This is the only reliable attribution for dark social: the podcast mention, the Slack recommendation, the conference conversation. No analytics tool can track those. Only the buyer knows. Ask them.
The data does not decay because it captures a moment in time. It tells you where your pipeline actually comes from, not where your last click came from.
The governance inversion
Most governance frameworks ask: “What is the minimum we are allowed to keep?”
That is the wrong question. The right question: “What is the maximum we are allowed to keep, given proper consent and a stated purpose?”
You are not being responsible by throwing data away early. You are being wasteful. Responsibility means collecting with purpose, retaining with consent, and using what you keep.
Do not be stricter than the law requires. Be as smart as the law allows.
This is the close
This is the last post in the series. If you read all three, you now know more about your data’s shelf life than most companies ever learn. The question is whether you will act on it before it decays.
Every issue in this post is reversible. DOB instead of age is a form change. Server-side cookies are a one-sprint migration. Identity linking at capture is a workflow decision. None requires a new platform. None requires board approval.
The hard part is admitting you have been doing it to yourself.
Book a working session. We will find where your own rules are throwing data away, and fix the ones that cost you the most.
Working on a similar problem?
Book a discovery call