--- title: "Hyperpersonalisation in Xperience by Kentico: what you can build today" description: "How far can you take hyperpersonalisation in Xperience by Kentico today? Explore how content, activities, intent and decisioning create adaptive experiences." url: https://www.jeroenfurst.nl/blog/hyperpersonalisation-in-xperience-by-kentico date: 2026-09-24 category: Personalisation tags: [Personalisation] reading_time: 9 --- # Hyperpersonalisation in Xperience by Kentico: what you can build today > How far can you take hyperpersonalisation in Xperience by Kentico today? Explore how content, activities, intent and decisioning create adaptive experiences. Personalisation has been on DXP feature lists for well over a decade, and for most organisations it still means the same thing: define a few audiences, build a variant for each and hope the rules are right. In conversations with other CMS and DXP practitioners I keep hearing the same story. Organisations license personalisation features and never really implement them, or they talk about personalisation and A/B testing without a plan, a measurement structure or the people to run it. I have been part of that history myself. In 2016 I wrote about [content personafication](~/blog/content-personafication) in Kentico 9: assign personas to pages, then filter or sort content so that items tagged for the visitor's persona appear first. The core idea still holds. Content that knows who it is for can be selected and ordered for the right visitor. What has changed is the assumption that a visitor fits one persona, and the amount of signal we can use to find out what they need. By hyperpersonalisation I mean an experience that adapts to what a visitor appears to need right now, based on signals that keep being re-evaluated, rather than a fixed set of audience variants. I have been experimenting with this quite a lot recently, mainly to find out how far Xperience by Kentico can take it today. My short answer: the data, content and extensibility are already there. What you need to add is a decision layer, and that is something you can start building now. ## Why variant-based personalisation stops scaling The classic approach runs into simple arithmetic. Say you want to take five topics, three journey stages and two levels of technical depth into account. That is already 30 combinations. Building and maintaining a hand-made variant for each, per page or per component, is where most personalisation programmes quietly stall. You could generate new content for every combination, but I prefer to compose the experience from structured content you already have and trust: select, order and emphasise existing items based on what you believe about the visitor. That scales better. Adding a topic or journey stage then means classifying content once, and the same selection logic handles every combination it touches. The content stays approved and consistent, which matters most in domains where accuracy and governance count, and personalisation becomes a matter of choosing well. That only works if the content model knows what each item is about. ## From structured content to structured intent In my [previous article about agentic content modelling](~/blog/agentic-content-modelling-why-structured-content-matters-for-ai-agents), I wrote about making meaning explicit in the content model. When content has clear relationships, taxonomy and domain meaning, an AI agent has far less context to reconstruct on its own. The same principle applies to personalisation. If content is properly classified, behaviour becomes more meaningful too. A page view stops being a visit to URL X and becomes a signal that somebody is interested in a particular topic, application or type of information. Add searches, downloads, form interactions and other behaviour, and you gradually build a picture of what that person is trying to achieve. I use a simple model for this: signal, intent, decision, experience, exposure and outcome. ![Six steps connected by arrows: signal, intent, decision, experience, exposure and outcome.](~/assets/blog/signal-to-outcome-hyperpersonalisation.webp) From signal to outcome: the chain behind hyperpersonalisation. The interpretation step is where most of the design work sits. One page view should probably not put somebody permanently into a persona. I would rather track several dimensions at the same time, such as current intent, topic affinity, journey stage and preferred depth of information. Confidence goes up when different signals confirm each other and down again when signals age or stop being reinforced. Personalisation then becomes a hypothesis about the visitor that keeps changing, instead of a fixed label. ## What Xperience by Kentico already provides The platform covers a lot of that chain. It tracks contacts and activities such as page visits and form submissions, and [custom activities](https://docs.kentico.com/documentation/developers-and-admins/digital-marketing-setup/set-up-activities/custom-activities) let developers capture behaviour that is specific to the experience they are building. Contact data, activities and contact groups can then drive personalisation conditions. That personalisation is not limited to Page Builder. Kentico also supports [personalisation conditions directly in components, controllers, views and other application code](https://docs.kentico.com/documentation/developers-and-admins/digital-marketing-setup/content-personalization). For hyperpersonalisation that distinction matters, because intent should be able to influence much more than one component variant: which content is retrieved, which CTA gets emphasis, what information is shown first, which related content is recommended and how the next page in the journey is put together. Kentico's new Customer Data Platform (CDP) adds to this. Kentico is introducing profiles and [segments](https://docs.kentico.com/documentation/developers-and-admins/digital-marketing-setup/customer-data-platform/segments), where a profile can belong to several segments at once and segment membership is re-evaluated automatically when profile information changes. That fits well with the idea that somebody can have multiple affinities and intents at the same time. The CDP is still in preview, so for now it is meant for evaluation. I am already experimenting with it on my own website, and it gives a good feel for where the platform is heading. The approach in this article does not depend on it, though: it works on the existing contact and activity infrastructure today. All of this depends on consent. Activities are only logged for visitors who have agreed to tracking, and the CDP has its own [consent model](https://docs.kentico.com/documentation/developers-and-admins/digital-marketing-setup/customer-data-platform/consent-development-cdp). The decision layer therefore has to work sensibly for anonymous, non-consenting visitors as well. In practice that means a good default experience and session-level signals that are not stored against a contact. ## Let the landing page tell you something A recurring challenge with personalisation is how little we know when somebody first arrives. With organic search, the exact query is generally not passed on to the website, which makes it hard to tell right away why somebody came. This is where personalisation connects with SEO, GEO and AEO. Instead of trying to infer everything after somebody arrives, we can make the destinations themselves much more specific. Structured content allows us to create pages around meaningful combinations of topic, problem, context or intent. When somebody lands directly on such a page from Google, an AI assistant or another discovery channel, the destination itself is a strong first-party signal of what they are probably looking for. Behaviour during the session then confirms or adjusts that assumption. Discovery ends up doing part of the initial matching. ![Flow from discovery to an intent-specific destination, initial intent, behaviour, stronger confidence and a personalised experience.](~/assets/blog/discovery-to-personalised-experience.webp) The landing page as the first signal of intent. There is a clear SEO caveat. This should not turn into a way of generating thousands of slightly different pages to capture every possible query. Google's [guidance on AI features and your website](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) explicitly warns against creating pages for large numbers of query variations when the main purpose is to manipulate rankings or generative responses. Google also [states](https://developers.google.com/search/blog/2026/05/a-new-resource-for-optimizing) that the usual SEO fundamentals continue to apply to AI Overviews and AI Mode. My criterion is therefore simple: a combination from the taxonomy only deserves its own landing page when it represents a distinct and useful user need. ## Humans and machines are becoming different consumers There is another form of personalisation I am already applying on my own website: distinguishing between human and machine consumers. A human visitor benefits from visual hierarchy, navigation, interactive components, images and calls to action. An AI agent or crawler may be better served by a cleaner representation of the same information, such as Markdown. On my site, regular visitors get rich HTML while machine consumers can receive a much cleaner Markdown version. I first treated this as another form of segmentation, but there is a real difference. Human visitors fit naturally into the contact and profile model: they perform activities, build up affinities and may eventually [identify themselves](https://docs.kentico.com/documentation/developers-and-admins/digital-marketing-setup/customer-data-platform/identity-resolution). A crawler has no customer journey of that kind. So I handle machine detection close to the request and rendering layer, rather than forcing an LLM crawler into a CDP segment. What matters is that both representations come from the same structured content. The meaning should not change because the consumer changes. That is also what keeps this on the right side of Google's cloaking rules: the facts and content are identical, only the format differs. Google explicitly states that special Markdown files, `llms.txt` or other AI-specific markup are [not required](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) for Google Search or its generative AI features, and that there is no need to rewrite content specifically for AI systems. So I do not see Markdown as a GEO trick. I see it as an architectural benefit of structured content: one semantic source of truth that can be represented differently depending on who, or what, consumes it. ## What you still need to build: a decision layer Looking at the complete picture, I see three layers. Xperience by Kentico is strong at capturing and managing data, and it leaves plenty of freedom in how the resulting experience is rendered. The work sits between those two: deciding what we currently believe about a visitor and how much of the experience we are willing to change because of it. That decision layer can start fairly simple. Explicit signals, such as an internal search or arriving on a very specific page, carry more weight than weaker ones. Several related interactions increase confidence, and older signals gradually lose relevance. The result is a current state with several dimensions. Take a visitor to a LEGO webshop who arrives on a page about Technic sets for adult builders and then compares two sets with motorised functions. That state could look like this: 1. High affinity with Technic, with high confidence. 2. Probably buying for themselves rather than as a gift, with medium confidence. 3. Prefers detailed build information, such as piece count and functions, with fairly high confidence. The platform can use that state straight away on the next request. AI is useful in this layer, but in a specific place. A language model is good at interpreting messy input, such as mapping an internal search query or a form question to terms from your taxonomy. I would keep the scoring and the decisions themselves explicit and rule-based, at least at first. You need to be able to explain why somebody saw what they saw. Speed plays a role here too, which I will come back to at the end. How far you let that state change the experience should depend on the impact: the bigger the change, the more confidence you need before making it. ## Measure what visitors actually saw I would build exposure tracking into the architecture from the start. Knowing that somebody qualified for a personalised experience tells you little until you also record what they actually saw. With both in place, you can follow the full chain from signal and decision through to exposure, interaction and outcome. Measurement is also where many personalisation programmes get stuck. Especially for informational organisations, such as pension funds or consumer organisations, it is often unclear what better personalisation actually delivers. Without exposure and outcome data, there is no way to answer that question. Experimentation is a natural extension of the same model. Once decisions, variants, exposures and outcomes share the same structure, a control group that gets the default experience is all you need to measure whether personalisation is actually making the experience better instead of simply making it different. That is also why I am curious [where Kentico takes experimentation and A/B testing next](https://roadmap.kentico.com/c/325-a-b-testing-for-pages). ## Where to start You do not need a hyperpersonalisation engine to begin. A first version fits in a normal Xperience by Kentico project: 1. Classify your content with a taxonomy that reflects what visitors are trying to do, such as the problem they want to solve or the stage they are in. AI can help with a first draft, for example by turning a flat set of tags into a layered taxonomy that editors then review. 2. Log the strong signals as custom activities: internal searches, downloads, key form interactions and arrivals on intent-specific pages. 3. Translate those signals into a small visitor state with a confidence score that drops as signals get older, and keep it available on every request. 4. Pick one journey and a few elements to personalise, such as the primary CTA, the order of information and related content. 5. Log every exposure and compare the results against a control group that sees the default experience. Xperience by Kentico provides the structured content, taxonomies, contacts, activities, personalisation conditions and the .NET extensibility for all of this. The scoring, confidence model and decisioning are yours to design, and that is probably a good thing: that is where your understanding of your own visitors lives. ## Looking ahead Language models could play a much bigger role in personalisation than interpreting signals. What makes that hard today is the latency a model adds when it has to work out the right adjustment during a page request. [Current benchmarks](https://aimultiple.com/llm-latency-benchmark) put the first response of mainstream models at around a second or more, which is a lot for a page that should start rendering almost immediately. For now I keep the model out of the request path: it interprets signals between requests and stores the result in the visitor state. As inference becomes faster and cheaper, more of this decision layer can move from explicit rules towards model-driven decisions. I would not wait for that, though. The architecture stays largely the same: structured content, meaningful signals, a clear visitor state and exposure tracking. The intelligence in the middle can evolve without rebuilding the foundation. Structured content helps machines understand what our content means. Hyperpersonalisation adds the other half: understanding what seems to matter to the visitor right now.