Private Identity Cloud™ accepts fragmented customer identifiers and uses the Identity Graph to map those identifiers to a single individual along with one or many customer specific (initiated) identifiers (e.g. loyalty ID, member ID). The result is a unique, persistent identifier from FullContact called a PersonID.
You can use FullContact's Private Identity Cloud™ map your CRM, call center, mailing address, and other customer information from various platforms to get real-time, two-way consolidation and updating of customer information with high match rates and confidence levels.
Unify your fragmented customer data points down to a persistent PersonID.
Private Identity Cloud™ accepts fragmented user, customer and prospect data as multi-field identifiers, matching against the FullContact Identity Graph to recognize them down to a Person level. This match is expressed in what FullContact calls the PersonID, which is customer-scoped, unique per person, persistent and portable, and of course secure. Connections between customer and user databases can be established to the PersonID through FullContact Private Identity Cloud™, allowing FullContact customers to provide a unified client experience and journey.
Benefits of resolving identifiers to a PersonID:
- Seamlessly stitch together customer and prospect data across your ecosystem
- Recognize your customers and prospects in real-time, across numerous channels
- To de-duplicate customer records down to a single person
Map fragmented records to internal identifiers in the Private Identity Cloud™
In addition to the PersonID, Resolve supports the ability to map custom identifiers, such as a customerID, loyaltyID, CDPID and any other internal database ID to the respective user/customer/prospect data (multi-field). You can also leverage this feature to associate analytics data (such as visitIDs and/or orderIDs) as you can map multiple identifiers to a single person.
Benefits of mapping custom identifiers to user/prospect data:
- Immediately know which data set a person is a part of at the moment of resolution, based on which RecordIDs are returned
- Offer a prospect or customer a tailored experience appropriate for the moment based on their existing relationship with you
- More securely query FullContact APIs with non-sensitive input parameters by using RecordIDs
Recognize anonymous website traffic by leveraging Customer Recognition Tags
Resolve real-time traffic on your website down to a personID using an embedded webtag provided by FullContact.
Private Identity Cloud™ leverages the person-centric identity graph to accept fragmented & incomplete identifiers and consolidates them down to a single person.
The Private Identity Cloud™ maintains a mapping between FullContact’s internal IDs and the PersonID. As the underlying graph data changes (your customer gets a new phone number, etc.), the Private Identity Cloud™ will ensure these mappings remain up to date. Additionally, it will accept custom identifiers (RecordIDs) so you can use your internalIDs to interact with Resolve and Enrich, as well as attach additional metadata to each RecordID.
Benefits of the Private Identity Cloud™:
- Maintain mapping between internal ID and client persistent identifiers (personID)
- Allow custom identifiers (RecordID) to be associated with dynamically changing people in the graph
- Associate metadata with custom identifiers (RecordIDs)
- Segment portions of your Private Identity Cloud™ using customer tags.
There are multiple API methods that can be used to interact with the Private Identity Cloud™:
identity.resolve - Resolve a Customer Record (multi-field input) down to a PersonID
identity.map - Map a Customer Record by sending any acceptable multi field identifier combination for each customer/client record. The RecordID is a unique, custom identifier.
identity.delete - Delete a Customer Record from the Private Identity Cloud™
With our Identity Graph constantly updating, there are typically two instances when PID changes occur:
- Merge Instances - this occurs when two or more PIDs that were previously returned based on inputted contact fragments are now found to be connected inside our Identity Graph.
- Split Instances - this occurs when one PID has been determined to have connected two or more individuals together inside our Identity Graph. This is generally seen in household relationship use cases. In split instances, it is recommended that the first PID in the list should be used for ongoing customer recognition.
Updated about 2 months ago