The Mautic Privacy Project

If you took the surveillance out of marketing automation, what would be left?

For most tools on the market, not very much. Tracking is not a feature bolted on top, it is the foundation on which they're built. Turn it off and things just stop working. Mautic is no exception today, and this project is how we change that.

NLnet has awarded Mautic €72,306 through the NGI Zero Commons Fund to do three things.

1. Make every Mautic feature capable of working without setting a cookie.

   Forms currently set cookies unless you use kiosk mode. Asset downloads, redirect links and Focus items always set them. The tracking pixel sets them. Forwarded emails set them, and can advance a campaign for someone who never opted in. There is no way to revoke a Mautic cookie once consent is withdrawn, and the Gravatar integration reaches a third party server every time you open a contact record, with no way to switch it off.

2. Build access controls that work on a need to know basis.

   At the moment, if you can see contacts in Mautic you can see everything about every contact. For an agency that is an inconvenience. For a government department, a political party or a human rights organisation it is a reason not to use the software at all. We will add field level permissions, controls over who can see engagement data, separation of contacts between teams, and audit logging that records who looked at what and when.

3. Create a privacy centre, and ship with tracking off.

   One screen where every tracking setting lives, with clear guidance on what each one does before you enable it. Some of these settings currently exist only in a configuration file with no interface at all. Once the groundwork is done, Mautic will ship with tracking turned off, so enabling it becomes a deliberate and informed choice.

Part of this has already been delivered by the community. Do Not Track and Global Privacy Control support landed in pull request 15844 in February 2026. The split of mtc.js into essential and tracking scripts landed in 16660 in July. Where that has happened we have reduced our scope and reallocated the funding. Two milestones exist specifically to finish existing community pull requests that have been open for months, passing tests, blocked only on review capacity.

This assembly is where the Mautic Privacy Project is specified, debated and reviewed in public.

Its remit covers agreeing the technical specification for each phase before implementation begins, reviewing user experience research and wireframes for the privacy centre and the contact facing preference controls, deciding how Mautic behaves on upgrade when tracking defaults change, agreeing what counts as a completed milestone, and surfacing privacy requirements from organisations we have not yet heard from.

Its remit does not cover the grant agreement itself, the budget allocation or the engagement of the funded contributors, which sit with the Project Lead and NLnet.

Decisions reached here are binding on the project team in the same way as any other agreed Mautic specification. Where this assembly and the Product Team reach different conclusions, the Product Team's decision stands, and the disagreement will be recorded here rather than resolved privately.

How work is agreed

Nothing is built before a proposal has been published here and a consultation period has closed. Each phases begins with a specification proposal and, where there is an interface involved, wireframes for comment. Consultation periods run for a minimum of two weeks.

How progress is tracked

Work is planned and tracked on a public project board linked to the mautic/mautic repository. Every milestone is evidenced either by a merged pull request or by a published document, and that evidence is posted back here when the milestone closes. Because this project is grant funded, the evidence trail is a condition of payment, so it will be unusually complete.

Cadence

Fortnightly sprints, with a written progress update posted to this assembly at the end of each sprint, and an open call at the close of each phase which is recorded and published for anyone who cannot attend live.

Dealing with disagreement

Where consensus is not reached, the Project Lead decides and records the reasoning here, including the arguments against. Where a decision affects product direction, the Product Team decides.

Language and accessibility

Working language is English. All interface work delivered by this project meets WCAG AA, and the assembly will publish a conformance statement at the end. If any part of this assembly is difficult for you to use, please say so and we will fix it, because it would be a poor project that built accessible software through an inaccessible process.

Funded roles

• Project Lead, Sīlavāpi Cheesley, accountable to NLnet for delivery and chairing this assembly. Funded by Mautic.

• Senior Developer, Predrag Vukovic, leading the backend work across cookieless operation and access control.

• Design Engineer, Anderson J Eccel, leading discovery, interface design and the self contained implementation milestones.

Standing participants

• The Mautic Product Team, who hold final say on product direction.

• The UX and UI Tiger Team, who review all interface work for accessibility and consistency with the Carbon Design System.

• Core Team reviewers, who merge the work.

Open to everyone

• Anyone with a community.mautic.org account may participate in every debate and proposal here. You do not need to be a contributor, a developer, or a member of any team.

• We are particularly seeking participants who operate Mautic in high privacy contexts, including public bodies, membership and political organisations, independent media and human rights groups. The requirements of those organisations shaped the funding proposal, and we would rather hear where we have got them wrong before we design than after we ship.