Offline Graph

Quickly jump to a specific section using these links:

• The Offline Graph File
• The Offline Graph Workflow
• Output File Fields
• Scores and Indicators
• Use of Offline Graph for Direct Mail
• Telephone Delivery
• Optional Hashed Email File Delivery
• Sample Output File
• Consumer Opt-Outs
• Using the Offline Graph for Matching Your 1st Party Data
• Preventing Reidentification: Separation of Offline PII from Digital Identifiers 
• FAQ

Experian builds and maintains an active universe of 250M adults, defined as individuals 18 years of age and older, across 126M households within the US. The Offline Graph provides a comprehensive license of offline known identity data, encompassing crucial information such as name, postal address, phone number, email address, geographic details, date of birth, and additional data elements that describe the offline identity information tied to those households and individuals.

Experian receives hundreds of deterministic, person-level data sources which is the foundation of a scaled and stable Offline Graph. The types of sources include property ownership, public records, and other forms of marketing data containing identities.

Experian’s offline consumer data is organized with the following groupings, and every consumer has the following identifiers associated with them:

• Person ID (“PID”) – Uniquely assigned to a specific person

• Living Unit ID (“LUID”) – Experian’s classification for a grouping of individuals (or, people) who share a residence, verified using family name, property ownership records, and other data sources

      - Note: In this document, we use the terms “person” and “individual” interchangeably.

• Address ID (“AID”) – Created from the postal address, regardless of all other personal data

Clients can leverage Offline Graph to build or enhance offline consumer data profiles, thereby strengthening their capacity to link data with partners, expanding audience reach, and improving measurement.   

The Offline Graph also powers all of Experian’s identity-enabled products where offline identities are used for resolution and appending of Experian data. Examples include: 

• Offline Identity Resolution, which helps to resolve disparate data points to a single consumer or household.
• Offline Identity Append, which expands clients’ 1P data footprint by appending PII to an input file containing offline PII. 
• Enrichment, where marketing attributes are appended to an input file containing offline PII.
• Collaboration, where parties wish to exchange data using files that contain offline PII which are resolved using our Offline Graph.

This document is focused on the delivery of Offline Graph data. Offline Graph data will either be delivered as a single standalone file or as part of a combined file with Experian Marketing Attributes, depending on what you have contracted with Experian. Regardless of how it is delivered, it can be used across your marketing and advertising use cases.

Our offline consumer data is organized at the following levels for every consumer. The following are standard attributes and are provided in all Offline Graph output files:

• Experian ID’s – These three IDs allow you to create views of consumers at each level of granularity:

            - Person ID (“PID”) – Uniquely assigned to a specific person

            - Living Unit ID (“LUID”) – Experian’s method for of defining offline households 

            - Address ID (“AID”) – This level is representative of the postal address regardless of other personal data

• Name/Address – Person first and last names as well as Postal Street address where a person/Living Unit resides. All postal addresses are USPS® standardized. Address components will be delivered as both consolidated and parsed components per Output File Parameters. Up to 8 people per Living Unit exist in the graph. 

• Scores & Indicators: Data elements, found in the data dictionary in the Name/Address category, are delivered when direct mail is the client use case, offering more context around Postal Addresses. 

The following are optional add-ons and will be provided in accordance with your agreement:

• Email Address – Hashed email addresses associated with people in the graph are available for resolution, linkage, and media activation. They will be provided in a separate file from other Offline Graph data points. Emails are only available in hashed format, details in the Data Hashing section. 

• Telephone – Hashed landline and mobile phone numbers associated with people in the graph can be used for resolution and linkage and will be sent in a separate file. Landline Telephone numbers can be provided in the clear for telemarketing purposes in your Offline Graph file. Special terms and conditions apply.

Experian builds the Offline Graph on an ongoing- and monthly-basis and the most recent version can be obtained at any time. The standard output is a file containing offline PII attributes. This process is done via a batch file transfer, details in the Output File Delivery section. The standard offering covers the full U.S. population. Receiving the Offline Graph is not dependent on any inputs. However, we also support the ability to define a subset that is relevant to you through:

• Geographic Selection - selecting a specific geography (State or Zip Code) to filter the Graph data prior to delivery.

Updated files will be delivered monthly, which is the standard. Other frequencies, like quarterly or annually, are also supported and the Offline Graph would be delivered in accordance with your agreement.

The standard output is a pipe delimited with a header record.

Files can be delivered via secure FTP (sFTP). Delivery to client hosted cloud platforms - AWS S3, Google Cloud, Azure, or Snowflake - are also supported. Note: Delivery to Snowflake, Google Cloud and Azure has an extended set up time of 3-4 weeks.

Files are compressed using gzip option as a standard and we can support PGP key encryption. PGP key encryption just requires time to set up and exchange public keys.

Standard hashing for fields that require it (per the Output File Parameters) is SHA-256.  Where applicable the required preprocessing steps that we take are listed below before hashing the data to SHA-256. 

When hashing data in the Offline Graph to match with other hashed Personally Identifiable Information (PII), it is crucial to apply the same preparation steps to both the Offline Graph data and the data it will be matched against. For detailed guidance on our best practices for hashing each ID type, please refer to our additional documentation.

The following file data category names can be delivered as part of our standard Offline Graph. 

• Offline Graph – ID

• Offline Graph – Name/Address

• Offline Graph – Geography

• Offline Graph – Demographics

 The following two data category names are part of the Offline Graph but, when licensed by a client, will be delivered in a separate file.

• Offline Graph – hashed telephone 

• Offline Graph – hashed email 

For a complete list of all available data in the Offline Graph, please reach out to your Experian point of contact, who will send you our Offline Graph data dictionary. 

Below is more information on different fields in our Offline Graph, which we consider to be Scores & Indicators, that provide more context on the living units in our Offline Graph.  

 Address Quality Indicator

Measures the address deliverability using the USPS Delivery Sequence File (DSF) footnotes and Experian proprietary logic. AQI is a grade specific to the address components and does not include the resident(s) at the address. This is typically only used for direct mail.

NCOA Move Update Code

NCOA method used, if the value in this field is 2, then it was updated by a NCOA link. If the value in this field is 4, then it was updated by an alternative method.

NCOA Move Update Date

Date provided for move by NCOA from USPS software.

Mail Objector

Consumers/Living Unit that have registered their preference regarding receiving direct mail offers. N=Living Units that can be used for direct mail offers; not registered. Y=Living Units that cannot be used for direct mail offers; are registered.

Person 1-8 List Rental Qualified

This defines if a record can be used for direct mail per the source of the data. N=Can not be used for list rental, meaning cannot be sent direct mail. Y=Can be used for list rental, meaning can be sent direct mail.

List Rental Qualified

This defines if a record can be used for direct mail per the source of the data. N=Can not be used for list rental, Y=Can be used for list rental.

Person #: Person Type

Characterizes each person in the living unit according to a role or status, which include D=Deceased, E=Elderly Parent, O=Other, P=Primary Decision Maker, Y=Young Adult, or Blank.

Activity Date

Activity date associated with the living unit/address relationship; from source inputs.

Recipient Reliability Code (RRC)

Combines an internally developed mobility score and USPS® Delivery Point Validation (DPV®) codes. The intersection of these variables creates a comprehensive confidence code that ranks the overall postal deliverability of living unit (LU) members at a “contact point” (i.e. the postal address). The RRC will look like one of the following: 0=Unknown,1=Very High,2=High,3=Moderate,4=Low,5=Telemarketing only/non-deliverable,6=End-dated/address only, used only in combination with Marketing Attributes and the use case is not direct mail. 

USPS Delivery Point Validation codes (DPV)

DPV assists in obtaining accurate delivery address information and facilitates identification of erroneous addresses contained in address files. The use of DPV will help to reduce the amount of undeliverable as addressed pieces, which in turn will result in more efficient postal mail processing and delivery operations.

Mobility Index – uses age of primary decision maker, housing tenure, dwelling unit size, and living unit date of last activity information.

The Offline Graph data contains attributes that may be used for both identity resolution (“linkage”) as well as direct mail. For your use cases where Offline Graph data (ie, Names & Addresses) are used for direct mail, then the following must be true:

• Recipient Reliability Code (RRC) must be 1-5. Note: depending on your specific agreements Experian, we may also deliver End-Dated records with RRC=6. End dated may only be used for identity resolution.

• Mail Objector must be N; and 

• List Rental Qualified must be Y; and 

• Person 1 – 8 List Rental Qualified must be Y

You can receive telephone numbers as part of your Offline Graph. We offer two varieties of telephone numbers, Hashed Telephone for linkage purposes and Landline Telephone in the clear for telemarketing purposes.

Hashed Telephone can be delivered with your Offline Graph and will include both hashed landline and mobile telephone numbers.  

Hashed Telephone will be delivered in a separate file from the Offline Graph with the fields below.

Note: the output file will be at a telephone level, meaning each row is a unique hashed telephone. 

Depending on your specific agreements with Experian, Offline Graph data may contain telephone numbers that can be used for telemarketing.

In this case, telephone number will be included in the same file as the rest of your Offline Graph. These telephone numbers will also be in the clear, not hashed. Additionally, you will receive the following fields below, which give you context on whether the landline telephone number can be used for telemarketing purposes. For any telemarketing use cases the following must be true:

• Phone: state objector must be N, and; (This defines if a record can be used for telemarketing. N=Can be used for telemarketing, Y= Can not be used for telemarketing. )
• Phone: national DNC objector must be N, and; (This is the National Do Not Call Registry and it defines if a record can be used for telemarketing. N=Can be used for telemarketing, Y= Can not be used for telemarketing.)
• Phone: Pander Flag must be N (Consumers/Living Unit that have registered their preference regarding receiving telemarketing offers.  N=Living Units that can be used for telemarketing; not registered. Y=Living Units that cannot be used for telemarketing offers; are registered.)

Hashed email can also be included in your Offline Graph license, for linkage, resolution, and activation use cases. It will be delivered in a separate file.

Note: The output file will be at an Email level meaning each row is a Unique Hashed Email.

This section includes sample data that has been truncated for brevity, but the contents of your text file may appear similar.

Offline Graph File Sample:

1234567899| 9876543211| 012345678| Ms| Dorothy||| Gale|| 1939 Yellowbrick Rd| Box 3 | Toto| KS| 1001| 67900| 1939|| Yellowbrick| Rd| Box| 3||||||| P| 20240628| 4| E| 2| 20240801| N| N| Y|||||||||| 198407| 198407__| 1984|

1234567899|98765543211|71b21eb3bf03a13dddd7589519418dffe0ff7d28dfcaa9c41110f93e8a5f1317

Prep work: 

1. Remove all non-numeric characters and spaces

2. Add US Country Code of ‘1’ to the 10-digit phone (the result is an 11-byte phone number)

3. Hash to SHA256 with no salt

   Example: 

• [555-867-5309] becomes:

• 71b21eb3bf03a13dddd7589519418dffe0ff7d28dfcaa9c41110f93e8a5f1317

1234567899|98765543211|84385a965ca052d4e2e739fbdcf932b81f5e768982097ad2a6f9d650a06dd7f5

Prep work:

1. Lowercase the email

2. Trim empty spaces from the email

3. Hash to SHA256 with no salt

   Example: 

• [dorothy@notthewizardOFoz.xyz] becomes:

• 84385a965ca052d4e2e739fbdcf932b81f5e768982097ad2a6f9d650a06dd7f5

Experian provides a full file weekly of consumer opt-outs via the same delivery path as the Offline Graph. Opt-outs should be applied to Experian data weekly and must be applied to all instances of Experian data that you received.

The following file layout will be used when delivering consumer opt-outs.

A common application of the Offline Graph is to match client first-party data. To achieve high accuracy and match rates, we recommend using a waterfall approach. Given the variability in first names compared to last names, the following matching sequence is advised:

1. Run Postal Standardization Software: If possible, standardize the client’s PII using postal software.

2. Match on Full Name and Address.

3. Match on First Initial, Last Name, and Address.

4. Match on First Initial, Last Name, and Zip Code. 

5. Match on Hashed Phone.

6. Match on Last Name and Zip Code.

Experian is a member of many adtech industry standards organizations, including NAI (Network Advertising Initiative) and DAA (Digital Advertising Alliance). Both organizations set standards for the collection, handling and use of digital identifiers. The crux of these standards is based on how the digital identifiers that Experian receives and uses to build the Digital Graph, such as IP addresses, mobile advertising ID’s, and cookies.  

At the time of collection, they are pseudonymized at the source. Experian is therefore obligated to ensure that these digital identifiers remain in a de-identified or pseudonymized state. Our approach to this is to maintain the physical separation of any offline identifiers (PII) from digital identifiers. These obligations apply to us, our clients, and any downstream party receiving or using the data. 

Offline Graph and Digital Graph may still be linked and referenced via pseudonymized ID’s but they may not be merged in any way that creates a single combined dataset or reidentifies any data. We provide Experian ID’s, the Living Unit ID (LUID) for example, as an ID that resides in both the Digital and Offline Graphs. 

To the extent that you receive both Experian’s Digital Graph and Offline Graph, this ID will be present in both Graphs and will allow you to query and cross-reference the data for your use cases without the need for merging data together. This separation of data also applies to the extent that we may provide an Experian ID appended to your own 1st party offline identifiers, either instead of or in addition to providing you the Offline Graph.

The terms of your agreement with Experian will contain language that is the same or very similar to the following: 

Prohibition on Re-Identification: In no event shall Client directly or through any third-party attempt, combine, or allow an attempted combination of the Experian Data (Offline Graph) with PII or in a manner that would allow for Reidentification. Client shall not combine any Offline Graph data with any other data that would allow for Reidentification of the data contained in Graph Services or permit any third party to engage in such Reidentification. Client must also implement technical safeguards and business processes that prohibit Reidentification of any consumer to whom the Graph Services provided under this Order may pertain and cooperate with any requests from Experian to ensure that Client has complied with this section

You are free to determine your own technical architecture. We do not prescribe this. However, we recommend considering the following when implementing Experian Graph data in your organization: 

• Ensuring separate data repositories for storing Offline Graph (or 1P Offline identifiers that have been appended with Experian IDs such as the LUID) and storing Digital Graph data. For clarity:

• Experian Offline Graph data may be stored in combination with your own offline data

• Experian Digital Graph data may be stored in combination with your own digital data.

• Ensuring data access controls for users that limit the ability to merge Offline Graph (or 1P Offline identifiers appended with Experian ID’s) and Digital Graph.

• Regular internal auditing and reviews to ensure Offline Graph and Digital Graph data has not been merged.

• The only acceptable method for including both Offline Graph data and Digital Graph data in the same dataset is as follows:

• Hash Offline Graph Data: Ensure the Offline Graph data is hashed in its own dataset.

• Hash Digital Graph Data: Similarly, hash the Digital Graph data in its own dataset.

• Combine Hashed Data: Combine the hashed versions of both datasets using a common ID.

It is crucial that this hash is non-reversible, and no Personally Identifiable Information (PII) or Digital IDs should be added to the dataset before hashing.

A common use case of Experian Data is connecting digital activity to offline profiles and enabling targeted direct mail campaigns. To ensure compliance, direct mailing can occur only if all addresses in a selected zip+4 are included in the outreach. Any zip+4 that are mailed must have at least 10 PIDs in said zip+4. The following rules and filtering procedure must be adhered to:

• The Offline Graph universe must be filtered to include only those ZIP+4 codes that have at least 10 PIDs.  

• This filtering process must be refreshed each time the Experian data is delivered to ensure accuracy and relevance. 

• The output file will include the following fields: LUID, ZIP+4, and Address and shall not contain other identifiable PII. 

• Mapping LUIDs to ZIP+4 and selecting all associated addresses to compile a direct mail list. 

Below are a variety of frequently asked questions pertaining to Experian IDs and how our Offline Graph accounts for real-world scenarios:

• What is the Living Unit, the Living Unit ID (LUID), the Person ID (PID), and their respective value?
• What types of living units are there?
• What happens when individual(s) move?
• What happens when new household members are added?
• What happens with deceased individuals?
• Do you use any other data types to create profiles for individuals or Living Units, such as data from the US Census or other demographic attributes beyond just PII?
• What other data address hygiene and quality steps are used to ensure the current nature of Living Unit data?
• How does the Offline Graph handle multi-familiy dwelling units?

Living Units and Living Unit IDs (LUIDs)

Experian organizes its household-level consumer profiles around the concept of Living Units. The Living Unit methodology works to determine all the individuals that belong together regardless of whether they have a consistent surname or not. This determination is based on multi-sourced information and our proprietary methodology that determines whether individuals should be grouped together and does not rely solely on common surnames or shared postal addresses.

Every Living Unit is assigned a Living Unit ID (LUID) that remains with the household until such time as there is a change in composition, such as a person moving in or out of a household. In those cases, a portion of the household would remain with the original LUID and individuals who may have moved out would receive a new LUID at their new postal address. However, outside of these dynamics, LUIDs generally persist over time and will remain stable even when a complete household relocates from one address to another.

This definition of Living Unit and the underlying logic means that individuals could represent a traditional family, cohabitants/roommates, or people living in a group setting that do not share the same family name. We use a variety of rules, in addition to multi-sourced data, to group individuals into a living unit.

Person IDs (PIDs)

In addition to the Living Unit/LUID, Experian assigns a unique Person ID (PID) for individual adult consumers within the Offline Graph. Each PID in the Offline Graph will have a LUID associated with it, and multiple PIDs can be assigned to the same LUID, when there is sufficient evidence to group them. Much like LUIDs, PIDs remain persistent so long as sufficient signals are received on a person’s identity over time. 

Value of LUIDs and PIDs

Lastly, our LUIDs and PIDs connect data across the entire Experian product suite, enabling clients to receive a more comprehensive picture of consumers by providing the data and identity needed to support a variety of use cases, across the offline, digital, and behavioural worlds. For example, a client licensing our Marketing Attributes with our Offline Graph can use the LUIDs and PIDs as the keys across both deliverables, enabling the client to connect the outputs they receive from Experian.  

Within Experian’s known offline identity data, there exists the concept of Active and End-dated Living Units, represented in the Offline Graph file by the Recipient Reliability Code (RRC). 

• Active Living Units represent households where the current population has active source signals, represented by RRC values 1 through 5. 

• End-dated Living Units are when there is an inactive or archived record, meaning Experian no longer receives sufficient signals from our data sources to maintain the living unit as current, which is represented by RRC 6. 

  Note: The End-dated Living Unit classification is not necessarily permanent; it just means Experian has not received active signals for that Living Unit. We maintain records in an End-Dated state for up to three years. Anytime there has not been activity on a profile for over 3 years, we drop these records from the Offline Graph altogether. 

  Example: When an individual moves and changes their address information, there can be a gap in information preventing us from updating their profile and confidently associating their LUID with their new address. This can result in us end-dating their LUID. However, as soon as we receive active signals again, then the LUID, which may have been temporarily end-dated, can be reinstated as active.

Our recommendation is that for identity resolution and data linking use cases, using both the Active and End-Dated universes help to maximize match rates. For use cases that may involve offline targeting, such as direct mail campaigns, using just the Active universe would be appropriate.

Scenario 1: An entire family or group of cohabitants move from one location to another location together. 

• Result: The existing assigned Living Unit ID would move to the new address with them. Many times, we receive this data one by one for each individual. Once we get the move information for each member of the living unit, indicating they have all moved to the same, new address, the oldest living unit is kept for that group.  

Scenario 2: An individual moves to a new address/residence.

• Result: Experian’s systems become aware of this data when an update is made to an approved individual source-level information, like USPS® NCOALink® – ie, National Change of Address. If information is received for only one member (John Doe) of a Living Unit -- without clear indication that other members of the same Living Unit have moved – the person level identifier is moved to the new address, and a new Living Unit identifier will be created. Meanwhile, the original Living Unit would retain the pre-existing Living Unit ID. This process will also account for temporary changes of address that are filed. 
• Example: If John Doe moves from 123 Main St. to 345 Second St. and this information is provided from a source that does not link old and new address information together, Experian will create a new PID and LUID at the new address, as well as maintain the existing record (PID/LUID/AID combination) in an end-dated status. Once information is received that confirms that both John Doe records are the same individual, John Doe will revert to their original PID, but keep his new LUID. If we receive indication that John Doe is now actually living as part of the existing  Living Unit ID at 345 Second St., say via Property Deeds, then we would be able to merge John Doe into the existing Living Unit ID and end-date the recently assigned Living Unit ID. 

A new Living Unit ID is not necessarily assigned if someone moves in or out. However, if an individual moves from one Living Unit where there had been multiple individuals, that individual will get a new LUID at their new address. The persons that stay at the old address will retain their original LUID. This would remain the case unless there is sufficient evidence that the moving individual should be merged into the existing LUID – for example, using property ownership data.

If one person were deceased and identified as such, their person type is changed accordingly. Any living persons would remain in the Living Unit, although person and/or person type relationships could be reassigned. In the case of two individuals within a Living Unit where both are deceased, they would also both be coded as deceased people. If there are no remaining living adult persons in the Living Unit, then that Living Unit would cease to exist.

Experian does not use other data types to inform the composition of individual or household level profiles. Profiles are reflective of Experian sourced data and the ability to link data is dependent on those sources. Experian uses metrics from US Census to help identify gaps in coverage and uses it as a guide towards acquiring new sources of consumer data to feed the Offline Graph.

A multi-tiered quality control process is used to compare and cross-check input source data to identify and investigate any discrepancies. This process involves the comparison of a sample of updated records that are analysed at an attribute level for changes and trends in individual consumer characteristics. In addition, Experian compares the Offline Graph data to benchmark against other internal truth sets to further inform data sourcing strategy.

 Experian regularly evaluates each source to ensure that data quality standards are being followed. These evaluation processes include items such as:

• The USPS National Change of Address (NCOALink) file - A databank of more than 160 million permanent address changes updated on a weekly basis. It is comprised of 48 months of reported move information. NCOALink identifies movers at the individual, family, and business level. Experian validates the offline graph database against the NCOALink file monthly to ensure the recency of offline profile data. 

• The Locatable Address Conversion System (LACSLink®) - This USPS database converts non-standardized rural-formatted addresses to standardized city-formatted addresses. LACSLink also detects address changes due to the renaming of a street or additional information that was altered to improve the accuracy of delivery. 

• The Delivery Sequence File (DSF2®) is the USPS listing of all deliverable addresses in the country. The use of the DSF2 file ensures that Experian is building households around only residential addresses.

The Offline Graph dataset contains a variety of address types, like Single-Family, Multi-Family (like small apartment building or condos), PO boxes, and high-rises. Experian may not always have a specific Apartment or Unit number included with the postal address information. In these cases, you may observe multiple active LUIDs at the same postal address. 

Experian has data sources, such as property and deed data, that indicate whether an address contains one or multiple households living there. Often, this data is more granular than what the USPS can provide. As a result, there are instances where a postal address may be considered a Single-Family Dwelling Unit by the USPS but Experian has received additional offline signals (such as property and deed data) to indicate that multiple active Living Units are present at the address. To allow for filtering between postal addresses that Experian has determined to be associated with Multi-Family vs Single Family Dwelling Units, a Dwelling Type field is supplied.

For more on dwelling units, check out the Offline Graph Data Dictionary. To get the Data Dictionary, please work with your Experian point of contact.

^{Last Updated: 10/23/2025}

^{Last Reviewed: 10/23/2025}