Location Hints, AAM DCS Regional Nodes, and ID Service Location Hints

Learn about the relationship between Adobe Experience Platform (AEP) WebSDK Location Hints, Experience Cloud ID Service location hints, and Adobe Audience Manager (AAM) DCS Regional Nodes.

Description description

Environment

Issue/Symptoms

What is the relationship between AEP (Adobe Experience Platform) WebSDK Location Hints, Experience Cloud ID Service, location hints, and AAM DCS Regional Nodes and why is it important to understand this relationship?

Resolution resolution

AEP WebSDK (which sends data to Experience Edge) and Adobe Audience Manager (AAM) real-time data collection happens at regional nodes dispersed worldwide. There are 7 regional nodes and AEP WebSDK/Experience Edge and AAM data collection use the same nodes. AAM’s Data Collection Servers (DCS) utilize the same network infrastructure that make up the Experience Edge. Similarly, since Experience Cloud ID service utilizes AAM technology, the ID service location hints are the same as the AAM regional data collection nodes. In other words, AAM DCS Nodes = ID service Location Hints =  Experience Edge location hints. AAM’s regional nodes are outlined in this documentation, whereas the same Experience Edge’s regional nodes are outlined in this documentation.

Even though AAM’s regional nodes and ID service location hints are identified by numbers and Experience Edge’s are identified by alphanumeric characters, you’ll notice that they all align to the same areas (except Brazil).  The below lookup table demonstrates how they line up:

Most Adobe Experience Cloud functionality that requires real-time responses utilize these regional nodes. The first call ID Service or Experience Edge call on a web page or mobile app determines which regional node to use. The location hints can be found in response to these calls:

Experience Cloud ID Service:

AEP Web SDK:

Once the closest regional node to the end user is determined, the region identifier is passed via Analytics, Target, and AEP WebSDK calls going forward. In Analytics, it is passed as the aamlh query string parameter:

In Target, it is passed in the experienceCloud.audienceManager.locationHint object of the request payload:

For AEP Web SDK, the path of the call is updated to reflect the regional node:

Note:  The first interact call from AEP WebSDK will NOT have the region in the path because, the region hasn’t been determined yet, but the location hint will be in the response (as noted above). The path of the original request will just be ..../ee/v1/.... However, subsequent calls will include the regional node information between the /ee/ and /v1/ path elements.

These parameters ensure that server-side forwarded Analytics data is forwarded to the correct AAM edge node, that Target requests segment information from that same edge node, and that AEP data sends data to AAM’s (and Audience library’s) correct regional node.

This information is important to know when sending server-side or user-side hits in non-standard ways to Adobe’s solutions. For example, a manually constructed AEP WebSDK call on a page purely for syncing an ECID (Experience Cloud ID) with an AEP profile needs to be sent to the correct Experience Edge regional node. If it isn’t, then any data shared from AEP to AAM will go to the AAM backend database and then take an additional 48 hours for AAM to push that data to each edge node, drastically slowing down the time Target would be able to use any AEP segments sent to AAM (or Audience Library). Or if a server-side Analytics request is sent to node 7, but the user’s on-page Target implementation uses region 9, then the data will be forwarded to AAM’s US East node, while Target is pinging the US West node for segment information. The end user wouldn’t be able to qualify for any Target activities using Audience Library audiences/AAM segments until the end nodes synced up 24-48 hours later. It’s standard practice in use cases like these to get the ECID using the getMarketingCloudVisitorID (ID service) or getIdentity (Web SDK) functions. However, in addition to getting the ECID, the location hint must also be retrieved and used by using the getLocationHint (ID Service) function or by retrieving it from the response payload of Web SDK calls.

Ask Questions In Our Experience League Campaign Community
If you have any questions you’d like answered about this topic, or read previous answered-questions, we invite you to view our Experience League Community blog post that includes this article, send us your questions and comments, and join our Experience League Campaign Community!