First-party data governance determines whether your customer data dies of natural causes or whether you kill it yourself. 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 — through capture design, cookie policy, and identity architecture choices that throw away data they were entitled to keep.
This is Post 3 of a three-part series on data half-life. Post 1 made the case that your customer data is decaying 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, Jan 2024). 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. This is the first principle of good first-party data governance — and it directly extends the data half-life of every record you hold.
Timestamp everything you collect
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.” Timestamps turn a static list into a decay-aware asset — and they are the foundation of customer data maximization, because you cannot maximise what you cannot measure.
Stop over-governing your first-party 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 first-party data governance 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 to prevent fragmentation
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 personalise 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). Carrefour’s loyalty programme succeeded because it linked basket-level purchase data to a single customer identity at the till — not in a quarterly batch job months later.
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 first-party data 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.
Collect the right data and start your half-life measurement
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.
Collect the right data — data with value beyond a few days or weeks — and start your half-life measurement. The goal is customer data maximization: extracting full commercial value from every record you hold. That means durable capture (DOB, not age), proper first-party data governance (server-side cookies, lawful retention windows), identity resolution at capture (not quarterly), and activation loops that fire before the data half-life cuts your return in half.
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 first-party data governance rules are throwing data away, and fix the ones that cost you the most. One session. Specific fixes. No theory.
Book a Data Governance Review →
This is Post 3 of 3 in the Data Half-Life series. Start from the beginning: The Half-Life of Data → The Playbook → this post.
Frequently asked questions
What is self-inflicted data decay?
Self-inflicted data decay happens when your own first-party data governance rules, capture design, or technical stack causes data to lose value faster than it would naturally. Examples: storing age instead of date of birth, setting cookie expiries shorter than the law allows, and holding duplicate identities for the same person without linking them.
Does PDPA or GDPR require 7-day cookie expiry?
No. Neither PDPA in Singapore nor GDPR in the EU/UK mandate a specific cookie duration for first-party analytics. A 30-day or even 13-month first-party cookie is lawful in most cases with proper consent. Many companies default to shorter windows out of caution, discarding usable signal without legal basis.
How do I stop Safari ITP from limiting my first-party cookies?
Safari's Intelligent Tracking Prevention caps JavaScript-set first-party cookies at approximately 7 days. The fix is to set cookies server-side via HTTP response headers. Server-set first-party cookies are not subject to the 7-day ITP cap and persist for the full duration you specify.
What is first-party data governance?
First-party data governance is the set of rules, capture designs, and technical choices that determine how long your own customer data stays usable. Good first-party data governance maximises the useful life of every record. Poor governance — over-cautious cookie expiry, age-not-DOB capture, fragmented identity — accelerates decay beyond what time alone would cause.
Working on a similar problem?
Book a discovery call