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