AI personalisation in marketing: how to scope a pilot project

AI personalisation should start with exactly one verifiable decision: for which person or group, in a given context, is which next action permitted and covered by the agreed purpose? A model score alone does not answer that. The decision needs stable eligibility rules, a clear data purpose, permitted actions, exclusions, a neutral default and a success measure defined in advance. Only when the decision can be explained on a single page is a limited pilot worthwhile.

Personalisation is a decision, not decoration

Adding a person’s name to a greeting does not by itself establish a sound personalisation strategy. Conversely, the recommended next action — the “next best action” — does not have to be different for every individual. It might, for example, choose between three approved information paths, or deliberately recommend no action at all. What matters is that the range of choices was narrowed in advance and that the system does not invent new offers, promises or contact channels on its own initiative.

Write the use case as a decision sentence: “If a record is permitted for purpose A, no exclusion rule applies and context B is present, the system may choose from the approved options C; where evidence is missing, option D applies as the neutral default.” That makes five things visible: the purpose, eligibility, the context, the permitted choices and the default. “Improve the customer experience with AI” names none of them and is therefore not yet a workable brief.

Start with a small audience and a clear decision point

A good starting point is neither the whole customer journey nor a standing promise that everything reacts in real time. Choose a clearly bounded situation in which the same question recurs, and decide in advance which options are available and what counts as success. One possible case is the order in which help content appears after a topic the visitor has explicitly chosen. A hypothetical example: after someone selects “setup”, a website may show a quick guide, a checklist or the neutral home page; if the situation remains unclear, the home page appears. The example only sets out approved response options, not a demonstrated result of personalisation; no real customer and no outcome are claimed.

Begin by establishing who is eligible at all. Eligibility is more than technical reachability. It covers purpose compatibility, channel status, how current the information is, exclusion lists, goals already reached and, where relevant, valid consent. The fact that a person’s record exists in the system does not make that person eligible for every analysis or approach. The eligibility check must come before the model decision and must be deterministically traceable.

Choose data by purpose, not by availability

Many personalisation projects begin with the question of what data is available. It is better to reverse that order: what is the minimum information this specific decision needs? An explicitly chosen topic may be enough, while complete contact or behavioural histories would be unnecessary. The FDPIC’s guidance on data processing using cookies and similar technologies (version 1.1) requires a purpose-related, transparent and proportionate review for cookies and similar technologies. It cannot be applied wholesale to every channel, but it supports the question of whether every available signal is really necessary for the purpose described.

Every input field needs a name, a source, a purpose, a date it was last updated and a person responsible for it. Derived features are marked separately. A field such as “high interest” is not an observation but an interpretation. The team must know how the feature was calculated and when it expires. Missing values must not be silently replaced by assumptions that merely sound plausible.

Personalisation may involve profiling or an automated individual decision. Whether a particular processing operation falls into that category, and which safeguards apply, depends on the individual case. The FDPIC stresses transparency about the purpose, how the system works and the data sources, together with human review for significant automated individual decisions. Where the risk is expected to be high, it must be clarified whether a data protection impact assessment is required. That is a question to examine, not a blanket diagnosis for every use case.

Keep the permitted set of actions deliberately small

A model should not draw freely on the entire marketing inventory. Define a positive list of permitted actions and a negative list. The positive list contains only variants reviewed on business and legal grounds, with stable identifiers. The negative list can include price changes, discount promises, sensitive topics, new contact channels or statements without an approved source. That turns an open generation problem into a bounded selection decision.

The impact of an action must be classified as well. An internal recommendation is less intrusive than a message sent automatically. Reordering a help section is judged differently from changing a price for one person. For a first pilot, the output should be reversible and, where possible, appear only as a proposal. Assign a reviewer who can inspect the inputs, rationale, selected action and fallback before the system affects a customer.

The neutral default is part of the product

A neutral default is not a technical error state but a deliberately designed customer experience. It applies when data is missing, sources contradict each other, the model answers outside the permitted options, confidence is insufficient or a block becomes active. The default may be a neutral help page, no message at all or a manual review task. “Show something anyway” is not a safe strategy.

Define contact exclusions and stop signals as well. A withdrawal, a complaint or an exceeded contact limit blocks the type of contact or use concerned; an independent neutral help page remains available. The system must not repeat the same proposal endlessly. Give each action an expiry time, a frequency limit and a clear stopping condition. These rules stay outside the model and are logged.

Make corrections and group differences visible

A professional review should not only read individual recommendations; it should also look for recurring patterns. How often does the system fall back to the neutral default for each defined group? Which inputs are missing particularly often? Which option do reviewers correct, and why? Such differences may point to gaps in the data, unsuitable features or a poorly chosen set of permitted options. They are a reason to investigate, not automatic proof of discrimination or of model quality.

Information about people must remain correctable. If a source is corrected or a status withdrawn, the next decision must not continue to rely on a feature derived from the old data. Define update deadlines and a way to recalculate or delete derived features. For each pilot, a named person decides which anomaly triggers a pause and who investigates the cause. That makes quality control an ongoing process rather than a one-off sign-off of the model.

Transparency for the people concerned and for the team

Transparency has two levels. The people concerned need appropriate, accessible information about how their data is processed and how to request access, correction or deletion. The internal team needs an audit trail: which version of the data was used? Which rule made the record eligible? Which options were available? Was a recommendation reviewed, delivered or discarded? Without that trail, the team cannot reliably explain an error or respond to a request for access, correction or deletion.

For cookies, third-party access or cross-channel tracking, the specific configuration must be reviewed separately. The FDPIC’s updated guidance shows that personalised advertising with third-party access and intensive location-based or cross-site profiling can create particular risks. That does not amount to a universal consent rule for every form of personalisation. It does mean that a project must not hide its data flows behind the catch-all term “optimisation”. The guidance supports a review of purpose and proportionality, and the distinction between ordinary and particularly risky profiling.

Measure impact through comparison, not activity

A model can produce many recommendations without improving the customer experience. So separate operational metrics from outcome metrics. Operational metrics include the share of eligible cases, the fallback rate, the review rate, error reasons and time to decision; they show whether the process runs reliably. Clicks, helpful task completion, qualified enquiries or customer satisfaction are outcome metrics and must be defined separately.

Before a pilot, choose one primary metric — not the most flattering number after the fact. Add guardrail metrics: opt-outs, complaints, frequent manual corrections and unexpected group differences. Where possible, a randomly assigned control group stays on the neutral default. Such a control group can support a causal effect on the click metric defined in advance; a higher observed click rate on its own proves neither causality nor long-term benefit.

Start with synthetic cases, then run in shadow mode

Test first with constructed examples: a complete eligible case, a missing mandatory field, contradictory signals, an active block, outdated data and a non-permitted output. For each case, the required result is fixed in advance: “not eligible”, “fallback”, “review” or “approved option”. A test counts as passed only when the log entry and the stop signal are correct too.

After that, shadow mode — the system produces recommendations without changing what customers see — shows the team which rules are missing and which data is not reliable. Approved variants reach customers only in a limited later phase. Every expansion needs a fresh review of purpose, risk, quality and measurement. A small pilot that runs successfully is not automatic permission to include more data, channels or autonomous actions. Examples of visible website behaviour in this article are hypothetical and not a customer result.

Settle the decision before the technology

A personalisation decision is ready for a pilot when the purpose, eligible group, minimum inputs, permitted actions, exclusions, neutral default, approval role, measurement plan and stop signals have all been named. If one of them is missing, the next task is a business clarification, not the selection of a model.

How maitiq helps: a relevant variant first, more complexity later

A pilot of manageable scope tests whether returning visitors receive a more relevant response to their stated interest. Start with transparent, approved segments and two variants reviewed on business grounds. Unknown features must not be replaced by supposed knowledge about individuals.

Check task completion, qualified enquiries and complaints against an unchanged comparison group. Within a scoped project agreed with you, maitiq can record the intended outcome, the rules for selecting a variant and the evaluation plan together with your team. Data access, delivery and integration are clarified in concrete terms before implementation. Personalisation is not a blanket promise of the Google Ads product; its benefit is judged on the specific interaction the project sets out to improve, against the effort and risk involved.

How a first pilot with maitiq starts

A scoped preliminary review shows which personalisation case is narrow enough, and what data minimisation, testing and the limits of later operation should look like. For an agreed pilot project, we record the project scope, the open data and control questions, the pilot plan and the criteria for later operation.

Decision rule: Personalise only when the purpose, data source, permitted use, fallback and impact measurement are settled before the test.

Sources and context

Both sources are linked below. The FDPIC’s guidance on data processing using cookies and similar technologies (version 1.1, English edition) sets out how cookies and similar technologies are reviewed for purpose, transparency and proportionality; it underpins the sections on data minimisation and transparency. The FDPIC’s page on AI and data protection places transparency about purpose, how a system works and its data sources, together with human review of automated individual decisions, in context. As authority sources, neither replaces an assessment of your specific case.

Have maitiq review your specific case.