Most advice about Meta account structure stops at principles. Principles are easy to agree with and hard to apply at four in the afternoon when someone needs a second ad account. What follows is four structures we actually build, written out in full, so you can mirror whichever matches your situation.
Four Principles Behind Every Structure Below
- One legal entity, one portfolio. Split portfolios only when invoicing, tax registration or contractual segregation genuinely demand it.
- Split ad accounts by money, not by campaign. A new ad account is justified by a separate budget owner, a separate payment method or a separate currency - not by a new campaign idea.
- One dataset per domain. Shared across ad accounts within the portfolio wherever the same site is being measured.
- The brand owns; the agency is granted. Every asset lives in the client portfolio and is reached through partner access.
Structure A: Single-Brand In-House Team
A hotel, a restaurant group with one brand, a developer with one company, a retailer with one website. The simplest correct structure, and the one most businesses should have.
Portfolio: Acme Ltd (verified)
├── People
│ ├── Admin - Managing Director (2FA)
│ ├── Admin - Marketing Manager (2FA)
│ └── Employee - Media Buyer (asset access only)
├── Pages
│ └── Acme (Facebook) + @acme (Instagram)
├── Domains
│ └── acme.com (verified)
├── Datasets
│ └── DS - Acme Web (pixel + Conversions API)
├── Ad accounts
│ └── AD - Acme - Main (EUR, company card, spend cap set)
├── Catalogue
│ └── CAT - Acme Products
└── Partners
└── Studio Communications (task access: ads, dataset, page)One ad account is enough far longer than people expect. Campaign budget separation, reporting by brand line and audience segmentation are all campaign- level concerns; splitting accounts to solve them fragments learning history and buys nothing.
Structure B: Multi-Brand Group
A hospitality group with three properties, a developer with distinct tower brands, a restaurant company with separate concepts. The question is whether each brand is a separate legal entity with its own invoicing.
Portfolio: Acme Group Ltd (verified) ├── Business unit: Coast Hotel │ ├── Page: Coast Hotel + @coasthotel │ ├── Domain: coasthotel.com (verified) │ ├── Dataset: DS - Coast Web │ └── Ad account: AD - Coast - Main ├── Business unit: Harbour Residences │ ├── Page: Harbour Residences + @harbourres │ ├── Domain: harbourresidences.com (verified) │ ├── Dataset: DS - Harbour Web │ └── Ad account: AD - Harbour - Main ├── Shared │ ├── Payment method: Group card │ └── Admins: Group CMO, Group Finance (2FA) └── Partners: agency per unit, scoped to that unit's assets
If the properties are separate legal entities with separate accountants and bank accounts, give each its own verified portfolio and let the group hold partner access into all of them. That is more administration and it is the only clean answer when invoices and liability are genuinely separate.
The test is simple: if two things are billed together and owned together, they belong together.
Structure C: Agency Serving Many Clients
An agency needs exactly one portfolio: its own. Client assets never live inside it. What the agency holds is its own identity, its own people, and partner access into every client portfolio.
Portfolio: Studio Communications Ltd (verified)
├── People
│ ├── Admin - Managing Partner (2FA)
│ ├── Admin - Head of Performance (2FA)
│ └── Employees - strategists, media buyers, analysts
├── Own assets
│ ├── Page + Instagram (agency brand)
│ ├── Domain: studio-comms.com (verified)
│ ├── Dataset: DS - Studio Web
│ └── Ad account: AD - Studio - House
└── Client access (partner links - no ownership)
├── Client A portfolio -> ads, dataset, page tasks
├── Client B portfolio -> ads, dataset tasks
└── Client C portfolio -> ads tasks onlyTwo operational rules make this survivable at scale. Grant your own team asset-level access per client rather than blanket admin, so a departure is a two-minute removal. And keep a single register of which client portfolios you are partnered into, which tasks you hold, and who the client-side admins are - that document is what turns an access emergency into a phone call.
The pattern to refuse, however convenient: creating the client's ad account or dataset inside the agency portfolio. It looks faster on day one and it is a dispute waiting to happen. An agency that owns its clients' history is not being efficient; it is holding a deposit it never agreed to return.
Structure D: Moving Agencies Without Losing History
The situation is common: everything sits in the outgoing agency's portfolio and the brand wants out. Sequence matters more than speed, because some transfers are one-way and ad account history is the piece most easily lost.
- Create and verify the brand portfolio first. Verification can take days; start it before you announce anything.
- Verify the domain in the new portfolio and reconfigure aggregated event measurement there.
- Request page transfer. Pages move cleanly and carry followers and history.
- Transfer dataset ownership, then re-share it back to the outgoing agency temporarily so campaigns keep measuring during the handover.
- Transfer or rebuild the ad account. Where a transfer is not possible, accept a new account and plan for a fresh learning phase; the dataset history is what carries most of the value forward.
- Add the new agency as a partner, then remove the old one - in that order, never the reverse.
One piece of practical advice: begin the transfer before you give notice. Transfers are executed by whoever currently holds admin, and goodwill is finite.
Naming Conventions That Survive Staff Changes
Every structure above uses the same convention, and it is worth adopting verbatim: asset type, brand, unit, purpose. AD - Coast - Main, DS - Harbour Web, CAT - Acme Products. Campaigns extend it with objective and date: Coast | Bookings | Q4 26 | Prospecting.
Alongside it, keep one document listing portfolio admins, verified domains, dataset IDs, payment methods and partner links. Meta will rename its interface again; IDs and a maintained register will still be true.