Multi-brand activation review

The profile has a main brand field, and relationships with other brands are not stored.

Next check: Find people who buy from more than one brand and check which brand their profile shows today.

There is a field per brand, but with no status or date, and each team fills it in its own way.

Next check: Agree what a relationship with a brand means and who writes that data.

Each brand has its own relationship on the profile, with a status, but it is loaded by hand or per project.

Next check: Move relationship loading into the group's data flow, with a clear owner.

One relationship per brand, with status and date, updated from the group's customer systems.

Next check: Check that a new brand is added as a relationship and not as one more field.

A single email consent applies to every brand in the group.

Next check: Compare what each brand's form asks for with the field that reaches the profile.

Each brand collects its own consent, but the profile reduces it to a single value.

Next check: Split consent per brand in the model before changing audiences or journeys.

We store consent per brand, but some marketing sends do not check it yet.

Next check: Identify those marketing sends and add the brand check before activating them. Treat transactional messages separately.

Consent per brand is checked before every marketing send, with test scenarios.

Next check: Keep the test scenarios, such as a person who accepts one brand and declines another.

Events and audiences carry no brand. It is inferred from the profile or the journey name.

Next check: Add the brand to the contract of the events that trigger journeys, starting with the order event.

Some events carry a brand, but with different values depending on the source that sends them.

Next check: Set a closed list of brand values and validate it at ingestion.

Events and audiences carry a brand, but we have not checked how it selects the sender.

Next check: In standard AJO, test conditions on the event's brand or brand-specific journeys with a fixed configuration.

Every send has an unambiguous brand, through conditions or a dedicated journey with a fixed configuration. We have tested it.

Next check: Test a purchase in each brand and check the sender and marketing consent separately.

Every brand uses a generic group sender and domain, without checking whether customers recognise them.

Next check: List the required senders and domains. Confirm limits and setup for the edition in use; standard AJO and B2B do not share the same delivery architecture.

The sender changes per brand through personalisation, but the sending domain is shared.

Next check: Assess whether separate brand subdomains are useful. Choose the setup method with the DNS team based on the edition and its responsibilities.

Each brand has its subdomain configured, and we manually select the sender when preparing each send.

Next check: Add a sender check before publishing. In standard AJO, a shared configuration requires unambiguous profile conditions.

Each brand sends with the intended sender and domain, tested with people linked to several brands.

Next check: Repeat the tests when configurations, personalisation or tokens change. Use the capabilities of the licensed edition.

Each brand creates its own profile of the same person, with separate identifiers.

Next check: Find people with a profile in more than one brand and add up the messages they can receive.

Profiles are per brand, but they share email as an identity and merging depends on the graph.

Next check: Check linking rules and the merge policy. Private graph uses existing links; a shared email can connect identifiers from different brands.

There is one profile per person, but the identity rules have not been tested with multi-brand cases.

Next check: Test the identity rules in Graph Simulation with multi-brand customers before enabling them.

One profile per person, with the brand as a relationship and identity rules tested before they go live.

Next check: Repeat the graph simulation before changing identities or adding a brand.

The plan is to buy B2B to model consumer brands as if they were accounts.

Next check: Review the per-brand relationship model before licensing anything.

We expect to activate B2B classes through Profile, but do not have Real-Time CDP B2B Edition or B2P Edition.

Next check: Confirm the edition. Without it, B2B classes do not take part in Real-Time Customer Profile.

The design expects standard AJO data sources to read relationships between person and account schemas.

Next check: Review the design. Standard AJO data sources do not support relationships between schemas.

We use AJO B2B for account-based marketing, with licences and delivery dependencies verified.

Next check: Check the dedicated Marketo Engage instance and whether batch account-audience evaluation fits the use case's timing.

We do not need account-based marketing. We manage brands through relationships on the person's profile.

Next check: Keep this model while it meets the requirements. Reassess B2B if genuine account-based marketing processes emerge.