Resolve: Building the Identity Resolution Engine (Part 2)

The following is the second installment of a multi-part series offering a glimpse of the behind-the-scenes advancements we achieved to deliver our Resolve API. You can find the first post, covering the origin of our Identity Graph and Resolve API, here.

Part 2: It’s a Party, BYOID!

To support the customization on the graph for each customer, we introduced two new concepts with our Resolve API – PersonID and Record ID. Both of which required some deep thinking around security and efficiency. We didn’t want hackable IDs, but we didn’t want unwieldy sized IDs either.

The PersonID (PID) is our version of a unique ID for a person, based on our own internal FullContact (FCID). The PID has a few simple characteristics:

• The IDs are safe to share on the Internet
• PIDs are persistent and don’t change
• Queryable as input to all FullContact APIs
• Scoped & unique per customer
• Predictable and reasonable length

For starters, the PID is always 48 characters long, making it predictably simple to store and embed in workflows. The PIDs are effectively random and hence there is no PII-based data ‘secretly’ encoded in them. Encoding information in IDs is tempting, but a risky decision as it opens the door to being hacked and decoded. Further, this adheres with the interpretation of data privacy laws (i.e. GDPR) where PII cannot be shared in pseudonymized form.

For each FullContact customer, PIDs are even guaranteed to differ for the same inputs. For example, if ABC Inc. and Startup LLC share a common person as a customer with an email of a@b.com, the PID returned by Resolve’s identity.resolve will be different. Together, these axioms virtually eliminate the potential for exposure of one’s customer/user base on the open web.

The other identifier we now support is called the Customer Record ID (RID). This is where you now get to Bring Your Own ID (BYOID) and conceptually load it into our graph! The RID is a company’s version of their customer’s ID that is naturally supported in their systems. It could come from a CRM, user account systems, loyalty programs, marketing automation, etc. It’s also fully supported as input into other FullContact APIs–simplifying integration for legacy systems written in, say COBOL, which could be helpful.

Thanks for reading! In the next post, we’ll talk about the places we pushed the envelope on security, and in the final post of the series, we cover all the ways we try to achieve peak performance of our systems and discuss some of the technology choices we made on the backend.