How should a CDP handle privacy, consent and data governance?

The short answer

A well-governed CDP starts with a defined customer purpose, not every field the organisation can access. It should make the approved sources, identity rules, permissions, exclusions, destinations, refresh schedules and owners visible before an audience is activated.

The platform can enforce agreed rules and produce a reviewable operating trail. It cannot decide whether the organisation has a lawful basis to collect or use data, repair an inadequate privacy notice, or replace legal, privacy and security review.

1. Define the purpose before connecting data

Write the customer decision in plain language. For example: suppress current customers from acquisition, change treatment when a lead qualifies, re-engage customers at an agreed lapse point, or create an acquisition seed from customers with observable value.

Then identify the smallest set of source fields needed to make that decision. A useful purpose statement names the people affected, the business outcome, the data required, the destination and the evidence that will show whether the use case worked. If the purpose cannot be explained clearly, the audience is not ready to build.

2. Map how every field was collected

Record the source system, original collection path, notice shown, relevant permission or other legal basis, collection date and any purpose restrictions. This is particularly important when information came from another organisation, a partner, an uploaded file or a source the customer did not interact with directly.

New Zealand Information Privacy Principle 3A came into force on 1 May 2026. It introduces notification requirements when personal information is collected indirectly, subject to the Act and its exceptions. Australian organisations should assess the Australian Privacy Principles that apply to their collection, use and disclosure. The exact obligation depends on the organisation, data and use case, so obtain appropriate advice.

NZ Privacy Commissioner on IPP 3A ↗ · OAIC Australian Privacy Principles ↗

3. Treat consent as one part of customer state

A single consent flag is rarely enough. An audience decision may also depend on opt-outs, suppression requests, channel preferences, age or eligibility rules, product restrictions, purpose limits and the date a customer state was last confirmed.

Define which source is authoritative for each state and what should happen when sources disagree. A CDP should preserve the restrictive state until the conflict has been resolved, rather than silently choosing the record that is easiest to activate.

4. Maintain one usable permission model

• Name each permission, preference and suppression state in language the business understands.
• Map source-system values into those common states without losing the original evidence.
• Record the source, timestamp and rule version used for an audience decision.
• Apply exclusions before activation and keep them current at the required cadence.
• Define how withdrawals, corrections and deletions move through connected systems.
• Make an accountable person responsible for approving each use case.

5. Minimise data at every stage

Connect only fields required for the approved use case, identity decision, exclusion or measurement design. The fact that a field is available does not make it necessary.

Apply the same discipline to destinations. An advertising platform may need a prepared identifier and an audience instruction, not the complete customer profile. Data minimisation reduces exposure, simplifies review and makes the customer-data architecture easier to operate.

6. Govern identity resolution explicitly

Identity resolution decides whether records from different sources belong to the same person. A false merge can apply the wrong permission, exclusion or customer state, while a missed match can leave a current customer in acquisition activity.

Document the identifiers used, required match strength, source precedence, conflict handling and the process for splitting or correcting a profile. Fractyl uses visible deterministic identity and source-precedence rules so the logic can be reviewed rather than hidden inside a black box.

7. Understand what hashing does and does not do

Fractyl can hash personally identifying fields before media activation leaves the client environment. This prepares selected identifiers for governed matching without sending them as plain text.

Hashing is not anonymisation. It does not create permission, clean inaccurate data, resolve identity, remove disclosure obligations or make an unsuitable use case acceptable. It is one technical control within a wider privacy, security and governance design.

8. Give every audience a contract

• Audience name, purpose and accountable business owner.
• Approved inclusion, exclusion, recency and suppression rules.
• Source fields, identity logic and data-quality thresholds.
• Destinations and advertising accounts permitted to receive it.
• Refresh cadence, failure handling and maximum acceptable data age.
• Measurement plan, review date and conditions for retirement.
• Approval record for privacy, security, legal or procurement review where required.

9. Review each destination as a separate decision

Google Ads, Meta, TikTok, DV360 and a third-party clean room are not interchangeable endpoints. Each has its own account structure, matching process, contractual terms, data location and operational risk. Approval for one destination should not be treated as blanket approval for all destinations.

For New Zealand organisations, overseas disclosure is specifically addressed by Information Privacy Principle 12. Australian organisations should assess the relevant Australian Privacy Principles. These reviews belong with the client and its advisers; the CDP should enforce the destinations and audience rules that have been approved.

NZ privacy principles ↗ · Australian Privacy Principles ↗

10. Plan retention, correction and deletion before launch

Set retention around the approved purpose and legal requirements, not indefinite availability. Define when raw source data, resolved profiles, audience membership and operational logs should be reviewed or removed.

A correction, withdrawal or deletion request may need to flow through several systems. Map which team receives the request, which system is authoritative, how Fractyl is updated, what can be removed from each destination and how completion is confirmed. The answer will depend on the client architecture and the obligations that apply.

11. Make access and change control operational

Give people only the access needed for their role. Separate those who can view source data, change identity logic, approve an audience and activate it. Record material changes to audience rules and destination settings.

Agree what happens when data is delayed, a synchronisation fails, a customer is matched incorrectly or an audience reaches an unintended account. A useful incident process names the owner, escalation path, containment action, evidence required and client communication decision before an incident occurs.

12. Measure value without collecting everything

A CDP measurement plan should start with the commercial decision. Customer suppression might track eligible acquisition exposure removed, destination match rate and mistaken exclusions. A win-back audience might track reactivation and downstream customer value against a suitable comparison.

Audience size, data volume and event count are operational measures, not the final outcome. Collect only the signals needed to operate the use case and evaluate whether it improved the intended customer or commercial result.

13. Use a clear shared-responsibility model

The client remains responsible for lawful collection, appropriate notices, permissions, data accuracy, suppression requirements and approval of the proposed use. Its legal, privacy and security advisers determine what is suitable for the organisation.

Fractyl operates the agreed implementation, access, identity, audience and activation controls. The client, agency and Fractyl team should document who approves rules, who changes them, who monitors delivery and who investigates exceptions. Shared delivery should never mean unclear accountability.

14. Separate current capability from product direction

Fractyl currently creates and maintains persistent unified customer records, applies visible deterministic identity and audience rules, hashes selected activation identifiers and synchronises approved audiences to Google Ads, Meta, TikTok, DV360 and supported third-party data clean rooms. Different schedules, including up to hourly, can be selected around the use case.

Media mix modelling is in beta. AI-assisted audience segments and attribution feedback are roadmap direction, while email and SMS destinations are planned rather than current live destinations. Future AI assistance should propose explainable segment logic for human review and remain subject to the same purpose, permission, exclusion and approval rules.

15. A practical governance checklist

• Can the team explain the use case and customer benefit in one sentence?
• Is the collection path and notice known for every required field?
• Are consent, preference, suppression and deletion states mapped?
• Are identity and source-precedence rules documented and testable?
• Is only necessary data connected and sent to each destination?
• Does every audience have an owner, expiry or review date and change trail?
• Are access, incident and failed-synchronisation processes agreed?
• Are current, beta and roadmap capabilities represented accurately?
• Has the client completed the legal, privacy, security and procurement review appropriate to the use case?

Important limitation

This guide is practical product and operating guidance, not legal advice. Privacy obligations depend on the organisation, jurisdiction, data, collection path, contracts and proposed use. Use the official regulator guidance and qualified advisers when designing or approving an implementation.

Office of the Privacy Commissioner New Zealand ↗ · Office of the Australian Information Commissioner ↗