We update our data quarterly, making iterative improvements, adding new sources and new fields, and ensuring our faster moving data fields stay up to date.
- Ensure we have current job title, company, and location for as many profiles as possible.
- We value the accuracy all fields, but we value the accuracy of these fields the most, as they are the most flexibly utilizable across all use cases. the last_updated field indicates when our "current" job and location last appeared in a data source.
- Increase total volume of data through our data union
- By increasing the number of values we have in each field we can improve match rates and the value of each profile to the end user.
- Our most highly valued data partners provide us linkages that cannot be found elsewhere. By taking advantage of these linkages we are able to often merge what would be multiple "sides" of our data together.
- Adding new data fields allows our customers to power new products and create new features. We typically aim to have relatively strong coverage of a new field before we add it to the production data. However, some fields are valued enough that we provide them as "restricted" fields to our license customers and don't expose them in the API
- Improve our data build process
- While we are relatively strict with our merging logic, by finding new ways to increase the number of profiles we merge without instantiating new errors allows us to increase the total volume of data without needing to acquire new sources of linkages.
- Improved standardization results in cleaner person profiles with better field-level de-duplication. Improved standardization can also allow us to resolve more profiles together
Quarterly builds allow us enough time between builds to gather new sources, validate them, and test new implementations for our record linkage model before releasing a finished product out to the customer.
Our eventual goal is to increase the speed of our updates to monthly and beyond.
When deploying an update, the API typically experiences a few minutes of downtime. All API customers with an active email attached to their key will be notified of this about a week in advance.
With the v5 schema our goal is to make persistence commitments regarding how each field will evolve between data releases. We aim to do this in order to help our customers build applications around our data that are sustainable. Any changes outside the potential changes listed in the Person Manual will be announced 90 days in advance of any release.
Updated 10 months ago