Your website, personalised for every visitor.
Mister Chameleon adapts headlines, proof, and CTAs in real time - no code changes, no privacy trade-offs.
3.2x more qualified leads
SaaS teams using Mister Chameleon see an average 3.2x lift in demo requests within 30 days of going live - no engineering changes required.
First experience live in under 5 minutes
Connect your domain, define two rules, and your first adaptive experience is live. Most teams are shipping within a single afternoon.
12 visitor signals, evaluated in real time
Source, device, campaign, recency, and more - every visit triggers a silent evaluation so the right experience loads before the page paints.
The adaptive decision engine - a technical deep dive.
Intent scoring, company enrichment, behavioural history, CRM context, and time-aware logic - combined in a single edge function that runs before your page finishes loading. This page explains exactly how it works, layer by layer.
Engine performance
Total pipeline latency
Signals evaluated per visit
Variant decision time
Third-party cookies used
Fires on every request. No warm-up. No lag.
A high-performance engine delivers precise power on demand - without the driver thinking about it. The Mister Chameleon decision engine works the same way. Every time a visitor loads a page, the engine fires: reads the full request context, loads the visitor's behavioural history, enriches from IP, scores intent, evaluates your rules, and selects the best-matching variant. All of this happens in under 50 milliseconds. The visitor never waits. The page never flickers.
Four layers of intelligence
Request layer
Captured on every request, before any session data is loaded: UTM source and campaign, referrer domain, traffic source classification (Google, LinkedIn, direct, email, dark social), device type, operating system, preferred language, and geographic region.
Behavioural layer
First-party session history retrieved from your Supabase database: pages visited in this session and historically, scroll depth, time on page, CTA clicks, form starts, form completions, and recognised navigation sequences. Stored in your database, in your region.
Enrichment layer
Server-side IP-to-company lookup: company name, industry, estimated headcount, and organisation type. Runs asynchronously - never blocks the page render. On Growth and Pro plans: CRM lifecycle stage, ABM target account matching, and weather context.
Intent layer
Composite scoring that combines all available signals into two 0-100 scores (intent and engagement) plus a predicted funnel stage (awareness, consideration, intent, high intent, or customer). Recalculated on every page load from the current full signal set.
The decision pipeline, step by step
- 1Request context is read0 ms
The edge middleware intercepts the request before any HTML is generated. UTM parameters, referrer, device type, and the session identifier are extracted from the request headers and cookies. This adds zero latency - it happens before any I/O.
- 2Session history is loaded< 5 ms
The session identifier is used to fetch the visitor's behavioural profile from your Supabase database. This includes all historical page visits, engagement events, prior variant exposures, intent scores from previous sessions, and journey sequence matches. New visitors get an empty profile.
- 3Company enrichment runs< 20 ms
The enrichment service performs a server-side IP lookup to resolve company name, industry, estimated size, and organisation type. This runs in parallel with session loading and is non-blocking - if enrichment takes longer than the budget allows, the decision proceeds without it and enrichment is attached to the next request.
- 4Intent and engagement are scored< 5 ms
The scoring engine combines the request layer, behavioural profile, and enrichment data using a weighted signal model. Traffic source weight, behavioural depth, enrichment tier, CRM stage, and recency are all factored in. The output is an intent score (0-100), an engagement score (0-100), and a predicted funnel stage.
- 5Rules are evaluated in priority order< 5 ms
Your personalisation rules are tested against the visitor's full context, in descending priority order. Each rule has a condition set (any combination of signal fields, scores, stages, and enrichment values) and a content plan (heroKey, proofKey, ctaKey). The first rule whose conditions all match is the winner.
- 6Variant is selected and rendered< 10 ms
The winning rule's content plan is applied. The CMS serves the matched hero variant, proof block, and CTA. The page renders server-side with the correct content on the first load - no client-side injection, no layout shift, no flicker. The decision is logged and the session profile is updated for the visitor's next visit.
Runs before a byte of HTML is sent.
The entire decision pipeline runs inside Next.js Edge Middleware - a serverless function that executes at the CDN edge, geographically close to the visitor. This is not a client-side script injecting content after load. It is server-side middleware that intercepts the request, makes a decision, and serves the already-personalised page in a single response. The visitor receives personalised content with the same time-to-first-byte as a static page.
Intent is a composite - not a page-view count.
Most intent scoring systems count page visits and call it done. The Mister Chameleon scoring model is more nuanced. Traffic source contributes a base weight - a visitor from a Google search for 'best personalisation software' starts higher than a visitor from a brand awareness LinkedIn post. Behavioural depth (total sessions, pages per session, scroll depth, time on site) compounds the score over time. CTA engagement - clicking a pricing link, opening a demo modal, or starting a form - signals proximity to decision and adds a significant weight. Form behaviour is particularly valuable: a visitor who started a form but did not submit it has revealed clear intent even without converting. Company enrichment adds a tier modifier: enterprise companies score higher by default, and named ABM target accounts score higher still.
Conditions plus content plans - no code required.
Personalisation rules are defined in a visual editor. Each rule has a priority number, a set of conditions, and a content plan. Conditions can target any field in the visitor context: intent score ranges, funnel stage values, UTM parameters, enrichment fields (industry equals fintech, company size greater than 500), behavioural flags (hasVisitedPricing, hasStartedForm), journey sequences, and named segment memberships. Conditions can be combined with AND and OR logic and nested to any depth. The content plan maps the matching visitor to a specific hero variant, proof block variant, and CTA variant. Rules are evaluated in priority order - the lowest priority number wins. If no rule matches, the page falls back to its configured default plan.
Marketing creates. The engine decides. No deploys.
Content variants live in Sanity. A variant is simply an alternative version of a page section - a different hero headline and image, a different proof block with case study quotes instead of stats, a different CTA with 'Book a demo' instead of 'Start free trial'. Marketing creates variants in the CMS, gives them a key, and publishes them. From that moment, the rules engine can route any visitor to any variant based on their context. Adding a new variant for a new audience does not require a code change, a pull request, or a deployment. It is a CMS operation.
Built for production use
Edge-first, zero blocking latency
The decision pipeline runs at the CDN edge in Next.js middleware. Total overhead is under 50ms, measured from request receipt to first byte sent. Page load speed is never affected.
Privacy by architecture
No third-party cookies. No cross-site tracking. Behavioural data is stored first-party in your own Supabase database, in your chosen region. The engine never sends visitor data to our servers.
No-flicker server-side rendering
Personalised content is rendered server-side in the initial response. The visitor sees the correct variant on the first paint - no layout shift, no content swap, no visible flash of default content.
Graceful fallback on every failure
If enrichment times out, the engine proceeds without it. If the database is unreachable, the engine uses request-only signals. If no rule matches, the page default is served. The engine never blocks a page load.
Variant exposure tracking
Every decision is logged: which rule matched, which variant was served, and when. This feeds the analytics dashboard and A/B test confidence calculations. You always know which visitor saw what.
Bot and spike protection
The engine includes built-in rate limiting and bot detection. Scraper traffic and synthetic load is excluded from personalisation decisions and analytics - so your variant performance data reflects real visitors only.
What technical teams say
The edge middleware architecture was the deciding factor for us. No client-side injection, no flicker, no performance hit. It integrates with our Next.js setup exactly the way you would hope - like it was designed for it.
Lars K.
CTO · JobBridgeI was sceptical about the sub-50ms claim. I ran it through our own load testing tool against a cold cache. The p95 latency added by the decision middleware was 23ms. The claim is real.
Thomas Becker
Lead Infrastructure Engineer · GrowlyticsThe rules system is more expressive than I expected. We have rules that combine intent score thresholds, enrichment industry matching, and journey sequence detection in a single condition set. It handles complexity well.
Anouk van Dijk
Head of Engineering · Frontline AgencyTechnical questions
Does the middleware add latency to every page load?
Yes, but it is minimal. The decision pipeline adds under 50ms of wall-clock time, measured at the edge, including enrichment. On pages where enrichment is not needed (returning visitors with cached profiles), the overhead is typically under 15ms. This is below the threshold of perceptible latency for page loads.
What happens if the Supabase database is slow or unreachable?
The engine has a hard timeout on the session history fetch. If the database does not respond within the latency budget, the engine proceeds using only request-layer signals (UTM, referrer, device). The visitor sees the best variant the engine can select with available data - not a broken page.
How does enrichment interact with GDPR?
IP-to-company lookup resolves organisational metadata only - company name, industry, estimated size, and type. This is not personal data under GDPR because it identifies the organisation, not the individual. The lookup is server-side and no data is stored beyond a short request-scoped cache. No consent is required for the enrichment itself.
Can I use the engine with my existing CMS instead of Sanity?
The decision engine is CMS-agnostic at the rule and scoring layer. Content variants are currently stored in and served from Sanity. Integration with other CMS platforms is on the roadmap. Contact us if you have a specific CMS requirement.
How does the engine handle A/B tests alongside personalisation rules?
A/B tests run as a special rule type with traffic splitting. A test rule has two or more variant arms with assigned traffic percentages. When a visitor matches a test rule, they are randomly assigned to an arm and that assignment is persisted in their session profile for consistent exposure. Test rules have a priority like any other rule and can be targeted to specific audiences.
Is the decision engine open source?
The core scoring model, rule evaluator, and enrichment pipeline are proprietary. The JavaScript tracking snippet, Sanity schema definitions, and Supabase migration files are open source and available on our GitHub. The studio plugin and seed tooling are also open.
See the engine make a live decision.
Open the interactive demo, simulate any visitor profile, and watch the engine select a variant in real time - with a full explanation of which rule matched and why.