How to choose your first personalisation use case and get it live

In my last post in this series on getting personalisation projects off the ground, I made the case for starting small. Not because ambition itself is the problem, but because the way most personalisation projects are set up makes getting started as difficult as possible. The teams that make personalisation work tend to pick one journey, solve it properly, and build from there.

This post is about doing exactly that. How to identify the right use case, what you actually need to get it live, and how to know whether it's working. To make the steps as concrete as possible, I've used a single scenario throughout. A university homepage, a prospective international student, and the question of what it takes to serve that visitor something more relevant than the default. However, the same logic applies regardless of the sector you're working in.

When you’re looking for your personalisation starting point, it’s tempting to ask, "Where could personalisation be useful?" The problem is, that question has too many answers to be actionable, and it tends to push thinking in the wrong direction. It encourages a kind of open-ended speculation that produces long lists of possibilities without a clear way of prioritising between them. Teams end up getting bogged down in hypotheticals rather than making a decision, and the project stalls before you’ve even scoped anything.

It’s more useful to ask where your site most obviously fails to serve a specific, identifiable group of people.

If you look at your site in this way, the answer tends to surface quickly. Maybe there’s a high-traffic page that treats two very different audiences identically. Perhaps a user journey built for one type of visitor is forcing everyone else to work around it. Or perhaps your homepage features a message that makes sense to most of your traffic but is actively unhelpful to a high-value segment. These usually aren't hard to find – most digital teams already know where the gaps in their user experience are, they've just been waiting for a framework large enough to justify addressing them.

Framing the question this way sets a more realistic scope. The use cases that emerge from "where are we failing a specific group" tend to be well-defined. The ones that emerge from "where could personalisation add value" tend to be ambitious and vague, and vague use cases are the ones that never get built.

With that framing in place, the right first use case tends to have four characteristics.

Not every visitor group justifies having its own experience. The ones that do have needs different enough from the default that serving them the same content is a noticeable failure – not just a missed opportunity. For example, a university homepage that treats prospective international students and current students identically. Or a council website that routes residents and businesses through the same navigation to find completely different services. In both of these cases, the gap between what one group needs and what they're currently getting is obvious.

Personalisation takes work to set up and keep running. Your first use case should quickly prove that effort is worth it, so pick a page or journey where relevance really matters. Good options are high-traffic pages, key conversion points, or moments when a visitor decides whether to continue their journey. For example, a landing page that shows the same message to both first-time visitors and those who have already researched a course is missing an easy win.

A common reason personalisation projects stall is the belief that you need lots of first-party data to get started. Most of the time, you don’t. The signal that tells you which group a visitor belongs to is often much simpler – like their location, referral source, device, or the pages they’ve viewed in the current session. For example, a university wanting to show different content to prospective international students doesn’t need a CRM integration. IP-based location data is enough to spot overseas visitors and show them more relevant content. Instead of asking "What data do we have?", ask "What signal would tell us which group this visitor belongs to?" and work backwards from there.

Personalisation creates a content maintenance commitment. Every variant you create must remain accurate, relevant, and consistent with the rest of the site. Before committing to a use case, it's worth being honest about whether your team has the capacity to create and maintain what‘s required – not just now, but over time. A use case that involves one or two content variations for a well-defined audience is far more sustainable than one that requires unique content for every stage of a complex journey.

The use case that scores well across all four is almost always obvious once you ask the questions directly. If nothing jumps out immediately, go back to your analytics. Look for pages with high bounce rates, drop-off points in key journeys, or segments of traffic that behave differently from the average.

Choosing a well-defined use case is one thing. Keeping it that way throughout the implementation process is another. Decisions get made incrementally – a second audience variant gets added while the first is still being configured, a single personalised message grows into a brief for five page elements – and each one seems reasonable in isolation. It's only when you step back that you notice the scope has doubled before anything has gone live.

The four steps below are deliberately sequenced to prevent that. They move from the broadest decision to the most specific, starting with how you define the audience and ending with what you'll measure, and each one is designed to keep the scope as tight as possible while still getting something meaningful live.

The instinct at this stage is to often over-specify, adding conditions and qualifiers until the audience definition is so narrow it barely triggers. A university setting this up for the first time might start by segmenting by country of origin, then by study level, and then by whether the visitor has previously viewed a course page. That level of specificity isn't necessarily wrong – it's just too much for now. Instead, start with the broadest reasonable version. In this case, that’s visitors outside the UK, identified by IP address. You can refine the definition later, once you have data to tell you whether your assumptions were right. Starting too narrow means the rule won't generate enough traffic to give you anything meaningful to work with.

Identify the one or two content differences that will have the most impact for this audience, and create those. For an international visitor landing on a university homepage, the most obvious gap is usually the hero. A message written with domestic applicants in mind says nothing about the experience of studying in the UK, what makes this institution worth the journey, or the kind of trust signals that appeal to international students. A different hero and a reframed primary CTA – something like "Find out how to apply from overseas" rather than a generic "Apply now" – is enough to test whether the personalised experience is more relevant than the default. Don't personalise every element of the page before the first rule has been tested. You won't be able to tell what's working, and you'll have more to maintain if things need to change.

Getting personalisation working in Contensis requires some initial technical setup – a developer needs to make the relevant components or placeholders in your front-end code available for personalisation. In this example, that means making the hero banner available for personalisation in both the front-end template and the CMS content type. But once that groundwork is in place, the ongoing management sits with the content team. Editors can define audiences, create content variants, set rules, and publish without raising a ticket or waiting on a build cycle – the developer involvement is a one-time cost rather than a recurring overhead every time you want to adjust a rule or test something new.

As my last post covered, reaching for conversion data too early will almost always produce an inconclusive result. For this use case, the signals worth tracking are return visit rate – are international visitors coming back after their first session? – and click-through on the personalised CTA against the default one. Those two metrics will tell you whether the experience is more relevant than what was there before. Define your baseline before the rule goes live, and set a realistic review window. Four to six weeks is usually enough to generate something meaningful.

A first personalisation use case that's running and generating data is worth considerably more than a personalisation programme that's still in the planning stage. But the value isn't just in the results you get, it's in what the process teaches you.

Once the rule has been running long enough to generate meaningful engagement data, the first question isn't "what should we personalise next", it's "have we got this one right." A use case that's working at a basic level can almost always be refined before you expand the scope. This might involve tightening the audience definition, improving the content variant, or adjusting the trigger. The data from the first few weeks will tell you more about your audience than any amount of upfront research, and that makes the next iteration faster and better targeted.

Positive engagement data from a single well-chosen use case is also often enough to shift attitudes internally, particularly among stakeholders who were sceptical at the outset. A concrete result, even a modest one, makes the case for expanding the programme in a way that a strategy document never will. It's easier to secure resource for a second use case when there's evidence that the first one worked than it is to justify the investment before anything has been tried.

The audience behaviour you observe in the first use case will also surface things you didn't anticipate – pages where engagement drops off unexpectedly, segments that behave differently from your assumptions, or content that resonates even more strongly than you expected. Let that data guide what comes next rather than following a pre-planned roadmap. Each use case teaches you something about your audience, your content, and your team's capacity to manage personalisation at scale, making the next one easier to scope, faster to implement, and easier to justify.

In the next post, we'll look at some of the most common personalisation use cases in practice, with content model suggestions and code examples to help your team get started.