Personalization
Personalization That Doesn’t Need a Cookie
Most personalization projects stall waiting for a customer data platform. The signals that move conversion most arrive with the click itself. They are free, immediate, and store nothing about anyone.
Ask a growth team about personalization and you usually get a roadmap: unify the data, build the profiles, define the segments, then finally change what someone sees. Twelve months later the profiles exist and the landing page still says the same thing to everyone.
Meanwhile the highest-value signal was arriving with every single click and being thrown away. You know which campaign sent them, which keyword or creative earned the click, what device they are holding, and where they are. None of it requires a profile, a cookie, or knowing who they are.
What arrives with every click, for free
| Signal | What it tells you | What to change |
|---|---|---|
| Keyword or search term | The problem in their words | Headline and first proof point |
| Campaign or ad set | The promise they responded to | Offer and hero image |
| Device | How much patience they have | Form length and page weight |
| Geography | Currency, language, availability | Price display and delivery claims |
| Time of day | Whether a human is available | Call now versus book a time |
| Referrer | Where they came from | How much context to assume |
None of this identifies anyone. It is context about the visit, not a profile of a person, which is why it survives every privacy change and why you can use it on the very first visit, the one where a profile-based approach has nothing to work with.
Profile-based personalization is useless when it matters most
For a paid acquisition funnel, most visitors are new. A system that personalizes based on accumulated behaviour has nothing on a first visit, which is exactly the visit you paid for. It works best for returning customers, who are usually your cheapest traffic already.
Change the promise, not the pixel
The common failure is personalizing the wrong depth. Injecting a city name into a headline is a parlour trick that visitors have learned to distrust. Changing what the page argues is what moves the number.
A useful ladder 01
Swap the headline to match the promise
The lowest-effort change with the largest effect. The ad said a thing; the page should say the same thing.
A useful ladder 02
Reorder the proof
Same page, different sequence. Lead with the objection this segment actually has rather than a fixed order.
A useful ladder 03
Change the offer or the next step
A high-intent comparison visitor and a top-of-funnel browser should not be asked for the same commitment.
A useful ladder 04
Branch the whole journey
Different segments follow genuinely different paths. Highest effort, and worth it only where the segments want different things.
Most teams get most of the available lift from the first two rungs, and never need a customer data platform to do it.
The line between relevant and unsettling
- Reflect what they told you, not what you worked out. Responding to a search someone typed feels helpful. Referencing something they never volunteered feels like surveillance.
- Never display the inference. Using company size to choose which case study to show is fine. Writing “as a 200-person company” on the page is not.
- Fail to something sensible. Every variant needs a default for when the signal is missing, and the default should be a good page in its own right.
- Keep the substance honest. Personalizing which true thing you lead with is good practice. Personalizing the claim itself is not.
Frequently asked questions
- Q: Do we need a CDP for this?
- Not for anything described here. Campaign context, device, geography and referrer arrive with the request. A CDP becomes useful for lifecycle and retention work, which is a different problem from first-touch paid acquisition.
- Q: How many variants before it becomes unmanageable?
- It becomes unmanageable when each variant is a hand-built page someone owns. Group by promise rather than by campaign, keep shared sections shared, and the count stays sane.
- Q: Does this need consent?
- Using request context to decide what to render generally does not involve storing anything about the visitor, which is what most consent regimes govern. Storing it, joining it to an identity, or passing it to third parties is a different matter. Check with whoever owns privacy at your company.