Updated: December 19, 2025
If you’re running server-side tracking with Google Tag Manager or Adobe Launch, you’ve probably heard the term FPID thrown around. Maybe you’ve seen it mentioned in documentation and wondered what it actually is, or maybe someone on your team told you to set it up and you’re not sure why.
The truth is, as browsers get stricter with cookies — blocking third-party cookies, limiting first-party cookie lifetimes, and introducing new privacy mechanisms — the traditional ways of identifying users are becoming less reliable. That’s where FPID comes in.
In this article, I’ll explain what FPID is, why it matters, and how it looks in both Adobe Launch and Google Tag Manager.
What is FPID
FPID stands for First-party ID (or First-party Device ID). It’s an identifier that is managed by your own server and stored as a first-party cookie on the user’s browser.
The key difference between FPID and other identifiers (like GA4’s Client ID or Adobe’s ECID) is who controls it. With FPID, your server generates the ID, sets the cookie, and decides how long it lives. You’re not relying on a third-party script or a browser-generated value.
Why does this matter? Because browser restrictions — ITP in Safari, Enhanced Tracking Protection in Firefox, and the ongoing depreciation of third-party cookies in Chrome — all make it harder for client-side scripts to reliably set and read identifiers. A server-generated FPID, set as an HTTPOnly cookie, sidesteps a lot of those restrictions.
Why Use FPID?
FPID gives you two real advantages over client-side identifiers,
Advantage #1: It survives browser cookie restrictions.
The biggest practical benefit of FPID: it continues to exist even if other IDs are cleared.
Let me give you an example. If you’re using a CNAME-based tracking setup, Safari limits first-party cookie lifetimes to 7 days. After that, the cookie is gone, the Client ID is lost, and the user looks like a new visitor. User counts get inflated, and your reporting takes a hit.
FPID doesn’t have that problem. Because it’s set and managed by your server — often with a longer expiration — it persists even when other cookies are cleared. The user gets re-identified correctly, and your user counts stay accurate.
Advantage #2: It’s more secure
FPID can be set as an HTTPOnly cookie. That means it can only be accessed by the server, not by client-side JavaScript. Tools like GTM running in the browser can’t read it, and neither can any third-party scripts or Chrome extensions running on your page.
That’s a meaningful improvement over client-side identifiers, which any injected script or browser extension can read.
What does FPID look like?
The format depends on the platform you’re using. Let’s look at the two most common cases.
FPID in Adobe Launch
In Adobe Launch, FPID follows the UUIDv4 format. It’s generated by your own server and written into a cookie as a standard UUID.
An example FPID value:
ac619d0b-0bce-4c92-ae26-75b4e93083bd
The server generates this UUID and sets it as a first-party cookie. That’s it — simple, clean, and standard.
FPID in Google Tag Manager
GTM’s server-side tagging uses a different FPID format. Instead of a simple UUID, the FPID contains multiple pieces of information packed into a single string.
Here’s what a GTM FPID looks like:
FPID2.2.F99Fd7gVuQuP93MZdJiEn07o/eZba6j9bAt8ETLsn8E=.1733280703Breaking it down:
| Value | Description |
|---|---|
| FPID2.2 | Version number |
| F99Fd7gVuQuP93MZdJiEn07o | Core user identifier |
| eZba6j9bAt8ETLsn8E= | Additional security or validation data |
| 1733280703 | Timestamp |
If you look closely, the value after the version number — F99Fd7gVuQuP93MZdJiEn07o/eZba6j9bAt8ETLsn8E=.1733280703 — is actually the same as what GA4 uses as its Client ID. So in GTM’s server-side tagging, the FPID essentially wraps the Client ID with a version prefix and some validation data.
FPID is for server-side tracking only
One thing I want to make clear: FPID is only relevant for server-side tracking. If you’re using client-side GTM or Launch without a server-side container, FPID isn’t something you need to worry about.
The reason is simple: FPID is designed to be set and read by the server, not the browser. It only becomes useful when you have a server-side tagging environment that can read the FPID cookie and use it for user identification.
Final Words
FPID is one of those concepts that sounds more complicated than it actually is. It’s just an identifier that your server controls instead of the browser. But in a world where browser restrictions keep tightening, that simple shift — from client-controlled to server-controlled — makes a significant difference in how reliably you can identify returning users.
If you’re running server-side tagging and haven’t set up FPID yet, it’s worth looking into. And if you’ve run into any quirks — especially around FPID format differences between platforms — drop a comment and share your experience.