Consent-aware marketing automation: purpose and consent as inputs to every decision

1Context and motivation

Marketing automation now decides whom to contact, when, on which channel and with which offer, using models trained on behavioural data. In many stacks, consent enters this pipeline once: as a flag checked just before a message leaves. Upstream, segmentation, feature computation and model training run on whatever data is available, on the assumption that a correct send-time check is enough.

It is not enough under the text of several data protection laws. Under the EU General Data Protection Regulation (GDPR), personal data must be collected for specified, explicit and legitimate purposes and not further processed in a manner incompatible with them, and must be limited to what is necessary for those purposes¹. When a person objects to processing for direct marketing, which includes profiling related to it, the data may no longer be processed for that purpose¹. A model that keeps scoring an objecting customer for marketing, while the send step quietly drops them, is still processing their data for marketing.

We describe a design in which consent, legal basis and purpose are inputs to every stage of marketing automation: data access, feature computation, model training, serving and sending. We derive the requirements from legal texts, argue the technical choices from published work, and set out what a deployment would need to measure. We do not report effects, because we have not measured any. Nothing here is legal advice.

2Requirements from the legal texts

We read five instruments that cover markets where merchants commonly operate. They differ in detail, but several requirements recur.

• Purpose limitation and minimisation. The GDPR requires purpose limitation, data minimisation and storage limitation¹. Brazil's LGPD lists among its principles that processing serve legitimate, specific, explicit and informed purposes, and that it be limited to the minimum necessary for those purposes². Singapore's PDPA contains provisions on consent, withdrawal of consent, and limitation of purpose and extent³.
• Lawful basis and consent. The GDPR permits processing only on one of a listed set of bases, consent and legitimate interests among them¹. Where consent is the basis, the controller must be able to demonstrate it, and withdrawing consent must be as easy as giving it¹. Under the LGPD, consent must refer to specified purposes, generic authorisations are void, and consent can be revoked at any time².
• Electronic direct marketing. The ePrivacy Directive, as adopted in 2002, allows email for direct marketing only to subscribers who have given prior consent, with one exception: a business that obtained a customer's email address in the context of a sale may market its own similar products, provided the customer can object, free of charge and easily, when the address is collected and in each message⁴. Singapore's PDPA establishes a Do Not Call Registry and a duty to check it before sending specified messages to Singapore telephone numbers³.
• Rights over data and profiling. The GDPR gives a right to object at any time to processing for direct marketing, including related profiling¹. Under the CCPA, as described by the California Attorney General, consumers can ask to know what personal information a business holds and how it is used, to delete it, to opt out of its sale or sharing, to correct it, and to limit the use of sensitive personal information⁵.
• Non-discrimination for exercising rights. Businesses subject to the CCPA cannot deny goods or services, charge a different price, or provide a different quality of service because a consumer exercised their rights⁵.
• Protection by design. The GDPR requires controllers to implement technical and organisational measures that put data protection principles into effect, both when the means of processing are determined and during processing, and to ensure by default that only data necessary for each specific purpose is processed¹.

These requirements share a structure: each one is a constraint on which data may be used for which purpose, for whom, and for how long. That structure is what the architecture encodes.

3Architecture

The design has six layers. Hoepman's eight privacy design strategies (minimise, hide, separate, aggregate, inform, control, enforce, demonstrate), derived from data protection legislation, give a vocabulary for what each layer does⁶.

3.1Consent and purpose graph

For each person, the graph records consents and objections per purpose and per channel, the legal basis relied on for each purpose, the jurisdiction that applies, the source and time of each change, and the person's own preferences (channels, frequency, quiet hours). Purposes are a fixed, reviewed list, for example: order and service messages, marketing by email, marketing by SMS, personalised recommendations, and aggregate analytics. Changes propagate as events, so that every downstream system sees a withdrawal promptly. This layer implements the strategies of control, inform and demonstrate.

3.2Purpose-scoped feature layer

Raw events are stored separately from derived features. Every feature declares the purposes it may serve and the raw fields it reads. A request for features names its purpose, and the layer returns only features whose declared purposes include it, computed only from people whose consent graph permits that purpose. A model trained for marketing by email therefore never sees data from people who objected to marketing, rather than seeing it and being overruled later. This implements minimise and separate.

3.3Policy engine

The policy engine encodes rules by jurisdiction and purpose: which legal basis applies to which purpose, which channels need prior consent, which registries must be checked, which attributes must not be used for targeting, and retention periods. It answers two kinds of query: at training time, "may this data set be used to train a model for this purpose", and at serving time, "may this action be taken for this person now". Rules are versioned and owned by people with legal review. This implements enforce.

3.4Model layer

Models for propensity, uplift, send time and fatigue are trained on purpose-scoped features and registered with their purpose, the jurisdictions their training data came from, and the feature list. A model registered for one purpose cannot be called for another without a new review.

3.5Decision layer

The orchestration system that decides whom to contact receives only eligible people and actions. It consults the policy engine again immediately before execution, because consent can change between scoring and sending.

3.6Audit and explanation layer

Each decision is logged with the person's consent state at that moment, the purpose and legal basis, the model and feature versions used, and the policy checks applied. The log supports access requests, internal review and, where the law provides for it, an explanation of why a person received a message. Retention of the log follows the same storage limits as the data it describes. This implements demonstrate.

Table 1 maps the requirements to the design components.

Requirement	Source	Design component
Purpose limitation, data minimisation	1, 2, 3	Purpose-scoped feature layer; purpose registry for models
Lawful basis per purpose; demonstrable consent	1	Consent and purpose graph with source and time of each change
Consent tied to specific purposes; revocable	2	Per-purpose consent records; withdrawal events propagate downstream
Prior consent for email marketing, with soft opt-in for own similar products	4	Policy engine rule per channel and jurisdiction; opt-out link in each message
Do Not Call Registry check	3	Policy engine registry check before SMS and calls to Singapore numbers
Objection to direct marketing, including profiling	1	Objection removes the person from marketing features and model training, not only from sends
Know, delete, correct, opt out of sale or sharing, limit sensitive data	5	Audit log for access; deletion and correction propagate to features; sensitive attributes excluded
No penalty for exercising rights	5	Rights requests are not model features; service quality is not conditioned on them
Protection by design and by default	1	All of the above, with defaults set to the narrowest purpose

Source: our design, with the works cited in the table.

4Privacy-preserving analytics

Marketing teams also need aggregate reporting and data sets for analysis. Removing names is not enough to make such data safe. k-anonymity formalises a release in which each record is indistinguishable from at least k-1 others on the identifying attributes⁷, but high-dimensional behavioural data is hard to protect this way: an attack on a large data set of anonymous movie ratings identified individual subscribers from a small amount of background knowledge⁸. Purchase and browsing histories are sparse in the same way. The design therefore does not release record-level behavioural exports as "anonymised". Aggregate reports with small cells are suppressed or published with differential privacy, which gives a mathematical bound on what any output reveals about any one person⁹. For some on-device signals, federated learning trains a shared model from updates computed on devices without collecting the raw data centrally¹⁰; we list it as an option to evaluate, not as a component we rely on.

5Consent interfaces

Consent recorded through a manipulative interface is a poor basis for anything downstream. In field experiments with more than 80,000 users of a German website, the position of a consent notice and the type of choice offered changed how people interacted with it, and nudging had a large effect on the choices they made¹¹. A study of 680 consent pop-ups from the five most popular consent platforms on the top 10,000 UK websites found dark patterns and implied consent to be ubiquitous, with only 11.8% meeting minimal requirements based on European law, and a field experiment found that removing the opt-out button from the first page increased consent by 22 to 23 percentage points¹². The design's preference centre therefore offers accept and decline with equal prominence, uses no pre-selected options, separates purposes, and makes withdrawal as easy as consent, as the GDPR requires¹. These choices lower recorded consent rates relative to a manipulative design; that is the intended effect.

6Costs and trade-offs

The design gives up data that unconstrained systems use, and published evidence says this has a cost. After EU privacy regulation restricted advertisers' ability to collect data for targeting, display advertising in the EU became far less effective at changing stated purchase intent relative to other countries, with larger losses for general-content websites¹³. A review of the economics of privacy finds situations in which privacy protection both raises and lowers individual and social welfare, and finds that consumers often decide about their data under imperfect or asymmetric information about when it is collected, for what purposes and with what consequences¹⁴. We do not claim the design is free. We claim that the constraints it encodes are requirements, and that making them explicit allows their cost to be measured rather than discovered in an enforcement action.

Privacy by design is also an organisational problem as much as a technical one: management commitment and step-by-step methods for integrating privacy into systems are among its main challenges¹⁵. The policy engine and the purpose registry give that commitment a place to live, but they do not create it.

7Evaluation protocol

Before any claim about outcomes could be made, a deployment would need to measure:

• Enforcement. The share of model training runs and decisions with a complete audit record, and the time from a consent withdrawal or objection to its effect in features, models and sends.
• Coverage. The share of people contactable for each purpose and channel, by jurisdiction.
• Performance cost. Predictive and decision performance of purpose-scoped models. A comparison against an unconstrained model could only be run offline on data already lawfully held for the purpose in question; training on data outside the purpose to measure the gap would itself breach the design.
• Rights handling. Time to fulfil access, deletion and correction requests, and completeness of what is returned or deleted.
• Interface effects. Consent rates and later withdrawal rates under the symmetric preference centre, by jurisdiction.

8Fairness

Consent and data availability vary by region and group. A model trained only on people who consented may serve non-consenting people's segments worse when they later consent, or may steer offers toward groups with more data. The design reports model performance and offer distribution by jurisdiction and cohort, and does not use the exercise of privacy rights as a feature, consistent with the non-discrimination right described above⁵.

9Limitations

• No measurements. We have not measured the performance cost, coverage or enforcement latency of this design.
• Not legal advice. We read the cited texts to derive engineering requirements. Their interpretation, national implementations of EU directives, regulator guidance and later amendments are outside this paper. For the ePrivacy Directive we read the text as adopted in 2002; for the CCPA we rely on the Attorney General's summary of the law as amended by the CPRA⁵.
• Partial coverage. We covered five instruments. Many other jurisdictions have their own laws, and rules for SMS, calls and messaging apps vary further.
• Classification of purposes. The design depends on a correct, reviewed list of purposes and on correct tagging of features. Mistakes there pass silently through every later layer.
• Legacy data. Data collected before purpose tagging may lack the metadata the design needs and may have to be excluded.

10Conclusion

We have described a design for marketing automation in which consent, legal basis and purpose govern data access, feature computation, training, serving and sending, with an audit record for each decision. The requirements come from the text of the cited laws and the technical choices from published work on privacy engineering, anonymisation, differential privacy and consent interfaces, mapped in Table 1. The next step is to implement the consent graph and purpose-scoped features for one purpose, marketing email, and measure enforcement latency and coverage before extending to other purposes and channels.