SFMC Business Units and Separate Ad Accounts: The Operating Model

Single-brand audience activation is a tutorial. Multi-brand is an operating model. The moment an SFMC instance holds several Business Units — brands, countries, regions — and the media side holds a matching (or worse, not matching) collection of ad accounts, the hard questions stop being technical: who owns which connection, which team can push what where, and how does audience logic get shared without budgets and consent getting shared along with it.

This post is the operating model we see work, drawn from running exactly these setups — including a 12-country retail group with 26 ad accounts.

The input rule: any Data Extension, managed per BU

The foundation is simple and worth stating first: Cezium takes the Data Extension as an input, no matter the type — local to a child BU, shared from the parent, synchronized, filtered — and the resulting audiences are managed per Business Unit.

That one rule is what makes central-plus-local governance possible. The parent BU can maintain the master suppression logic once — a group-level "do not target" DE, shared down — while each child BU builds its own retargeting and lifecycle audiences on local DEs. The shared DE doesn't need copying per brand; the local DEs don't need centralizing. Each BU's audiences live, refresh, and are permissioned in that BU, with volume allocation per Business Unit so one brand's enthusiasm can't consume the group's capacity.

Mapping BUs to ad accounts: the three patterns

1:1 — one BU, one ad account per platform. The clean multi-brand case: each brand's BU connects to that brand's Meta and Google accounts. Isolation is total — audiences, budgets, reporting all stay brand-side. Most multi-brand groups should default here.

One BU, many accounts — the regional pattern. One brand, one BU, but per-country ad accounts (the 12-market setup: 12 Meta accounts, 12 Google accounts, one brand). The BU's audiences map to the right country account, usually from country-segmented DEs. The discipline that matters: name the mapping explicitly (audience ↔ destination account) in your inventory, because "which account does this audience feed?" is the first question during any incident.

Many BUs, shared accounts — the pattern to avoid when you can. Several brands pushing into one ad account happens (agency legacies, ad-account scarcity on some platforms), but it blurs consent boundaries and reporting. If you inherit it, per-role permissions become your control layer: who can push into the shared account is the governance, since the account itself no longer separates anything.

Token ownership: the part that fails silently

Every platform connection is an OAuth grant from a human with admin rights on the ad account — and connections owned by humans die when humans leave. The operating rules:

• Connect with a dedicated service user per side, not a personal login — on the ad platform side especially. This is the single most repeated lesson from migrations we've run: the pipeline should not depend on anyone's employment.
• Know who your ad account admins are, per account, before setup. In regional and agency setups, several "your" accounts are actually administered inside an agency structure — getting those grants is calendar time, not tool time. Chase it first.
• Ownership follows the account, not the tool: the media side (or agency) owns the ad-platform grant, the SFMC side owns the BU connection. Write both names down next to each connection in your inventory. Secrets rotate; owners shouldn't be a mystery.

Roles: setup is two admins, operation is permissions

Setup needs exactly two profiles: an SFMC admin (package install, BU connections) and the ad account admins (per-platform authorization). After that, day-to-day work runs on per-role permissions inside Cezium: which users can create audiences, which can push, and to which destinations. In practice that means a central team can hold destination-connection rights while regional marketers create and refresh audiences within their BU — the local teams move fast inside their lane, and the lanes are real.

For regional organizations, one more habit pays for itself: give each region's audiences a naming convention carrying BU, market, and purpose (FR–Retargeting–Cart, DE–Suppression–Purchasers). Every platform's ads manager will eventually be read by someone who wasn't in the setup meeting; names are the documentation that survives.

Why this beats the per-brand-platform alternative

It's worth saying what this model replaces. On Data Cloud, siloed brands mean one Data Space per brand — a platform build per silo. On manual CSV routines, multi-BU means a spreadsheet workflow per brand per platform. The per-BU model here keeps one installation, one governance layer, and as many isolation boundaries as your org chart needs — which is the actual requirement: isolation where it protects, sharing where it saves work.

Frequently asked questions

Can shared Data Extensions feed audiences in child Business Units?

Yes. Any Data Extension type — local, shared from the parent BU, synchronized, filtered — works as an audience source; the audiences built on it are then managed within each Business Unit.

How do you map Business Units to ad accounts?

Three patterns: 1:1 (brand BU → brand accounts, the default), one-BU-to-many (regional accounts fed from country-segmented DEs), and many-BUs-to-shared-account (avoid where possible; govern with per-role push permissions where not).

Who needs to be involved in setup?

An SFMC admin and the admin of each ad account — once. Ongoing operation is governed by per-role permissions: audience creation, push rights, and destination access assigned per user.

How do you keep connections from breaking when people leave?

Connect through dedicated service users rather than personal logins, record an owner per connection (SFMC side and ad-platform side), and treat agency-administered accounts as their own workstream — the grants take longer than the setup.

Can each Business Unit be capped on volume?

Yes — audience volume is allocated per Business Unit, so group capacity is distributed deliberately rather than consumed first-come, first-served.

Running multi-brand SFMC? See the model live — book a demo →