AbiliTec Components

AbiliTec Links are the identifiers that the graph will return for an input, and which represent a person, place, or household in the graph. It is not possible to determine an individual’s name or address by looking at the ConsumerLink, which is a match code capable of powerful recognition and accurate data integration.

16-Byte Link Breakdown with Prefixes

Documents are the foundational data assets of the Abilitec Identity Graph. There are 4 document types (entity, person, place, household). You can think of Documents as "containers" of all associated data/metadata that are tied to a specific node within the Identity Graph

The vast majority of customers do not need to receive DocIDs for their specific use case. For all practical purposes, they can be viewed as another analogous ID that can represent a person/place/household.

Document IDs are backward compatible with link use cases. Contact your LiveRamp representative if you have any further questions about Document IDs.

Document IDs do not contain any of the following information:

The Match Cascade parses the input data into different component parts and then matches on the earliest step in which a match occurs. This methodology ensures the highest match rate to the largest portion of relevant identifiers and can allow clients to understand which components of their records match to different entities in the LiveRamp Identity Graph. Data sent to the Match Endpoint will use the Match Cascade.

The Match endpoint accepts plaintext (raw) PII as input data. This plaintext PII goes through data normalization and uses approximate matching during the matching process. Approximate matching allows for matching in cases such as misspellings, JR/SR conflicts, name swaps, and address formatting variations. The PII is taken through a sequence of matching steps (the "match cascade") utilizing various components of the PII until a match to a maintained AbiliTec Identifier is found. If no maintained AbiliTec ID is found after all steps of the match cascade are performed, a derived AbiliTec ID is returned.

There are two configurations of the match cascade – default and strict. Default cascade is used for a majority of use cases, but the strict cascade has fewer steps and can be used for clients that do not match on email touchpoints.

The LookUp function (available via the LookUp endpoint) does not use a match cascade. LookUp only returns exact matches, and it does not perform any approximate matching on inputs, which allows it to rapidly look up exact matches in the graph. This also enables it to perform domain translation and hashed entity matching.

Domain Translation

Every AbiliTec identifier has a specific encoding to ensure the security and privacy of our partner's data. A partner domain must be specified as a parameter in a call, and the API will allow this translation to occur only if the client has permission from the owner of that domain and that permission has been shared in written form to LiveRamp.

Allowed Hashed Inputs

While the LookUp endpoint can accept plaintext inputs that the client wants to match without using the match cascade, that is not the primary use case. This endpoint has the ability to receive a much wider range of hashed inputs than the Match endpoint. Accepted hashed entity representations are listed in the table below. For PII inputs, entities must be all lowercase and space-delimited before hashing. If you are planning on matching address data, the underlying plaintext address inputs should be USPS CASS certified. Any inconsistencies, invisible or excess characters, or normalization differences will not result in any matches.

The match metadata included in the Match Metadata bundle provides additional insight into which input data was used to generate a match. These include the following flags and values:

The Best Contact Bundle provides a set of flags that can indicate whether a particular postal address, phone number, or email address is the primary one for that individual. Best Contact flags are Boolean values (“TRUE / FALSE”) operators that indicate if the address, email, or phone that was sent matches the one that the Identity Graph has determined is the best one for that user.

Best Contact Flags have valuable use cases, including:

If a record is sent to the API that includes all of the best touchpoints, we will return “true” for all three touchpoint types.

The Email Click Verified Flag is a signal that is used in designating the Best Email Address for a user that could have other uses in building data assets or scoring email address data. Because this signal relies on specific deterministic signals from a small subset of LiveRamp match data contributors, it appears on a subset of “Best Email” addresses, and should not be used as the only filter for understanding active email addresses.

Best Contact Flags include the following:

A ConsumerLink represents an individual. This link helps overcome the challenges of

customer data integration by overcoming conventional issues of consumer touchpoint

processing. It helps you consistently recognize and link individuals across multiple

touchpoints and multiple name representations available in the marketplace. It also

provides the ability to link a consumer across multiple data sets.

The ConsumerLink remains consistent across all places and touchpoints that a

consumer has been recognized, as shown in the example below. The Consumer Link

remains the same for this individual although multiple touchpoints are sent in on the

client file.

Example

AbiliTec uses the following name elements to perform matching. The maximum field lengths and types for each element are as follows:

International name elements may differ, such as

AbiliTec uses Name Suffix information when appending links. The AbiliTec “no conflict” rule states that two, populated, non-identical strings will not be allowed to match, while a populated string compared to a non-populated string is a candidate for matching if other fields meet the scoring threshold.

AbiliTec recognizes the most common last name suffixes including the following:

AbiliTec uses the following address elements to perform matching:

AbiliTec uses ZIP Code only in link assignment. It does not take into account the information in the city or state fields. Two records sent with the same zip code, but with different city and state designators, will output the same link associated with the correct zip code.

Example:

Since the ZIP code actually belongs in New York, the City and State will be disregarded the match, assuming that other match identifiers match the link.

Occupancy-Based Matching means the Consumer Link and Address Link are considered to be a set. An Occupancy-Based Address Link is the standard Address Link returned for Consumer AbiliTec. It is so named because the link returned is more representative of the address associated with an occupant existing in the AbiliTec Match Indices. Therefore, links returned are based on name and address.

Address Only Matching results in an Address Link that most closely represents the

address input data. An Address Only Link is an Address Link associated with only the

address information submitted for linking and is not in any way related to names or occupancies.

There are three reasons that a record sent to the Identity Graph for matching would generate more than one identifier.

Example

Example

Example

The default matching behavior for the API or when appending AbiliTec Links to records in a file or API calls. In order to navigate overlapping identities, we recommend that sophisticated use cases (such as reversing over consolidations or validating the people formations in an existing CRM file) use multi-match. Additionally, using multiple links returned can help increase the overlap with a second- or third-party data set to increase match rate, and help account for identity conflicts or incomplete data in the overlapped data set.