Ad Unit Naming Convention: A Practical Framework for Ad Ops Teams

What ad unit naming convention should a multi-property publisher use? Start with site_page-or-category_position_size. Add placement only when it changes trafficking or reporting, and keep tests or business rules out of the core name unless they point to a real inventory difference.

Key takeaways

• Use a fixed field order so names stay searchable across GAM, Prebid, reports, and QA.
• Name the inventory fact, not the business rule; keep tests, pricing, and sponsorship labels out of the core string.
• Separate ad unit names from targeting keys so GAM paths and Prebid values do not drift.
• Only add extra labels when they represent a real inventory difference or trafficking decision.
• Document the convention in one place or it will degrade as soon as multiple teams touch it.

Why naming consistency matters at scale

Naming consistency matters because Google Ad Manager, Prebid, reporting exports, QA sheets, and traffickers all touch the same inventory label at different moments. A name that seems fine inside one property turns into operational debt once you add sister sites, branded content, sponsorship packages, responsive slots, and repeat test cycles.

The failure pattern is easy to spot. One property uses hp_top_728x90, another uses homepage_leaderboard, a third uses top-banner, and now the yield team has to remember that all three mean the same commercial slot. Reporting joins get messy. Trafficking notes get longer. QA starts relying on tribal memory.

The name has to serve humans before systems

Google Ad Manager and Prebid can put up with plenty of naming mess as long as the IDs, paths, and key-values are wired correctly. Your team can’t. The display name is what an ad ops specialist scans during trafficking, what a yield manager filters in a report, and what a product manager checks when asking whether a page redesign touched monetized inventory.

Short names are usually the wrong thing to optimize for. medrec is shorter than news_article_mid_300x250, sure, but it makes the reader infer the site, template, slot position, and size from context. Searchable beats clever. If a name doesn’t hold up in a CSV export, a Slack message, and a GAM line item search, it’s too opaque.

The standard has to identify the commercial slot

A usable ad unit naming convention should tell you four things without opening a lookup sheet: site, page or category, position, and size. Add placement when it represents a distinct package, sponsorship surface, or sales concept. Don’t add it just because another team wants one more label in the string.

Naming systems outside ad ops enforce the same lesson: the string is a control surface. Microsoft Learn’s guidance for Windows Server and Active Directory naming conventions treats valid characters, uniqueness, and object clarity as governance issues, not cosmetic choices Microsoft Learn. Ad unit names need that same discipline because they become shared infrastructure.

You’ll see this exact operational question in the Google Ad Manager Help Community because multi-site publishers eventually run into the same wall: the old single-site naming style no longer carries enough context. The answer isn’t to make every name longer. It’s to use a predictable field order and a clear rule for what earns a slot.

A scalable naming taxonomy for site, page, position, and size

A scalable taxonomy uses the fewest fields needed to make the ad unit unique, searchable, and useful for trafficking decisions. For most U.S. publishers running multiple properties, the safest base order is site_page-position_position_size, with lowercase tokens and one delimiter that exports cleanly across tools.

Delimiter choice feels boring right up until it breaks a report. Use underscores between major fields and hyphens inside multi-word values: site_article-top_300x250 is easier to parse than site|article top|300 x 250. Avoid spaces, special characters, diacritics, and mixed casing unless your organization has already standardized them across exports.

Bionic’s naming convention guidance for media planning makes the same operational point from another angle: hand-built strings in spreadsheets get fragile when the convention depends on lookups and concatenation rules Bionic. For ad units, the rule should be simple enough that a trafficker can create the right name without rebuilding a formula chain.

Where to stop adding detail

Stop adding fields once the next token describes a business decision instead of an inventory fact. direct, programmatic, q4, sponsor, and highvalue can feel useful during setup. They age badly. A slot can move from remnant to premium, a sponsorship can end, and a Q4 test can become the standard template.

Creative file naming follows a different logic. Advariation discusses ad creative file naming around IAB-oriented production workflows, where asset dimensions, versions, and formats are part of the file’s identity Advariation. An ad unit lives longer than a creative file. Treat it like inventory infrastructure, not campaign packaging.

How to avoid conflicts across GAM and Prebid

Conflicts show up when the ad unit name, the GAM ad unit path, and Prebid targeting keys all try to describe the same thing in different ways. The clean setup is straightforward: let the name identify inventory, let key-values carry request-time context, and let line items express commercial rules.

1. Separate the display name from targeting semantics. The ad unit name should say site_article_top_300x250. Key-values can carry page_type=article, section=sports, pos=top, or refresh=eligible. If both the name and key-values encode the same changing business logic, one of them will go stale.
2. Map one inventory concept across systems. In Google Ad Manager, the ad unit path and line item targeting should point to the same slot concept that Prebid calls in the adUnits configuration. Do not create separate names for the same slot just because one demand path is direct and another is header bidding.
3. Keep Prebid labels descriptive, not decorative. A Prebid adUnit code should be traceable to the same slot your ad server uses, but bidder parameters and mediaTypes already describe demand mechanics. Do not bury bidder, floor, or deal logic inside the visible ad unit string.
4. Handle reused placements with context. If the same 300x250 appears on article pages and gallery pages, page/category must separate them. If the same module appears twice on one template, position must separate them: article_mid1_300x250 and article_mid2_300x250 are clearer than two copies of article_medrec.
5. Treat responsive slots as inventory families. If GAM size mapping allows 970x250, 728x90, and 320x50 from the same top slot, do not force every possible size into the name. Use top_multi or omit size if the actual allowed sizes live in GAM and Prebid configuration.
6. Do not encode remnant versus premium in the ad unit. That distinction belongs in line item priority, pricing rules, packages, deals, or reporting labels. Once premium_rail_300x250 underdelivers and gets opened to broader demand, the name becomes a lie.
7. Reserve renames for structural changes. A redesign that moves the slot from the right rail to an in-content position deserves a new position token. A sales team renaming a package does not. If the pixels and commercial inventory are the same, keep the ad unit stable.

The risky naming convention is the one that turns into a mini data warehouse. If your string includes site, template, position, size, audience, refresh status, floor tier, sales channel, device, and experiment, it may look helpful for one quarter. After the next reorg, it becomes a maintenance problem.

How to handle A/B testing without breaking the convention

A/B test markers should stay as temporary metadata unless the variant creates a durable inventory shape. Keep the core ad unit name stable for test treatments that change rules, floors, refresh, or demand access. Create a new name only when the page exposes a materially different slot.

• Put test markers at the end when they must be visible: site_article_top_300x250_exp42b is easier to strip and filter than exp42b_site_article_top_300x250. The suffix should never interrupt the base field order.
• Use control and variant labels only for short-lived QA. ctrl and varB help during launch checks, but they are poor permanent taxonomy because they have no meaning after the test closes.
• Prefer a separate experiment field for auction or rule tests. If the test changes floors, refresh eligibility, lazy-load thresholds, or demand partners, store the experiment ID in a key-value, analytics dimension, or test management field rather than cloning ad units.
• Create a new ad unit for structural slot tests. If variant B adds a second mid-article unit, changes the top slot into a sticky unit, or replaces a rail unit with an in-feed unit, the inventory has changed. Name the new slot by its new position, not by the experiment that discovered it.
• Set an expiration rule before launch. Every test suffix needs an owner and a cleanup date. Without that, exp, test, v2, and new become permanent junk fields that future traffickers are afraid to delete.
• Do not reuse old experiment IDs. A suffix like exp17 should point to one decision. Reusing it for a later layout test creates false joins in reporting and makes historical comparisons harder to trust.
• Promote winners by renaming only when necessary. If a test changes configuration but the ad unit remains the same commercial slot, remove the marker and keep the base name. If the winning variant becomes a new layout position, create the clean permanent name and archive the variant label.

The practical rule is simple: tests can annotate inventory, but they shouldn’t redefine the taxonomy unless the user-facing ad opportunity changed. That keeps A/B testing traceable without turning your GAM tree into a graveyard of abandoned variants.

Document the convention so the team actually uses it

A naming convention only works when the source of truth is easier than improvising. Put the standard where trafficking actually happens: the ad ops SOP, the new-site launch checklist, the GAM build request form, and the master inventory sheet your yield team already trusts.

1. Write the pattern in one line. Example: site_page-position_position_size_optionalplacement_optionalsuffix. Then define each allowed field below it with approved tokens and examples.
2. Assign one owner. The owner can be ad ops, revenue operations, or platform operations, but one person or group must approve new tokens. Shared ownership without a final approver produces local dialects.
3. Create a change request path. New sites, new templates, sponsored modules, and redesigns should trigger a naming review before GAM objects are created. Rename cleanup after launch is slower and riskier.
4. Keep a token registry. List approved site codes, page/category tokens, position tokens, size handling rules, placement values, and retired values. Mark deprecated tokens so reporting users know why old names still exist.
5. Add validation to trafficking QA. The checklist should ask whether the name uses approved delimiters, matches the site code, includes the correct page/category, uses a real position, handles size correctly, and avoids business logic.
6. Review exceptions monthly during active build periods. Exceptions are not automatically bad; undocumented exceptions are. If a local property needs a special token, document the reason, owner, and sunset condition.
7. Onboard new properties with mapping, not translation. Do not copy a local site’s old names into the shared network. Map old inventory to the standard pattern and preserve legacy names only as notes or reporting aliases.
8. Automate after the rule is stable. Spreadsheet formulas can help, but they should implement the convention rather than invent it. If you use planning or workflow software, encode the approved fields there so names are generated consistently.

Borrow the governance mindset from Active Directory and Windows Server naming: objects stay manageable when names are constrained, predictable, and reviewed before they spread. Ad ops doesn’t need enterprise IT bureaucracy. It does need the same refusal to let every team invent local syntax.

Final operating checklist

• Use site_page/category_position_size as the default ad unit naming convention for shared Google Ad Manager environments.
• Require a stable site code for every property in a multi-property network.
• Use page/category tokens that match monetized templates or commercial sections, not deep editorial taxonomies.
• Name position by layout reality: top, mid, rail, footer, sticky, infeed, or another approved token.
• Include size only when it identifies the slot or affects trafficking; use multi or omit it for responsive inventory where configuration carries the size list.
• Keep Prebid adUnit codes, GAM ad units, and line item targeting aligned to one inventory concept.
• Put floors, deal type, demand source, remnant status, and sales priority outside the ad unit name.
• Use experiment suffixes only when visibility is required, and remove or promote them after the test decision.
• Document every exception with an owner, reason, and sunset condition.
• Do not launch a new site, redesign, or sponsored module until its names pass the token registry and QA checklist.

Frequently asked questions

What is the best ad unit naming convention?

The best one is the simplest pattern that still identifies the site, page or category, position, and size without ambiguity. For most multi-property publishers, that means a stable, searchable string that a trafficker can read in GAM, a yield manager can filter in a report, and QA can recognize in a Slack thread without opening a lookup sheet.

Should ad unit names include sizes?

Yes, when size changes the slot or prevents confusion between similar placements. If a placement can appear in more than one size, or the size is part of how you report and traffic it, include it. If the slot is always the same size and already obvious from context, repeating it just adds noise.

How do I keep GAM and Prebid naming consistent?

Use the same core taxonomy across both systems, but keep one stable human-readable name instead of stuffing display labels, targeting keys, and test markers into it. GAM paths, Prebid keys, and reporting exports can differ under the hood; the important part is that everyone maps back to the same commercial slot without guessing.

Should A/B test variants be part of the ad unit name?

Yes, if the test changes the slot itself and the variant needs to stay distinct in reporting. Use a clear suffix for short-lived tests, then remove it on cleanup so the experiment label does not turn into permanent clutter. Keep business rules out of the core name unless they represent a real inventory difference.

How we researched this

Sources consulted for this article:

• What naming convention to use when managing ad units for multiple...
• Ad Naming Conventions: Templates and Structure for Meta Ads
• Wikipedia talk:Naming conventions (military units))
• Ad Creative File Naming Conventions - Advariation
• Name computers, domains, sites, and OUs - Windows Server | Microsoft Learn
• How to Deliver Perfect Naming Conventions, Every Time