Companies and properties in Adobe Experience Platform Tags

When you need this

Every Tags implementation eventually asks the same question: does a new brand, region, or app get its own property, or does it live inside an existing one? Get the answer wrong early and it compounds - two properties end up with copy-pasted extensions and data elements that drift apart the first time either one is edited, or one property tries to serve five unrelated domains and every publish becomes a shared-risk event for teams who have nothing to do with each other.

This is also where you land when auditing an inherited implementation: before touching a single rule, you need to know which company and property actually govern the domain in front of you, and whether other properties in the same company are quietly serving the same pages through an old embed code nobody removed.

How to work with it correctly

1. Treat the company as a licensing and user-permission boundary, not a content one. One company holds every property under a given Adobe Experience Cloud org. User access, extension entitlements, and the Adobe org ID are set at this level, so the company is where you decide who can touch Tags at all - not where you decide how many sites you're tracking.

Experience Platform > Tags
  > (top-left company switcher) shows every company your login can access
  > Properties tab lists every property inside the selected company
  > each property card shows its embed code environments (Dev / Staging / Production)

2. Split properties around independent publish schedules, not around brand names. Two brands that always deploy together and share every rule are cheaper to run as one property with shared extensions than as two properties with duplicated logic that has to be kept in sync by hand. Conversely, one brand with a marketing microsite that a different team owns and publishes on its own schedule usually deserves its own property, even though it's "the same brand."

3. Name properties for what they contain, not for who asked for them. "acme-marketing-www" ages better than "Q3-project-property" - a property outlives the project that created it, and an implementation audit two years later has to reverse-engineer scope from the name alone when nobody who requested it still works there.

4. Check for property sprawl before adding a new one. An org that's been live for years often has properties nobody remembers creating, some still holding a live embed code on production pages. Before requesting a new property, search existing ones' domain lists and installed extensions - the need is sometimes already covered.

How to verify it worked

Verifying a company/property structure isn't about a single tag firing - it's about confirming exactly one property serves each page, on purpose.

• Open the Adobe Experience Platform Debugger on a live page and confirm it reports exactly one Tags property and library version - a second, unexpected property name here means an old embed code is still live.
• In the property's Publishing flow, confirm the domain list under its hosted-libraries configuration matches the actual domains it should serve - an unreviewed domain list is how a property quietly starts (or stops) serving a site nobody flagged.
• Check the Network tab for exactly one embed script request per property you expect on that page - two requests to two different property IDs is the concrete symptom of the sprawl this structure is meant to prevent.

Illustrative, not a measured result: a company running six regional microsites as six near-identical properties might consolidate to one property with region-scoped rules, so a shared extension update only needs one publish instead of six coordinated ones.

Company and property administration screens change between Adobe Experience Platform releases - verify current menu paths against Adobe's own Tags documentation before an audit.

FAQ

Can one property serve multiple domains?

Yes - a property's hosted library isn't restricted to a single domain, and many implementations deliberately serve several related domains from one property to share extensions and rules. The trade-off is shared risk: a bad publish affects every domain on that property at once, which is exactly why the domain list deserves a periodic review rather than silent growth.

What happens to data elements and rules if we split a property in two?

Nothing carries over automatically - Tags doesn't offer a native "split property" operation, so extensions, data elements, and rules have to be rebuilt or exported and re-imported into the new property. This is why the property boundary decision is worth getting right up front; splitting later is a rebuild, not a setting change.