← All insights

Customer data maximization · 5 · Playbook

Consent as a data type: the full playbook

Half of companies say privacy rules made personalisation harder. This is the operating sequence to fix it: model consent on the profile, enforce it everywhere downstream, and store the rule not the build.

Consent as a data type: the full playbook

Fix consent in three steps. Model it as a data type on the customer profile, with purpose and region attached. Enforce it everywhere downstream, so every system reads the permission before it acts. Store the rule as policy, not a hard-coded build, so it moves when the law does. Capture once, enforce everywhere, and privacy stops fighting personalisation.

Most privacy projects start with a legal review and a new tool. This one starts with the customer profile you already have. The permission is usually captured somewhere. The problem is that it never reaches the record that drives your campaigns. Here is the sequence to fix that, with owners and what to measure at each step.

Consent has to become a field, not a filing cabinet. On the master customer record, add the permission itself, the purpose it covers, the region it was given in, the channel, and the timestamp. Store it next to email and purchase history, on the same record every team already reads.

This is the same discipline that ends data fragmentation: one master record everything defers to, described in fragmented customer data. If your profile is scattered, fix that first, because consent scattered across silos is worse than useless. It gives false confidence.

Model purpose carefully. Consent for order updates is not consent for marketing, and consent for marketing is not consent for third-party sharing. Each purpose is its own field. That granularity is what lets you personalise for the people who agreed while suppressing the people who did not.

Owner: the data or CRM lead who owns the master profile, because this is a data-model decision, not a legal one. Measure: the percentage of active profiles carrying a complete consent record, with purpose and region. Aim for full coverage before you trust any of it.

A consent field nobody reads is decoration. The value comes from enforcement. Every system that acts on a customer, the email platform, the ad audience export, the personalisation engine, reads the consent field before it sends. No read, no send.

Make it a required check in the pipeline, not a manual step a marketer remembers. An opt-out in one channel suppresses the person in all of them, automatically, because they all read the same field on the same record. Capture once, enforce everywhere. That single rule removes most of your breach exposure and most of the hesitation that stalls campaigns.

Test it the way an auditor would. Pull a live segment, pick ten people at random, and prove consent for the exact use, from the profile, in under a minute. If you cannot, the enforcement is not real yet. When you can, personalisation stops being a legal question and goes back to being a marketing one.

Owner: marketing operations, because they hold the activation systems that must read the field. Measure: the share of outbound activity that passes a consent check before send. You want 100%, with exceptions logged and investigated, not waved through.

Step 3: store the rule, not the build

The law differs by region and keeps changing. GDPR, PDPA, and the next market’s variant all draw the line in a slightly different place, and all of them move. Any team that hard-codes compliance into a system rebuilds it every time a regulator updates guidance. That is a treadmill.

Escape it by separating data from policy. The consent data lives on the profile and stays stable. A policy layer sits on top and decides what each region and purpose permits, and you change the policy when the law changes, not the plumbing. New market, new rule, same data model.

This keeps you honest without freezing you. When a rule tightens, you update policy and every downstream system inherits it at the next read. When a market opens, you add its rule rather than rebuilding your stack. The data type is permanent. The interpretation is editable.

Owner: a named person spanning data and legal, so policy changes have one home and do not scatter across teams. Measure: time to apply a regulatory change end to end. A mature setup measures this in days, not the months a hard-coded build demands.

How to train your team to hold the fix

Consent decays like any other data discipline, quietly, through small exceptions. A one-off export that skipped the check. A new tool wired in without reading the field. Left alone, the enforcement erodes and you are back to guessing.

Set one rule that holds the line: no system touches a customer without reading consent first. Make it a condition of onboarding any new tool, the same way you would demand a security review. Give consent a named owner who reviews coverage each quarter, refreshes the policy layer against current law, and checks that every activation path still enforces.

The mindset to build is the useful one, not the fearful one. Consent is not a brake on personalisation. It is the permission that makes personalisation safe to run at speed. A team that trusts its consent data moves faster than one that checks the law by hand every time, because the answer is already on the record. That confidence is the whole point of the fix.

Where Morphy helps

We run a four to eight week consent-as-a-data-type engagement. We model consent onto your master profile with purpose and region, wire your activation systems to enforce it before they send, and stand up a policy layer you can change as the law moves. You end with permission you can prove, per person, in under a minute.

The defined metric is your consent coverage and enforcement rate: the share of active profiles with a complete consent record, and the share of outbound activity that passes a consent check before send. We baseline both and set a target. Then, and this is the honest part, we point you back at activation. Consent is a floor you build once. The revenue is in what you do on top of it, so we do not let it become the whole roadmap.

Go deeper on customer data maximization

Three ways forward. Pick the one that fits where you are.

  • Get the playbook. Practical notes on turning the customer data you already own into revenue, straight to your inbox. Join the newsletter at the foot of this page.
  • Take the assessment. Score your customer data maximization in four minutes and see your top revenue blockers. Start the assessment →
  • Book a meeting. Bring your data problem. Leave with a prioritised fix, not a platform pitch. Book a call →

The playbook companion to How do you handle consent and privacy without killing personalisation?. Post 5 of 25 in the Customer Data Maximization series.

Frequently asked questions

What is the first step to fixing consent and privacy?

Model consent as fields on the customer profile: the permission, the purpose, the region, and the timestamp. Store it next to email and purchase history, not in a separate log. Once consent is a data type on the master record, every downstream system can read it before it acts.

How do you enforce consent across every channel?

Make consent a required check, not an optional one. Every activation system, email tool and ad platform reads the consent field before it sends. An opt-out anywhere suppresses the person everywhere. Capture the permission once and enforce it downstream, so no campaign runs on someone who said no.

How do you handle privacy rules that keep changing?

Store the rule as policy, not as code baked into a system. Regions differ and the law moves, so a fixed compliance build is out of date on arrival. Keep consent as data on the profile, with region and purpose attached, and let a policy layer decide what each region permits.

How long does a consent fix take?

Getting consent to first-class-data-type standard fits inside four to eight weeks for most mid-market teams. The consent is usually already captured. The work is routing it to the profile and wiring the downstream systems to read it before they act, then handing over a policy layer you can change.