First-party tracking: what it is and how it works

Your analytics says a shopper is new when you know they've been to your store three times this month. Meta says an ad drove 40 sales, your own reports can only find 25, and returning customers keep showing up as strangers. A lot of that comes down to who is doing the tracking, and whose name is on it.

That's what first-party tracking is about. It's not a product or a setting. It's a way of collecting data where your own website does the remembering and the recording, instead of handing that job to other companies' scripts.

This guide explains what first-party tracking is, how it works under the hood, why browsers and ad blockers treat it differently, and what it can and can't fix.

What is first-party tracking?

First-party tracking means your own website collects data about visits to your own website. The "first party" is you: the site the shopper chose to visit. A "third party" is any other company whose code runs on your pages, like an ad platform or an analytics vendor.

The difference shows up in three places:

Whose cookie it is. A cookie is a small note a website leaves in the browser so it can recognize the visitor next time. A first-party cookie belongs to the site in the address bar (yourstore.com). A third-party cookie belongs to some other domain loaded inside the page.
Where the data is sent. First-party tracking sends events to an address on your own domain, or to your own server. Third-party tracking sends them straight to the vendor's domain.
Who keeps it. With first-party tracking, the data lands somewhere you control first. You decide what gets passed on to anyone else.

Picture Leo visiting your store. Your site gives his browser a first-party cookie that says "visitor 8812". He leaves, comes back two days later from a Google search, and the same cookie is still there, so your analytics knows this is Leo's second visit, not a new person. When he buys, your server records the order and ties it to visitor 8812's earlier visits. That's first-party tracking working as intended.

How first-party tracking works

A first-party setup usually has three parts.

1. An identifier on your own domain

Your site sets a first-party cookie with a random ID for the visitor. It contains nothing personal. It's just a label so that visit two can be connected to visit one.

2. A collection point on your own domain

When something happens (a page view, an add to cart), the browser sends the event to an address on your domain, or to a server you run, rather than straight to a vendor. From there it can be stored, cleaned up, and forwarded to the tools that need it. This is what people mean by server-side tracking: a server in the middle that you control. We explain it in full in what is server-side tracking .

3. Purchases recorded from the store, not the browser

The most important events shouldn't depend on a browser at all. When an order is placed, Shopify can notify your server directly . That notification is called a webhook. It arrives whether or not the shopper's browser ever loaded the thank-you page, had an ad blocker, or closed the tab early.

The browser parts tell you how the shopper got there. The server part makes sure the sale itself is never lost.

Why browsers treat first-party tracking differently

Browsers have spent years cutting back on tracking, and most of the cuts target third parties.

Safari blocks third-party cookies by default .
Firefox blocks cookies from known trackers by default and keeps each site's cookies in a separate box, so one company can't follow you from site to site with them.
Chrome still allows third-party cookies by default. Google dropped its plan to switch them off , but shoppers can block them in settings, and many do.

First-party cookies survive all of that, because they're how websites keep you logged in and remember your cart. Browsers can't block them without breaking the web.

The catch: Safari still limits some first-party cookies

Safari's tracking protection (called Intelligent Tracking Prevention, or ITP) doesn't only look at who owns a cookie. It also looks at how it was created.

Cookies created by JavaScript (a script running in the page) are capped at **7 days** in Safari , even when they're first-party. Meta's _fbp cookie is a good example: it sits on your domain, but the Meta pixel's script creates it, so in Safari it expires after a week without a new visit. If you want to know what that pixel does, our guide to the Meta pixel covers it.
Cookies set by your server in its response to the browser aren't subject to that cap in the same way, as long as Safari sees the server as genuinely part of your site.
Safari checks that claim. If your "first-party" tracking address is really a pointer to another company's servers ( a DNS setting called a **CNAME** ), or is served from a very different network address than your website, Safari can treat it like a third party and cap its cookies at 7 days too.

What this means in practice: a shopper who visits on a Monday from a Snapchat or Meta ad and comes back eight days later on Safari can look like a brand new visitor if your only identifier was created by a script. That's the "returning customers showing up as strangers" problem from the top of this post.

Why ad blockers treat it differently

Ad blockers mostly work from filter lists: long, shared lists of known tracking domains and script names. A request to a well-known ad or analytics domain is easy to spot and block.

Events sent to your own domain are much harder to put on a shared list, because every store's domain is different. So first-party collection loses far fewer events to blockers than a script loaded straight from a vendor.

It isn't a guarantee, though. Blockers can also match on script names and address patterns, and some lists include known first-party tracking setups. That's another reason purchases should come from the server: an order recorded by a webhook never touches the shopper's browser, so there's nothing to block.

What first-party tracking can't do

It helps to be honest about the limits, because "first-party" gets oversold.

It doesn't replace consent. In places like the EU and UK, you need the visitor's permission for non-essential cookies and tracking whether they're first-party or third-party. If a shopper declines, a first-party setup should respect that just like any other. Shopify's own analytics, for example, only counts sessions from visitors who accept cookies where a banner is required. Our post on server-side tracking and GDPR goes into this.
It doesn't follow people across other websites. First-party data is about visits to your site. That's the point.
It doesn't connect devices on its own. Leo's phone and laptop have different cookies. To know they're the same person, you need something he gives you on both, like logging in or buying with the same email. Our guide to customer journey analytics shows why that matters.
It doesn't rebuild the past. Journeys only exist from the day tracking is installed. Orders can be imported later, but the visits behind them can't.

How to check whether your tracking is first-party

You don't need to be a developer to get a rough answer.

Look at where your events go. In Chrome, right-click your store, choose Inspect, open the Network tab, and reload. Requests to your own domain are first-party. Requests to facebook.net, analytics.tiktok.com and similar are third-party scripts doing their own collection.
Look at your cookies. In the same tools, the Application tab lists cookies. Check which ones are on your domain and how long they're set to last.
Check what happens to purchases. Ask whoever set up your tracking, or your app's support: is the purchase sent from the browser's thank-you page, or from the store's server when the order is created? Only the second survives a closed tab.
Test in Safari with an ad blocker on. Place a test order, then see which of your tools recorded it.

Setting up first-party tracking on Shopify

On Shopify you have a few routes:

Use the platforms' own server connections. Meta's Conversions API, TikTok's Events API and similar send events from a server. They help the ad platforms, but each one is separate and each platform keeps its own copy. See Conversions API vs Meta pixel for how the two fit together.
Run your own tracking server. Server-side Google Tag Manager on a subdomain of your store is the common do-it-yourself option. You get control, and you also get hosting bills and maintenance.
Use a server-side tracking platform that collects events on your store, records orders from the server, keeps the data in your own analytics and forwards it to the ad platforms. We compare options in top server-side tracking tools .

Whichever you choose, the same rules apply: record purchases from the server, keep identifiers you control, respect consent, and be skeptical of anyone promising that first-party tracking sees everything.

How Soran handles it

Soran is built on your store's own data, collected first and kept in one place before anything is shared.

Purchases are recorded server-side, so ad blockers, tracking prevention and closed tabs don't lose them.
One site tracker, created for you. On Shopify, checkout and thank-you page events come with the store connection, and storefront tracking starts once you switch on the theme app embed. Setup shows how many events arrived in the last 24 hours, so you can see it's working.
One customer stays one person. Orders, visits and touchpoints from different devices are joined into one customer profile where they can be connected, and repeat revenue is shown apart from first purchases.
Spend is matched to the exact ad through tracking parameters on your ad URLs, so the link from click to order doesn't hang on a cookie alone.
Conversions go back to Meta and TikTok with duplicates removed, and you can see and edit what's sent.
The event log shows every raw event as it arrived, if you ever need to check whether something was tracked.

One honest limit: visit paths only start once tracking is installed. Shopify orders import with their history, but the journeys behind past orders can't be rebuilt.

Frequently asked questions

Is first-party tracking the same as server-side tracking?

They overlap but aren't the same. First-party is about whose domain and cookies are used. Server-side is about where events are processed and sent from. A good setup usually does both: first-party identifiers, plus a server that records purchases and forwards events.

Do first-party cookies need consent?

In the EU, UK and other places with similar rules, yes, unless the cookie is strictly necessary for the site to work (like a shopping cart). Analytics and marketing cookies need consent whether they're first-party or third-party.

How long do first-party cookies last in Safari?

It depends on how they're created. Safari caps cookies created by JavaScript at 7 days. Cookies set by your own server can last longer, unless Safari decides the server really belongs to another company.

Does first-party tracking get around ad blockers?

It loses far fewer events to them, because blockers mostly target known vendor domains. It's not a guarantee. Purchases recorded from the server are the only events a browser can't interfere with.

Is Meta's pixel first-party tracking?

Partly. The _fbp cookie it creates sits on your domain, so it's technically a first-party cookie, but the script and the data go to Meta. That's why Meta also offers the Conversions API, covered in our guide to the Meta Conversions API on Shopify .

Want your store's tracking collected first, kept in your own analytics, and every sale recorded on the server? Book a demo and we'll walk through your setup.