Pattern 11Multi-brand activation

A brand is a relationship, not a person attribute

In a multi-brand group, a main brand does not describe all of a person's relationships. Each send needs a brand and the relevant permission check.

Each send knows its brand

Send path

Trigger

Order event + brand

Profile

Brand relationships

Decision

Condition on brand

Delivery

Brand configuration

Generic diagram. It does not reproduce a client architecture.

A main brand can help classify customers, but does not necessarily identify the brand of each purchase. A sender that only reads that field may select another brand. Global consent cannot preserve different preferences per brand either.

I recommend storing the relationship between the person and each brand, with its consent. Duplicating profiles to resolve the sender can increase licence consumption and spread message limits across profiles. A shared email may also link them if identity rules allow it.

What breaks: A customer of two brands gets emails from one with the other's sender, or from a brand she said no to.
Where the state lives: The relationship with each brand lives on the profile, with its consent. Each send states which brand it belongs to: the event that triggers the journey or the campaign audience.
Who owns it: Each brand owns its consent and its sending domain. The relationship model is kept by whoever manages the group's customer data.
What trade-off we accept: One profile per person with relationships takes more modelling work, but it does not duplicate licence or capping. A profile per brand is quick to build and is paid for in cost and merge risk.
How it evolves: Move the brand from a field to a relationship, add it to the events, create a channel configuration per brand, and retire the duplicated profiles.

Production signals

The profile has a main brand and the group sells under several.
The same person exists as one profile per brand.
There is a single email consent even though each brand asks for its own.
Order events do not say which brand they belong to.

Recommended architecture

Model the relationship between the person and each brand with its consent, and make every send state which brand it belongs to.

In standard AJO, I recommend separate configurations by brand and message type. Shared configurations with personalisation are also possible if the sender resolves unambiguously.

When not to apply it

I would not use a shared profile without first checking whether the brands can share customer data.
If the business needs account-based marketing and buying groups, I would assess B2B against those needs. Having several brands is not a reason to rule it out.

Try it in a simulator

Interactive scenarios where this pattern fails and gets fixed.

AEP · AJO
Person or account?

Laura is a customer of two brands. How does each one email her with its own sender, respecting what she agreed to with each?
Open the simulator →

Explore this decision

Seeing data does not permit every use
Who can see data, what it may be used for and what a person accepts. Compare access controls, DULE and consent in AEP.