Skip to main content

AbiliTec Components

AbiliTec Identifiers

There are two types of identifiers that can be pulled from the graph for use in data unification and linking. These are backward compatible, and in most cases can be used interchangeably.

Links

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.

AbiliTec-Link-structure-diagram.png

16-Byte Link Breakdown with Prefixes

Link Part

Description

Format

Example

Domain

Specifies the encoding value

4 alphanumeric characters

T001

Country Code

Code for country graph matching to

2 numeric digits (ISO-2 Country Standard) ZZ is used when ISO-2 does not assign a Country Code

US

Link Type

Distinguishes the type of link – Maintained, Derived, Consumer, Address, etc.

2 numeric digits

01

Value

This represents the value portion of the link

8 alphanumeric characters

abcd1234

AbiliTec Link Types

There are three types of links that a user can request from an input record. These links allow clients to use varying precision levels for better customer insight and more effective targeting and suppression.

  • A ConsumerLink represents an individual. AbiliTec assigns a ConsumerLink by using the following: First Name, Last Name, Middle Initial/Name, Name Suffix, Primary Number, Pre-Directional, Street Name, Street Suffix, Unit Designator, and ZIP (Postal) Code, Email and Phone (“Alan J. Wright, Jr., 220 E. Apple St., 72205”, for example).

  • An AddressLink represents a site or physical location. AbiliTec assigns a ConsumerLink by using the following: Primary Number, Pre-Directional, Street Name, Street Suffix, Unit Designator, and ZIP (Postal) Code (“220 E. Apple St. 72205”, for example).

  • A HouseholdLink represents adults living together at the same location who exhibit a persistent relationship. This includes both traditional and non-traditional definitions of a household. It uses the following: First Name, Last Name, Middle Initial / Name, Generational Suffix, Primary Number, Pre-Directional, Street Name, Street Suffix, Post Directional, Unit Designator, Secondary Number, City, State, and ZIP (Postal) Code.

The description of each link type, as well as the code for identifying it in the link, is explained below. Note that all links can be maintained or derived.

Identifier

Description

Link Type Code (Maintained)

Link Type Code (Derived)

ConsumerLink

A ConsumerLink is unique to each individual.

01, 02

11

HouseholdLink

A HouseholdLink denotes a group of individuals that share a primary residence and likely make purchase decisions as a unit.

08

18

AddressLink

An AddressLink is a unique identifier for a physical business or residential address.

03

13

Maintained and Derived Links

All link types can come in maintained or derived form, depending on whether or not they match with a record in the graph.

  • Maintained links are returned when we have a match for the input data in the AbiliTec Identity Graph. These IDs are maintained in the graph, and so are persistent.

  • Derived links, unlike maintained links, are not maintained in the AbiliTec Identity Graph. They are algorithmically derived based on the client input data. The same touchpoint will consistently output the same derived link on input.

Understanding Derived Links

AbiliTec accomplishes 100% file coverage by assigning derived links to all consumers and addresses for unrecognized input data. When AbiliTec assigns a derived link, it is not indicative of data quality, move status, or any form of intelligence. It simply means that AbiliTec was unable to recognize the input information. This feature allows AbiliTec to be useful as a primary key for data records since it will persistently generate matching links using approximate matching even for records that are not recognized so that the client does not have to build separate logic or IDs for unrecognized records.

New data content is added to the AbiliTec Identity Graph on an ongoing basis. Therefore, records that receive derived links can receive maintained links at some point in the future. LiveRamp does not provide mappings of derived links that have been retired and consolidated into maintained links. It is recommended that all derived links be re-run through AbiliTec quarterly to take advantage of any new occupancy records that have been added to the Identity Graph. This can be handled by rerunning the touchpoints that generated a derived link on a previous run in a future build and then replacing it with a Maintained Link if one is returned. Since the build occurs each month, this does not need to be done more often than monthly.

Derived Link Characteristics

  • Guarantee 100% record coverage from an input file

  • Generate links consistently for the same input data

  • Do not link individuals across multiple addresses (secondary and unit designators are not included in creating derived AddressLinks)

  • Are not maintained by AbiliTec

  • Are not automatically promoted to maintained links

  • Change periodically with updates

  • Collisions can occur

Derived Link Collisions

Derived link collisions occur when, as a result of mathematical calculations, completely different names generate the same (derived) value, as the following example illustrates.

Thomas Wilson

123 Main St.

T001US1187654321

Jeremey Keeley

456 1st St.

T001US1187654321

Derived links are returned most often for general delivery addresses, military addresses (APOs), or addresses in U.S. territories like Puerto Rico and the U.S. Virgin Islands, so the number of collisions in these populations may be higher than normal. This occurs because the more derived links generated for geography, the more collisions can occur. If a large number of derived links are returned, the increase in collisions is exponentially increased.

Generally, collisions do not occur within the same postal code. When using derived links for customer data integration, it is recommended that a combination of the ZIP code and the link set be used. A link set is a ConsumerLink and an AddressLink.

Document IDs

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.

AbiliTec-DocID-structure-diagram.png

ID Part

Description

Format

Example

Domain

Unique customer encoding code for IDs

4 digits

T321

Realm

Environment in which IDs will be stored (known realm is 00)

2 digits

00

Country Code

Each country has a distinct graph in order to maintain compliance in each market. For derived DocIDs, this will be “ZZ”.

2 digit ISO code

US

Reserved

This space in the ID is reserved for future use cases

2 digits

00

Value

Unique value that represents associated data

28 digit

See below

Document IDs do not contain any of the following information:

  • Document class

  • Bundle information

  • Attribute values from the document

  • Request parameter values

  • Anything specific about the type of request that returned the document ID

Match Types

The AbiliTec Identity Graph has three ways in which it can match input data – Default Match Cascade, Strict Match Cascade, and LookUp.

Tip

Match Performance Guiding Principle

As a general guideline, the more data that is sent to the graph for matching (such as PII, in addition to name and address or digital components), the more accurate the match.

Match Cascade

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.

AbiliTec-match_cascade_diagram.png

LookUp Function

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.

Entity

Hash Types Accepted

Email

MD5, SHA1, SHA256

PhoneNumber

SHA1

FirstName LastName Address City State ZipCode

SHA1

FirstName LastName GenerationalSuffix Address City State ZipCode

SHA1

FirstName MiddleInitial LastName Address City State ZipCode

SHA1

FirstName MiddleInitial LastName GenerationalSuffix Address City State ZipCode

SHA1

FirstName LastName Email

SHA1

FirstName LastName Zip

SHA1

FirstName LastName PhoneNumber

SHA1

Address City State ZipCode

SHA1

FirstName LastName GenerationalSuffix Email

SHA1

FirstName LastName GenerationalSuffix PhoneNumber

SHA1

FirstName MiddleInitial LastName Email

SHA1

FirstName MiddleInitial LastName GenerationalSuffix Email

SHA1

FirstName MiddleInitial LastName PhoneNumber

SHA1

FirstName MiddleName LastName Address City State ZipCode

SHA1

FirstName MiddleName LastName Email

SHA1

FirstName MiddleName LastName GenerationalSuffix Address City State ZipCode

SHA1

FirstName MiddleName LastName GenerationalSuffix Email

SHA1

FirstName MiddleName LastName GenerationalSuffix PhoneNumber

SHA1

FirstName MiddleName LastName PhoneNumber

SHA1

AbiliTec Data Bundles

AbiliTec can provide several bundles of supplemental data and metadata that can provide additional insight into client’s customer data, and that can provide powerful signals for making decisions based on AbiliTec links or for building applications on AbiliTec link data.

Match Metadata Bundle

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:

Match Components

Input parts that contributed to the match

Distinct Match

The distinct match flag for person and place documents is only equal to true when there is only one distinct document ID for a given match cascade step. For entity documents, the distinct match flag is only equal to true when there is only one unique ConsumerLink for that entity.

Match Confidence

Indicates the confidence in the match. Corresponds directly to the step in which it matched in the cascade (see matchComponents).

Name Match Integrity

Indicates whether part or all of the major name components were used to obtain the match.

Best Contact Bundle

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:

  • Determine which record to designate as the primary one when making consolidation decisions based on duplicate AbiliTec Identifiers.

  • Target campaigns to gather better contact data for existing customers.

  • Coordinate multiple touchpoint campaigns.

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:

Flag Name

Description

Sample Value

Best Postal Address

This flag will return “TRUE” if the address used for making a match is the best one for that consumer in the graph. This flag is only available for people documents.

TRUE

Best Phone Number

This flag will return “TRUE” if the phone number used for making a match is the best one for that consumer in the graph. This flag is only available for people documents.

TRUE

Best Email Address

This flag will return “TRUE” if the email address used for making a match is the best one for that consumer in the graph. This flag is only available for people documents.

TRUE

Email Click Verified

This flag indicates that a source in LiveRamp’s match network has verified a click on a link within a user’s email address. This flag is only available for entities documents.

TRUE

Matching Elements

In Consumer Linking, three types of links can be returned:

  • Consumer Links (Individual level)

  • Address Links (for address information)

  • Household Link (for groups of individuals living together)

By default, AbiliTec employs occupancy-based matching, meaning that name and address are used together when matching to the graph. The combination of occupancy-based matching with approximate match logic allows AbiliTec to overcome transpositions within primary numbers, multi-match situations, or missing or invalid secondary number information. If clients are interested in other levels of Address linking, AbiliTec does offer a Street Front and Address Only level link as well. These options are covered later in this document.

Using Consumer Links

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:

Name

Touchpoint

ConsumerLink

John Young

123 Main St 60672

DDDDUS01B123C567

J Young

John.young@gmail.com

DDDDUS01B123C567

John J. Young

555-555-1234

DDDDUS01B123C567

Name Elements

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

  • First Name: 25 characters

  • Middle Initial: 1 character

  • Last Name: 25 characters

  • Suffix Title (Name Suffix): 6 characters

International name elements may differ, such as

  • Given Name 1: 25 characters

  • Given Name 2: 25 characters

  • Family Name: 25 characters

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:

  • SR, SENIOR, 1, 1ST, FIRST, I

  • JR, JUNIOR, 2, 2ND, SECOND, II

  • 3, 3RD, THIRD, III

  • 4, 4TH, FOURTH, IV

AbiliTec-name_elements_diagram.png

Address Elements

AbiliTec uses the following address elements to perform matching:

  • Primary Number

  • Pre-Directional

  • Street Name

  • Street Suffix

  • Post-Directional

  • Unit Designator

  • Secondary Number

AbiliTec-address_elements_diagram.png

AbiliTec uses ZIP codes only in link assignments. It does not consider 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:

New York

NY

100011

DDDDUS01B123C567

Los Angeles

CA

100011

DDDDUS01B123C567

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

Occupancy-Based Matching

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

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.

Multi-Match

Fairly often, records that are matched to the AbiliTec Identity Graph will return more than one link in response. These responses can mean a variety of things and can function as very useful tools for reversing over consolidations on an input file or maximizing reach.

Links will always be returned back in the order in which they are returned in the match cascade.

When Will a Record Match to More than One Identifier?

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

. Input Record Overconsolidation
  • You will know that this has occurred if there is more than one maintained link returned for a record.

  • Records will only match to more than one link if the input PII matches a step in the match cascade.

  • This will only occur if you have specified a link return value greater than “1”.

Example

Name

Postal

Email

Link

Match

John Cook

123 Main St., Sacramento, CA 60672

jcooke@gmail.com

T001US01B123C567

Name, Address

T001US01B431V59

Email

. Input touchpoint not recognized
  • You will know that this has occurred if one or more of the links returned from an input are derived links.

  • Records will only match to more than one link if the input PII matches a step in the match cascade.

  • This will only occur if you have specified a link return value of greater than “1”.

Example

Name

Postal

Email

Link

Match

John Cook

123 Main St., Sacramento, CA 60672

jcook@gmail.com

T001US01B123C567

Name, Address

T001US11B431V59

Email

. Shared Touchpoints
  • You will know that this has occurred if more than one maintained link is returned

  • You can determine that this is the case if the link appears attached to more than one maintained link along with match metadata that does not indicate that a match was made on a full name.

  • The most frequent shared touchpoints are phone and address, particularly when name is not used to generate a match.

  • These most often occur for individuals that share a current household or individuals that have the same historical touchpoint (perhaps a past residence), that may be current for one and not current for another.

  • Records will only match to more than one link if the input PII matches a step in the match cascade.

  • This will only occur if you have specified a link return value greater than “1”.

Example

Name

Postal

Phone

Link

Match

John Cook

123 Main St., Sacramento, CA 60672

(555) 555-5555

T001US01B123C567

Name, Address

T001US01B431V59

Phone

Christina Thomas

123 Main St., Sacramento, CA 60672

(555) 555-5555

T001US01B123C567

Address

T001US01B431V59

Name Phone

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.