What first-party data is, why it matters more now that cookies live shorter, and how server-side tagging and your CRM get more out of it.
First-party data is everything you collect in your own channels: behaviour on your site or in your app, orders in your shop, customer records in your CRM, email interactions, support conversations.
You know where it came from, you decide how long you keep it, and you can attach it to a customer you already have. Third-party data comes from a company that collected it somewhere else and sells or shares it. You rarely know how it was assembled or how fresh it is.
Safari and Firefox block third-party cookies by default. Chrome called off removing them, but nothing else about the field went back to how it was.
The part that hits your measurement harder: tracking prevention also shortens the life of cookies on your own domain. Set a cookie from JavaScript with document.cookie and Safari keeps it for at most seven days. A visitor returning after nine days is a new user in GA4, with a new session source.
The result is an undercount of returning visitors, attribution windows shorter than the ones you configured, and too little credit for channels people use early in their orientation.
With server-side tagging you set the analytics cookie from your own subdomain, through an HTTP header instead of JavaScript. That is the main win of going server-side: the clock stops resetting every week.
Two things vendors tend to leave out. Your container has to run on a subdomain of your main domain, not on some domain belonging to your provider, or the cookie is third-party anyway. And a subdomain that points to someone else's infrastructure through a CNAME is recognised by Safari, which brings back the same seven-day cap. An A record pointing at a server inside your own environment avoids that.
The container also lets you decide which field goes to which platform. You can hash an email address before it leaves, or block a field entirely. We compared the hosting routes in server-side GTM on Taggrs or Stape.
You hold data the advertising platforms do not have: who actually bought, for how much, and what came back as a return.
Enhanced Conversions in Google Ads. You send hashed customer details along with the conversion, such as email address, phone number, and name with address. Google matches them against signed-in users and closes part of the gap that cookie loss leaves behind. Hashing is SHA-256, after normalising: trim the whitespace, lowercase everything.
Meta's Conversions API. Same idea, from your server. If you run both the pixel and server events, use one event_id in both so Meta can deduplicate.
Offline conversions from your CRM. For lead generation this is the biggest step. You import which lead became a quote and which quote became an order, carrying the gclid or a user identifier. Google Ads then optimises towards signed deals rather than submitted forms.
First-party data is not a free pass. Sending customer details back to an advertising platform needs a legal basis, and in practice consent. The ad_user_data and ad_personalization signals in Consent Mode cover exactly this: without permission, those details should stay with you.
As long as your data sits in separate platforms, you steer on whatever each platform reports about itself. Bring orders, returns, cost prices and ad spend together in a warehouse and you can ask different questions.
Which campaign brings in customers who come back within a year. Which product group loses its margin to returns. Which channels drop out once you weigh new customers above repeat purchases.
The join that makes this possible is usually dull: an order id you can find in both your event data and your backend. Get those two to line up before you start building models on top.
Want to talk about this?