HUB · 6 GUIDES
Content personalisation
How headless CMS platforms power personalised content across web, app and channel, and where Australian privacy rules apply.
Quick answer: A headless CMS enables personalisation by storing content variants as structured data served via API to any channel, subject to the Australian Privacy Principles.
Last updated
Quick answer
What is content personalisation in a headless CMS, and how does it work?
Content personalisation serves different content variants to different audiences. A headless CMS stores each variant once and delivers it through an API that any front end or channel can query with segment context.
Additional Context
Applies to React and Next.js front ends pulling content from a decoupled CMS API, and to enterprise platforms such as AEM when personalisation logic sits outside the authoring layer.
Sources
- Australian Privacy Principles guidance
OAIC guidance on how APP 3 and APP 6 govern collection and use of personal information, relevant to any profiling used for personalisation.
- Notifiable Data Breaches scheme
OAIC scheme requiring organisations to report eligible data breaches, relevant to systems that centralise personal data for targeting.
How it works
How a headless CMS enables content personalisation
A headless CMS separates the content store from the presentation layer, exposing every piece of content through an API rather than baking it into a template. That separation is what makes personalisation practical at scale: a single article, product description or hero banner can hold several audience-specific variants, and the API decides which variant to return based on segment, device or behavioural signal passed in at request time. Teams building on headless CMS architecture for the first time typically underestimate how much of the personalisation logic needs to live inside the content model, since the delivery layer alone can't hold it.
The failure mode shows up early. A content model built for a single 'page' object with no concept of variants forces every personalised block to become a schema change. Marketing teams end up waiting on a developer for edits that should take minutes, simply because the model has nowhere to put a second version of anything. Modelling for personalisation from the start, with explicit variant fields and segment metadata, avoids that bottleneck later.
Headless CMS vs traditional CMS for personalisation
A traditional, coupled CMS renders the page and the personalisation logic in one system, which works fine for a handful of rules but breaks down once personalisation needs to reach a mobile app, a kiosk or a partner site on a different stack. A headless CMS treats content as data served over an API, so the same personalisation rules and content variants can be reused across every surface without duplicating logic. This is also why React and Next.js front ends favour headless platforms: the API contract stays stable regardless of what renders it, and personalisation state can be resolved client-side or at the edge.
Where personalisation depends on behavioural signals rather than a declared attribute, the compliance picture changes. Systems that infer interest or intent from browsing activity face closer scrutiny under Australian privacy law than systems that segment by stated preference, covered in more detail in the piece on behavioural targeting. Enterprise deployments running Adobe Experience Manager in a headless configuration face the same modelling questions, even though the authoring experience differs considerably from developer-first platforms like Contentful or Sanity.
The Problem
Personalisation That Doesn't Outrun Your Content Model
Problem
Marketing teams want to serve different content to different segments across web, app and email, but the content platform they're running was built for one version of each page. Every new personalisation idea turns into a developer ticket, and the backlog grows faster than the campaigns it's meant to support.
Common Pain Points:
- Every variant needs a developer Content models built for one version per page force schema changes for routine campaign work.
- Segmentation logic lives outside the CMS Audience rules sit in a CDP or analytics tool with no reliable link back to the content that should respond to them.
- Personalisation stalls at the pilot stage A single successful campaign proves the concept, but the platform can't scale rules across channels.
Business Impact:
Time Wasted: Recurring developer requests for content changes that should be marketer-editable
Cost Implication: Ongoing agency or developer spend on changes a properly modelled CMS would let marketers make directly
Opportunity Cost: Campaigns launch late or ship a single generic version because the platform can't hold variants
Solution
Rebuild the content model around explicit variants and segment metadata inside the existing headless CMS, then hand the resulting authoring interface to marketing so routine changes no longer need a development ticket.
Our Approach:
- Audit the current content model(2-3 weeks)
Map every page and component type against the personalisation rules the business actually wants to run, identifying where variant fields are missing.
- Introduce variant and segment fields(4-8 weeks)
Extend content types with structured variant and audience metadata, then connect the delivery API to the segmentation source already in use.
Expected Outcome: Marketers can publish and adjust personalised content variants without a development ticket for every change.
Key Takeaways
What Actually Determines Personalisation Success
- Content modelling matters more than the personalisation engineImportant
A well-modelled headless CMS with explicit variant fields will outperform a sophisticated personalisation tool bolted onto a rigid content model.
- Segment data and content variants need a stable linkCritical
Personalisation breaks down when the CDP or analytics platform holding audience segments has no reliable identifier shared with the CMS content variants.
- React and Next.js front ends favour API-first deliveryImportant
Decoupled front ends resolve personalisation rules against a stable content API, which keeps rendering logic separate from what content gets shown.
- Behavioural targeting carries more compliance weight than declared preferenceCritical
Inferring interest from browsing activity draws closer scrutiny under the Australian Privacy Principles than segmenting by information a customer volunteered.
Personalisation succeeds when the content model, the segmentation source and the delivery API are designed together as one system, from the first schema decision onward.
Personalisation, Data Handling and Regulatory Context
Personalisation systems that use behavioural or profiling data sit inside a specific Australian regulatory framework, which shapes how the content model and segmentation logic should be designed.
Governs collection and use of personal information
APP 3 and APP 6 scope
Significance: highThe Australian Privacy Principles set out when personal information, including inferred interest data used for personalisation, can be collected and how it can subsequently be used or disclosed.
Source: OAIC, Australian Privacy Principles guidance, oaic.gov.au
Mandatory reporting of eligible breaches
Notifiable Data Breaches scheme
Significance: mediumCentralising audience and behavioural data to power personalisation increases the personal information holding that falls under the OAIC's mandatory breach reporting scheme.
Source: OAIC, Notifiable Data Breaches scheme, oaic.gov.au
Subject of ACCC inquiry
Digital platform profiling scrutiny
Significance: mediumThe ACCC's Digital Platforms Inquiry work has kept sustained regulatory attention on how platforms profile and target users, a pressure that extends to any business running its own behavioural personalisation.
Source: ACCC, Digital Platforms Inquiry, accc.gov.au
Methodology
Points drawn from published Australian regulatory guidance and inquiry findings rather than internal project data, reflecting the compliance backdrop any personalisation build needs to account for.
Choosing an approach
Choosing the right personalisation approach
Not every personalisation need justifies a dedicated engine. Rule-based segmentation, where a visitor sees one of two or three predefined variants based on declared attributes like location or industry, can usually run inside the CMS itself with no additional platform. A content recommendation engine becomes worth the added complexity only once the number of content items and audience combinations grows past what a marketer can reasonably configure by hand, typically once a catalogue or resource library runs into the hundreds of items.
Enterprise headless CMS platforms, including AEM running in headless mode, ship with native personalisation modules, but the modules are only as good as the underlying content model. A business migrating off a monolithic WordPress site, similar to the multi-site consolidation covered in the WordPress to headless CMS migration case study, often finds personalisation is the reason the migration was worth doing at all, since the old platform had no clean way to hold multiple variants of the same content block.
Privacy and measurement considerations
Every personalisation rule needs proof it worked. That means running content experimentation against the variants the CMS is serving and checking the results, since assumptions about which version performs better are frequently wrong. It also means deciding, before a single rule ships, what data actually needs to be collected to drive the segmentation. The businesses that get this right define the segmentation logic first and only then decide what data is strictly needed to run it, keeping the collection footprint smaller and easier to justify under Australian privacy law.
Talk to National Digital About Your Content Platform
Whether personalisation means rule-based variants inside your existing CMS or a full recommendation engine, an initial conversation maps out what your current platform can already do.
Content Personalisation FAQs
Can Adobe Experience Manager run as a headless CMS?
Adobe Experience Manager supports a headless content model through its Content Fragments and GraphQL API, alongside its traditional page-based authoring. Many enterprise teams run AEM in a hybrid mode, using the headless layer for app and channel delivery while keeping page authoring for the main website, which differs from a purpose-built headless platform where every delivery path is API-first by default.
Why choose a headless CMS over a traditional CMS for personalised content?
A traditional CMS renders pages and personalisation logic in one system, which limits reuse to that one website. A headless CMS stores content as structured data with variant fields, then serves it through an API to web, app, email and any other channel, so the same personalisation rule works everywhere without being rebuilt per surface.
Do headless CMS platforms come with personalisation built in?
Some, including Contentful, Sanity and enterprise platforms like AEM, offer native personalisation or experimentation add-ons, while others such as Strapi leave segmentation to an external tool. A platform without personalisation features but a well-structured content model is often easier to extend than one with personalisation switched on but a rigid model underneath.
Is a headless CMS a good fit for a React or Next.js front end?
Yes. Headless platforms expose content through a REST or GraphQL API, which is exactly the contract a React or Next.js application expects, and the front end can resolve personalisation state client-side or at the edge without waiting on the CMS to render a full page. This is the main reason headless architecture and modern JavaScript frameworks are usually adopted together.
What does content personalisation actually mean for a marketing team?
It means the same page, email or app screen can show a different version of a content block depending on who's viewing it, based on attributes like industry, location or prior behaviour. That only works smoothly when the CMS stores each variant as structured content; treating each variant as a one-off page duplicate turns every new variant into a manual build.
How does personalisation stay compliant with Australian privacy law?
Personalisation built on inferred or behavioural data falls under Australian Privacy Principles 3 and 6, which govern collection and use of personal information; segmentation based on information a customer explicitly provided carries a lighter compliance burden. Designing the content model to collect only what a rule genuinely needs, and documenting that decision, is the practical way most businesses manage this.