Overview

This page details the Person Data that we provide through our Person APIs, such as Person Enrichment and Person Search.

📘

Field Availability

Not all fields are available in all bundles.

Free plans, by default, do not have access to contact fields like emails, phone numbers, and street addresses and will instead appear as true if the value exists or false if it does not. To unlock the values, please upgrade to a Pro plan. Read more here: Plan types: Free vs Pro

• For more information about data formatting, see Data Types and Data Formatting
• For a full example record, see Example Person Record.
• 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

Field Details

The person's first name.

Example

  "first_name": "sean"

full_name

Field Details

The first and the last name fields appended with a space.

Example

  "full_name": "sean thorne"

id

Field Details

The ID is a unique, persistent, and hashed value that represents a specific person.

As of v24, IDs have a max length of 64 characters, although in practice we expect IDs to be closer to 32 characters in length.

See https://docs.peopledatalabs.com/docs/persistent-ids for more information.

Example

  "id": "qEnOZ5Oh0poWnQ1luFBfVw_0000"

last_initial

Field Details

The first letter of the person's last name.

Example

  "last_initial": "t"

last_name

Field Details

The person's last name.

Example

  "last_name": "thorne"

middle_initial

Field Details

The first letter of the person's middle name.

Example

  "middle_initial": "f"

middle_name

Field Details

The person's middle name.

Example

  "middle_name": "fong"

name_aliases

Field Details

Any associated names or aliases besides the primary one used in the full_name field.

💡

Sort Order

Name aliases are sorted with the primary alias first. The remaining aliases are sorted by num_sources, last_seen, first_seen, full_name, all in reverse order (highest first, most recent, Z→A):

1. Primary name first
2. num_sources (highest first)
3. last_seen (most recent first)
4. first_seen (most recent first)
5. full_name (Z→A)

Example

  "name_aliases": [
    "andrew nichol",
    "r andrew nichol",
    "robert nichol"
  ]

Contact Information

emails

Field Details

Each email associated with the person will be added to this list as its own object.

💡

Sort Order

Emails are sorted first by last_seen, then by first_seen, email , all in reverse order (most recent first, Z→A):

1. last_seen (most recent first)
2. first_seen (most recent first)
3. email (Z→A)

Example

  "emails": [
    {
      "address": "[email protected]",
      "type": "current_professional",
      "first_seen": "2017-06-02",
      "last_seen": "2019-07-18",
      "num_sources": 17
    },
    {
      "address": "[email protected]",
      "type": "personal",
      "first_seen": "2017-06-02",
      "last_seen": "2019-07-18",
      "num_sources": 17
    }
  ]

mobile_phone

Field Details

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.

Example

  "mobile_phone": "+15558675309"

personal_emails

Field Details

The list of all emails tagged as type = personal.

💡

Sort Order

Personal emails are sorted with the recommended personal email first. The remaining emails are sorted in the same order as the emails array:last_seen, then by first_seen, email, all in reverse order (most recent first, Z→A):

1. Recommended personal email first
2. last_seen (most recent first)
3. first_seen (most recent first)
4. email (Z→A)

Example

  "personal_emails": [
    "[email protected]"
  ]

phone_numbers

Field Details

For more detailed metadata on individual phone numbers, see the phones field.

💡

Sort Order

Phone numbers are sorted with any mobile phone numbers first. The rest of the array is sorted by num_sources, last_seen, first_seen, all in reverse order and using the E.164 format (highest first, most recent first):

1. Mobile phone numbers first
2. num_sources (highest first)
3. last_seen (most recent first)
4. first_seen (most recent first)

Example

  "phone_numbers": [
    "+15558675309"
  ]

phones

Field Details

Each phone number object in this list will contain the following information.

💡

Sort Order

Phones are sorted with any mobile phone numbers first. The rest of the array is sorted by num_sources, last_seen, first_seen, all in reverse order and using the E.164 format (highest first, most recent first):

1. Mobile phone numbers first
2. num_sources (highest first)
3. last_seen (most recent first)
4. first_seen (most recent first)

Example

  "phones": [
    {
      "number": "+15558675309",
      "first_seen": "2017-06-02",
      "last_seen": "2019-07-18",
      "num_sources": 17   
    }
  ]

recommended_personal_email

Field Details

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.

Example

  "recommended_personal_email": "[email protected]"

work_email

Field Details

The value for this field must use valid email address formatting. It is common and expected that work email domains may differ from the company's website for a number of reasons:

• The company changed their website domain
• The company has opted for a shorter email domain
• The company has been merged into or was acquired by another company

Example

  "work_email": "[email protected]"

Current Company

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.

job_company_12mo_employee_growth_rate

Example

  "job_company_12mo_employee_growth_rate": -0.1379

job_company_facebook_url

Example

  "job_company_facebook_url": "facebook.com/peopledatalabs"

job_company_founded

Example

  "job_company_founded": 2015

job_company_employee_count

Example

  "job_company_employee_count": 125

job_company_id

Example

  "job_company_id": "tnHcNHbCv8MKeLh92946LAkX6PKg"

job_company_industry

Example

  "job_company_industry": "computer software"

job_company_inferred_revenue

Example

  "job_company_inferred_revenue": "$25M-$50M"

job_company_linkedin_id

Example

  "job_company_linkedin_id": "18170482"

job_company_linkedin_url

Example

  "job_company_linkedin_url": "linkedin.com/company/peopledatalabs"

job_company_location_address_line_2

Example

  "job_company_location_address_line_2": "suite 1670"

job_company_location_continent

Example

  "job_company_location_continent": "north america"

job_company_location_country

Example

  "job_company_location_country": "united states"

job_company_location_geo

Example

  "job_company_location_geo": "37.77,-122.41"

job_company_location_locality

Example

  "job_company_location_locality": "san francisco"

job_company_location_metro

Example

  "job_company_location_metro": "san francisco, california"

job_company_location_name

Example

  "job_company_location_name": "san francisco, california, united states"

job_company_location_postal_code

Example

  "job_company_location_postal_code": "94105"

job_company_location_region

Example

  "job_company_location_region": "california"

job_company_location_street_address

Example

  "job_company_location_street_address": "455 market st"

job_company_name

Example

  "job_company_name": "people data labs"

job_company_size

Example

  "job_company_size": "51-200"

job_company_ticker

Example

  "job_company_ticker": "goog"

job_company_total_funding_raised

Example

  "job_company_total_funding_raised": 55250000.0

job_company_twitter_url

Example

  "job_company_twitter_url": "twitter.com/peopledatalabs"

job_company_type

Example

  "job_company_type": "public"

job_company_website

Example

  "job_company_website": "peopledatalabs.com"

Current Job

These fields describe the person's most recent work experience.

inferred_salary

Field Details

Must be one of our Canonical Inferred Salary Ranges.

Example

  "inferred_salary": "70,000-85,000"

job_last_changed

Field Details

An update is the time when the current employment information is modified in the record.

🚧

Limitations of Observed Data

This field reflects observed data. This means that this timestamp will reflect the date when updates were propagated into our data build from our data sources, and may contain some lag time compared to real-life events. For example, if User A changed their job on October 1, 2023, but did not update that publicly until December 1, 2023, our timestamp for job_last_changed will be December.

Example

  "job_last_changed": "2023-12-01"

job_last_verified

Field Details

An update is the time when the information in a record is validated through a data source. For more information how this timestamp is generated see: Experience & Location Updates

Example

  "job_last_verified": "2024-01-05"

job_onet_broad_occupation

Example

  "job_onet_broad_occupation": "Chief Executives"

job_onet_code

Field Details

The 8-digit O*NET code for the person’s current job title, following the 2018 SOC guidelines.

Example

  "job_onet_code": "11-1011.00"

job_onet_major_group

Example

  "job_onet_major_group": "Management Occupations"

job_onet_minor_group

Example

  "job_onet_minor_group": "Top Executives"

job_onet_specific_occupation

Example

  "job_onet_specific_occupation": "Chief Executives"

job_onet_specific_occupation_detail

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.

Example

  "job_onet_specific_occupation_detail": "Chief Technology Officer"

job_start_date

Example

  "job_start_date": "2015-03"

job_summary

Field Details

The summary is lowercased, but otherwise kept as-is from the raw source.

Example

  "job_summary": "worked on the \"search analytics\" team to understand our users better"

job_title

Field Details

The person's current job title.

Example

  "job_title": "co-founder and chief executive officer"

job_title_class

Field Details

Each class in the list will be one of our Canonical Job Title Classes.

Example

  "job_title_class": "research_and_development"

job_title_levels

Field Details

Each level in the list will be one of our Canonical Job Title Levels.

Note: The cxo level is a catch-all for "Chief __ Officer" roles, so a CEO, CIO, CTO, etc. will all have job_title_levels: ["cxo"].

Example

  "job_title_levels": ["cxo", "owner"]

job_title_role

Field Details

The value will be one of our Canonical Job Roles.

🚧

Major Update as of v29.1 (February 29.1)

In v29.1 (February 2024) we made significant improvements to our role and sub_role categorizations and updated many of the canonical values associated with these fields.

Please see our February 2025 Release Notes (v29.1)for further information.

Example

  "job_title_role": "operations"

job_title_sub_role

Field Details

The value will be one of our Canonical Job Sub Roles. Each subrole maps to a role. See https://docs.peopledatalabs.com/docs/title-subroles-to-roles for a complete mapping list.

🚧

Major Update as of v29.1 (February 29.1)

In v29.1 (February 2024) we made significant improvements to our role and sub_role categorizations and updated many of the canonical values associated with these fields.

Please see our February 2025 Release Notes (v29.1)for further information.

Example

  "job_title_sub_role": "logistics"

Demographics

birth_date

Field Details

If this field exists, birth_year will agree with it.

Example

  "birth_date": "1990-12-02"

birth_year

Field Details

The approximated birth year associated with this person profile. If a profile has a birth_date, the birth_year field will match it.

Example

  "birth_year": 1990

sex

🚧

gender was renamed to sex in v26.0

In v26.0 (April 2024) we renamed this field from gender to sex, in accordance with legislative changes defining aspects of gender as sensitive personal data (which PDL does not process or output).

Please see our April 2024 Release Announcement (v26.0) for further information.

Field Details

The value will always be one of our Canonical Sex.

Example

  "sex": "male"

languages

Field Details

The languages listed are based on user input, we do not verify them.

💡

Sort Order

Languages are sorted by proficiency first, followed by name, all in reverse order (highest proficiency first, Z→A):

1. proficiency (highest first)
2. name (Z→A)

Example

  "languages": [
    {
      "name": "english",
      "proficiency": 5
    }
  ]

Education

education

Field Details

The education objects associated with this person profile, which, when output in CSV format, have indexing based on recency and associativity.

Each education object in the list will include the following data:

💡

Sort Order

Education entries are sorted first by start_date, then by end_date. If dates are identical, then sorting occurs by school.name, followed by majors, minors and degrees, all in reverse order (most recent first, Z→A):

1. start_date(most recent first)
2. end_date (most recent first)
3. school.name (Z→A)
4. countriesmajors (Z→A)
5. minors (Z→A)
6. degrees (Z→A)

education.school

To tap into our school matching logic, use our School Cleaner API to retrieve possible school values.

Example

  "education": [
    {
      "school": {
        "name": "university of oregon",
        "type": "post-secondary institution",
        "id": "64LkgfdwWYkCC2TjbldMDQ_0",
        "location": {
          "name": "eugene, oregon, united states",
          "locality": "eugene",
          "region": "oregon",
          "country": "united states",
          "continent": "north america"
        },
        "linkedin_url": "linkedin.com/school/university-of-oregon",
        "linkedin_id": "19207",
        "facebook_url": "facebook.com/universityoforegon",
        "twitter_url": "twitter.com/uoregon",
        "website": "uoregon.edu",
        "domain": "uoregon.edu",
        "raw": [
          "university of oregon"
        ]
      },
      "end_date": "2014",
      "start_date": "2010",
      "gpa": null,
      "degrees": [],
      "majors": [
        "entrepreneurship"
      ],
      "minors": [],
      "raw": [
        "data analytics & entrepreneurship",
        ", entrepreneurship",
        "entrepreneurship"
      ],
      "summary": "when i was at oregon i volunteered at a local homeless shelter 3 days a week"
    },
  ]

Location

For more information on our standard location fields, see https://docs.peopledatalabs.com/docs/data-types#locations.

countries

💡

Sort Order

Countries are sorted using location sort order, with any duplicate countries removed.

Location Sort Order

Locations are sorted by primary location first. The remaining locations are sorted by first_seen, last_seen, location_name, street_address, then address_line_2 in descending order (most recent first, Z→A):

1. Primary location first
2. Sort by first_seen (most recent first)
3. Sort by last_seen (most recent first)
4. Sort by location_name (Z→A)
5. Sort by street_address (Z→A)
6. Sort by address_line_2 (Z→A)

Example

  "countries": [
    "united states"
  ]

location_address_line_2

Example

  "location_address_line_2": "apartment 12"

location_continent

Example

  "location_continent": "north america"

location_country

Example

  "location_country": "united states"

location_geo

Example

  "location_geo": "37.87,-122.27"

location_last_updated

Field Details

An update is the time when either new information is added to the record or existing information is validated.

Example

  "location_last_updated": "2018-11-05"

location_locality

Example

  "location_locality": "berkeley"

location_metro

Example

  "location_metro": "san francisco, california"

location_name

Example

  "location_name": "berkeley, california, united states"

location_names

💡

Sort Order

Location names are sorted by location order with duplicate names removed

Location Sort Order

Locations are sorted by primary location first. The remaining locations are sorted by first_seen, last_seen, location_name, street_address, then address_line_2 in descending order (most recent first, Z→A):

1. Primary location first
2. Sort by first_seen (most recent first)
3. Sort by last_seen (most recent first)
4. Sort by location_name (Z→A)
5. Sort by street_address (Z→A)
6. Sort by address_line_2 (Z→A)

Example

  "location_names": [
    "berkeley, california, united states",
    "san francisco, california, united states"
  ]

location_postal_code

Example

  "location_postal_code": "94704"

location_region

Example

  "location_region": "california"

location_street_address

Example

  "location_street_address": "455 fake st"

regions

💡

Sort Order

Regions are sorted by location order, with any duplicate regions removed.

Location Sort Order

Locations are sorted by primary location first. The remaining locations are sorted by first_seen, last_seen, location_name, street_address, then address_line_2 in descending order (most recent first, Z→A):

1. Primary location first
2. Sort by first_seen (most recent first)
3. Sort by last_seen (most recent first)
4. Sort by location_name (Z→A)
5. Sort by street_address (Z→A)
6. Sort by address_line_2 (Z→A)

Example

  "regions": [
    "california, united states"
  ]

street_addresses

Field Details

Each address associated with the person will be added to this list as its own object.

In addition to the Common Location Fields, street_addresses will also include:

💡

Sort Order

Street addresses are sorted by location order.

Location Sort Order

Locations are sorted by primary location first. The remaining locations are sorted by first_seen, last_seen, location_name, street_address, then address_line_2 in descending order (most recent first, Z→A):

1. Primary location first
2. Sort by first_seen (most recent first)
3. Sort by last_seen (most recent first)
4. Sort by location_name (Z→A)
5. Sort by street_address (Z→A)
6. Sort by address_line_2 (Z→A)

Example

  "street_addresses": [
    {
      "name": "berkeley, california, united states",
      "locality": "berkeley",
      "metro": "san francisco, california",
      "region": "california",
      "country": "united states",
      "continent": "north america",
      "street_address": "455 fake st",
      "address_line_2": "apartment 12",
      "postal_code": "94704",
      "geo": "37.87,-122.27",
      "first_seen": "2017-06-02",
      "last_seen": "2019-07-18",
      "num_sources": 17
    }
  ]

Lower Confidence Data

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

Field Details

The dates in this field use the same format as the birth_date field.

💡

Sort Order

Possible birth dates are sorted by num_sources, last_seen, first_seen, birth_date, all in reverse order (highest first, most recent first):

1. num_sources (highest first)
2. last_seen (most recent first)
3. first_seen (most recent first)
4. birth_date (most recent first)

Example

  "possible_birth_dates": [
    "1991-05-26",
    "1992-05-26"
  ]

possible_emails

Field Details

This field uses the same format as the emails field.

💡

Sort Order

Possible emails are sorted by last_seen, first_seen, email, all in reverse order (most recent first, Z→A):

1. last_seen (most recent first)
2. first_seen (most recent first)
3. email (Z→A)

Example

  "possible_emails": [
    {
      "address": "[email protected]",
      "type": null,
      "first_seen": "2021-06-13",
      "last_seen": "2021-06-13",
      "num_sources": 2
    }
  ]

possible_location_names

Field Details

This field uses the same format as the location_names field.

Possible locations are inferred based on phone area codes, university location, and other associations.

💡

Sort Order

Possible locations are sorted by first_seen, last_seen, location.name, all in reverse order (most recent first, Z→A):

1. first_seen (most recent first)
2. last_seen (most recent first)
3. location.name (Z→A)

Example

  "possible_location_names": [
    "berkeley, california, united states",
    "san francisco, california, united states"
  ]

possible_phones

Field Details

This field uses the same format as the phones field.

💡

Sort Order

Possible phones are sorted by num_sources, last_seen, first_seen, all in reverse order and using the E.164 format (highest first, most recent first):

1. num_sources (highest first)
2. last_seen (most recent first)
3. first_seen(most recent first)

Example

  "possible_phones": [
    {
      "number": "+15558675309",
      "first_seen": "2021-06-13",
      "last_seen": "2021-06-13",
      "num_sources": 2
    }
  ]    

possible_profiles

Field Details

This field uses the same format as the profiles field.

💡

Sort Order

Possible profiles are sorted first by return status codes (200 > unknown > 404). The array is then sorted by number of profiles globally, last_seen, first_seen, username, id, all in reverse order (highest first, most recent first, Z→A):

1. Status Codes:
   • Profiles with 200 return status codes are first
   • Profiles with unknown return status codes come next
   • Profiles with 404 return status codes are placed last
2. Number of profiles globally (highest first)
3. last_seen (most recent first)
4. first_seen (most recent first)
5. username (Z→A)
6. id (Z→A)

Example

  "possible_profiles": [
    {
      "network": "linkedin",
      "id": "145991517",
      "url": "linkedin.com/in/seanthorne",
      "username": "seanthorne",
      "first_seen": "2021-06-13",
      "last_seen": "2021-06-13",
      "num_sources": 2
    }
  ]

possible_street_addresses

Field Details

This field uses the same format as the street_addresses field.

💡

Sort Order

Possible street addresses are sorted by first_seen, last_seen, location.name, location.street_address, location.address_line_2, all in reverse order (most recent first, Z→A):

1. first_seen (most recent first)
2. last_seen (most recent first)
3. location.name (Z→A)
4. location.street_address (Z→A)
5. location.address_line_2 (Z→A)

Example

  "possible_street_addresses": [
    {
      "name": "berkeley, california, united states",
      "locality": "berkeley",
      "metro": "san francisco, california",
      "region": "california",
      "country": "united states",
      "continent": "north america",
      "street_address": "455 fake st",
      "address_line_2": "apartment 12",
      "postal_code": "94704",
      "geo": "37.87,-122.27",
      "first_seen": "2021-06-13",
      "last_seen": "2021-06-13",
      "num_sources": 2
    }
  ]

Social Presence

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

Example

  "facebook_friends": 3912

facebook_id

Example

  "facebook_id": "1089351304"

facebook_url

Example

  "facebook_url": "facebook.com/deseanthorne"

facebook_username

Example

  "facebook_username": "deseanthorne"

github_url

Example

  "github_url": "github.com/deseanathan_thornolotheu"

github_username

Example

  "github_username": "deseanathan_thornolotheu"

linkedin_connections

Field Details

Typically between 0-500.

Example

  "linkedin_connections": 432

linkedin_id

Example

  "linkedin_id": "145991517"

linkedin_url

Example

  "linkedin_url": "linkedin.com/in/seanthorne"

linkedin_username

Example

  "linkedin_username": "seanthorne"

profiles

Field Details

Each profile associated with the person will be added to this list as its own object.

💡

Sort Order

Profiles are sorted with the primary profiles listed first (facebook, linkedin, twitter, and github, in that order). The rest of the array is then sorted by status codes (200 > unknown > 404), number of profiles globally, last_seen, first_seen, username, id, all in reverse order (highest first, most recent first, Z→A):

1. Primary profiles first
   1. Facebook
   2. LinkedIn
   3. Twitter
   4. Github
2. Status Codes:
   • Profiles with 200 return status codes are first
   • Profiles with unknown return status codes come next
   • Profiles with 404 return status codes are placed last
3. Number of profiles globally (highest first)
4. last_seen (most recent first)
5. first_seen (most recent first)
6. username (Z→A)
7. id (Z→A)

Example

  "profiles": [
    {
      "network": "linkedin",
      "id": "145991517",
      "url": "linkedin.com/in/seanthorne",
      "username": "seanthorne",
      "first_seen": "2017-06-02",
      "last_seen": "2019-07-18",
      "num_sources": 17
    }
  ]

twitter_url

Example

  "twitter_url": "twitter.com/seanthorne5"

twitter_username

Example

  "twitter_username": "seanthorne5"

Work History

certifications

Field Details

The certifications listed are based on user input, we do not verify them.

💡

Sort Order

Certifications are sorted first by start_date, then by end_date and finally by name, all in reverse order (most recent first, Z→A):

1. start_date (most recent first)
2. end_date (most recent first)
3. name (Z→A)

Example

  "certifications": [
    {
      "name": "machine learning certification",
      "organization": "coursera",
      "start_date": "2022-03",
      "end_date": "2023-04"
    }
  ]

experience

Field Details

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:

💡

Sort Order

Experience entries are sorted with the primary experience first. The remaining entries are then sorted by start_date, end_date, company.name, and title.name, all in reverse order (most recent first, Z→A):

1. Primary Experience (is_primary = True )
2. start_date (most recent first)
3. end_date (most recent first)
4. company.name (Z→A)
5. title.name (Z→A)

experience.company

The fields in experience.company map to the corresponding fields in our Company Schema. The same parsing and formatting logic apply.

experience.title

See the corresponding Current Job fields for more details on the information included and formatting of these fields.

💡

Sort Order (experience.title.levels)

Title levels are sorted from most important to least important based on the following ranking:

1. cxo (first)
2. owner
3. vp
4. director
5. partner
6. senior
7. manager
8. entry
9. training
10. unpaid (last)

Example

  "experience": [
    {
      "company": {
        "name": "people data labs",
        "size": "11-50",
        "id": "peopledatalabs",
        "founded": 2015,
        "industry": "computer software",
        "location": {
          "name": "san francisco, california, united states",
          "locality": "san francisco",
          "region": "california",
          "metro": "san francisco, california",
          "country": "united states",
          "continent": "north america",
          "street_address": "455 market street",
          "address_line_2": "suite 1670",
          "postal_code": "94105",
          "geo": "37.77,-122.41"
        },
        "linkedin_url": "linkedin.com/company/peopledatalabs",
        "linkedin_id": "18170482",
        "facebook_url": "facebook.com/peopledatalabs",
        "twitter_url": "twitter.com/peopledatalabs",
        "website": "peopledatalabs.com",
        "ticker": null,
        "type": "private",
        "raw": [
          "people data labs"
        ],
      },
      "location_names": ["san francisco, california, united states"],
      "end_date": null,
      "start_date": "2015-03",
      "title": {
        "name": "chief executive officer and co-founder",
        "raw": [
          "co-founder & ceo",
          "co-founder & ceo",
          "co-founder and chief executive officer"
        ],
        "role": "operations",
        "sub_role": "executive",
        "class": "general_and_administrative"
        "levels": [
          "cxo",
          "owner"
        ],
      },
      "is_primary": true,
      "summary": "worked on the \"search analytics\" team to understand our users better",
      "first_seen": "2018-10-11",
      "last_seen": "2022-11-15",
      "num_sources": 17
    },
  ]

headline

Field Details

The self-written headline tied to the person profile (often a LinkedIn headline).

The summary is lowercased, but otherwise kept as-is from the raw source.

Example

  "headline": "senior data engineer at people data labs"

industry

Field Details

A person's industry is determined based on their tagged personal industries and the industries of the companies that they have worked for.

The value will be one of our Canonical Industries.

Example

  "industry": "computer software"

inferred_years_experience

Field Details

The value will be between 0 and 100.

Example

  "inferred_years_experience": 7

interests

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.

💡

Sort Order

Interests are sorted alphabetically (from A→Z)

Example

  "interests": [
    "data",
    "software"
  ]

job_history

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.

💡

Sort Order

Job history entries are sorted by start_date, end_date, company.name, and title.name, all in reverse order (most recent first, Z→A):

1. start_date (most recent first)
2. end_date (most recent first)
3. company.name (Z→A)
4. title.name (Z→A)

Example

  "job_history": [
    {
      "company_id": "OMdETRug8CpuRDWGkhQ35wx8CvVk",
      "company_name": "auntie annes",
      "title": "food service supervisor",
      "first_seen": "2016-05-17",
      "last_seen": "2020-05-30",
      "num_sources": 12
    }
  ]

skills

Field Details

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.

💡

Sort Order

Skills are sorted alphabetically (from A→Z)

Example

  "skills": [
    "entrepreneurship"
  ]

summary

Field Details

The self-written summary tied to the person profile (often a LinkedIn summary).

The summary is lowercased, but otherwise kept as-is from the raw source.

Example

  "summary": "growth-hacker and digital nomad"

PDL Record Information & Metadata

dataset_version

Field Details

This field currently exists in Person Enrichment API responses.

Note: This number corresponds to the data release number, not the API release number.

Example

  "dataset_version": "19.2"

first_seen

Example

  "first_seen": "2017-06-02"

num_records

Example

  "num_records": 420

num_sources

Example

  "num_sources": 72

operation_id

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.

Example

  "operation_id": "acee3bde2e1a2cb7e75c57b80d5b7bc2d5de5b02e7ea51f91304c28df77251dc"