For a simplified overview of our person fields, check out the Person Data Overview.
For more details about our person fields, including fill rates and which fields are included in the base vs premium field bundles, check out our Person Stats pages.
For a full data ingestion JSON schema, check out this page.
If you'd like access to premium fields or have questions about which fields are included in your specific field bundle(s), please speak to one of our data consultants.
Identifiers
first_name
Description
The person's first name.
Data Type
String
Field Details
The person's first name.
Example
"first_name": "sean"
full_name
Description
The person's full name.
Data Type
String
Field Details
The first and the last name fields appended with a space.
Upcoming Person ID Maximum Length Change in October 2023
We will be adjusting the maximum character length of PDL Persistent Person IDs. We will be launching this change in October 2023 to allow for ample time to adjust any of your processes impacted by this change.
Currently, IDs are 27 characters long. We recommend allowing for a 64 character maximum for our IDs and will not have any IDs beyond this length, but in practice we expect the changes to result in IDs closer to 32 characters in length. Existing IDs will not change or change length. Only newly created IDs will have the new length.
Example
"id": "qEnOZ5Oh0poWnQ1luFBfVw_0000"
last_initial
Description
The first letter of the person's last name.
Data Type
String (1 character)
Field Details
The first letter of the person's last name.
Example
"last_initial": "t"
last_name
Description
The person's last name.
Data Type
String
Field Details
The person's last name.
Example
"last_name": "thorne"
middle_initial
Description
The first letter of the person's middle name.
Data Type
String (1 character)
Field Details
The first letter of the person's middle name.
Example
"middle_initial": "f"
middle_name
Description
The person's middle name.
Data Type
String
Field Details
The person's middle name.
Example
"middle_name": "fong"
name_aliases
Description
Any other names the person goes by.
Data Type
Array [String]
Field Details
Any associated names or aliases besides the primary one used in the full_name field.
Example
"name_aliases": [
"andrew nichol",
"r andrew nichol",
"robert nichol"
]
Contact Information
emails
Description
Email addresses associated with the person.
Data Type
Array [Object]
Field Details
Each email associated with the person will be added to this list as its own object.
The mobile_phone field is generated from a highly confident source of mobile phones. We've hand-validated a sample of these and seen over 90% accuracy.
This field is generated by analyzing the all of a person's emails in the personal_emails list to identify the best available email.
Through testing, we’ve found that using the email identified in recommended_personal_email versus selecting a random email address from personal_emails resulted in ~37% higher deliverability.
These fields describe the company the person currently works at. These fields will match the corresponding values in our Company Schema and will use the same formatting and parsing logic.
A more detailed job title classification than O*NET Specific Occupation.
Data Type
String
Field Details
A more detailed job title for records where the specific occupation within O*NET's standard hierarchy isn't granular enough to accurately describe the job title.
For example, the highest level of granularity in O*NET for C-suite positions is Chief Executives. With this field, we can specify the type of executive role.
PDL values high confidence data that is very likely to be associated with a person. The data in these fields have lower confidence than the data used in other fields.
possible_birth_dates
Description
Birthdays associated with this person that have a lower level of confidence.
We currently cover person social profiles on our Canonical Profile Networks. All profiles we've found for a person will be added to the profiles list.
Each social profile URL has one or more standard formats that we parse and turn into a standard PDL format for that social URL. We invalidate profiles that have non-valid person stubs (for example, linkedin.com/company), and we also have a blacklist of usernames that we know are invalid.
We do not validate if a URL is valid (that is, whether you can access it) because doing this at scale is considered a Direct Denial of Service (DDoS) attack and/or a form of crawling. This is highly discouraged! We try to mitigate invalid URLs as much as possible by using Entity Resolution (Merging) to link URLs together and then tagging the primary URL at the top level for key networks.
facebook_friends
Description
The number of Facebook friends the person has.
Data Type
Integer (>= 0)
Example
"facebook_friends": 3912
facebook_id
Description
The person's Facebook profile ID based on source agreement.
Data Type
String
Example
"facebook_id": "1089351304"
facebook_url
Description
The person's Facebook profile URL based on source agreement.
Data Type
String
Example
"facebook_url": "facebook.com/deseanthorne"
facebook_username
Description
The person's Facebook profile username based on source agreement.
Data Type
String
Example
"facebook_username": "deseanthorne"
github_url
Description
The person's GitHub profile URL based on source agreement.
The order of work experience in the list is determined by recency and associativity. The experience object that is tagged as experience.is_primary = True is copied over to the flattened job_ fields (see Current Job and Current Company).
Each work experience object contains the following fields:
The person's inferred years of total work experience.
Data Type
Integer (0 - 100)
Field Details
The value will be between 0 and 100.
Example
"inferred_years_experience": 7
interests
Description
The person's self-reported interests.
Data Type
Array [String]
Field Details
Each interest is cleaned (lowercased, stripped of whitespace, etc.). We don't have a canonical list of interests but we remove profanity and do some basic cleaning.
Example
"interests": [
"data"
]
job_history
Description
Additional professional positions that may have been removed or changed on resumes.
Data Type
Array [Object]
Field Details
Any additional job history information PDL has that is not included in the experience field.
Usually these are positions that have been removed or changed on resumes.
Each skill is cleaned (lowercased, stripped of whitespace, etc.). We do not always strip punctuation because it can be relevant for some skills (ex: "c++" vs "c").
We do not do any canonicalization, so "java" and "java 8.0" are considered separate skills. For this reason, we encourage our customers to use fuzzy text matching with the skills field.
The number of unique raw records contributing to this specific PDL profile.
Data Type
Integer (> 0)
Example
"num_records": 420
num_sources
Description
The number of unique sources contributing to this specific PDL profile.
Data Type
Integer (> 0)
Example
"num_sources": 72
operation_id
Description
An identifier for an operation in a Data License delivery, used for troubleshooting.
Data Type
String
Field Details
This field exists only in Data License deliveries, and allows PDL employees to identify the timestamp and operations performed on the internal data in order to return a record in a delivery.
Metadata about the version of the dataset used to retrieve this record.
Data Type
Object
Field Details
This object tracks the pervious and current dataset version, and any other persistent IDs that were merged into this record using improved entity resolution and the status of the record.
Field
Data Type
Description
contains
Array [String]
The list of IDs that have been merged into this record since the last release.
current_version
String
The current data version.
previous_version
String
The previous data version.
status
Enum (String)
The changes made to this record between the previous release and the current one. One of our Canonical Version Statuses.