Experience Cloud ID Service, setCustomerIds and FPID

[bjoern_k]

Hey guys,

with the immanent demise of third-party cookies, assuming that in one year from DEMDEX is history and even the first-party cookie approach's cookie lifetime drastically cut through ITP, more limitations likely to happen, I have a general question:

For AEP, it is recommended to create your own FPID cookie that is written server-side, and pass it into the "identityMap" XDM object, see also.

Now, without the Experience Platform and relying on the Experience Cloud ID Service to reidentify the user, I was wondering whether one could not use the same approach i.e.,

• set up a service that creates and returns a server-side cookie in the specified format
• pass this into the Visitor service using the setCustomerIds function

Any thoughts on this? Does this even make sense and will this help to reidentify the user even if the ECID first-party cookie set through your own tracking subdomain expires?

Summary:

with DEMDEX cookies soon being history since all browser are blocking 3rd-party cookies, plus ITP limiting Adobe's 1st-party cookie lifetime, how can I make sure

• to identify the same user on the same device
• that is not logged in / has no loyalty card number or similar
• for as long as possible
• on every major browser?

Cheers from Switzerland

Björn 

[yuhuisg]

A far simpler alternative: if your website exists in one single domain only, e.g. foo.com, then you don't have to worry about the third-party demdex.net cookie to help ECID identify the same users in different domains.

In that case, you can rely entirely on the ECID being generated server-side via Web SDK. In your implementation, don't add any of the ECID "Visitor" code. Or if you're using Tags for managing your tags, then you can uninstall the ECID extension. Without this client-side ECID code, Web SDK will have to generate the ECID from the server-side.

BTW based on my experience with the "setCustomerIds" function, I found that my customer IDs were always tracked in addition to the ECID. I don't know if I was doing something wrongly or that is just how customer IDs work, but basically, I could never get my customer IDs to replace ECID itself.

[bjoern_k]

Hi, I was more referring to clients without WebSDK and relying on the "old world".

As I understand it, ITP is already detecting "cloaked" analytics calls through a first-party CNAME that ends up on an Adobe server writing the set-cookie header.

In which case Safari is downgrading the cookie lifetime to 7 days.

See blogs about this here and here.

So, if I could create my own self-hosted web service that creates a UUIDv3 and stores this as a server-side cookie, this information will - at least on ITP browser - be stored for longed that the classic first-party cookie with the ECID that is generated from Adobe, leading to more precise visitor and visit numbers, no?

The general question is now, how to best integrate this in the classic Visitor ID Service approach?

---

@yuhuisg wrote:

BTW based on my experience with the "setCustomerIds" function, I found that my customer IDs were always tracked in addition to the ECID. I don't know if I was doing something wrongly or that is just how customer IDs work, but basically, I could never get my customer IDs to replace ECID itself.

---

That is an interesting point. I guess the "standard" use case for "setCustomerIds" would be a loyalty card number as soon as the client is logged in.

In my case above, the point is not about identifying the user cross-channel, but making sure to identify the user on the same device for longer, assuming the ECID cookie is limited to 7 days only.

Hope that makes it clearer

Björn

[VinayC]

You can always setup your own unique visitor ID for each visitor using a session based first party cookie.
The disadvantage of such an approach is that these unique visitor ID values might change with every session. 
So In a longer time period report, you might get multiple ID's against a single IP.

I would still rely on ECID as a unique identifier for a user.

[bjoern_k]

Why would I want to have a session-based first-party cookie if I can generate something server-side that enables a 2-year cookie?

That's what it's all about Assuming that in one year from DEMDEX is history since all browser are blocking 3rd-party cookies, how can I at least make sure to identify the same user on the same device, that is not logged in / has no loyalty card number or similar, for as long as possible?

Cheers