Personalisatie in headless Umbraco met OpenAI of Claude
Een LLM laten kiezen welke blocks bij welke bezoeker passen — dat is personalisatie zoals het altijd had moeten werken. Hoe dat eruit ziet in moderne, headless Umbraco, wat het kost, en welke valkuilen we de laatste twaalf maanden zelf zijn tegengekomen.
Het korte antwoord
Personalisatie in headless Umbraco kon altijd al. Met regels, segmenten, audience-builders. De vraag was nooit of het kon, maar of het werkbaar bleef zodra je drie segmenten had — en hoe je in december uitlegde waarom de homepage voor "geïnteresseerd in B2B" exact hetzelfde toonde als vorig kwartaal.
Door headless Umbraco te koppelen aan een LLM (Claude, OpenAI of een zelfgehost Llama-model) verschuift dat verhaal. De CMS levert de bouwblokken, het taalmodel kiest en sorteert ze op basis van wie binnenkomt. Geen experimentele toekomst meer — dit draait vandaag bij teams die geen enterprise-suite willen aanschaffen.
Dit artikel laat zien hoe die architectuur eruit ziet, wat het in euro's per maand betekent en welke valkuilen we de laatste twaalf maanden zelf zijn tegengekomen. Geen hypothesen. Praktijk.
Waarom personalisatie nu pas zin krijgt
De vroege generatie personalisatie was if-then. Bezoeker uit branche X krijgt blok Y. Komt iemand twee keer terug, dan eerst de prijspagina, anders eerst de demo. Het werkte, het schaalde niet. Elke nieuwe regel bewoog drie andere regels. Marketing bouwde, redactie testte, niemand wist na een halfjaar nog welke combinatie wie zag.
Wat LLM's veranderen: in plaats van vooraf regels schrijven, voer je context aan een model en laat je het beslissen welke blok-combinatie het beste past. "Bezoeker komt binnen via Google Ads op zoekwoord 'umbraco migratie sitecore', kijkt vijf seconden naar de pagina, scrollt naar het prijsblok." Het model kiest dan: case van een Sitecore-migratie eerst, prijsblok daarna, demo-CTA onderaan. Geen vooraf gedefinieerde regel, wel een uitlegbare keuze.
De drempel is verlaagd door drie dingen tegelijk: API-kosten van LLM's zijn sinds 2024 met circa 80 procent gedaald, headless-architectuur is standaard in Umbraco 17, en edge-functies (Cloudflare Workers, Vercel Edge) maken een sub-200ms response inclusief AI-call eindelijk haalbaar. Geen van die drie was vorig jaar al volledig waar.
De architectuur in headless Umbraco
Vanuit vogelperspectief ziet zo'n setup er als volgt uit:
De front-end (React, Next.js, of een eigen .NET-front) ontvangt de bezoeker. Bij het eerste request stuurt die front-end een signaal-pakket naar je eigen API: bron, referrer, eventuele UTM-parameters, apparaat-categorie, een flag voor herhaalbezoek uit een cookie. Die API doet twee dingen tegelijk. Eén: ze haalt content op uit de Umbraco Delivery API (of de Heartcore-API). Twee: ze stuurt het signaal-pakket plus een korte samenvatting van de beschikbare blocks naar Claude of OpenAI.
Het model krijgt geen volledige content mee, alleen aliassen en metadata. Dat scheelt tokens én voorkomt dat AI per ongeluk content gaat herschrijven die niet door redactie is goedgekeurd. Het antwoord van het model is een gewogen lijst: "Voor deze bezoeker is de meest passende volgorde blok-3, blok-1, blok-7". De API rangschikt vervolgens de échte content uit Umbraco in die volgorde en stuurt het naar de front-end.
De truc zit in wat het model níet doet: het schrijft geen nieuwe tekst, het maakt geen nieuwe content. Het kiest. Dat houdt de keten controleerbaar en de redactionele vrijheid intact. Wat in Umbraco vs Contentful als headless-architectuur staat beschreven blijft hier overeind — je gooit de bestaande content-flow niet om, je voegt een dunne laag toe.
Wat het kost in productie
De boekhouding eerst. Een gemiddelde rerank-call naar Claude Haiku of GPT-4o-mini gebruikt 800 input-tokens en 150 output-tokens. Bij de huidige prijzen kom je dan rond €0,003 per request uit. Met edge-caching (vijf minuten per signaal-hash) halveer je dat opnieuw.
Een site met 100.000 bezoekers per maand, die elk gemiddeld twee gepersonaliseerde pagina's zien, zit zonder caching op ongeveer €600 per maand. Mét caching: €120 tot €200. Vergelijk dat met een licentie voor een enterprise-personalisatie-suite die je per duizend bezoekers laat betalen, en je rekent jezelf rijk.
Daar bovenop komt de developer-tijd om het te bouwen — voor een werkende eerste versie reken je zes tot acht weken bij een team dat al ervaring heeft met de Umbraco Delivery API. Eenmalig, geen abonnement.
Bezoeker-signalen versturen naar een LLM die buiten de EU wordt gehost is een AVG-puzzel. Houd persoonsgegevens uit het signaal-pakket (anonimiseer of hash IP-adressen, gebruik geen e-mailadressen), kies indien mogelijk voor Anthropic of OpenAI met EU-data-residency, of overweeg een zelfgehost open-source model voor zorg en overheid.
De vier bouwblokken
Een werkende AI-personalisatie in headless Umbraco bestaat in de praktijk uit vier componenten. Allemaal nodig, geen weglaten zonder verlies.
1. Een goed gestructureerd content-model. Block Grid of Block List werkt prima, maar je blocks moeten herkenbare aliassen en duidelijke metadata hebben. Een blok blockHeroBranche met een veld branche en tone — daar kan een LLM iets mee. Een naamloos generiek blok dat overal voor wordt gebruikt — daar niet.
2. Een signaal-laag. Een lichte client-side script of edge-function die contextsignalen verzamelt zonder de privacy-grens te overschrijden. Referrer, zoekterm (als die in de URL staat), apparaat-categorie, herhaalbezoek-flag. Geen fingerprinting. Geen verborgen tracking. Bij ons gaat dit standaard via een Cloudflare Worker die de signalen al normaliseert voordat ze de Umbraco-API raken.
3. Een prompt-template met examples. Het hart van het systeem. Een goede prompt geeft het model duidelijk mee: hier zijn de beschikbare blocks (alias en korte beschrijving), hier is het bezoekersignaal, antwoord met een gerangschikte JSON-lijst. Examples in de prompt zorgen voor consistentie. Zonder examples krijg je bij elke nieuwe deploy ander gedrag — en dat is precies wat je niet wilt.
4. Een fallback-pad. De LLM-call kan falen, traag zijn of een onverwacht antwoord geven. Je systeem moet binnen 300ms altijd een lay-out kunnen serveren, AI of niet. Onze klanten draaien standaard een regel die zegt: geen AI-antwoord binnen 150ms, dan de standaardvolgorde tonen. Bezoekers merken er niks van, conversie blijft doorlopen, en monitoring vangt het op.
Fases van implementatie
Onder de motorkap doorlopen we drie fases. Tezamen tussen tien en twaalf weken voor een werkende eerste versie:
-
Content-model controleren op duidelijke aliassen en metadata, één pilot-pagina kiezen (meestal de homepage of belangrijkste landingspagina), signaal-laag opzetten op de edge. In deze fase wordt duidelijk welke blocks AI-vriendelijk zijn en welke voor de pilot moeten worden opgeschoond.
-
Prompt-template bouwen met drie tot vijf examples, integratie met Claude of OpenAI opzetten, fallback-logica wiren, A/B-test infrastructuur klaarmaken zodat je vanaf dag één meet wat het oplevert. Geen launch zonder meetbaar nulpunt — anders weet je over drie maanden niet of het werkt.
-
Meer pagina's aansluiten op basis van de pilot-resultaten, prompt-template verfijnen op basis van logs van mismatched keuzes, kosten en latency monitoren, AVG-review elk kwartaal opnieuw doen. Personalisatie is geen project dat 'klaar' is op een specifieke datum — het is een tuning-discipline.
Valkuilen die je wilt voorkomen
Het model laten schrijven in plaats van kiezen. Verleidelijk. Levert ongeplande SEO-problemen op (Google ziet steeds wisselende content), juridische ruis (wie is verantwoordelijk voor automatische beweringen?) en een redactie die haar grip kwijtraakt. Houd het strikt: kiezen mag, schrijven niet.
Te veel signalen tegelijk versturen. Meer context is niet beter. Een prompt met twintig velden is duurder, trager en levert geen merkbaar betere keuze op dan een prompt met vijf goed gekozen signalen. We zijn ooit met dertien velden begonnen en eindigden bij vier. De keuzes werden niet slechter, de kosten halveerden.
Geen caching. Twee bezoekers met identieke signalen krijgen dezelfde keuze. Cache de AI-beslissing per signaal-hash voor minimaal vijf minuten op de edge. Dit halveert kosten zonder enig verlies aan personalisatie-kwaliteit.
Vergeten dat het uitlegbaar moet zijn. Op een dag vraagt iemand: waarom kreeg ik dit te zien? Log per AI-beslissing welke signalen meegingen en welk antwoord terugkwam. Niet alleen voor compliance — ook om te leren waarom personalisatie wel of niet werkt.
Direct met de grootste modellen starten. Voor blok-rangschikking is een klein model (Claude Haiku, GPT-4o-mini) ruim voldoende en tot tien keer goedkoper. Bewaar Opus en GPT-4 voor situaties waar serieuze redenering écht nodig is. Voor "kies de juiste hero-block" hoef je geen filosofische zwaargewicht in te zetten.
Praktisch starten
Voor het eerst sinds personalisatie als concept bestaat, is de techniek niet meer de bottleneck. De bottleneck is duidelijk weten wat je wilt personaliseren en waarom. Begin niet met "wat kan er allemaal" maar met "welke pagina kost ons nu het meeste aan misgelopen conversie". Vrijwel altijd is dat de homepage of een belangrijke landingspagina.
Bij De Codebrouwerij bouwen we deze setups op moderne Umbraco 17 met Claude of OpenAI als rerank-laag. Doorlooptijd voor een eerste werkende variant: zes tot acht weken. Maandelijkse runtime-kosten voor een middelgrote site: tussen €40 en €200, afhankelijk van het verkeer. Vergelijk dat met een enterprise-personalisatie-suite en de rekensom spreekt voor zich.
Wil je verkennen wat dit voor jouw site oplevert? Lees onze aanpak voor headless Umbraco of plan een intake. We rekenen graag een eerlijke business-case voor je door — inclusief wanneer het juist géén goed idee is om aan AI-personalisatie te beginnen.