How to get started with Wagtail Personalisation: a practical guide

What is Wagtail Personalisation?

Personalisation in Wagtail isn't a single product, it's two layers:

• Core Wagtail already handles common cases: segmented StreamField blocks, preview modes per segment, campaign segmentation via routable pages, and members-only content via private pages.
• The wagtail-personalisation package (open source, MIT licence, now at v1.0.0) adds more advanced, analytics-driven segmentation for organisations that need it — full audience rules, behavioural triggers, and GA4-native reporting.

Everything sits inside the Wagtail admin your editors already use, which means targeting, content, and scheduling all live in one workflow rather than being split across a separate personalisation platform.

The Royal College of Art, who originally commissioned Wagtail's development over a decade ago, is a great example of personalisation in action. Their Senior Website and Content Manager, Helen Roberts, has been leading a rollout that's deliberately practical rather than chasing "the big personalisation dream."

1. Decide why you're doing this before you decide how

The RCA didn't start from "we need a personalisation tool." They started from a governance comparison: cost, control, content design, performance, and data privacy, weighed against the third-party subscription tools they could have bought instead.

Key considerations:

• Cost — native personalisation avoided the recurring licensing fees of third-party tools; the RCA estimated roughly 50% savings in Year 1 alone.
• Control — everything sits inside Wagtail admin, under your own governance, rather than a separate login with its own permissions model.
• Data privacy — segment and visitor data streams directly into your own GA4 property, with no third-party data lock-in.
• Performance — content renders server-side as part of the page, so there's no extra client-side script dragging down Core Web Vitals.

By keeping personalisation native it avoids creating content silos to manage outside the CMS, no separate login pulling editors out of their normal workflow, and no external script sitting on top of the page slowing things down.

2. Choose your CTA types and triggers

Once you know why you're doing it, decide what "personalised content" looks like on your site. There's no fixed menu, CTA types are entirely customisable, built from your own Wagtail components. The RCA settled on four, and they're a good starting reference because they solve a common set of problems that other organisations are likely to recognise too:

• Pop-up — a centred modal overlaying the page, used for time-sensitive promotion (e.g. a webinar).
• Event countdown — a persistent bottom bar counting down to a live event, like the RCA's Summer Shows.
• Collapsible nav — a slide-out side panel for focused journeys, such as offer-holder enrolment or fee payment.
• Embedded footer — contextual next steps built into the footer, low-key and always-on.

With each client, we usually run some light discovery first to work out which CTA types match their use cases, for example, a membership renewal journey needs a different shape of prompt to a donation appeal or an events calendar.

The same customisation applies to triggers, on page load, on inactivity, on scroll depth, or on exit intent, and to the segments you show them to, whether that's time of day, device type, new vs. returning visitor, or geo-location.

You don't need every CTA type or every trigger on day one. Pick the combination that matches a real, current problem rather than building the full toolkit speculatively.

3. Get the package installed

For developers, this is a well-documented, native Wagtail installation; there's no separate platform to procure, integrate, or renew. If personalisation needs go beyond what core Wagtail covers (segmented blocks, preview modes, private pages), the wagtail-personalisation package extends it with the audience-rule and analytics layer described above.

If you work with us at Torchbox, speak to your client partner and we'll help scope this. If you have an in-house team or work with another agency, the wagtail-personalisation documentation and the Wagtail personalisation docs are the right place to start.

4. Build your segments and get your governance right

Once the CTA blocks and triggers are configured, editors can create personalised content directly in the Wagtail admin, assigning triggers, setting page placement (a specific page, or a page type plus its children), and scheduling go-live and expiry dates.

The RCA deliberately restricts CMS creation of personalisation rules to two or three trained admins, and tracks every active campaign in a shared log, such as CTA name, target URL, go-live/expiry dates, screenshots, and rules, so nothing runs indefinitely or gets forgotten about.

If you're a charity, membership body, or public sector organisation, this governance layer matters as much as the technical setup. It's the difference between a useful, current set of personalised journeys and a graveyard of stale pop-ups nobody remembers switching on.

5. Start with one well-defined journey

Rather than personalising broadly from the outset, pick a single, well-bounded use case — a fee-payment deadline, an open day, an enrolment window, and build one CTA type against it.

The RCA's approach across the Sound Practice MA page, the Facilities page, the Enrolment page, and the Research Degrees page shows the same pattern each time: one clear behavioural trigger, one clear audience, one clear next step.

This also makes measurement straightforward from day one, which leads into the next step.

6. Measure it in the tools you already trust

Every impression, click, and conversion tracks straight into your existing GA4 property, which means you can compare personalised CTA performance against the rest of your site using analytics your team already has access to.