BloomIdea: Mautic Audiences for Drupal: personalisation built on the segments you already maintain
Your marketing team already knows who the VIPs are. They maintain the segment in Mautic, they send it a campaign every month, they add and remove people as orders and behaviour change. Then somebody asks for a VIP banner on the website, and the website turns out to know nothing about any of it. So "VIP" gets built a second time, as a Drupal role or a checkbox on the user: two definitions of the same audience, maintained by two teams, drifting apart from the first week.
The second problem arrives with the first. Personalisation on Drupal usually means varying the page per visitor, and a page that varies per visitor is a page nobody else can be served, so the banner meant to lift conversion ends up slowing the site down for everyone.
We build and run Mautic-driven marketing for our e-commerce clients, so we kept meeting both problems on the same projects. Mautic Audiences is our answer, now on drupal.org as free software (GPL-2.0-or-later) for Drupal 10.3 and 11, covered by Drupal's security advisory policy. It reads the segments and tags you already maintain in Mautic and turns them into native Drupal primitives: block visibility, Twig, tokens, JavaScript, Views, Search API and, since 1.1, a field.
What editors can build without a developerPlace any block, scroll to Visibility, pick Mautic segment, type vip. Save. That is the whole configuration, and it covers most of what people actually ask for:
- A VIP banner that appears the moment Mautic adds someone to the segment. No Drupal save, no cache flush.
- A homepage hero per traffic source: three blocks, one each for newsletter, instagram and paid-search, each gated on its own segment.
- Hiding what someone already has. The newsletter signup block disappears for visitors already tagged subscriber.
- Coupon-aware touches for visitors carrying a coupon:* tag, fired client-side so the page itself stays cacheable at the edge.
- Cross-channel campaigns. Mautic sends the email, and the Drupal page the link lands on recognises the segment it was sent to. One audience definition, two channels.
Anonymous visitors count: someone carrying Mautic's tracking cookie has an audience with no login, which is what lets a campaign link open a personalised page at all. Editors check their work by appending ?ma_preview_segments=vip to any URL, which shows the site as a member of that segment sees it.
Themers get the same decision as a one-liner that brings its own cache metadata, and there is a token for metatag patterns and a JavaScript call for whatever has to happen after the page is served:
{% if is_in_segment('vip') %} <p>Free shipping today, your VIP perk.</p> {% endif %} Content that knows who it is forThe module started by answering "who is this visitor?". Version 1.1 adds the other half, "who is this content for?", in a bundled sub-module.
Add the Mautic audience field to any bundle and editors pick, from the real list of segment names, who a piece of content is meant for. By default that is a targeting hint templates and listings read. Per field, you can turn on Restrict viewing to the selected Mautic segments, and content with a segment picked is then refused to everyone outside it. Content with nothing picked stays for everyone.
A gate that only closes the page is not a gate, so the sub-module also ships a Views filter that keeps whichever rows each visitor is entitled to, and a Search API processor that adds the condition at query time rather than keeping items out of the index. Its README lists what none of it can cover, exports, feeds, custom code that loads entities without an access check, because a promise of restriction with holes in it is worse than no promise.
The interesting part is what it refuses to exposeSegment names and tags are business intelligence: cancelled-subscription, risk:churn-90d, coupon:VIP-50. Ship them to the browser and you have published how you categorise your customers, and sometimes a working coupon code, to anyone with DevTools open.
So the client-side API answers questions instead of listing facts. It will tell you whether this visitor is in a segment you name; it will not tell you which segments exist or which ones they are in. The endpoint that returns an actual list starts empty and returns only what an editor has allowlisted. The field type has no formatter at all, and reading its values takes an administrative permission, which covers JSON:API, REST and Views alike.
It stays out of your render pathAudiences are read from local storage on every render, never from the Mautic API, so a slow Mautic never sits in front of a page, and an outage degrades to an empty audience rather than an error. Cache contexts key on the resolved audience rather than on the visitor, so two people in the same segments share a cache entry and a page with two gated blocks has four variants, not one per visitor. Anonymous personalisation does cost you Drupal's Internal Page Cache on the pages that use it, which docs/cdn.md deals with head on.
Get it composer require drupal/mautic_audiences drush en mautic_audiencesIt needs Advanced Mautic Integration for API connectivity, a Mautic instance with API credentials, and PHP 8.2 or later. A bundled sub-module wires Klaro into the resolver, so visitors who have not consented resolve to an empty audience without any code.
The project page, the issue queue and the documentation are at drupal.org/project/mautic_audiences. If you run Drupal Commerce, Commerce Mautic Connect pushes the abandoned carts, customer metrics and coupon tags into Mautic that this module reads back. Issues and merge requests are very welcome.
