AI personalisation that's relevant,
not creepy.

It can be: badly done, it's the "why is this following me" feeling that makes people reach for the cookie settings. The line is usually obvious when you look for it. Helpful personalisation uses what a customer knowingly shared with you to save them effort (their size, their reorder cycle, the category they always browse); creepy personalisation reveals that you inferred something they never told you. We build to the first side of that line and write the boundaries into scope: sensitive categories are excluded, inferred traits are never surfaced in copy, and consent is checked at decision time. The working test: if the customer could see exactly why they were shown something, would they mind? If yes, it doesn't ship.

First-party behaviour from your own properties: pages browsed, products bought, searches run, emails opened, tied to consent your privacy flow actually collected. We don't buy third-party profiles or enrich against data brokers. Besides the ethics, that data is exactly what regulators and browsers are killing. If your traffic or history is thin, a smaller plan helps more than machine learning: we start with a handful of behavioural segments rather than pretending one-to-one prediction is possible, and the pilot scope says so plainly. The discovery audit tells you what you have, what it supports, and what a consent-flow fix would unlock, before anything is priced.

Against a holdout: a randomly assigned slice of your audience that never sees personalisation and acts as the control. Every result is a comparison between the personalised group and that baseline, on your own commercial metrics: conversion, order value, repeat purchase. This is why no page of ours quotes an average uplift number. Vendor averages tell you about the vendor's best clients, not about your site. It also means we find out when a tactic isn't paying: the holdout exposes personalisation that merely reshuffles revenue rather than adding it, and those tactics get retired in the report, not defended.

Personalisation only runs on data your consent flow permits: that's an architectural rule, not a policy aspiration. Consent state is evaluated at decision time, so a visitor who declines tracking gets the default experience with no degradation and no nagging. Withdraw consent later and the personalisation stops with it. Data stays in your own stack, processing purposes are documented so your DPO has answers before the regulator asks, and regional rules (GDPR, UK GDPR, similar regimes elsewhere) are part of the scope conversation, not an afterthought. We work under NDA as standard, and we'll tell you plainly if something you've asked for can't be squared with the consent you actually hold.

They're complements, not rivals. An A/B test asks "which version is better for everyone?" and ships the winner to all visitors. Personalisation asks "which version is better for this segment?" and serves different experiences to different people. Each personalisation rule is itself validated experimentally against the holdout, so the discipline your CRO programme taught you still applies. In practice the two feed each other: test results reveal segments that respond differently, and personalisation rules generate hypotheses worth testing properly. If you already run a conversion-optimisation programme, we plug into it rather than duplicating it.

It depends on the surfaces, the data work and the guardrails your sector needs, so we don't quote from a rate card. Every engagement opens with a scoped pilot: one surface, agreed segments, a preserved holdout, priced as a small, defined build. The proposal you receive itemises what ships, including the rules built, the integrations wired, and the measurement included. You compare deliverables, not day rates. Extending to more surfaces or lifecycle flows is priced per step, only after the holdout numbers have earned it.

Both. On a store it recommends products, re-ranks search and shapes content blocks for returning customers and first-time visitors. The same consented signals feed lifecycle segments your email and SMS flows can act on. It is built into the storefront or CMS you already run, not a platform you migrate to.