Bloomreach Consent Management: What Good Looks Like in 2026

A DPO asks a simple question: which consent covers the SMS that went out on Tuesday? The CRM manager opens Bloomreach, then the cookie tool, then a spreadsheet from the last newsletter migration. Forty minutes later the answer is “probably the newsletter checkbox, from 2023.”

That team isn’t careless. It has consent captured in three places, each correct on its own terms, none of them the record the platform checked before sending. Consent done well is invisible: the send goes to the people who said yes, and the audit takes five minutes. Consent done badly looks fine until the question arrives.

This is what good looks like for a team running Bloomreach Marketing (Engagement) in 2026. It covers the consent model the platform gives you, the three setups that fail most often, which parts of the law are changing, and a build checklist.

The model Bloomreach gives you

Fig 1 · Consent in Bloomreach · Category, consent event, action node, and expiry, plus the three setups that fail

Bloomreach stores consent on the customer profile, per purpose, as a record with a history. The pieces:

Consent categories. Defined once, per project. Each is a purpose: newsletter, product updates, SMS offers, personalization, partner offers. A category can be marked as legitimate interest, which changes the default from opt-in to opt-out for that purpose; that is a legal decision, not a configuration convenience.

The consent event. Every grant and every withdrawal is an event on the profile. It carries the category, the action (accept or reject), a valid_until date, and its own timestamp. The platform sets a source on the event itself (page, import, scenario, API). The finer origin (banner, account form, call center) is a property you add at capture. Because it is an event, the history is append-only: you can answer “what did this customer consent to on the day we sent” without a separate audit log.

Enforcement at the action node. Email, SMS, and push nodes in a scenario are tied to a consent category. A customer without a valid consent for that category is suppressed at the node and shows in the Evaluate tab under Policy and Consents. The check happens at send time, not when the scenario was designed, so a withdrawal an hour before the send holds.

Expiry. valid_until is a date on the consent, not a policy in a document. A consent whose valid_until has passed counts as absent at send time.

That is the whole model: purposes, an event log, enforcement at the channel, and expiry on the record. Everything below is about keeping every other system in line with it.

Pattern 1 that fails: one category for everything

The most common setup we open has a single category, usually called “marketing,” attached to every node. Email, SMS, push, partner offers, all under one yes.

It fails in two directions. A customer who withdraws from SMS withdraws from email too, because there is only one switch. And a customer who signed up for a newsletter is now legally, in the platform’s eyes, consented to SMS offers they never saw a checkbox for. The first direction loses reach. The second is the one the regulator asks about.

Good looks like a purpose per meaningful choice a customer might want to make, with channels mapped to purposes, never the reverse. Five to eight categories cover most mid-market programs. More than that and the preference center becomes the twenty-field form nobody updates.

Pattern 2 that fails: consent captured on the site, never on the profile

The cookie banner records a choice. Consent Mode passes it to Google. The account form has a checkbox that writes to the shop database. The newsletter tool has its own list. Bloomreach has consent events for some of these, imported once, during the migration.

Then a customer opts out in the preference center of the old newsletter tool, and Bloomreach never hears about it. Or the banner tool logs “reject” and the profile still says “accept” from an account form two years ago. Two sources of truth drift; the send goes to the one that says yes.

Good looks like one source of truth, and in a Bloomreach-led stack that is the profile. Every capture surface, the banner, the account form, the checkout checkbox, the preference center, the call center script, the trade-show tablet, produces a consent event. Downstream tools read from the profile, not from their own copy. The consent management platform on the site is a capture surface, not the record. We covered the site side in consent management and preference centers; the platform side is the same rule, enforced where the send happens.

Pattern 3 that fails: no expiry, no source

A consent record that says “newsletter: accepted” and nothing else. No date it was given, no surface it came from, no date it ends.

It fails at the audit. “When did they consent, and to what wording?” has no answer. It fails at re-permission. Without a valid_until, you can’t send a renewal campaign to people whose consent is about to run out. So you either mail them forever or delete everyone. And it fails on merge. When two profiles for the same person are joined, the platform has to pick one consent state. A record with no timestamp gives it nothing to choose by. That merge case belongs to identity resolution as much as to consent; decide both together.

Good looks like this: every consent event carries a timestamp, a source, and a valid_until. The expiry period is one your legal team agreed. A renewal scenario runs sixty days before it.

Fig 2 · One consent, one end date · The renewal scenario runs sixty days before valid_until

The law: what is moving and what isn’t

Consent rules in the EU are in negotiation, and the headlines are ahead of the text. The Digital Omnibus was proposed in November 2025. Its AI part became law in July 2026 (Regulation (EU) 2026/1744, Official Journal 24 July 2026). Its data part, the one touching GDPR and cookies, isn’t law. On 21 October 2026 the Council agreed its negotiating mandate. It keeps cookie rules in the ePrivacy Directive and sets a four-month wait before you can ask for consent again after someone refuses. Parliament hasn’t adopted its position, and talks between the two haven’t opened.

So next year you’ll most likely be audited against the rules in force today. And total GDPR fines in EU records have passed €6 billion.

What no version of the bill changes is the data model. Four things are required today and stay required under every draft: consent per purpose, a timestamp and a source on every record, a check per channel at send time, and a withdrawal path that works. Build those and the eventual law is a configuration change. Skip them and a friendlier law won’t pass the audit.

What good looks like: the checklist

Ten items. Each one is verifiable in the project, not in a policy document.

1. Consent categories defined per purpose, five to eight, named in plain language a customer would recognize from the checkbox they ticked.

2. Channels mapped to purposes in a written table. No node sends on a category it wasn’t mapped to.

3. Every capture surface produces a consent event: banner, account form, checkout, preference center, call center, offline forms. No surface writes consent anywhere else first.

4. Every consent event carries timestamp, source, and valid_until.

5. Every email, SMS, and push node in every live scenario has a consent category attached. A scan of scenarios with a node and no category returns zero.

6. Withdrawal reaches the profile in real time from every surface, and the send-time check is the enforcement, not the audience build.

7. A renewal scenario runs before expiry for each category that expires.

8. Merge behavior for consent is documented: which record’s consent wins, per purpose, and when.

9. A test customer with rejected consent for each category receives nothing on that category, verified by a real send to a test address, per channel.

10. The data subject request runbook reaches every system the profile feeds: warehouse exports, ad platform audiences, the analytics store, the loyalty system.

Items one to five are configuration and take days. Six to ten are process and take a quarter to prove. A team that can show all ten answers the DPO’s Tuesday question in five minutes, from one screen.

The takeaway

Consent in Bloomreach is a record on the profile with a purpose, a source, a timestamp, and an end date, checked by every channel at the moment it sends. Everything that goes wrong is a departure from that: one purpose for everything, consent living somewhere the send doesn’t check, records with no dates. The law will keep moving. The model doesn’t have to.

Read next

• Consent management and preference centers: what good looks like in 2026. The capture side: banner, preference center, the event log.

• Identity resolution: deterministic, probabilistic, and where each breaks. What happens to consent when two profiles merge.

• Your Framer cookie banner looks compliant. It isn’t. The most common capture surface, tested.