March 2025 Release Notes - People Data Labs Documentation

Release Name	Dataset Version	Publish Date
March 2025	`v29.2`	03/18/2025

Welcome to our March 2025 release notes! This month, we’re rolling out key improvements to make our data more accurate, comprehensive, and easier to use. Here’s what’s new:

🌎 Smarter Location Data: We updated our Location Cleaner to improve location details across our datasets.
🏢 Enhanced Company Coverage: Better coverage for industry classifications, follower counts, and founding dates.
📊 Consistent Sorting for Person Data: We’ve introduced a default sort order for array fields, making it easier to work with Person records.
🔍 Fresher Insights: We verified 201M+ jobs and detected 282K+ job changes across our global dataset this month.

Dive into the details below, or jump to a specific section using the table of contents.

📣 Key Announcements

Schema Changes

Sorted Arrays (Person Schema)

This month, we completed an update to our Person Schema: we now apply deterministic sorting logic for each of the array-typed fields in our Person Schema. This change is meant to surface the most relevant array elements first. For example, the experience array in each Person record is now sorted so that primary work experiences are first in the array with the remaining experiences being sorted by date. The high-level goals for the sorting logic on each field are to:

List any primary values first in the array
Logically order the remaining values to improve the user experience when displaying these array fields

The exact sorting logic for each array-typed field in the Person Schema is shown in the table below:

Refer to Person Schema for Updated Sorting Logic Moving ForwardAs this is the first release of sorting logic for our array fields, some of the definitions or logic may change in the next few months as we get customer feedback. Moving forward, please refer to the entries on the Person Schema page for the most up-to-date definition on the current sorting logic for each field. The table below will not be maintained and will be preserved for historic documentation purposes instead.

FIELD NAME	FIELD TYPE	SORT ORDER
`certifications`	`Array [Object]`	Certifications are sorted first by `start_date`, then by `end_date` and finally by `name`, all in reverse order (most recent first, Z→A)
`countries`	`Array [Enum (String)]`	Countries are sorted by location order, with any duplicate countries removed.
`education`	`Array [Object]`	Education entries are sorted first by `start_date`, then by `end_date`. If dates are identical, then sorting occurs by `[school.name](http://school.name/)`, followed by `majors`, `minors` and `degrees`, all in reverse order (most recent first, Z→A)
`emails`	`Array [Object]`	Emails are sorted first by `last_seen`, then by `first_seen`, `email`, all in reverse order (most recent first, Z→A)
`experience`	`Array [Object]`	Experience entries are sorted with the primary experience first. The remaining entries are then sorted by `start_date`, `end_date`, `[company.name](http://company.name/)`, `[title.name](http://title.name/)`, all in reverse order (most recent first, Z→A)
`experience.title.levels`	`Array [Enum (String)]`	Title levels are sorted from most important to least important based on the following ranking:`cxo`, `owner`, `vp`, `director`, `partner`, `senior`, `manager`, `entry`, `training`, `unpaid`
`interests`	`Array [String]`	Interests are sorted alphabetically (from A→Z)
`job_history`	`Array [Object]`	Job history entries are sorted by `start_date`, `end_date`, `[company.name](http://company.name/)`, `[title.name](http://title.name/)`, all in reverse order (most recent first, Z→A)
`languages`	`Array [Object]`	Languages are sorted by `proficiency` first, followed by `name`, all in reverse order (highest proficiency first, Z→A)
`location`	`-`	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)
`location_names`	`Array [String]`	Location names are sorted by location order with duplicate names removed
`name_aliases`	`Array [String]`	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)
`personal_emails`	`Array [String]`	Personal emails are sorted with the recommended personal email first. The remaining emails are sorted by `last_seen`, then by `first_seen`, `email`, all in reverse order (most recent first, Z→A)
`phone_numbers`	`Array [String (Phone)]`	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)
`phones`	`Array [Object]`	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)
`possible_birth_dates`	`Array [String (Date)]`	Possible birth dates are sorted by `num_sources`, `last_seen`, `first_seen`, `birth_date`, all in reverse order (highest first, most recent first)
`possible_emails`	`Array [String (Date)]`	Possible emails are sorted by `last_seen`, `first_seen`, `email`, all in reverse order (most recent first, Z→A)
`possible_location_names`	`Array [String]`	Possible locations are sorted by `first_seen`, `last_seen`, `[location.name](http://location.name/)`, all in reverse order (most recent first, Z→A)
`possible_phones`	`Array [Object]`	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)
`possible_profiles`	`Array [Object]`	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)
`possible_street_addresses`	`Array [Object]`	Possible street addresses are sorted by `first_seen`, `last_seen`, `[location.name](http://location.name/)`, `location.street_address`, `location.address_line_2`, all in reverse order (most recent first, Z→A)
`profiles`	`Array [Object]`	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)
`regions`	`Array [String]`	Regions are sorted by location order, with any duplicate regions removed.
`skills`	`Array [String]`	Skills are sorted alphabetically (from A→Z)
`street_addresses`	`Array [Object]`	Street addresses are sorted by location order

❗Breaking Changes (Going Live This Month)

There are no breaking changes going live this month, instead see the section below for upcoming breaking changes going live in the upcoming months.

⚠️ Upcoming Breaking Changes

Upcoming Breaking ChangesUpcoming breaking changes in future versions may impact your current processes. We are announcing them here to provide ample time for you to adjust your processes accordingly.

⚠️ Snowflake Listing Migration

Change expected in: v30.0 / April 2025 Previous Announcements: v29.0 / Jan. 2025, v29.1 / Feb. 2025 Products Impacted: Snowflake Listings

Products Impacted
Snowflake Data License Deliveries

In April 2025, we will be migrating all Snowflake customers with multiple listings to a single listing per customer. Why this change?
Historically, Snowflake customers receiving multiple data entities (i.e. both Person and Company datasets) were assigned separate listings in Snowflake for each entity. As of August 2024, we transitioned all new customers to a single-listing approach that improved our ability to support and deliver customer data. By April 2025, we will be migrating our remaining Snowflake customers to a single listing. Options for Migration
For customers with multiple listings, there are 2 options for migrating to a single listing:

New Listing (recommended, default): PDL creates a new listing for the customer, and moves all data from the pre-existing listings into the new listing. All pre-existing listings will be removed.\
Customer action required:
Customers mustaccept the new listing and update their downstream integrations to point to the new listing. If no action is taken, this will be the default option applied.\
Merge and Deprecate: Customers can choose to keep one of their existing listings (e.g. Person) and the data from the other listing (e.g. Company) will be moved over to the first listing. Once the data has been moved over, PDL will remove the second listing.\
Customer action required:
Customers mustconfirm which listing they want to keep and ensure their downstream dependencies are updated accordingly before the second listing is removed.\

As mentioned above, we strongly recommend the New Listing approach (option 1) for customers as it ensures proper configuration and consistency across the transition. If no action is taken, customers will automatically be migrated using the New Listing approach. To begin your migration process or specify your desired migration approach, please connect with your Technical Services and Customer Account team.

⚠️ Deprecation of Skill Enrichment API

Change expected in: v30.0 / April 2025 Previous Announcements: v29.0 / Jan. 2025, v29.1 / Feb. 2025 Products Impacted: Skill Enrichment API

Products Impacted
Skill Enrichment API

In April 2025, we will be removing the Skill Enrichment API. Why this change?
The Job Title and Skill Enrichment APIs were designed to help improve the user experience when working with our Person Search API. However, based on historical usage patterns we’ve decided to reprioritize our efforts on these APIs. Specifically, we will be sunsetting the Skill Enrichment API, which has had limited usage, in favor of improving our Job Title Enrichment API (details of this will be announced in a future release). For any questions, please contact your Customer Account Team. If you have feedback or product suggestions, please share them in our Roadmap Feature Request Board!

🚀 Data Updates

March 2025 (v29.2) is a Minor ReleaseAs a reminder, March 2025 is a minor release. This means that the information reported below is based on the last one month of updates (rather than the 3 months of updates we typically report for the major releases).

Freshness

The number of jobs and locations verified in our datasets over the pastmonth (based on the job_last_verified and location_last_updated fields).

Dataset	Geography	Field	Records Updated
Resume	Global	experience	201,179,754
Resume	Global	location	322,326,150
Resume	United States	experience	52,960,030
Resume	United States	location	75,712,242

Job Changes

The number of person records where the primary job experience changed in our Person Dataset over the pastmonth (based on the job_last_changed field).

Dataset	Geography	Records Updated
Resume	Global	282,997
Resume	United States	136,139

Coverage (Full Stats: Person, Company)

Resume Dataset

Linkage	Coverage in v29.1	Coverage in v29.2	Increase (%)
`total_records`	737,689,989	751,349,471	1.85%
`experience.location_names`	186,823,042	226,502,955	21.24%
`headline`	61,893,388	74,663,576	20.63%
`location_locality`	439,001,157	491,161,756	11.88%
`location_names`	444,085,756	495,057,393	11.48%
`job_summary`	73,561,906	65,209,023	-11.35%

API Dataset

Linkage	Coverage in v29.1	Coverage in v29.2	Increase (%)
`total_records`	2,461,673,017	2,473,230,064	0.47%
`headline`	61,927,977	74,708,280	20.64%
`experience.location_names`	284,171,791	329,369,826	15.91%
`education.school.location.locality`	245,448,315	283,098,192	15.34%

Email Dataset

Linkage	Coverage in v29.1	Coverage in v29.2	Increase (%)
`total_records`	635,947,701	634,528,966	-0.22%

Mobile Phone Dataset

Linkage	Coverage in v29.1	Coverage in v29.2	Increase (%)
`total_records`	486,275,248	486,065,010	-0.04%

Company Dataset

Linkage	Coverage in v29.1	Coverage in v29.2	Increase (%)
`total_records`	71,479,382	71,481,597	0.003%
`affiliated_profiles`	281,790	196,015	-30.44%
`location.street_address`	18,962,880	45,998,672	142.57%
`linkedin_follower_count`	19,603,411	30,391,497	55.03%
`industry`	45,770,567	53,934,351	17.84%
`location.locality`	50,342,729	56,645,643	12.52%
`location.geo`	49,687,658	55,383,937	11.46%
`founded`	13,602,887	15,108,348	11.07%

Commentary

We saw significant increases in our coverage of locations across both our Person and Company datasets as a result of our location cleaner improvements. See Improvements below for more details.
We saw an additional 20% increase in coverage for our headline field in our Person datasets this month. We expect to see further coverage increases as we continue to backfill this field over the coming months.
We saw an 11% drop in our coverage of job_summaries in our Resume dataset as a result of removing an inaccurate data source. See Bug Fixes below for more details.
We saw increases in our industry, linkedin_follower_count, and founded fields as a result of improvements in our sourcing process. See Improvements below for more details.
We saw a drop in our coverage of affiliated_profiles as a part of the same sourcing improvements in the previous bullet. Note that despite seeing a 30% drop in coverage here, the absolute number of profiles dropped is <90,000, since this was a field we currently have low fill rates for. We are looking at approaches to revitalize and improve the utility of this field in future releases.

🛠 Improvements and Bug Fixes

Improvements

Location Cleaner Improvements
- This month, we released some major improvements to our location cleaner to improve the consistency and quality of our locality and region data in particular.
  - Our goals for this project were to standardize values in the underlying location data to reduce duplication and to refactor our address cleaning and locality matching to provide more precision.
- This update has led to significant coverage improvements across our Person, Company and School datasets, as seen in the Coverage section above.
Field Sorting Improvements
- Array-typed fields are now deterministically sorted in our Person Schema to improve the user experience when displaying data from our Person records. For more details see the Schema Changes section above.
Company Data Sourcing Improvements
- This month we completed work to improve our sourcing of key company data fields including industry, founded, and linkedin_follower_count.
- These sourcing improvements led to significant coverage increases for each of these fields in our Company dataset.
- As part of this update we removed some legacy and outdated sourcing methods, which caused a drop in our coverage of affiliated_profiles. We will be looking to address this in future releases.

Bug Fixes

We fixed a bug that was causing stock tickers to be dropped if a company’s primary website changed.
We removed a data source that was incorrectly representing company summaries as job summaries in our person record.

​📣 Key Announcements

​Schema Changes

​Sorted Arrays (Person Schema)

​❗Breaking Changes (Going Live This Month)

​⚠️ Upcoming Breaking Changes

​⚠️ Snowflake Listing Migration

​⚠️ Deprecation of Skill Enrichment API

​🚀 Data Updates

​Freshness

​Job Changes

​Coverage (Full Stats: Person, Company)

​Commentary

​🛠 Improvements and Bug Fixes

​Improvements

​Bug Fixes

📣 Key Announcements

Schema Changes

Sorted Arrays (Person Schema)

❗Breaking Changes (Going Live This Month)

⚠️ Upcoming Breaking Changes

⚠️ Snowflake Listing Migration

⚠️ Deprecation of Skill Enrichment API

🚀 Data Updates

Freshness

Job Changes

Coverage (Full Stats: Person, Company)

Commentary

🛠 Improvements and Bug Fixes

Improvements

Bug Fixes