Adobe Experience Platform Web SDK leverages Adobe Identity Service. This ensures that each device has a unique identifier that is persisted on the device so activity between pages can be tied together.
The Identity Service stores the identity in a cookie in a first-party domain. The Identity Service attempts to set the cookie using an HTTP header on the domain. If that fails, the Identity Service will fall back to setting cookies via Javascript. Adobe recommends that you set up a CNAME to ensure that your cookies will not be capped by client side ITP restrictions.
The Identity Service has the ability to sync an ID with a 3rd-party domain (demdex.net) to enable tracking across sites. When this is enabled the first request for a visitor (for example, someone without an ECID) will be made to demdex.net. This will only be done on browsers that allow it such as Chrome) and is controlled by the thirdPartyCookiesEnabled
parameter in the configuration. If you would like to disable this feature all together, set thirdPartyCookiesEnabled
to false.
When migrating from using Visitor API, you can also migrate existing AMCV cookies. To enable ECID migration, set the idMigrationEnabled
parameter in the configuration. ID migration enables the following use cases:
idMigrationEnabled
for a period of time so that most of the visitor cookies are migrated, the setting can be turned off.When XDM formatted data is sent into Audience Manager this data will need to be converted into signals when migrating. Your traits will need to be updated to reflect the new keys that XDM provides. This process is made easier by using the BAAAM tool that Audience Manager has created.
If you currently have server side forwarding enabled and are using appmeasurement.js
. and visitor.js
you can keep the server side forwarding feature enabled and this won’t cause any issues. In the backend, Adobe fetches any AAM segments and adds them to the call to Analytics. If the call to Analytics contains those segments, Analytics won’t call Audience Manager to forward any data, so there isn’t any double data collection. There is also no need for Location Hint when using the Web SDK because the same segmentation endpoints are called in the backend.
If you want to use this unique ID, use the getIdentity
command. getIdentity
returns the existing ECID for the current visitor. For first-time visitors who don’t have an ECID yet, this command generates a new ECID.
This method is typically used with custom solutions that require reading the Experience Cloud ID. It is not used by a standard implementation.
alloy("getIdentity")
.then(function(result) {
// The command succeeded.
console.log(result.identity.ECID);
})
.catch(function(error) {
// The command failed.
// "error" will be an error object with additional information.
});
The syncIdentity
method has been removed in version 2.1.0, in addition to the hashing feature. If you are using version 2.1.0+ and would like to sync identities, you can send them directly in the xdm
option of the sendEvent
command, under the identityMap
field.
Additionally, the Identity Service allows you to sync your own identifiers with the ECID using the syncIdentity
command.
It is highly recommended to pass all available identities on every sendEvent
command. This unlocks a range of use cases, including personalization. Now that you can pass those identities in the sendEvent
command, they can be placed directly in your DataLayer.
Syncing identities allows you to identify a device/user using multiple identities, set their authentication state and decide which identifier is considered the primary one. If no identifier has been set as primary
, the primary defaults to be the ECID
.
alloy("sendEvent", {
xdm: {
"identityMap": {
"ID_NAMESPACE": [ // Notice how each namespace can contain multiple identifiers.
{
"id": "1234",
"authenticatedState": "ambiguous",
"primary": true
}
]
}
}
});
Each property within identityMap
represents identities belonging to a particular identity namespace. The property name should be the identity namespace symbol, which you can find listed in the Adobe Experience Platform user interface under “Identities”. The property value should be an array of identities pertaining to that identity namespace.
Each identity object in the identities array is structured as follows:
id
Type | Required | Default Value |
---|---|---|
String | Yes | none |
This is the ID that you want to sync for the given namespace.
authenticationState
Type | Required | Default Value | Possible Values |
---|---|---|---|
String | Yes | ambiguous | ambiguous, authenticated & loggedOut |
The authentication state of the ID.
primary
Type | Required | Default Value |
---|---|---|
Boolean | optional | false |
Determines whether this identity should be used as a primary fragment in the unified profile. By default, the ECID is set as the primary identifier for the user.