First-party tracking: a complete guide for marketers

First-party tracking is the practice of collecting visitor, session and conversion data through a domain you control, rather than through a domain belonging to an ad platform. The browser classifies the resulting requests and cookies as first-party, and applies materially fewer restrictions to them.

That is the whole definition. Everything else is consequence, and one of those consequences is that "first-party" is not saying what most people think it says.

What is first-party tracking?

The common misreading is that first-party data means data you collected yourself. It does not. First-party is a classification the browser applies based on the domain a request is sent to, relative to the page being viewed.

MDN states the rule directly. A cookie is first-party when its "domain and scheme match the current page the user is looking at", meaning "the URL shown in the browser's address bar". Where they differ, the cookie is third-party.

Nothing in that rule mentions ownership. Your customer, your sale, your database, your consent record: none of it enters the decision. The destination domain does.

What is an example of first-party tracking?

A visitor is on yourstore.com and completes a purchase. That single event can travel two ways.

Same visitor, same purchase, same payload. Only the destination changed, and only the destination was ever being judged.

This is why a custom tracking subdomain matters more than it sounds like it should. It is not a cosmetic change to a URL. It moves the request across the line the browser is drawing.

What each browser actually does

The restrictions are not uniform, and treating them as one policy is how setups end up solving a problem their traffic does not have.

WebKit's announcement is unambiguous on the first row. "Cookies for cross-site resources are now blocked by default across the board", it says. The same change deletes "all of a website's script-writable storage after seven days of Safari use without user interaction on the site". Firefox blocks "content loaded from domains that track users across sites", from a shipped list.

Third-party cookies did not go away

The third row surprises people, because most content on this subject was written for a deprecation that was called off.

On 22 April 2025, Anthony Chavez, VP of Privacy Sandbox, set out the decision. Google will "maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies."

Read that carefully, because it cuts both ways. There is no deadline to plan around, so anyone selling you urgency about one is selling a date that does not exist. And the loss you are seeing is still real, because it was never mostly coming from Chrome. It comes from Safari's default blocking, from Firefox's list, from ad blockers, and from App Tracking Transparency. Since iOS 14.5 that framework requires permission before an app may "track them or access their device's advertising identifier". Without it, "the device's advertising identifier value will be all zeros".

The seven-day cap most setups miss

Moving collection to your own subdomain gets the request classified first-party. It does not, on its own, decide how long the identifier lasts.

Two cookies on one domain, holding the same value. One lasts seven days, the other can ask for ninety. The difference is who wrote them.

WebKit's 2019 change "would cap the expiry of client-side cookies to seven days", and the 2020 change extended the same treatment to script-writable storage generally. A cookie your own server writes in a Set-Cookie response header is not written by script, so it is not what that cap was aimed at.

This is the practical difference between a tracking setup that puts a script on your subdomain and one that answers from a server on it. Both are first-party. Only the second sets the cookie in a response header, which is the part the seven-day cap was never aimed at.

The gap you are actually looking at

Most people arrive at this subject holding a spreadsheet. Meta reports 200 conversions, Google Ads reports 180, and your own back end recorded 250 orders in total.

Two separate things are happening in that gap. The month below is a composite. The amounts are constructed. The arithmetic is the point.

The overcount is overlap, and first-party tracking does not fix it. Each platform reports on itself, under its own window and its own claiming rules. A buyer who saw a Meta ad and later clicked a Google search ad is claimed by both. Why your ad platform ROAS is wrong covers that arithmetic in full.

The last row is loss, and that is the one this is about. Those conversions happened. The reporting path broke.

What it changes, and what it does not

Recovered events are the direct effect. Events that were being dropped now arrive, and reported conversions rise because more of what happened is being recorded, not because more people bought.

The second effect matters more and gets discussed less. Those conversions can be sent back to the ad platform from your server, carrying hashed identifiers such as an email address or an order ID. Better-matched conversions are not only better reporting. They are a better optimization signal, and the platform spends your budget against the signal it receives. Server-side tracking covers that leg, and the Meta Conversions API guide covers one implementation of it end to end.

Cross-device is the honest limit. A visitor clicks an ad on a phone at lunch and converts on a laptop that evening, and no cookie spans those sessions. Where the conversion carries an email that matches earlier activity, the two can be linked. Where nothing is shared, they cannot, and a tool presenting that link as certain is describing a probability.

One term worth separating before you go further: first-party tracking is this classification question, while first-party data is a question about provenance, meaning information collected directly from your own customers. They are related and they are not the same, and you can own data completely while it still travels as a third-party request.

This is not only an ecommerce problem

Store owners notice first because orders are countable and the gap is obvious. The mechanism is identical for any business running paid ads.

A lead generation advertiser loses form submissions to the same restrictions. A SaaS company loses trial starts. A service business loses booked calls. An agency loses all of the above across every client account it manages. The conversion object changes. Nothing else does.

What implementing it involves

Three components, in order.

1. Collection from your own domain. A subdomain you control, answering requests and recording page views, ad click identifiers and the events preceding a conversion.
2. A server-side record of the conversion. A webhook or server call capturing the completed order, lead, booking or subscription with the attribution data attached, independent of whether the browser cooperated.
3. A send-back to the ad platforms. The conversion delivered server-side to Meta, Google Ads, TikTok, Microsoft Ads or GA4, enriched with first-party identifiers. It shares an event ID with the browser event, so the platform deduplicates rather than double-counts.

Step three is where implementations go quiet rather than loud. Send the same conversion from two sources without a shared event ID and the platform has no way to know they are one conversion. The TikTok Events API guide shows what that pairing looks like where it is done properly.

How TrueTracked does this

TrueTracked collects from a subdomain of your own domain, so the requests carrying your visitor and conversion data are classified first-party rather than cross-site.

On that subdomain it sets cookies server-side, through Set-Cookie response headers rather than from a script, and refreshes them on subsequent visits. The Meta identifiers _fbp and _fbc carry a 90-day lifetime, the TikTok browser identifier 13 months, and a stored TikTok click identifier 30 days. Those are configured expiries rather than guarantees against browser restrictions or a visitor clearing their storage.

The conversion itself is recorded server-side from your store's own order data, so an order still reports when the browser request never fired. Click identifiers captured on arrival are stored against the session and attached to that conversion later. That is what lets a purchase recorded days afterwards still carry the ad click that started it.

The limit worth stating plainly: none of this reaches a visitor who left no identifier at all, and it will not tell you the metaphysically true origin of every sale. Nothing will. First-party server-side tracking is the page that shows the setup, and TrueSignal covers the delivery leg that sends the recovered conversion back.

Where this leaves you

First-party tracking is not a workaround for a temporary privacy change, and it is not a response to a deprecation date, because the most-cited one was cancelled. It is an adjustment to a rule browsers have been applying for a decade and show no sign of relaxing.

Three things decide whether an implementation is worth anything:

1. Whether the requests genuinely go to a domain you control, since that is the only thing being classified.
2. Whether the cookies are written by a server rather than by a script, which is what separates seven days from ninety.
3. Whether the conversion is recorded independently of the browser, so a broken request costs you a signal rather than a sale you never knew about.

Get the first wrong and the other two cannot help. Get all three right and the remaining gap is overlap, which is a different problem with a different answer.

Sources

• Third-party cookies, MDN Web Docs, for the rule that decides whether a cookie is first-party or third-party
• Full Third-Party Cookie Blocking and More, WebKit, for Safari's default cross-site cookie blocking and the seven-day caps on client-side cookies and script-writable storage
• Firefox tracking protection, MDN Web Docs, for what Firefox blocks and how the list works
• Next steps for Privacy Sandbox and tracking protections in Chrome, Anthony Chavez, Google, 22 April 2025, for Chrome retaining third-party cookie choice
• User privacy and data use, Apple Developer, for what App Tracking Transparency requires since iOS 14.5 and what happens without permission

All five sources checked September 2026, and the TrueTracked details against the product code.