Two coffees in, our homepage still looked the same to everyone. The brief was simple. Show a different hero to returning visitors who checked pricing last time. Our CMS could do the usual tricks and a couple of plugins promised magic, but none of that felt like a steady way forward. Then a friend messaged me a link. Apache Unomi. An open source customer data brain that listens to events, builds profiles and segments and tells your tools who is who. My tabs were already a mess with WWDC recaps and iOS betas, so what was one more tab. I clicked and that started an oddly satisfying evening of wiring a context server to a plain CMS and seeing content change for the right person at the right moment.
Since a lot of teams are asking how to connect Unomi with a CMS, let me walk through what worked for us, where we stubbed our toes, and what still feels like a cheat code for marketers and developers sitting in the same room.
The short story of why Unomi is worth your evening
Unomi is an Apache project that acts like a memory for your visitors. It stores profiles and sessions, listens to events like page views, clicks and form sends, and groups people into segments using rules. Your CMS asks Unomi who is here and what they have done, then changes the page, picks a slot, or tweaks copy on the fly. All of this happens over a simple REST API, with data living in ElasticSearch, and the runtime running in Apache Karaf.
The model is headless. No theme, no templates. Unomi just tells you what it knows and what to do. Your CMS does the show part. This split is nice because it lets you keep your current site while adding a brain that learns from traffic.
What made this click for me was seeing a first load render with default content, then a second load show a tailored block, all driven by one tiny call to Unomi. No page rebuilds. No custom fields explosion. Just data in and a decision out.
How to wire Unomi to your CMS without turning your week upside down
There are two basic paths. Client side calls from the browser, and server side calls from your CMS. I like to start with client side because it is quick to prove value, then move heavy lifting to the server as you go.
What Unomi expects
Unomi deals with a few core bits:
- Profile: a person with properties like firstName, email, interests and custom traits you define
- Session: a visit with properties like referrer, device, campaign tags and time on site
- Event: something that happened, like view, click, search, formSent, download and any custom event you define
- Segment: a saved condition like people who viewed pricing at least twice and are from the US
- Rule: if a condition matches, do an action such as tag a profile, bump a score, or add to a segment
Under the hood, Unomi uses JSON over HTTP. It sets a cookie to keep track of the profile and the current session. You can send events in batches and ask for the current context in one request. The response gives you profile properties, matched segments, and any decisions you asked it to make.
Client side first pass
On the front end, drop a tiny script that sends a page view event and asks Unomi for the current context. This is where the low hanging fruit lives. With one call, you can get back a list of segments and traits to feed into your CMS templates. For single page apps it feels natural. For server rendered pages it still works fine.
Once you have segments in hand, your CMS can switch blocks or copy. Think hero slot, sidebar promo, or the order of cards on a list. Use the CMS you already have. WordPress, Drupal, Jahia DX, whatever your team ships with. The pattern is the same. Ask Unomi for the read, make a decision in your template.
Privacy tip: do not push raw email or other sensitive fields from the browser unless your policy says you can. Use a generated user id if you have it from your auth system and attach email on the server side where you can keep a closer eye on it.
Server side for the serious bits
After your first tests, move key calls to the server. Login, signup, and checkout are perfect places to raise clean events and merge profiles when you recognize a person. Unomi can link an anonymous cookie profile with a known profile using an identifier like customerId. This merge is where the magic starts. Past behavior joins with known fields and your segments get a lot smarter.
From the CMS, send events for content downloads, form sends, and feature use. Grab the response from Unomi and attach segments to your page model so your templates can pick the right blocks without extra network chatter from the browser.
For editors, expose segments inside the CMS UI as audiences. Let them target a block to one or more segments. Keep it simple. If the block has no match, fall back to the default. No dead ends for visitors.
Data model that will not haunt you later
Before you go wild with events, agree on names and shapes. Pick a small set of profile properties you trust. A few good ones beat a river of noise. Same with events. Start with view, formSent, download and one or two custom events tied to your product. Add more only when someone asks for a real use case.
On segments, write them like you write tests. Clear, small, and useful on their own. People who viewed pricing twice. People who came from a partner referrer. People who used search with a specific keyword. Stack them later if you need a combo. Give each a human name and a short note.
Rules should do light work. Tag a profile, bump a score, add to a segment. Keep heavy logic in your CMS or in a service you control. Unomi is great at storing and matching. Let it stay great by not turning it into a kitchen sink.
Runtime notes that save you a weekend
Unomi runs on Apache Karaf. If your team has worked with OSGi before, you will feel at home. If not, do not panic. Treat it like a service you start and monitor. ElasticSearch is where your data lives. Give it room to breathe. Memory for the heap, disk for the index, and a quiet box if you can. Keep an eye on shard count and do not create one index per event type. You do not need that.
Use HTTP keep alive. Batch events when you can. Cache segment lists in your CMS for a short time to handle brief hiccups without breaking the page. If your site is global, think about network distance to Unomi. The round trip matters for real time calls. A small edge cache for context reads can go a long way.
Security Privacy Lock down the API. Put it behind your normal auth and only open the endpoint you actually need from the browser. Watch for fields that should never leave the server. Delete test profiles once you are done. Treat it like a real data store from day one.
What this means for managers who need results without burning the team
Here is the plain pitch. Unomi gives you a source of truth for visitor behavior and a simple way to turn that into on site changes. It does not replace your CMS. It does not force a new theme. It sits next to your stack and makes it smarter.
Why care:
- Faster tests: Editors can ship a targeted block without a new deployment
- Less plugin sprawl: One place for segments instead of one per tool
- Cleaner data: Events and profiles stay consistent across channels
- Open source safety: No lock in. You can extend it, move it, or replace it later
What it costs:
- One service to run: Karaf app plus ElasticSearch. Your ops team will want a small runway
- Some dev time: A CMS plugin or module to call the API and expose segments to editors
- Governance: Someone to own segments and events so they do not multiply without reason
How to measure if this was worth it:
- Profile growth: number of profiles with at least one meaningful trait
- Segment match rate: percent of visits where at least one targetable segment matches
- Time to ship: idea to live test measured in days, not weeks
- Lift: click through on targeted blocks and form finish rate for known visitors
Scope it. Do not try to wire every page and every event. Start with one funnel step and one audience. Make it work there. Then expand. The team gets a quick win and the system stays tidy.
A practical path to connect Unomi with your CMS
Here is the playbook that has worked for me across WordPress, Drupal and Jahia based sites.
- Pick one page and one goal: for example the homepage hero for returning traffic that touched pricing
- Define three segments: returning visitor, pricing viewer, and everyone else as the default
- Send two events: a page view on every load and a named event when someone sees the pricing page
- Ask for context before render: from the CMS, call Unomi and store matched segments on the page model
- Render the block: if pricing viewer matches, show the tailored hero, else show the default
- Watch the numbers: lift in click through for the targeted block and match rate for the segment
Keep a short loop with editors. If they can pick an audience and see results in analytics the same week, you are on the right path. If they need a dev for every change, strip features until they do not.
Gotchas you will thank yourself for avoiding
- Do not over personalizes: one to three slots per page is plenty. The rest should stay steady
- Avoid edge case segments: if less than one percent of traffic matches, park it until later
- Keep names boring: pricing viewer beats growth rocket tier two every time
- Document events: one living doc with names and properties saves rework
- Have a rollback: a toggle in the CMS that turns all blocks to default if Unomi is offline
Also watch cookie scope. If your CMS and Unomi live on different subdomains, set CORS and cookies so the browser can keep the same profile id between calls. Test this with a clean browser session. You will catch most mismatches in ten minutes.
Where Unomi fits next to the rest of your stack
Think of Unomi as the customer brain for on site actions. It sits next to your analytics, email tool and ad platforms. You can push traits and segments out when needed. If you already use a tag manager, keep it. Use it to send a few events in the first phase while your CMS work lands. If you have a data warehouse, plan a nightly export from ElasticSearch to keep history beyond what you want to keep hot in Unomi.
For teams with a product suite, this is also a nice bridge. Web, app, and support can all feed the same profile. When someone opens a ticket or finishes a tutorial, you can reflect that on the site in a gentle way. Gated content is softer when the gate opens by itself for people who already shared what you need.
Heads up on community and support. Unomi is in Apache with active folks around it. You will see the usual mailing lists and docs. Since it is early days, expect to read source now and then. The flip side is you get to shape the project by sharing your use cases.
Your turn: a one week challenge
By next Friday, try this and tell me how it goes.
- Spin up Unomi on a sandbox box with ElasticSearch
- Create three segments: pricing viewer, returning visitor, new visitor
- Wire your CMS to send page view and a pricing event
- Expose segments in the editor UI for one hero block
- Ship a tiny test with a different headline for pricing viewers
- Measure click through and time on page for each audience
If you get stuck, strip it to a single segment and a single block. If you get it running, add one more event tied to a key action. Keep the momentum. The first win is the hardest part.
We are all watching the same keynote replays and product launches this week. It is fun. But the most satisfying thing I did was watch a page greet someone like it remembered them. That is what this is about. Turning data into small and helpful changes that make people feel like the site is paying attention.
If you ship this, send me a note with what you changed and what moved. If you found a better pattern to connect Unomi with your CMS, share that too. We all get better when the playbook gets sharper.