Ad Units in Google Ad Manager: Naming, Codes and Structure

When you move from AdSense to Google Ad Manager, one of the first jobs is setting up ad units. In AdSense, ad units are mostly a convenience. In Ad Manager, they are the backbone of your inventory: they decide how ads are requested, how pricing rules are targeted and how your reports read. A few hours of planning now can save months of confusing reports later. This guide explains what Google Ad Manager ad units are, the difference between a name and a code, the rules Google applies to codes, and a simple structure for a typical content site.

What an ad unit is

Google's definition is short: each ad space on your site or app is called an ad unit. Your inventory, in Ad Manager terms, is the organized set of places where you want ads to run, and the sizes you want them to be.

Ad units sit in a hierarchy. You can create top-level ad units and child ad units beneath them. Google notes that child ad units automatically inherit many settings from their parent ad units, and that the Google Publisher Tag (GPT) lets you use multiple levels of hierarchy for more specific targeting based on your content.

Ad units are only one part of the picture. Google describes inventory as a combination of three things:

• Ad units, the building blocks, which allow targeting to "flow down" to subsections.
• Placements, which group ad units together so they can be targeted as one.
• Key-values, which let you target across your content horizontally, regardless of where an ad unit sits in the hierarchy.

Keeping these three roles separate is the secret to a structure that stays clean.

You create ad units under Inventory > Ad units > New ad unit. The main fields are a name, a code and sizes, with optional fields such as description, target window, labels, teams and placements.

Name vs code

Every ad unit has both a name and a code, and they do different jobs.

• The name is what people see inside Ad Manager, for example in the targeting picker and in reports. Google says it should be descriptive, so anyone using Ad Manager understands what the ad unit represents.
• The code is a string of characters used in your ad tags. It is what the browser actually sends when it asks for an ad. If you do not enter a code, Ad Manager uses the name.

A practical way to think about it: the name is for humans, the code is for machines. "Recipes, article pages" is a good name. "recipes_article" is a good code.

Because the code lives in the tags on your live pages, it is the part to get right first time. Changing a code later means changing the tags that use it, on every page.

Code rules (length, characters, uniqueness)

Google's help page on ad unit names and codes sets out the rules:

• Length: codes can be up to 100 characters.
• Case: codes are not case-sensitive. "Recipes_Article" and "recipes_article" are treated the same, so do not rely on capital letters to tell codes apart.
• Characters: only letters, numbers, underscores, hyphens, periods, asterisks, exclamation marks, left angle brackets, colons, forward slashes and parentheses are allowed.
• Uniqueness: codes must be unique at the same level of the hierarchy. They may be reused at different levels, but not for Ad Exchange ad units. An Ad Exchange ad unit code cannot be the same anywhere in the hierarchy.

That last rule is the one that matters most for an AdX plan. Google's own example reuses "homepage" as a code under two different section ad units, which is allowed for ordinary ad units. If you expect to run AdX on that inventory, avoid reuse entirely and give every ad unit a code that is unique across the whole network. A simple way to do that is to build the parent into the code, such as "travel_homepage" and "news_homepage".

A few habits make codes easier to live with:

• Use lowercase and underscores only, even though more characters are allowed.
• Keep codes short and readable. They will appear in tags, logs and support tickets.
• Avoid dates, campaign names or anything that will go stale.

A simple hierarchy for a content site

There is no single correct structure, and Google says planning is ongoing because sites change. For a typical content site moving from AdSense, though, a two-level layout is a sensible start:

• Level 1: the site. One top-level ad unit per domain, for example "example_com".
• Level 2: the section or page type. Child ad units such as "example_com_home", "example_com_article", "example_com_category".

Then use key-values for ad position (for example top, middle and bottom) rather than creating separate ad units for each slot. That is close to Google's own inventory planning example, which uses position key-values to tell slots apart within the same ad unit.

Why keep it shallow? Because every extra level and every extra ad unit is something you have to tag, price, report on and maintain. You can always split an ad unit later when you have a reason, such as a section with very different content or audience.

If you also run AdSense inside Ad Manager during the transition, note that AdSense can be enabled for the whole network or for individual ad units, and Google says ad unit settings for AdSense take precedence over network settings. A clean hierarchy makes it much easier to see which ad units have it switched on.

Ad units in MCM tags (child and parent network codes)

Your ad unit codes appear inside the ad unit path in your tags, alongside your network code. Google describes the network code as a unique numeric identifier for your network, visible in your Google Publisher Tags.

Under Multiple Customer Management, tagging depends on the delegation type:

• Manage Account: the child publisher uses its own Ad Manager tags. Your ad units live in your own network, and your partner works on them inside your account.
• Manage Inventory: the child publisher uses the parent publisher's tags, which include an identifier for the child account.

Google's ad unit code page adds that in MCM tags, the child and parent network codes can be separated by a comma. This is how one ad request can identify both networks. Your partner should give you the exact tag format; do not try to assemble it by hand. Our guide on how MCM works covers the delegation types in more depth.

Either way, a tidy, unique set of ad unit codes makes onboarding smoother, because both sides can see at a glance which inventory is which.

Key-values vs more ad units

Key-values are custom attributes you attach to an ad request. GPT takes the ad unit code, the ad size and any key-values, builds the request and sends it to Ad Manager. When Google's tag generator builds a GPT tag, one of its options is page-level key-values, which apply to every ad slot on the page.

The question is when to use a key-value and when to create another ad unit. A simple test:

• Use an ad unit for where the ad sits in your site's structure: a site, a section, a page type.
• Use a key-value for an attribute that cuts across that structure: ad position, article topic, page template, logged-in or not.

For example, if every section has a top and a bottom slot, one "position" key with values "top" and "bottom" covers them all. Creating "news_top", "news_bottom", "sport_top", "sport_bottom" and so on multiplies your ad units and makes reports harder to compare.

Key-values have limits too. Google lists a maximum of 200 active keys per network, keys of up to 20 characters and values of up to 40 characters. Plan a small, stable set of keys and use them consistently.

Placements are the third tool. They group ad units so you can target them together, for example all article pages across several sites. Google allows up to 1,000 ad units per placement.

Pricing rules can also target inventory such as ad units, with up to 200 pricing rules per network. A clean structure makes floors easier to manage later.

Mistakes that make reporting hard

Most ad unit problems only show up months later, when you try to answer a simple question in a report. Here are the common ones:

• One ad unit for everything. Easy to set up, but your reports cannot tell a homepage from an article page.
• An ad unit for every slot on every page. The opposite problem: hundreds of rows that are hard to compare and easy to mis-tag.
• Reused codes across levels. Allowed for ordinary ad units, but confusing in reports and not allowed for Ad Exchange ad units anywhere in the hierarchy.
• Codes that rely on capital letters. Codes are not case-sensitive, so "Top" and "top" are the same code.
• Vague names. "Unit 1" and "New ad unit (2)" tell nobody anything. Names are free; make them descriptive.
• Old ad units left active. When you redesign a page, deactivate ad units you no longer use so they do not clutter reports.
• No record of the plan. Keep a short document listing each ad unit, its code, its sizes and which pages carry it. It helps you, and it helps any partner you work with.

Once your structure is in place, tags come next. You generate them under Inventory > Ad units, by opening an ad unit and choosing the Tags tab. Our guide to Google Publisher Tag basics explains how those tags work. If you have not set up the network itself yet, start with Ad Manager account setup.

Next step

A clear ad unit structure makes AdX easier to switch on and easier to measure, whichever MCM delegation type you use. Before you ask for an invitation, check that your network, sites and policy record are ready using the requirements. If they are, you can Get AdX access and request a review through our MCM partner network.