Different UBX endpoints can sometime use different attributes to identify the same customer. Sometimes, the endpoints use different names for the same identifying attribute. UBX can join the different identifier attributes across different endpoints to develop a rich view of specific customer behavior over time and in different situations.
To overcome differences in how various applications identify customers and customer behaviors, UBX examines and compares the different identifying attributes that it receives from various endpoints and published events. Over time, UBX determines which of the different identifiers relate to the same customer. Where possible, UBX compares identifying information across different endpoints to provide the business user with multiple ways to view and reach the customer.
UBX requires that endpoint providers specify the attributes that it uses as customer identifier attributes. When you register an application as a UBX endpoint, you must declare the name and type of all of the attributes that the endpoint might use as identifiers when it publishes events to UBX. Because identifying information can vary by event, the endpoint must also specify which of the declared identifiers it provides when calls the v1/event API to publish an event.
Customer identity association with the x1Id
UBX maintains a database to store unique customer identifiers that are discovered when
the UBX Identity Service evaluates customer identity information that is contained in incoming
published events. UBX defines an x1Id for each new unique identifier that is
discovered when it evaluates incoming events.
Note: During provisioning, identity data storage can be turned off for an account, upon request.
This ensures that no identity information is stored by UBX. However, event and audience exchanges
still retain the identifier information that they are published with until the end of their
Because unique customer identifiers are associated with a particular individual, each
x1Id is also associated with a single customer. However, a single customer can
initiate events in different endpoints that publish event data to UBX. The different endpoints often
associate different unique identifiers with the same customer. In this situation, UBX can sometimes
create multiple x1Id entries for the same person.
Each time UBX receives a published event, it compares customer identity information that is
contained in the incoming event to values for all x1Id entries. Any new customer
identifiers that UBX can correlate to existing records are added to the x1Id
entry. Over time, UBX accumulates unique customer identifiers for the x1Id
entries in the identity store.
UBX continually collects unique identifiers, and compares them to existing known identifiers.
When it finds the same type of identifier, UBX can join the x1Id records for the
individual. The result is a better understanding of how the individual behaves in multiple endpoint
applications. In effect, merging x1Id records gives the marketer a view of the
customer in multiple commercial contexts.
Note: UBX limits the number of identifiers that can be associates with an x1Id to
100. Additional identifiers beyond that limit are dropped and UBX logs an error message.
Suggested unique identifier types
To improve the chances that UBX can detect and join identifiers across different
endpoints, participating applications can use commonly recognized identifiers to identify
individuals who interact with each application. UBX provides a list of suggested unique
For ease of implementation and maximum acceptance across different businesses, the attribute that
an application submits as a unique identifier must adhere to common internet standards, must be
unique among other commonly recognized identifiers, and must be specific to a single individual.
UBX suggests the following list of identifier types as typical of identifiers with an improved
chance of matching across endpoints.
Tip: Always define the identifier name in lower case letters.