First-party data: the tracking gets worse every year, and the pixel was always a crutch
Not a cookie-apocalypse panic piece. Your orders, your accounts, your search terms and your email list were always the better signal. What to collect, what to never collect, and how the DSGVO framing actually helps you.
Photo: free stock photography (Unsplash licence) — see imprint
Nobody knows when third-party cookies actually die, and it does not matter
Every year since roughly 2020 somebody has stood on a stage and announced the date. The date then moved. It has moved enough times that we will not name one here, and you should treat anybody who does with the same suspicion you would treat a weather forecast for next April. Some browsers block by default already, others do not, and the policy keeps being revised in public.
The deadline is a distraction anyway, because the erosion is not one event. It is browser defaults, consent banners that people click away, ad blockers, app tracking prompts, and shorter cookie lifetimes — a dozen unrelated forces all pulling the same direction, none of which have a date. Your attribution has been quietly getting less honest for years. The question is not when it stops. It is what you build that does not depend on it.
The pixel was never telling you what you thought it was telling you
Here is the part the panic pieces skip. Third-party tracking was always a probabilistic story told about strangers, stitched across devices with guesswork, filtered through consent, and interpreted by a platform with a commercial interest in the answer being 'the ads worked'. Half your dashboard was modelled. You were making budget decisions on a reconstruction and calling it measurement.
Meanwhile, sitting in your own database, was a fact: this named customer paid this amount on this date for these articles, and came back — or did not — 94 days later. That is not modelled. It is not sampled. Nobody can deprecate it, no browser update can take it away, and it is the only data in the building that ties directly to money. The pixel was a crutch for not knowing your customers. It was never better than knowing them.
What is worth collecting is what you would act on tomorrow
The test for any data point is brutally simple: name the decision it changes. If you cannot, you are hoarding, and hoarding is a liability with a storage bill and a breach exposure. Most shops already hold far more than they use — the interesting move is not collecting more, it is finally reading what is already there.
- Internal search terms with no results — a list of products your customers want and you do not sell.
- Reorder interval per customer — tells you exactly when an email is welcome instead of annoying.
- Which article pairs appear in the same order — real cross-selling, from your own tills.
- Return reasons, written down and categorised — the cheapest product feedback in existence.
- Which customers stopped buying, and when — churn is visible months before it is fatal.
The DSGVO is not the obstacle here, it is the design brief
German companies have been trained to hear DSGVO and flinch. But read what it actually asks: have a purpose, tell people the purpose, collect only what serves it, keep it only as long as it serves it, and be able to hand it back or delete it. Every one of those is also just good data engineering. A shop that can answer 'why do we have this field' for every field is a shop that is both compliant and, not coincidentally, capable of using its data.
The practical upside is that first-party data lives on much firmer legal ground than a third-party pixel. Processing an order, running the account the customer asked for, keeping the invoice — these have a straightforward basis and do not depend on somebody clicking accept on a banner. Marketing on top still needs its own basis and its own honesty, and email consent is not a technicality you can bury in a checkbox. But the foundation is yours by right, not by permission of an ad network.
What to never collect, no matter how easy it is
Restraint is a feature. Do not collect a date of birth because a form builder offered the field. Do not store card numbers because the processor's raw response happened to contain them. Do not enrich your customer records with bought demographic data whose provenance you cannot explain to a customer's face. Do not log full request bodies 'for debugging' into a system where they will sit for three years.
The rule we use with clients: if the collection would embarrass you when read aloud at a Betriebsrat meeting, it is not a legal question, it is already the answer. Data you do not hold cannot leak, cannot be subpoenaed, cannot be misconfigured into a public bucket, and cannot be the reason your name is in the trade press. The cheapest security control in existence is not having the data.
| Signal | Third-party tracking | Your own data |
|---|---|---|
| Who the person is | A probabilistic guess, stitched across devices | A customer number, an invoice, a name |
| What it is worth | A modelled conversion value | The amount that hit the bank account |
| Survives browser policy | No — that is the whole problem | Yes — it is in your database |
| Legal footing | Depends on a banner click you did not get | Order processing and contract — for marketing, still get consent |
- The cookie deadline has moved repeatedly — build for the erosion, not the date.
- Half your ad dashboard was modelled; your order table was never a guess.
- If a data point changes no decision, it is not an asset — it is a liability with a storage bill.
- The DSGVO's questions are the same questions a competent data model already answers.
Frequently asked questions
There is no date you can plan against — the timeline has been announced and revised repeatedly, and the approach itself has changed shape more than once. Planning your data strategy around a specific quarter is how you end up rebuilding it. Other browsers already restrict by default, consent rates already cut your coverage, and ad blockers already remove a slice. Assume the signal degrades and keeps degrading, and build what does not depend on it.
You need something that shows you traffic sources and on-site behaviour — order data cannot tell you which product page people leave. But be clear about the division of labour: web analytics is for finding where the funnel leaks, and your database is for anything involving money, lifetime value or a specific customer. Most shops over-invest in the first and never look at the second, which is exactly backwards.
No. First-party means you collected it yourself, not that you may do anything with it. Running an order and keeping the invoice rests on solid ground; mailing that customer a campaign, profiling their behaviour or enriching their record are separate purposes needing their own basis. The improvement over a pixel is that the purposes are ones you can actually explain in one sentence — which is most of the compliance work done.
With two queries and no new software. First: internal search terms that returned nothing, sorted by frequency — that is a ranked list of demand you are refusing. Second: customers who bought twice or more, and the gap between orders — that tells you when a reminder is useful rather than spam. Both take an afternoon, neither needs a platform, and both usually beat whatever the tracking was telling you.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer