Concept Review: Strengthening User Tracking with Server-Side FPID

[nitesh__anwani]

I am currently working on migrating a legacy implementation based on AppMeasurement.js to the Adobe Web SDK for Adobe Analytics across our sites and apps.
I have reviewed the concept of the FPID, which must be generated by the application server in UUID format and returned to the browser as part of the page response. Because the FPID is set by the server, the browser does not apply the typical lifespan restrictions that apply to JavaScript-generated cookies. Adobe Edge then uses the FPID to issue an ECID, which is derived from the FPID. If the ECID expires, Adobe Edge can regenerate the same ECID when the same FPID is sent again.

This is my understanding of how the FPID mechanism works.
(I am not covering additional details such as the priority rules when an existing ECID cookie is present.)
In summary, today’s inflated Unique Visitor counts—largely caused by frequent cookie expiration—should decrease because visitor identity will remain stable at the browser level.

Background

• We operate multiple sites with multiple user journeys, and users may access them from different browsers or devices. 

• All data flows into a single global report suite, and the Unique Visitors metric is based on the ECID.

• The applications in focus is a content platform where users consume news and reference content across app or website (with single sign-on account).

• From the business perspective, authenticated user traffic and journeys matter most.

Current Challenges

Unique Visitor counts remain inflated due to:

1. Cookie expiration – partially resolved by FPID.

2. Users switching devices or browsers – not solved by FPID.

   • Previously, third-party cookies like demdex helped, but they are now largely blocked and not a recommended solution over a FPID.

3. No cross-platform journey visibility (e.g., app ↔ website).

Proposed Idea (Acknowledging It May Be a Workaround)

Since the FPID is generated by the application server—and the server often has additional user context (past authenticated sessions, personalized links, or internal identity-resolution logic)—this information could be leveraged to improve identity consistency.

Proposed Approach

1. The backend maintains a mapping between each FPID and a user ID in a database.

2. When the server identifies the user, it retrieves the mapped FPID and sets it as the FPID cookie in the browser.

3. If the same user returns on a different device or browser—and the backend identifies them—the same FPID is issued again.

4. Adobe Edge then returns the same ECID, resulting in a consistent identity across browsers and devices.

This approach could reduce Unique Visitor inflation and enable cross-platform journey stitching, using a single server-generated identifier.

Edge Cases to Consider

1. Anonymous → Authenticated Transition

If a user begins a session anonymously and later logs in, the anonymous portion would use a random FPID, while the authenticated portion would use the mapped FPID. This breaks continuity within that specific visit.
However, this may be acceptable since the business primarily analyzes authenticated users, and anonymous pre-login activity is less critical.

2. Authentication Occurring Mid-Session

If parts of the experience require login within the same session, the session may experience two different FPIDs. This would slightly inflate session counts, as the system would treat this as two visits.
The impact may be minor, and authentication metadata could help contextualize such patterns.

Request for Expert Input

I would like to understand how analytics experts view this approach.
What potential risks, limitations, or gaps should I be aware of?

My goal is to identify a solution that provides:

• cleaner and more accurate Unique Visitor counts

• cross-platform journey stitching

• minimal ongoing maintenance after an initial server-side FPID implementation

Side Note

This idea did not originate as a business requirement. It is something I am exploring proactively, which is why I am seeking different expert perspectives from the community.

Any input, thoughts, or feedback would be greatly appreciated.
Thank you in advance!

Thanks,
Nitesh

[SamuelPaulPeter]

Your understanding of FPID is correct:
FPID = stable, server-set identifier → Adobe Edge → stable ECID, unaffected by browser restrictions.

Your proposed idea (reuse the same FPID for the same known user across devices) would technically work, but here’s the key:

1. FPID was not designed to be a cross-device identity

FPID is intended to be a browser-level durable ID, not a user identity solution.
Reusing the same FPID across devices forces Adobe to assign one ECID to multiple devices, which breaks some foundational assumptions of Analytics:

• ECID = “device/browser identity”

• FPID = “server-persisted replacement for ECID”

Once FPID becomes a user ID, ECID becomes user-level too — this affects visitor deduplication, attribution logic, fallout pathing, and bot detection.

2. You would lose device-level analytics

If multiple devices share the same FPID → same ECID → Analytics sees them as one device.

This impacts:

• Device reports

• Technology breakdowns

• Sessionization (session merges across devices)

• Attribution paths skipping actual device transitions

3. Cross-device stitching already exists: Use XDM Identity + Identity Graph

Adobe Experience Platform supports cross-device identity stitching using:

• Authenticated user ID (primary identity)

• ECID

• Deterministic linking via Identity Graph

This is the correct and scalable approach — not forcing FPID reuse.

4. You may violate internal or compliance expectations

If FPID suddenly becomes a “user identifier,” it may fall under stricter data handling rules (GDPR/PII policies) depending on what you map it to.

5. Mid-session FPID switching = visit fragmentation

You already called this out. In practice, this will:

• inflate visit counts

• break activity maps

• break sequential flows (A → Login → B becomes two visits)

What I would normally recommend instead:

1. Let FPID stabilize device identity only

- This solves the cookie expiration problem cleanly.

2. Use a proper authenticated identity for cross-device stitching

In Web SDK, send the logged-in user ID as:

identityMap: {
"customer_id": [{ "id": "12345", "authenticatedState": "authenticated", "primary": true }]
}

This gives you:

• Clean visitor counts

• True cross-device stitching

• Consistent journeys

• No hacking of FPID

• No risk to attribution logic

[nitesh__anwani]

Hi @SamuelPaulPeter ,

Thanks a lot for your response!

I understand that the workaround on FPID to make it as user specific adds significant complexity and may also introduce compliance risks, in addition to creating an operational burden for backend data management.

I’m interested in gaining a clearer understanding of the customer_id + Identity Graph concept. I reviewed the Adobe documentation, but it is not very intuitive from an analytics perspective.

My current understanding is that Adobe Identity Service uses the customer_id across different devices and links all associated ECIDs for the same user within the Identity Graph based on that customer_id. However, it’s not entirely clear to me how Adobe Analytics actually leverages the customer_id in reporting.

Any additional details or clarification you could share would be very helpful.

Also, in our current appmeasurement.js-based implementation, we already send the customer_id in the analytics calls. However, I am not sure how this information is processed by the Identity Service or how it ultimately contributes to cross-device analytics or customer_id–based unique visitor reporting.

Thanks,
Nitesh

[SamuelPaulPeter]

Thanks Nitesh, happy to clarify, because this is one of the most misunderstood parts of the Adobe identity model.

What the Identity Graph actually does

Your understanding is correct:

• When a user logs in, and you send a customer_id

• Adobe Identity Service links all ECIDs (web, app, device A, device B, etc.) to that same customer_id

• This creates one unified identity inside the Identity Graph

So internally, Adobe knows:
ECID-1 ↔ customer_id
ECID-2 ↔ customer_id
ECID-3 ↔ customer_id, etc.

What Adobe Analytics does with customer_id

This is the part that confuses most people:

👉 Analytics does NOT automatically use customer_id for visitor stitching.
Analytics continues to use ECID as the official visitor ID.

So even though Identity Service knows the user is the same person across devices, Analytics reports will still show separate Unique Visitors unless you do one of two things:

How to make Analytics treat customer_id as the “person”

You have two options:

Option A: Use the customer_id as the Primary ID in Web SDK

If you set customer_id as primary when the user is authenticated:

identityMap: {
"customer_id": [{
"id": "12345",
"authenticatedState": "authenticated",
"primary": true
}]
}

Then Adobe Analytics will use customer_id → ECID resolution and report one Unique Visitor for that user across devices.

This is the “official” cross-device stitching method.

Option B: Use Cross-Device Analytics (CDA)

CDA (premium) uses the Identity Graph to unify users across devices automatically.
This is the only way Analytics will truly use the Identity Graph without manual identity configuration.

Why your AppMeasurement.js customer_id doesn’t unify users today

In the legacy AppMeasurement world:

• Sending customer_id in context data or eVars
  does NOT stitch users across devices

• It simply stores customer_id as a normal dimension

• Identity Service does receive it, but Analytics does not use it for visitor ID resolution

This is why cross-device journeys don’t appear unified today.

If you migrate to Web SDK

Then you can:

• Send customer_id in the identityMap

• Mark it as primary when authenticated

• Let ECID handle anonymous states

• Get clean cross-device stitching without touching FPID

This is the modern, scalable approach.

[nitesh__anwani]

Hi @SamuelPaulPeter ,

Thank you again for answering my questions.

I believe this topic deserves its own detailed documentation from Adobe.

In my current implementation, we track the user identifier as a context variable, which we then map to an Analytics variable through processing rules. This is similar to tracking any other user attribute. However, what I was trying to highlight in my earlier message is that we also pass the customer_id to the Identity Service, which then appends it to the Analytics calls, following the approach described in the document you referenced: https://experienceleague.adobe.com/en/docs/id-service/using/id-service-api/methods/setcustomerids 

What remains unclear to me is how this setup would enable Analytics to use customer_id as the Unique Visitor identifier. If passing customer_id does not impact the unique visitor computation, then it adds no real value, because the information we need is already captured in the required eVar.

Regarding the two options you mentioned:

1. Using the primary identity as the customer_id in the identityMap via Web SDK

2. Using the Customer Data Access (CDA) feature — Does this require additional licensing from Adobe?

For Option #1, assuming that with a Web SDK implementation we pass the user ID as the primary identifier in the identityMap within the XDM object, I would like to better understand what happens behind the scenes.

My understanding is that the Identity Service links identities using the customer_id and builds an identity graph across all ECIDs. But what exactly is sent to Analytics that makes it treat customer_id as the basis for Unique Visitor calculations? What changes in the data sent to Analytics to shift UV reporting from ECID to customer_id?

Additionally, what are the implications for segmentation and data feeds?

• Does this affect how visitor-level segments behave?

• Does Analytics begin evaluating visitor-level segments using customer_id?

• Which ECID (or other identifier) is exported in the Data Feeds?

I know I am asking many questions, but there is no clear, Analytics-focused documentation from Adobe that explains this topic end-to-end. Most available documentation discusses identity and customer_id in the context of personalization use cases.

Once I understand the above, I think I can make my use case work. Historical trends will still be based on ECID, which presents its own challenges. However, I can still justify the migration to stakeholders, since we expect unique visitors to drop due to longer cookie lifespans with FPID—reducing the inflation in UV counts.

Thanks,
Nitesh

[nitesh__anwani]

I got confirmation from Adobe Support that Adobe Analytics does not use the Identity Service for visitor identification.

Adobe Analytics continues to use the ECID as the primary identifier.

The Identity Service and the identities built using identityMap are used by AEP applications such as CJA, RT-CDP, etc.

Therefore, passing the user identifier in the identityMap will not solve any use case for Adobe Analytics.