One bounded cream region becomes visible while the wider blue field remains quiet.

Growth Marketing

Personalisation Should Earn the Data It Asks For

Use customer data only where it creates a clear, useful difference.

MT BYTES6 min read
Read the perspective

Name the benefit before requesting the information

Remembering a customer's chosen language can make a service easier to use. Remembering a delivery preference may remove a repetitive step. Building a detailed profile from unrelated behaviour raises different questions, even when all three activities are described as personalisation.

The term covers too much to serve as a project brief. Before deciding what data to collect, state what the proposed feature will do for the customer and what the business expects to gain. Be specific enough that both claims can be assessed.

A business might want to help customers find the relevant support route, recommend an appropriate service or avoid showing information they have already supplied. Each purpose creates a different data requirement. “Improve the customer experience” is too broad to explain why a particular detail is necessary.

Start with a short description of the feature: when it appears, what changes, which information drives that change and how the customer can correct it. If the team cannot explain that relationship clearly, it may be too early to build the feature.

This also helps distinguish useful personalisation from an attempt to collect information that might become valuable later. The business should be able to justify the present use and recognise when a proposed new use needs a fresh decision.

Personalisation deserves a clear purpose before it deserves more data. That order makes the design, technical scope and customer explanation easier to evaluate.

Personalisation deserves a clear purpose before it deserves more data.

Find the least intrusive way to help

A feature does not always need a persistent customer profile. A choice made in the current session may provide enough context. A preference stated by the customer may be more useful than an inference assembled from unrelated activity.

Consider a hypothetical business-support website that wants to show relevant service information. Asking visitors to select their immediate problem could be sufficient. Inferring the same need from a broad collection of browsing history would create a more complicated data flow and more opportunities to misunderstand the person.

Examine what happens when the inference is wrong. Can the customer see and correct the assumed preference? Will an outdated profile keep presenting an irrelevant offer? Could someone using a shared device receive information intended for another person?

The FTC's January 2025 update on surveillance-pricing research describes early findings about direct and inferred information used in pricing systems. Examine the specific use: remembering a customer's stated preference and changing a price based on a profile create different decisions about what information the business needs and how the customer is affected.

For a proposed feature, compare a simpler option with the more data-intensive version. What additional customer benefit does the extra information create? Is the improvement meaningful enough to justify the added complexity, security exposure and maintenance?

Sometimes the answer may support a richer profile. Sometimes a clearly expressed preference will do the job. The useful decision is the one tied to the feature's purpose, rather than a general assumption that more information must produce a better experience.

Make the customer's choice change the system

A preference control is credible only if it affects the experience as described. The customer should be able to understand the choice, make it without unnecessary pressure and see the relevant consequences.

The FTC's 2022 report on dark patterns discusses interface practices that obscure or frustrate privacy choices. It is a US staff report, not a universal template for legal compliance.

Apply the underlying design question to the proposed feature. Is the explanation specific enough for the customer to understand the use? Are optional choices distinguishable from information required to deliver the requested service? Does declining an optional feature leave a workable route through the essential task?

The implementation must honour the answer. If a customer changes a preference, identify which systems need the update and how the change will be reflected. A visible setting that leaves connected marketing or recommendation systems unchanged creates a misleading experience.

Correction matters as much as initial choice. People change roles, locations, needs and interests. A profile should not make an old assumption difficult to escape. Where a feature relies on an inferred preference, give the customer an understandable way to replace it.

Avoid turning every interaction into a long consent exercise. That can make the service harder to use without making the decision clearer. Design explanations around the actual use and its significance, while obtaining the legal review required for the jurisdictions and information involved.

The result should be a functioning control, not merely a screen that records an acceptance.

Follow the information beyond the interface

A clear customer explanation is only the visible part of the work. The business needs to know where the information goes, who can access it and what happens when it is no longer needed.

Map the systems involved in the feature, including analytics, customer management, messaging and external personalisation services. Identify which fields each one receives and why. A broad integration that copies an entire profile may be convenient to configure while exceeding what the feature requires.

The FTC's Start with Security guidance recommends limiting unnecessary collection, retention and access. For a project team, that translates into concrete decisions about fields, permissions, supplier arrangements and deletion.

Keep development and testing in view. A feature can be evaluated with suitable test information without casually copying live customer details into every environment. Decide who needs access for support and how that access is removed when responsibilities change.

Retention needs its own decision. Information useful during an active request may not be needed indefinitely. Define a review or deletion rule around the purpose and applicable obligations, then check that connected systems can follow it. Removing a visible profile field does not necessarily remove its copies elsewhere.

Location also matters. A business operating across the US, Pakistan, GCC and APAC cannot treat a single privacy statement as proof that every data flow is appropriate. Applicable duties depend on the countries, people, data and organisations involved. Obtain the relevant local advice before treating a design choice as a legal conclusion.

This is a useful point to involve cybersecurity expertise. The customer-facing feature and its underlying data handling need to be assessed together, so the business can support the explanation it gives to customers.

Assess usefulness and the ability to correct

An increase in clicks can be relevant, but it is not a complete assessment of personalisation. Examine whether the feature helps the intended customer complete a useful task and whether errors or unwanted effects are being addressed.

For a support-routing feature, the important question may be whether customers reach the right team with less repetition. For a service recommendation, it may be whether the suggestion fits the stated need. The appropriate outcome follows from the purpose established in the brief.

Include evidence that might challenge the feature. Are people repeatedly changing the suggested preference? Do staff receive complaints about irrelevant messages? Does the system make it hard to discover options outside the profile? These observations can point to a narrow improvement or to a reason to remove the feature.

Review the data requirement when the feature changes. Adding a new recommendation or connecting a new supplier can alter the purpose and exposure even if the interface looks familiar. Keep the technical description and customer explanation current.

Include a named owner for that review in the growth marketing plan. The feature should not continue collecting information indefinitely simply because nobody has responsibility for deciding whether it still serves its purpose.

Begin with a feature the business can explain and maintain. Expand it when the evidence supports the additional complexity, with the customer's ability to understand and correct the experience preserved.

MT
MT BYTES

Perspectives on technology and business.

Explore perspectives

Give your personalisation project clear boundaries

Discuss the customer benefit, data requirements and implementation controls for your personalisation project with MT BYTES.

Discuss your project