How I automate publisher advertising with Codex, Google Ad Manager and AdSense.

A publisher’s advertising setup often grows one tag, one campaign and one exception at a time. Eventually the website contains several ways to request an ad, the commercial team has its own spreadsheet, and nobody is entirely sure what should happen when a direct campaign is not eligible to serve.

My preferred answer is not to ask artificial intelligence to make every revenue decision. It is to build a clear operating model in which Google Ad Manager (GAM) remains the ad server, Google Publisher Tag (GPT) remains the delivery layer on the website, and Codex helps keep the configuration and code in step.

The architecture is simple enough to write in two lines:

This is the workflow I would use for an established publisher that wants direct-sold advertising, AdSense monetisation and house promotion to coexist without maintaining a fragile tangle of page-level ad scripts.

Why Google Ad Manager becomes the control centre

AdSense is an excellent way to monetise a website with relatively little operational overhead. But a publisher that wants to sell campaigns directly, reserve inventory for its own promotions and control where different kinds of demand may appear needs an ad server, not a collection of unrelated snippets.

GAM gives each placement a stable identity. A page asks GAM for an ad in a defined slot; GAM evaluates the eligible line items, targeting, creative sizes and delivery rules; the winning response is returned through GPT. The website does not have to contain separate business logic for every advertiser.

The website should describe the opportunity. Ad Manager should decide which eligible ad serves into it.

That distinction matters. Custom code that says “try the direct ad, then call AdSense, then show our banner” duplicates part of an ad server in JavaScript. It is difficult to forecast, report, test and maintain. With GAM at the centre, the publisher can manage commercial priority and eligibility in one place while keeping the browser implementation predictable.

Google supports enabling AdSense access at the network, individual ad-unit or AdSense line-item level. The exact choice depends on how broadly the publisher wants AdSense to compete and which options are available in the account. Once AdSense or Ad Exchange line items are trafficked through GAM, Google also confirms that they can be delivered through GPT; separate AdSense tags are not required on the website.

Designing responsive inventory with Google Publisher Tag

“Responsive” should not mean stretching a fixed creative with CSS. It means defining which real creative sizes are eligible at different viewport widths, then allowing GPT to request the appropriate size set.

I begin with a small inventory vocabulary that describes location and purpose rather than a temporary advertiser. A useful starting set might be:

These are examples, not universal prescriptions. The right map depends on the actual layout, demand, viewability, cumulative layout shift risk and reader experience. A mobile slot should be omitted when the page has no responsible place for it.

GPT responsive size mapping associates viewport thresholds with eligible creative sizes. The default size set provides a safe fallback when no mapping matches. It is also possible to collapse an unfilled slot, but that choice should be made carefully because collapsing after the page has rendered can cause layout movement. I prefer to reserve sensible space or control collapsing deliberately rather than treat blank-space removal as a free optimisation.

Inventory definitions should be reusable data

The same definitions should drive both sides of the system. A version-controlled inventory manifest can record the GAM ad-unit code, allowed sizes, page contexts and GPT element ID. Codex can use that approved source to prepare API operations and update the website integration. That reduces mismatches such as a 970×250 creative being eligible in GAM while the page only reserves 90 pixels of height.

It also makes review possible. A change from “300×250 only” to “300×250 or 336×280” becomes a visible code and configuration change, not an undocumented click made months ago.

Direct sales, AdSense, dynamic allocation and house ads

The conceptual delivery chain is easy to understand, but it is important not to turn it into a crude, hard-coded waterfall:

1. Direct-sold campaigns receive the delivery treatment and targeting agreed with the advertiser.
2. AdSense and other eligible demand can monetise inventory that is not required by a higher-priority commitment and, where dynamic allocation applies, compete appropriately.
3. House ads promote the publisher’s own products, newsletter, events or other priorities when no revenue-producing demand serves.

Direct campaigns

A direct deal normally becomes an order containing one or more line items. The line item carries the dates, quantity or goal, rate, pacing, frequency controls, inventory targeting and other eligibility rules. Creatives are associated with the line item in the sizes that the targeted slots can accept.

The automation opportunity is consistency. Instead of manually translating every insertion order into a fresh configuration, Codex can take a reviewed campaign specification and prepare or perform the supported API operations. Naming conventions, labels, targeting keys and validation rules can be applied the same way every time. A human should still approve what was sold, the price, the dates, the creative and any sensitive targeting before activation.

AdSense monetisation and backfill

AdSense can be made eligible broadly at network level, selectively at ad-unit level or through line items, depending on the publisher’s account and desired control. The important point is that GPT requests GAM inventory. AdSense demand can serve through that GAM request without adding a second AdSense unit to the same position.

This keeps measurement and delivery coherent. It also prevents the page template from having to know whether an impression will become a direct campaign, an AdSense ad or something else.

Dynamic allocation is competition, not merely “second place”

It is common to describe AdSense as backfill, but that shorthand can hide how GAM actually optimises eligible impressions. Google explains that dynamic allocation allows AdSense, Ad Exchange, Open Bidding and remnant line items to compete without compromising guaranteed line-item delivery. AdSense or Ad Exchange serves when it can offer a higher CPM than the competing eligible line item.

That means price and priority settings have commercial consequences. Inflated CPM values, careless line-item types or overly broad targeting can suppress useful competition. Automation can enforce rules, but it cannot rescue a bad yield strategy.

House ads are the final fallback

A house ad is not a substitute for paid demand. Google describes House line items as the lowest-priority line-item type. They serve when no remnant line item is available, so they are well suited to valuable publisher messages that would otherwise receive no exposure.

Good house campaigns are still campaigns. They need relevant creative sizes, destination URLs, start and end dates where appropriate, and reporting. A newsletter promotion that has run unchanged for three years is technically a fallback, but not necessarily a useful one.

What Codex can automate after authorisation

Once the account, API access and repository permissions are in place, Codex can act as an implementation and operations layer. I divide that work into GAM configuration and website delivery.

The phrase “where supported” is important. GAM features, API availability and line-item options vary by network, product access, permissions and API version. A responsible automation checks the current account capabilities and current Google documentation rather than assuming every network exposes the same controls.

I also favour idempotent automation: running the same approved operation twice should update or confirm the intended object, not create duplicates. External IDs, predictable names and a recorded mapping between repository inventory and GAM objects make that possible.

What remains manual, authorised and human

Codex can operate approved systems; it cannot create legitimacy or consent on someone’s behalf. The initial Google-side setup still requires the publisher or an authorised administrator.

• Opening or approving the relevant AdSense and Google Ad Manager accounts.
• Accepting Google’s agreements and product terms.
• Completing publisher, identity, site or address verification.
• Providing tax, business and payment information.
• Passing Google’s policy reviews and any account or site approvals.
• Enabling API access and completing OAuth authorisation with appropriate scopes.
• Assigning a service account or user only the permissions genuinely required.
• Approving commercial commitments, pricing, sensitive targeting and final campaign activation.

These are not inconvenient gaps in the automation. They are boundaries that protect the publisher, advertiser, users and platform. OAuth tokens and credentials should live in an appropriate secret store, never in a repository or prompt. Production writes should be logged, reversible where the API allows it, and constrained to the intended GAM network.

A practical implementation sequence

1. Audit the existing stack

Document every current ad tag, slot, size, page type, consent dependency, direct campaign and fallback. Measure layout behaviour and identify which positions genuinely have value. Migrating an undocumented mess directly into GAM only creates a more organised mess.

2. Agree the commercial rules

Define which inventory may accept direct advertising, where AdSense may compete, what house campaigns are appropriate and which experiences are off limits. Decide who can approve price, targeting, creative and release.

3. Create the inventory contract

Write the standard ad-unit names, sizes, responsive mappings, page contexts and element IDs into a version-controlled manifest. Validate names and sizes before creating anything in GAM.

4. Connect the authorised API client

Enable the required access, complete OAuth or service-account setup as appropriate, and test read-only calls first. Confirm the network code and permissions. Then use a dry run to show exactly which objects would be created or changed.

5. Build GAM inventory and demand

Create or reconcile the ad units. Configure AdSense access at the appropriate level. Add reviewed direct and house campaigns, then confirm priorities, rates, goals, targeting, creatives and dates in GAM before release.

6. Implement GPT in the repository

Generate or write the GPT definitions from the same inventory contract, integrate slots into the real templates, and use Google’s Publisher Tag guidance as the delivery reference. Keep consent and privacy requirements in the request path.

7. Validate before publishing

Use GAM preview and delivery tools, browser testing and a staging environment where available. Test representative content at desktop, tablet and mobile widths. Check duplicate slot IDs, eligible sizes, empty-state behaviour, console errors, consent signals and layout stability.

8. Deploy and monitor

Release through the website’s existing deployment workflow, verify the live GPT requests and watch delivery reports. Compare requested impressions, matched impressions, viewability, CPM, revenue and direct-campaign pacing. Keep a rollback path for both code and configuration.

Will this increase advertising revenue?

It can create the conditions for better revenue, but changing the serving architecture does not guarantee an uplift. GAM does not make weak inventory valuable by itself, and routing the same AdSense demand through GAM does not magically create a higher-paying auction.

The potential gains come from better control and execution: more direct demand, fewer missed opportunities, accurate competition, responsive sizes that match real demand, improved viewability, cleaner reporting and faster operational work. Results still depend on audience location, advertiser demand, consent, content, traffic quality, policy status, seasonality and implementation.

I would establish a baseline before migration and annotate the launch date. Revenue per thousand sessions or page views can be more informative than CPM alone because a layout change may affect the number and viewability of impressions. Direct revenue, programmatic revenue, fill, viewability and reader-experience metrics should be reviewed together.

The objective is not “more ads at any cost.” It is a system in which suitable impressions can work harder, campaigns can be operated reliably, and the publisher can understand why an ad did—or did not—serve.

A controlled system, not an autonomous black box

The best use of Codex here is as a careful operator between a reviewed commercial plan and two complex technical surfaces. It can turn standard inventory definitions into GAM objects, turn those same definitions into GPT code, validate the relationship and help deploy the result. It can also make repeat work—new campaigns, revised sizes, fresh house creatives—far less manual.

But the publisher remains in charge. Google remains responsible for account approval and platform eligibility. GAM remains responsible for ad serving. The repository remains the source of truth for what the website actually requests. Human approval remains attached to money, access, policy and commercial promises.

That is the balance I want: automation where repetition creates errors, and judgement where the decisions create consequences.