Back

The Cost of Bad Ad Tech Integration for Publishers

AdTech

• 7 min read

A reader opens an article. Somewhere between the headline and the second paragraph, an auction takes place, software chooses an advertisement, and several companies acquire an opinion about what just happened.

The reader would like to read the article.

These ambitions can coexist. Getting them to coexist reliably is a substantial part of publisher engineering.

An ad opportunity has a short working life. The page needs to request it, buyers need time to respond, and the winning creative needs to appear while someone is still there to see it. Afterwards, the systems involved need to produce numbers that the publisher can explain.

A problem at any of those handoffs can affect revenue. It can also leave an ad ops team spending Tuesday establishing what happened on Monday.

To understand the cost of bad ad tech integration, follow one ad through the page.

First, the page has to get its timing right

An article can appear promptly while its advertising is still getting organised. Page speed and ad delivery speed are related, but they are not interchangeable.

In a poorly coordinated setup, the reader may reach an empty slot before the auction has finished. Elsewhere on the same page, an ad may load so far below the reader that it never comes into view. Both deserve investigation, although they call for different fixes.

The temptation is to load everything immediately. That gives distant ad slots work to do while the content someone actually came for competes for resources.

Google’s publisher guidance recommends prioritising ads likely to be visible first and using lazy loading for those farther down the page. Lazy loading defers work until a slot approaches the visible area. The timing still needs testing: start too late and the reader arrives before the creative does; start unnecessarily early and much of the benefit disappears. [1]

Measure the journey from the start of the page visit through the auction to the rendered ad. Split the results by device and page template. A desktop average will offer very little comfort to someone waiting on a phone.

The useful finding is specific: a particular template, on a particular device, consistently starts its auction late. That gives engineering something to fix and ad ops something to verify.

Then the auction has to know when to stop

Header bidding allows multiple demand partners to compete for inventory before the ad server makes its decision. More competition can be valuable. Waiting indefinitely for it cannot.

Timeouts put a limit on that wait. Prebid distinguishes between the auction timeout, which limits how long bidders have to respond, and a broader failsafe that lets the page proceed if Prebid fails to load or encounters a serious problem. [2]

Setting those limits involves a tradeoff. A shorter window may exclude valuable bids. A longer one may delay delivery. The right setting depends on the audience and implementation; copying another publisher’s number is a starting hypothesis, at best.

The same applies to choosing partners. Two supply-side platforms reaching some of the same buyers does not, by itself, mean the publisher pays two fees on one impression. Overlapping demand is a reason to examine their contribution, rather than an automatic instruction to remove one.

Test what happens when a partner is added or removed. Look at net revenue alongside response times and rendering performance. A partner’s own revenue total cannot tell you how much of that money another partner would have earned in its absence.

Every partner can bring a presentation explaining its importance. A controlled test is a useful addition to the meeting.

Winning is followed by the small matter of being seen

A successful auction does not establish that the ad became viewable.

Google’s Active View reporting makes the distinction explicit: an ad below the visible area can count as an impression even if the reader never scrolls down to it. Viewability measures a different event. [3]

Nor does a non-viewable impression automatically mean no payment. The billing arrangement matters. Google Ad Manager supports viewable CPM campaigns whose delivery goals and rates are based specifically on viewable impressions. Treating every campaign as though it works that way confuses the diagnosis. [4]

For a publisher, the practical work begins at slot level. Check whether the creative arrives in time, where the slot sits, and how the page behaves around it. Avoid treating one site-wide viewability percentage as a complete explanation.

Layout deserves particular attention. When an ad appears in space that was never reserved for it, the surrounding article can move. Google recommends reserving appropriate space to reduce these shifts. [5]

Anyone who has lost their place halfway through a sentence already understands the reader’s objection.

The commercial response should be measured too. Before adding more inventory, test whether the existing placements can work better. Consider revenue per session alongside viewability and reading behaviour. An additional slot may earn money of its own while changing the performance of the rest of the page.

Counting its earnings alone leaves half the experiment unexamined.

Eventually, somebody has to explain the numbers

By the reporting stage, one page visit has become several different records.

The auction system has bid responses. The ad server has delivery figures. Viewability measurement describes which eligible impressions met its criteria. Partner reports may apply their own fees and adjustments.

Some differences are expected. Different time zones, reporting delays or gross-versus-net definitions can make two legitimate totals disagree. A shared dashboard will display that disagreement very neatly unless somebody first resolves the definitions.

For a recurring discrepancy, establish which events each system counts and when it records them. Compare the same period, currency and inventory. Document where fees enter the calculation and which report governs settlement.

This is also where integration work acquires a human cost. If someone must reconcile the same unexplained difference every week, that work belongs in the assessment of the system. So does the delay it creates when a team needs to decide whether a change helped.

A useful reporting pipeline preserves enough detail to investigate a result. It lets people connect a revenue movement to a release, a partner or a page template, rather than beginning another round of spreadsheet archaeology.

Start with a failure you can actually observe

An underperforming ad stack does not automatically require a replacement. It requires a diagnosis detailed enough to justify the next decision.

Choose a commercially important template and examine it on the devices readers actually use. Follow the ad from request through rendering and measurement, then into the revenue report. Note where the sequence breaks down and what evidence is missing.

That produces a manageable piece of work. Perhaps the auction starts late on mobile. Perhaps an ad slot moves when the creative arrives. Perhaps the apparent revenue decline is a reporting mismatch that nobody has documented.

Fix the identified problem and compare the result against a control where practical. Check the commercial outcome and the effect on the page. Keep a way to reverse the change.

Then give the relevant measures an owner. Decide what should trigger an investigation after future releases. A fix that depends on one person remembering to check a dashboard has an unusually fragile maintenance plan.

The engineering is part of the revenue model

Publisher revenue depends partly on whether an ad opportunity survives the journey through the systems intended to sell it. Each handoff deserves the same attention as the individual tools.

At Lerpal, our work in publishing infrastructure brings us to those connections: how the CMS shapes the page, how advertising loads within it, and how the resulting data supports the next decision.

For an ad tech integration review, we would start with a page and a traceable problem. Establish where the opportunity is being lost, agree on what improvement would look like, and test the change.

The reader should be able to finish the article. The publisher should be able to explain what it earned along the way.

Talk to Lerpal about your publishing infrastructure.