Using Deconfliction on a Universe Dataset
Deconfliction refers to an optional identity resolution configuration that attempts to reduce the number of “conflicting” RampIDs for each individual record in a universe dataset. A RampID is considered conflicting if the same RampID is linked to the record for another user (such as a family member) in your system. Deconfliction attempts to include only the RampIDs that are most relevant to an individual record and reduce the number of “shared” RampIDs. This optimizes the fit of the LiveRamp graph to your definition of a customer.
Deconfliction is currently available for universe datasets in our Snowflake, Amazon ADX, and BigQuery identity resolution workflows, as well as in Local Encoder workflows.
Deconfliction refers to an optional identity resolution configuration that optimizes the fit of the LiveRamp graph to your definition of a customer, which is particularly beneficial for universe datasets.
Deconfliction attempts to reduce the number of “conflicting” RampIDs for each individual record in a universe dataset. A RampID is considered conflicting if the same RampID is linked to the record for another user (such as a family member) in your system. Deconfliction attempts to include only the RampIDs that are most relevant to an individual record and reduce the number of “shared” RampIDs.
Using deconfliction on large universe datasets can help match your records to the RampIDs that are determined to be the most relevant for each record by looking at the strength of the connection of each RampID to each touchpoint. It includes references to how active the linkage is in the digital ecosystem.
To utilize deconfliction for a cloud workflow, you’ll need to provide a CID (custom ID) for each record, and for the configuration to drive the highest value, the full universe is required to deconflict across the table. The output you receive will include the best fidelity RampIDs for each CID.
To utilize deconfliction for a Local Encoder workflow, you’ll need to provide an RID (Record ID) for each record, and for the configuration to drive the highest value, the full universe is required to deconflict across the table. The output you receive will include the best fidelity RampIDs for each RID.
You can choose from the following options:
Note
For BigQuery identity resolution workflows, only the "Standard" and "Maximized first-party fidelity" options are available.
Standard: This configuration returns the RampIDs that are determined to be most relevant and removes CIDs that are determined to be duplicates (based on linking to the same RampID). This is the default option and covers most advertiser use cases.
Maximized first-party fidelity: This configuration returns the RampIDs that are determined to be most relevant but preserves additional CIDs even if there are RampIDs that indicate LiveRamp could consolidate them. This option is ideal for publishers and other data owners.
Household expansion: This configuration allows clients with a household-based CID to resolve and deconflict with individual RampIDs that represent the full household. This option is ideal for retailers with household-based loyalty programs, as an example.
Event integrity: This configuration preserves all CIDs, meaning identity conflicts are minimized but not eliminated. This option is ideal for CIDs that represent transaction data, as an example.
Note
In addition to these deconfliction options, you can also choose an option that expands all identifiers to their individual touchpoints to return all associated RampIDs for each identifier touchpoint variation. This option is best for clients using the derived only resolution configuration to expand potential overlap for data collaboration use cases.
For example, if you included PII, this option would return a RampID for each touchpoint (or touchpoint combination), such as:
name and postal address
name and email
name and phone
partial name and email
partial name phone
name and zip
plaintext email
phone
last name and postal address
If hashed versions of the plaintext email address were not included, we would also match to hashed versions of the email address (using SHA1, SHA256, and MD5 hashing) and return RampIDs for those versions.