> ## Documentation Index
> Fetch the complete documentation index at: https://docs.peopledatalabs.com/llms.txt
> Use this file to discover all available pages before exploring further.
# March 2025 Release Notes
| 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](#improvements) to improve location details across our datasets.
* 🏢 **Enhanced Company Coverage**: [Better coverage](#commentary) for industry classifications, follower counts, and founding dates.
* 📊 **Consistent Sorting for Person Data**: We’ve introduced a [default sort order for array fields](#field-sorting), making it easier to work with Person records.
* 🔍 **Fresher Insights**: We [verified 201M+ jobs](#freshness) and detected [282K+ job changes](#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](/docs/person-schema))
This month, we completed an [update](https://peopledatalabs.canny.io/feature-requests/p/order-the-experience-array-by-startdate) 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:
1. List any primary values first in the array
2. 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](/docs/person-schema)** for Updated Sorting Logic Moving Forward**
As 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](/docs/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`](/docs/fields#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`](/docs/fields#countries) | `Array [Enum (String)]` | Countries are sorted by location order, with any duplicate countries removed. |
| [`education`](/docs/fields#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`](/docs/fields#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`](/docs/fields#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`](/docs/fields#experiencetitle) | `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`](/docs/fields#interests) | `Array [String]` | Interests are sorted alphabetically (from A→Z) |
| [`job_history`](/docs/fields#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`](/docs/fields#languages) | `Array [Object]` | Languages are sorted by `proficiency` first, followed by `name`, all in reverse order (highest proficiency first, Z→A) |
| [`location`](/docs/fields#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`](/docs/fields#location_names) | `Array [String]` | Location names are sorted by location order with duplicate names removed |
| [`name_aliases`](/docs/fields#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`](/docs/fields#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`](/docs/fields#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`](/docs/fields#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`](/docs/fields#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`](/docs/fields#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`](/docs/fields#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`](/docs/fields#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`](/docs/fields#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`](/docs/fields#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`](/docs/fields#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`](/docs/fields#regions) | `Array [String]` | Regions are sorted by location order, with any duplicate regions removed. |
| [`skills`](/docs/fields#skills) | `Array [String]` | Skills are sorted alphabetically (from A→Z) |
| [`street_addresses`](/docs/fields#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 Changes**
**Upcoming 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](/changelog/january-2025-release-notes-v290#snowflake-migration), [v29.1 / Feb. 2025](/changelog/february-2025-release-notes-v291#snowflake-migration)
Products Impacted: **Snowflake Listings**
| Products Impacted |
| :----------------------------------------------------------------------- |
| [Snowflake Data License Deliveries](/docs/data-delivery-using-snowflake) |
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:
1. **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 must**accept 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.*\
2. **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 must**confirm 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](/changelog/january-2025-release-notes-v290#skill-enrich-deprecation), [v29.1 / Feb. 2025](/changelog/february-2025-release-notes-v291#skill-enrich-deprecation)
Products Impacted: **Skill Enrichment API**
| Products Impacted |
| :------------------------------------------------- |
| [Skill Enrichment API](/docs/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](https://feedback.peopledatalabs.com/)!
***
## 🚀 Data Updates
**March 2025 (v29.2) is a Minor Release**
As 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 past**month** (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 past**month** (based on the `job_last_changed` field).*
| Dataset | Geography | Records Updated |
| ------- | ------------- | --------------- |
| Resume | Global | 282,997 |
| Resume | United States | 136,139 |
### Coverage (Full Stats: [Person](/docs/datasets), [Company](/docs/company-stats))
**[Resume Dataset](/docs/resume-stats)**
| 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](/docs/stats)**
| 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](/docs/email-stats)**
| Linkage | Coverage in v29.1 | Coverage in v29.2 | Increase (%) |
| --------------- | ----------------- | ----------------- | ------------ |
| `total_records` | 635,947,701 | 634,528,966 | -0.22% |
**[Mobile Phone Dataset](/docs/mobile-phone-stats)**
| Linkage | Coverage in v29.1 | Coverage in v29.2 | Increase (%) |
| --------------- | ----------------- | ----------------- | ------------ |
| `total_records` | 486,275,248 | 486,065,010 | -0.04% |
**[Company Dataset](/docs/company-stats)**
| 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](#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](#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](#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](#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](#-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.
## Related topics
- [March 2026 Release Notes](/changelog/march-2026-release-notes-v332.md)
- [December 2025 Release Notes](/changelog/december-2025-release-notes-v322.md)
- [November 2025 Release Notes](/changelog/november-2025-release-notes-v321.md)
- [January 2025 Release Notes](/changelog/january-2025-release-notes-v290.md)
- [August 2025 Release Notes](/changelog/august-2025-release-notes-v311.md)