Consent Was Withdrawn On One Of Three Records
Consent and retention are recorded per system, per row. A customer withdraws marketing consent in your preference centre, and the record in your events platform, under another email, still says yes. A retention rule deletes the old CRM row and keeps its copy in the warehouse.
The customer said no. Two of their three records still say yes.
Policies Apply To Rows. People Don’t Live In One
Consent flags and retention dates are stored on records: a preference row, a CRM lead, a user in an events tool. Each system enforces its own rule on its own rows.
When the same person has several records, those rules drift apart. Consent is withdrawn on one and still granted on another. One record ages out and is deleted, while a copy under a different key stays forever. Nobody decided that; the systems simply never knew the records were the same person.
The drift shows up later, as a campaign sent to someone who opted out, or data kept longer than the policy allows.
Conflicting Flags
The same person has consent granted in one system and withdrawn in another.
Uneven Retention
One copy is deleted on schedule; another under a different key is kept.
Found Too Late
Drift surfaces as a complaint or an audit finding, not as an error.
Attach Policy To The Person
Resolve people across systems, then evaluate consent and retention on the person instead of the row. Decide which consent wins, and when the person’s data is due for deletion, once, for the identity.
Push that answer back to every record behind the identity, so marketing, analytics and operations all read the same consent and the same retention date.
Read consent and retention from the person, and every record behind them gets the same answer.
One Identity Per Person
All of a person’s records are linked before any policy is applied.
One Decision Per Person
Consent and retention are decided for the identity, not row by row.
Every System Reads It
The decision flows back to each record behind the person.
The Identity Layer Under Privacy
Zingg runs as a workload inside your data platform and gives every entity one persistent ZINGG_ID. Everything above it reads the same resolved entities.
The same layer powersCustomer Analytics & MarketingFinancial Crime & RiskSupply Chain & ProcurementProduct 360Master Data ManagementAI & Data Foundations
Policies That Follow People
ZINGG_ID On Every Record
Each record carries the person’s persistent ZINGG_ID, so consent and retention can be joined on it.
Changes Handled Incrementally
New, updated and deleted records are processed by the incremental flow, and the ZINGG_ID persists.
Matching Plus Rules
Learned matching on names and addresses, combined with deterministic rules on email or phone.
In Your Data Platform
Runs inside Databricks, Snowflake, Microsoft Fabric, Google Cloud or AWS.
Consent & Retention Questions
Why do consent flags disagree across systems?
Each system stores consent on its own records. When the same person has records in several systems that were never linked, a change in one never reaches the others.
Does Zingg store or manage consent?
No. Zingg resolves people and gives each one a ZINGG_ID. Your consent and retention systems use that ID to apply one decision to every record.
What happens when records are deleted?
The incremental flow handles deleted records and removes them from the identity, while the rest of the person’s records keep their ZINGG_ID.
Does this work for customers and employees alike?
Yes. Zingg resolves any entity you can describe with fields, including customers, prospects, patients and employees.
Apply Consent To The Whole Person
Resolve people inside your own data platform and let every system read one decision.