AI personalisation at scale: the architecture that actually works

Quick scene-setting before the architecture, because "AI personalisation" is one phrase doing three different jobs. When a vendor says it, they could mean any of the three below — and the failure modes, the cost, and the lift profile are different for each.

An ESP — email service provider, the platform that actually sends your messages, like Braze, Iterable, Klaviyo, HubSpot — typically packages all three under one "AI" label. Useful to separate them.

Predictive personalisation — models that score each user with a number (churn risk, propensity to buy, predicted lifetime value) and route the message accordingly. Braze Predictive Suite, Iterable Brain, Klaviyo Predictive Analytics, Salesforce Einstein. The output is a number per user that drives a decision ("send the win-back to anyone with churn risk above 0.7").

Generative personalisation — models (LLMs, the same family of large language models behind ChatGPT and Claude) that produce content per user or per cohort: subject lines, body copy, product blurbs. BrazeAI (formerly Sage AI), Iterable Copy Assist, Klaviyo Subject Line generator. The output is the actual words the user reads in the inbox.

Optimisation personalisation — models that pick from a candidate set the marketer pre-defined: best send time, best variant, best frequency. Send-time optimisation (STO), multi-armed bandits (an algorithm that allocates more traffic to whichever variant is winning, in real time), next-best-action engines. The output is a decision among options you already wrote.

Different stacks, different failure modes, different return-on-investment profiles. A program that says "we're using AI personalisation" without naming which of the three is using marketing language to obscure an architectural question. Job number one of any AI personalisation effort is naming which capability is being deployed and why.

Most lifecycle teams want to argue about which model is best. The model is rarely the problem. Every AI personalisation deployment that produces measurable lift sits on top of four layers underneath the model. Skip one and the clever bit on top is decoration.

Picture it as a building: the model is the penthouse, but if the foundations are cracked the whole thing leans.

Layer 1 — Event capture. Real-time, well-named, complete events — the records of what users did and when, like added_to_cart or completed_signup — flowing from your product into the ESP. Without this the model trains on a partial picture and fires recommendations on stale signal. The most common cause of "our AI doesn't work" is that events lag by hours, fire inconsistently across web and mobile, or carry names like click_button_2 that mean nothing to anyone, model included.

Layer 2 — Unified user profile. A single, real-time view of the user that combines behavioural events, custom attributes (the stored facts about a user — plan tier, sign-up date, country), subscription state, and product catalog interactions. Braze ships this natively; Iterable, Klaviyo, and HubSpot ship variations. If your profile is fragmented across systems and the AI only sees one slice, expect performance bounded by what that slice contains.

Layer 3 — Modular content. Content Blocks (Braze's reusable, swappable email components), dynamic blocks, catalog items — anything the model can swap into a message without a human re-authoring the email. A program with one master HTML file per send and no modular structure has nowhere for AI personalisation to write its output. The model produces a recommendation; there's no slot to drop it into. This is where most programs stall — not in the model, in the place where the model's output is supposed to land.

Layer 4 — Activation logic. The runtime that picks which version of which block goes to which user. Braze does this through Connected Content (a feature that pulls live data from outside Braze into the email at send time) plus Catalogs and Liquid (the templating language most ESPs use to inject personalised values into messages — same family as the Liquid in Shopify). Iterable does it through Catalog Lookup, Klaviyo through dynamic content blocks. The model's output is meaningless without an activation layer that can route it to the right user at the right moment.

Braze packages the four layers into named features. Useful to map them, since most operators inherit a Braze instance with some of these turned on without anyone documenting why. If you're on a different ESP the names change and the shape doesn't — Iterable, Klaviyo, HubSpot and Salesforce all have the same four layers under different brand labels. The translation table is at the bottom of this section.

BrazeAI. The generative layer — subject lines, copy variations, image suggestions inside the Braze composer. Rebranded from Sage AI; same feature set, new umbrella name. It operates on the message in front of you, not the broader program. Useful for accelerating production, less useful for personalisation in the strict sense — it generates copy a marketer reviews, not per-user output that varies in real time.

Predictive Suite. Predictive layer — churn risk, conversion propensity, lifetime value (LTV) prediction. Output: a score per user that becomes filterable in segment logic. Quality varies dramatically with data volume — a program with 10,000 monthly active users (MAU) and a thin event history gets a worse model than one with 10 million MAU and three years of clean events. The model is the same. The input is the bottleneck.

Connected Content. Activation layer — pulls real-time data from external APIs into the message at send time. Think of it as a placeholder in the email that, the moment the email is being rendered for a specific user, calls out to a service of your choosing and asks "what should this person see?". It's the bridge between AI output produced elsewhere (your warehouse, an internal recommendation service, a Vertex AI endpoint, an OpenAI call) and the rendered message. The most underused Braze feature in most programs and the most powerful when you outgrow Predictive Suite's built-ins.

Catalogs. Content layer — the structured product, content, or asset library that AI personalisation references. Without a properly structured Catalog, recommendations are limited to what fits in custom attributes (a handful of fields per user). Catalog quality — taxonomy, completeness, freshness — directly bounds recommendation quality. Junk in, junk recommendations out.

Liquid. Activation layer (the runtime). Every dynamic decision in a Braze message resolves through Liquid syntax. The Liquid reference covers the syntax. The activation layer is where bad architecture becomes visible to the user — a Liquid expression that breaks ships {{ ${first_name} }} to 50,000 people regardless of how clever the AI was upstream. Every lifecycle lead with five years on the tools has shipped one of those at least once.

The same architecture maps onto Iterable (Brain + Catalogs + Catalog Lookup), Klaviyo (Predictive Analytics + dynamic blocks + product feeds), HubSpot (Smart Content + Personalization Tokens), and Salesforce Marketing Cloud (Einstein + Personalization Builder). Different feature names, identical layers. If you can find the four layers, you can run this stack.

Once the four layers are healthy, three decisions decide whether AI personalisation moves revenue or just produces a nice-looking dashboard.

Build vs buy the model. The AI features your ESP ships out of the box are good enough for activation, churn risk, and basic recommendations at small-to-mid scale. They stop being good enough when the use case is specific to your domain — a fashion marketplace needs style-similarity recommendations the ESP doesn't ship; a B2B SaaS needs intent scoring tied to product usage patterns; a marketplace needs supply-side and demand-side signals stitched together. The build-vs-buy call should be made on use-case specificity, not on which option sounds more sophisticated. The AI Personalisation skill covers the decision framework.

Real-time vs batch activation. Real-time scoring (Connected Content calling a recommendation API at the moment the email is being assembled for a user) opens the door to fresh signal but adds latency and a runtime dependency — if the API is slow or down, your send is slow or down. Batch activation (recommendations precomputed in your warehouse and synced to user attributes nightly) is more reliable but always 24 hours stale. Most programs over-rotate to real-time when batch would do, then under-invest in the latency monitoring that makes real-time safe. Pick on how fresh the signal needs to be. A product recommendation can be a day old. A churn-save trigger probably can't.

How much human review the model output gets. Generative AI output that ships unreviewed will eventually produce something off-brand, factually wrong, or quietly offensive. Generative AI output that gets human-reviewed before every send is too slow to scale. The middle path: the model produces variants, a human approves the first batch per template, then the system rotates approved variants automatically. Klaviyo and Iterable have built variants of this pattern. BrazeAI is more interactive — per-message generation in the composer — and works better in a pre-send review flow than a fully automated one.

The temptation is to flip every switch on day one and see what happens. The pattern that works is the opposite: one capability, one program, one measurement window, expand only after the previous expansion produced a measurable, holdout-validated lift.

A defensible rollout sequence:

1. Pick one program where the data is clean and the activation layer already exists. Usually onboarding, abandoned cart, or post-purchase. Programs with messy data or no modular content are fixable but should be fixed before AI gets layered on.

2. Pick one capability. Predictive scoring on a single segment, or AI subject lines on a single template, or a single product recommendation slot. Not five at once. The goal is to learn whether this lever moves this metric for this audience.

3. Run for at least 30 days against a holdout. A holdout is the random group you deliberately don't expose to the new thing — your control, the way a clinical trial works. 10–20% of the audience receives the non-AI version. The holdout group guide covers the design. Anything shorter is noise; anything without a holdout is vendor marketing.

4. Read out against the metric the program exists for. Typically downstream conversion or revenue, not opens or clicks. Apple Mail Privacy Protection (MPP — the iOS feature that pre-fetches images, including the tracking pixel that records opens, before the user has even looked at the email) makes the open rate unreliable; AI personalisation often inflates opens without moving revenue. The measurement guide covers the honest readout.

5. If the holdout test produces real lift, expand. Second program or second capability. If it doesn't, don't expand. Diagnose why — usually it's back at the data or activation layer rather than the model itself.

The teams that get the most out of AI personalisation treat it as a series of small bets validated individually, not a platform decision validated by the vendor. The teams that get the least flip everything on, watch dashboards trend up due to MPP and seasonality, and write a case study the data won't survive an audit of.

One thing to do Monday: name which of the three capabilities (predictive, generative, optimisation) you actually want, name the program you'll run it on, and confirm that program has a holdout. If any of those three is missing, that's the work — not the model.