Filing by Location Instead of by Collector
The three-party vocabulary describes relationships, not storage. That is where nearly everyone goes wrong.
Second-party data is somebody else's first-party data, shared with you. The collection was direct and legitimate. It just was not done by you. When an affiliate network passes buyer details back on a postback, that is second-party data arriving. The quality can be excellent. The origin is still not yours, and your rights over it are exactly the rights the other party granted, no more.
Third-party data is assembled and sold by a company that never met the person. Stitched together from many sources, sold to many buyers, and nobody anywhere in that chain had a conversation with the individual it describes.
Zero-party data, since the term keeps turning up, is information a person deliberately volunteers about themselves: preferences, intent, budget, usually through a quiz or a preference centre. It is a subset of first-party data where the collection is explicit rather than observed.
Once a file lands in your warehouse, all three look identical. Same columns, same row count, same hashed email format. Which is exactly why people file by location. The column that matters is the one nobody ever stores: who was in the room.
Seven rows that all end up in the same warehouse, sorted by the only column nobody stores: who did the collecting.
Why Affiliates Fail This Test by Design
Here is the part that stings if you run traffic to network offers.
On a ClickBank, CPA, or vendor offer, the checkout is not yours. Your prospect clicks your ad, reads your prelander, clicks through, and types their name, email, phone, and card details into a form on somebody else's domain. You paid for the click. You wrote the angle. You never meet the buyer. I called this the identity handoff in a separate piece, because it explains more disappointing dashboards than any misconfiguration does.
What you are left with is a click record, not a person. A click record is a real asset, and it is genuinely first-party if your own server wrote it, but it describes an event rather than an identity. The difference shows up the second an ad platform asks you who bought.
Three of the five segments belong to you, and the number of match keys you can send is decided entirely inside those three.
Owning the Collection Point Is Not a Lawful Basis
This is where first-party talk turns into a sales pitch and somebody gets hurt.
Collecting data yourself does not create permission to process it. Under the GDPR you still need a lawful basis, you still owe transparency at the moment of collection, and you still have to honour access and deletion requests. The ePrivacy Directive sits alongside that and is stricter about one specific act: storing information on, or reading information already stored in, a person's device. Article 5(3) is written technology-neutrally, so it reaches well past cookies, and the EDPB guidelines on its technical scope make that explicit. Its two exemptions are transmission and strict necessity for a service the user asked for. Analytics measurement is neither, because your site works fine without it and nobody ever requested to be counted.
Hashing does not rescue any of this. An SHA-256 email is pseudonymised data, not anonymous data. The EDPB's draft pseudonymisation guidelines take the position that pseudonymised information stays personal data because it still relates to an identifiable person, and a plain hash counts as pseudonymisation rather than anonymisation. An email address is low-entropy by nature: anyone holding the same address computes the same digest and matches it, which is the entire reason the technique works for ad platforms in the first place.
One 2025 development cuts the other way. In EDPS v SRB (C-413/23 P, September 2025) the Court of Justice held that whether pseudonymised data is personal data can depend on who holds it: personal for a controller who can re-identify, not personal for a recipient who reasonably cannot. That relativity helps recipients. You are the collector, and you hold the mapping between the hash and the person. On your side it is personal data, full stop.
Two honest caveats. Those EDPB guidelines were adopted in draft in January 2025 and, as far as I could confirm in August 2026, are still not final, sitting in the 2026-2027 work programme. And this is a description of a mechanism, not legal advice. Have your consent flow reviewed by somebody who does that for a living.
What Counts, Ranked by Durability
In descending order of how long it stays useful.
A click identifier logged server-side at the moment of the click. Your endpoint received the request and your server wrote the row. It does not vanish when a browser cleans house, and it is the join key everything else hangs off.
An email or phone captured on a page you control, before the visitor leaves. The highest-value thing an affiliate can own, because it survives devices, browsers, and the handoff itself.
An order or transaction ID reconciled back to your click record. Second-party at origin, since the network's checkout collected it, but it becomes genuinely useful the moment you join it to a click you logged yourself.
Now the things that do not count, however the vendor describes them.
A cookie a vendor script wrote on your page. The script is theirs, the read is theirs, and on Safari that storage is deleted after seven days of browser use with no first-party interaction, which is the mechanism behind the seven-day ceiling. A cookie your own server sets in a response header is a different category entirely, and that difference is the whole argument for server-side tagging.
A platform audience you can target but never export. If the only place it exists is inside an ad account, somebody else owns it and is renting you access.
A licensed data set. Somebody else's collection with your logo on the invoice.
What It Buys You Downstream
Advanced matching and the Conversions API are the machinery that consumes all of this, and they are unforgiving about origin.
Meta accepts up to fifteen customer-information parameters on a conversion event and grades the result. Four of them arrive on their own with any competent server-side setup: client IP address, user agent, and the two Meta browser identifiers. The fifth, email, only exists if your own page asked for it. That single field is the most valuable first-party thing on the list, and it is why an opt-in step ahead of the offer page can pay for itself even when it costs you conversion rate.
TikTok's Events API matches on twelve identity signals, including hashed email, hashed phone, external ID and ttclid. Google's enhanced conversions works from nine and needs at least an email address, a phone number, or a block of first name, last name, postal code and country. All three hash what you send. None of them can hash something you never collected.
The Audit Worth Running This Week
Open your ad platform's event manager and list every field arriving on your purchase event. Beside each one write two things: WHERE you obtained it, and WHO was standing there.
Not the vendor's name for the field. The physical answer. "Email, from the opt-in form on my landing page, collected by me". "City, from the network postback, collected by the vendor's checkout". "external_id, from a cookie some script wrote, collected by, actually, I am not sure".
Anything you cannot answer is not first-party data, no matter what your vendor calls it in the pricing page. It might still be useful. It is not yours, and you should stop planning around it as though it is.
ClickerVolt logs the click server-side and stores identity captured on your own pages against that click, so the join already exists when the network postback lands instead of being reconstructed afterwards. See how the first-party collection layer is put together. The audit matters more than the tool though. Run it either way.
FAQ
What is first-party data in simple terms?
Data you collected yourself, directly from the person it describes, on a website, app, or server you control. The test is where the collection happened, not where the file ended up. If you bought it, licensed it, or received it from a partner, it is not first-party data for you, even though it was for whoever collected it.
Is second-party data just first-party data with extra steps?
It is somebody else's first-party data shared with you. The collection was direct and legitimate, but a different company did it, so your rights over the data are limited to whatever that company granted and whatever the person consented to at their collection point. An affiliate network sending buyer details back on a postback is the everyday example.
Does hashing an email make it non-personal data under GDPR?
No. Hashed identifiers are pseudonymised data rather than anonymous data, and pseudonymised data stays inside the GDPR. The EDPB's draft pseudonymisation guidelines say so directly. A 2025 CJEU judgment added that the assessment can vary by holder, so data may cease to be personal for a recipient who genuinely cannot re-identify. That does not help you, because you hold the original.
Can an affiliate promoting network offers have first-party data at all?
Yes, but only from the part of the journey you own. The click identifier your server logged, the email or phone your landing page captured, the quiz answers on your prelander. Everything the buyer typed at checkout was collected by the vendor and comes back to you, if it comes back at all, as second-party data.
Is a first-party cookie the same thing as first-party data?
No, and the overlap in wording causes real damage. A first-party cookie is a storage location scoped to your domain, and a third-party script can write into it. First-party data is a statement about who did the collecting. A cookie on your domain that a vendor's script populated is first-party storage holding third-party collection. See cookie versus cookieless for the storage side.
