First-party data for paid media: what to collect and where to send it.

Most first-party data advice is written for people who want to build a data warehouse. This is written for people who want their ad accounts to see the sales they are actually making.

That is a narrower goal, and a more urgent one. Every purchase the ad platforms cannot see is a purchase their bidding systems cannot learn from. Over time the account drifts toward the customers who are easiest to track rather than the ones who are most valuable.

What the browser took away

Safari has blocked third-party cookies by default since 2020 and limits how long cookies set by scripts can last. Firefox blocks known trackers by default. Ad blockers stop many pixels from loading at all. And in regions where tracking needs consent, a share of visitors decline it. Whatever Chrome eventually does, a meaningful part of your traffic already arrives without the signals a browser pixel depends on.

The effect is not that tracking stopped. It is that the pixel became one partial view among several. First-party data is how you fill the gaps with information your own site legitimately collects.

What to collect

• →Click IDs on landing. The gclid, gbraid, and wbraid from Google, and fbclid from Meta, stored on your own domain so they can travel with the order later.
• →Identifiers at signup and checkout. Email and phone, normalized and hashed before they are sent anywhere, and only where the customer has agreed to the use.
• →Purchase events from your server. The order your store recorded, with its value, sent server side as well as from the browser, with a shared event ID for deduplication.
• →Later outcomes. Refunds, cancellations, and for subscriptions the first payment, so the value the platforms learned from can be corrected.
• →The customer list. Every past buyer, hashed, so new customers can be separated from returning ones and existing customers can be excluded from acquisition campaigns.

Where each one goes

Consent decides what you may send

None of this overrides a customer’s choice. In the EEA and the UK, advertising use of personal data needs consent, and Google requires consent signals through Consent Mode for measurement and personalization there. When someone declines, their identifiers should not be sent, and Google can model conversions from anonymous signals rather than observe them.

• →Pass the consent state with every event, and make the server respect it, not only the browser.
• →Hash identifiers before they leave your systems, following each platform’s normalization rules.
• →Do not use fingerprinting or other techniques designed to identify people who opted out.
• →Keep what you collect proportionate. Collecting data you do not use is risk without return.

The order to do it in

1. Audit the purchase event. Make sure the browser event fires once per order with the right value, before adding anything server side.
2. Add the server-side purchase event to Meta and Google, with deduplication, and confirm counts line up with the store.
3. Add hashed identifiers to those events where consent allows, and watch Meta’s event match quality and Google’s enhanced conversion diagnostics.
4. Store click IDs and wire offline import for outcomes that arrive later, such as refunds or subscription payments.
5. Bring in the customer list for exclusions and new-versus-returning measurement.
6. Put first-party tracking on your own domain, so the full path across channels can be read in one place.

The first two steps usually deliver most of the gain. The later steps make the reporting honest rather than just more complete. Our own platform works the same way for clients: first-party tracking on the brand’s domain, purchases captured server side, and the customer list read alongside the ad platforms and the store. The setup detail for the server-side step is in the Conversions API and server-side tracking guide.

What each platform does with it

It helps to know what happens on the other side, because it explains which details matter. Meta takes the hashed identifiers on each event and tries to match the event to a person on its apps. The better the match, the more of your purchases Meta can connect to the ads people saw, and the more its delivery system can learn. It reports how well this is going as an event match quality score, out of ten, for each event.

Google’s enhanced conversions work similarly. The conversion tag, or your server, sends hashed customer data with the conversion, and Google matches it to signed-in Google accounts to recover conversions that cookies alone would have missed. Offline conversion import is the other half: it connects outcomes recorded later in your own systems, such as refunds or a subscription’s first payment, to the click that started them, through the stored click ID or the hashed identifiers.

In both cases the identifiers never have to leave your systems unhashed, and the platforms do not need to learn anything new about the customer. They need to recognize someone they already know, at the moment that person bought.

Server side is not the same as first party

Moving the pixel onto a server container on your own subdomain is useful. It survives more ad blockers and extends cookie life in some browsers. But it is still sending what the browser saw. The bigger gain comes from sending what the store recorded: the order that actually happened, with its real value, from the system that took the payment.

The difference shows up in the awkward cases. A customer who pays with a wallet that redirects away and never returns to the thank-you page is invisible to a browser event and obvious to the store. So is an order edited after checkout, or one placed by phone. When the store is the source of the purchase event, those orders are counted once, at the right value.

Common implementation mistakes

• →Missing or mismatched event IDs, so the browser and server copies of a purchase are counted twice.
• →Hashing without normalizing first. Emails need to be trimmed and lowercased, and phone numbers put in the platform’s format, before hashing, or nothing matches.
• →Purchase events that fire again when the thank-you page is reloaded or revisited.
• →Values sent in the wrong currency, or including tax and shipping in one platform and excluding them in another.
• →Test orders and internal staff purchases left in the live event stream.
• →Identifiers sent for visitors who declined consent, which is both a compliance problem and a data quality one.

Who owns which part

First-party data projects stall when everyone assumes someone else owns them. A workable split: the developer or platform partner owns the event plumbing and deduplication. The marketer owns which events are sent, the values they carry, and checking the counts against the store each week. Whoever owns privacy owns the consent setup and the disclosure in the privacy policy. Write the split down, because the failure mode is a quiet break that nobody notices for a month.

How to tell it worked

• →The share of store orders that the platforms report as conversions rises, then holds steady.
• →Meta’s event match quality score for purchases improves, and Google reports enhanced conversions as active.
• →Duplicate counts do not appear. If a platform suddenly reports more purchases than the store took, deduplication is broken.
• →The ratio of platform-claimed revenue to store revenue becomes more stable week to week, which makes a real change easier to see.

Do not expect the platforms to agree with each other afterward. They will still count shared orders. The goal is that each one sees more of the truth, and that you can see all of it.