First Party ID
15 Jun 2025 » Platform
Now that I have addressed the Experience Cloud ID (ECID) from a 2025 perspective, I can proceed to write a post on the First Party ID (FPID). It has remained on my list of future posts for some time, but until recently, I had not encountered it in a client scenario. Now that I have sufficient context, I can provide an explanation of this feature, how to use it, and the typical use cases for it.
What is this FPID?
As you very well know, all Adobe tools share a unique identifier for anonymous visitors: the ECID. It has played a pivotal role since we began integrating tools, starting with Adobe Analytics and Adobe Target in A4T. However, what if you cannot store the ECID client-side or have a better identifier? Would it not be preferable if you could supply an equivalent identifier that you control?
This is where the FPID becomes relevant. If you are using AEP’s Edge Network, you can supply your own durable identifier instead of the ECID. In other words, the FPID is a unique identifier generated and managed by you, the Adobe client.
How It Works Internally
In case you are wondering how the FPID is treated, the process is quite simple. The AEP Edge Network uses it to create an ECID and then uses this ECID internally. The most important detail is that this conversion from FPID to ECID is deterministic. This means that for a given FPID, AEP will always generate the same ECID.
How to Use It
To enable and use the FPID in your implementation, follow these steps.
1. Generate the FPID
The first step is to generate this durable ID. This must occur outside of the Adobe stack. Remember, if you are choosing to use the FPID, it is because you believe it will work better than the ECID for your use case. You are responsible for its full lifecycle: creation, retrieval, and storage.
One important detail is that Adobe only supports the UUIDv4 format for the FPID.
2. Edge Configuration
If you are going to send the FPID using the identityMap XDM parameter, you are all set in terms of configuration.
The alternative is to send it in a cookie. To do this, you need to:
- Store the generated FPID in a first-party cookie.
- Set up a CNAME for the Edge Network so that the calls to it are made in a first-party context.
- Configure the datastream to read this cookie from the HTTP request.
3. Send the FPID
As described in the previous step, there are two ways to send the FPID.
If you send it in the identityMap, you must use the out-of-the-box identity namespace FPID. For example:
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-12d3-a456-426614174000",
"authenticatedState": "ambiguous",
"primary": true
}
],
"EMAIL": [
{
"id": "[email protected]",
"authenticatedState": "authenticated"
}
]
}
}
I will not explain here how and when to use authenticatedState and primary.
If you are using a cookie, then there are two scenarios:
- If you are using WebSDK, then no additional action is required. If everything is configured correctly, the browser will append the cookie to the call to the Edge Network, and the datastream will read it from there.
- If you are in a server-to-server scenario, or on a device for which there is no SDK, you must manually attach the cookie to the HTTP call. However, in these cases, I strongly recommend using the
identityMap.
Use Cases
I can think of two main use cases for using the FPID. Let me know in the comments if you can think of other scenarios or are already using the FPID in a different context.
Beating ITP
Safari’s Intelligent Tracking Prevention (ITP) aggressively limits the lifespan of client-side cookies that it believes are used for tracking, especially third-party cookies. However, by using the FPID:
- You store the FPID in a first-party context, which is less likely to be purged.
- You maintain a custom device identifier, which is more likely to go unnoticed.
To clarify, this does not beat ITP in the sense of bypassing it, but it maximizes the longevity of your identifiers within the browser’s rules.
Server-Side Implementation
In server-side or hybrid implementations, maintaining identity continuity can be challenging. With the FPID:
- You control the identifier, rather than relying on the ECID, which is generated outside of your systems.
- You do not need to manage the ECID: receiving it, storing it, retrieving it, and attaching it to all subsequent calls. Since you own the FPID, you likely have a method for maintaining it.
More Information
There are many more details beyond this brief introduction. If you want more information, there are several resources you can consult:
- Experience League documentation:
- A blog post from my coworkers Prachi and Luc: Improved Visitor Identification using Adobe’s First-Party Device ID
Photo by George Prentzas on Unsplash