Mautic Audiences

Mautic Audiences shows each visitor of a Drupal site the content meant for the segments and tags they have in Mautic: a banner only VIP customers see, an article for the people interested in a collection, a newsletter block hidden from those already subscribed. Site builders set it up with block visibility conditions and an Audience field, themers with Twig functions and tokens, front-end code with a JavaScript API, all reading the same audience. It works for logged-in users and for anonymous visitors Mautic tracks through its cookie, and uses the Mautic connection the site already has in Advanced Mautic Integration.

Features

• ⚙️ Block visibility and Views filters by segment or tag. Any block placement gains Mautic segment and Mautic tag conditions: the aliases one per line, any or all of them, and core's negate. The Visitor Mautic audience matches filter shows or hides a whole view the same way.
• 🧩 Audience field sub-module. A Mautic audience field says which segments or tags a piece of content is for, on any fieldable entity, picked from the list Mautic returns. Templates and listings can read it, a Views filter keeps the rows that match the visitor, and the optional Restrict viewing to the selected Mautic segments setting lets only those visitors, and whoever may edit the content, view it. A Search API processor, Mautic audience access, keeps restricted content out of their search results.
• 🎨 Twig functions and tokens. is_in_segment(), has_tag() and current_audiences() in templates, where the first two also take an Audience field, so a template can ask whether the visitor matches the content it renders. Tokens such as [mautic-audience:in-segment-vip] answer the same question in token-aware fields.
• ⚡ Caches by audience, not by visitor. Pages carry cache contexts computed from the visitor's segments and tags, so the Dynamic Page Cache keeps one variant per audience answer and two visitors who answer the same share it. Audiences are read from Drupal's own stores and kept current by Mautic webhooks and a reconciliation on cron.
• 🔌 For front-end and site code. Drupal.mauticAudiences.hasSegment(), hasTag() and list() ask two small endpoints that answer privately for the visitor, so the page itself can stay in a shared cache. Drush commands sync users and test what the resolver sees, and identity strategies, by email or by a user field, are plugins a site can add to.
• 📊 Preview and debugging. Editors with the permission can view any page as a given audience by adding ?ma_preview_segments=vip to its URL. With Masquerade, a back office user who switches to a customer sees the customer's audiences, and a banner says so. A report at Reports > Mautic Audiences shows what the resolver sees for any user, email or contact.
• 🛡️ Consent gate, with a Klaro sub-module. A service you name can withhold every audience until the visitor consents. The Mautic Audiences: Klaro consent gate sub-module provides one that reads the visitor's decision in Klaro Cookie & Consent Management.

Quick start

composer require drupal/mautic_audiences
drush en mautic_audiences

1. At Configuration > Web services > Advanced Mautic Integration, fill in Mautic API URL, Mautic API user and Mautic API password, if the site does not have them yet.
2. At Configuration > Web services > Mautic Audiences, under Webhook, click Generate a secret, then add a webhook in Mautic that posts to /mautic-audiences/webhook on your site, signed with that secret, for the contact events the README lists.
3. At Structure > Block layout, configure a block, open the Mautic segment tab under Visibility, and enter a segment alias, such as vip.
4. Visit the site as a contact in that segment: the block shows for them and for no one else. Reports > Mautic Audiences shows the segments and tags the resolver read for you.

The Audience field on an article, with the segments Mautic returns. Ticked segments are the ones the article is for.

Good to know

• The module only reads from Mautic. It asks for a visitor's segments and tags when nothing is stored for them yet: on their first request, for an anonymous visitor again once the cache lifetime set in Cache TTL (seconds) ends (5 minutes by default), and on every request while Mautic does not answer. Webhooks and the reconciliation on cron keep what is stored current; reconciliation checks a user again once their record is older than the drift threshold, 7 days by default.
• Anonymous visitors are recognized by the mtc_id cookie of Mautic's tracking script. A visitor without it has an empty audience.
• Pages that ask about the audience of an anonymous visitor are kept out of core's Internal Page Cache, which can hold only one response per URL, and are served from the Dynamic Page Cache instead. Pages that never ask keep the Internal Page Cache.
• Block visibility and the Views filters decide what is rendered, not who may access what. Only the Audience field's restriction setting controls access to content, and editors of that content are exempt from it.
• Lists of a visitor's segments and tags, from the joined tokens or from list(), contain only the segment aliases and tag prefixes you allow under Client-side exposure. Checks for one segment or tag need no allowance, since they only confirm a name the caller already has.
• Webhooks are accepted unsigned while no secret is set, which the module logs as a warning; set one before going live.
• The JavaScript API is a library, mautic_audiences/audiences, that a theme or module attaches where it uses it.
• Drupal core's Layout Builder offers no visibility conditions for the blocks it places, so the conditions do not appear there.

Additional requirements

• Drupal 10.3 or later, or 11, on PHP 8.2 or later.
• Advanced Mautic Integration 1.0 or later, connected to a Mautic with its API enabled.
• For the Klaro sub-module, Klaro Cookie & Consent Management.

Recommended modules/libraries

• Commerce Mautic Connect: fills Mautic with what happens in a Drupal Commerce store, such as abandoned carts, coupon tags and order metrics, for segments this module can then show content to.
• Block Content Visibility: sets the Mautic segment and Mautic tag conditions on a reusable block itself, so they apply wherever it is placed.
• AI Mautic: lets an AI agent or an MCP client look up and change Mautic contacts, segments and tags.
• Search API: with the Audience field sub-module, filters search results by audience at query time.
• Token: the token browser, where the [mautic-audience:*] tokens can be found.

Similar projects

• Smart Content: shows a different block to each visitor from conditions the browser evaluates, such as language, device, screen size, cookies and localStorage, and fetches the chosen block after the page loads. It has no Mautic source. Pick it when the conditions live in the browser rather than in Mautic.

Community documentation

• README: every setting, the webhook events to send, the Twig functions, tokens and JavaScript API, identity strategies, the Drush commands, and the documents in docs/ on security, webhooks, JavaScript, Twig and tokens, Layout Builder and CDNs.
• Audience field README: setting up the field, choosing between targeting and restricting, and what listings and search follow.

Supporting this module

Developed and maintained by Bloomidea. Bloomidea offers support and custom development for this module.