Did your ads even run?

While everyone else is distracted by supply chain transparency studies, scary MFA sites, and reducing carbon footprint of their media buying, there's something more basic and easy to look for that will save you money and make your digital campaigns more effective.

Did your ads serve?

Are you surprised by the question? Did you assume that all the billions of ad impressions you paid for actually ran -- i.e. arrived in the device and got rendered on screen? If you've studied ad fraud as long as I have (11 years) you will remember cases like the Uber lawsuit where they discovered that the mobile exchanges committing fraud had fabricated all the log level data, without actually running any ads. Surprised? Don't be. That's what fraudsters do.

How do you check for this yourself?

Years ago, I advised clients to simply compare the quantities of ad impressions reported by their DSP (ad buying platform) to the quantities reported by their ad server. Most of you will remember the 2 slides below, where the drop-offs between bids won, ads served, and ads displayed add up to 1/4 to 1/3 of the total. Advertisers pay when they win the bids. There's no guarantee that the ads successfully got served by the ad server. And further, there's no guarantee that the ad arrived in the device in time and got rendered on screen. So ad buyers regularly get LESS than what they paid for, sometimes 1/4 to 1/3 less.

My clients regularly check this -- their DSP quantities vs their ad server quantities. If these match closely (i.e. with less than 10% discrepancy) that's a good thing. The four campaign examples below show discrepancies in the 2 - 3% range.

Did your ads get displayed on screen?

The FouAnalytics in-ad tag is set to asynchronous. That means it fires after the ad renders on screen. That makes it a good proxy for the number of ad impressions that made it in time and got rendered on screen. In the second slide above, you will note that even though most of the ads got served, there was a much larger drop-off between ads served and ads displayed. This often happens in mobile environments where bandwidth is lower and devices have less powerful processors. Even if the ad gets served by the ad server, it may not arrive in time and get rendered on screen in time for a user to see it. You may have experienced yourself when scrolling webpages on your smartphone that there are some ad slots marked [Ad] that are empty. Those are waiting for the programmatic bidding and ad serving process to complete so some ad gets served into the ad slot. You are not going to wait for the ad to appear, you usually just keep scrolling. The unnecessarily convoluted and complex process of real time bidding ads seconds of delay, which means ads may never arrive in time to be seen.

In the 4 data grids above, you can see the "ad-didnt-run:1" parameter in yellow highlight. FouAnalytics in-ad measurement shows you what percentage of your ads didn't arrive in time to be displayed on screen -- 3%, 8%, 9.9%, 15%.

What about log level data and viewability vendors' numbers?

So glad you asked. Log level data tells you where your ads were SUPPOSED to go, not where your ad ACTUALLY went. This is because the log level data from the DSP takes the domain that was passed in the bid request and records that. It does not run a postbid javascript tag to measure where (site or mobile app) the ad actually went. Similarly, the ad server does not run a post-ad-serving javascript tag to detect and record where the ad actually went. Advertisers using a FouAnalytics in-ad tag will actually get to see where their ad went, and the count of ads that made it in time to be rendered on screen. To reiterate, log level data does not show you 1) the percentage of ads that actually displayed on screen, or 2) where the ads actually went.

What about the high viewability numbers reported by the MRC-accredited viewability vendors you pay for? Good question. I don't know how they arrive at viewability percentages from 70 - 90% when 25 - 33% of ads never even got served, and 5 - 15% of ads never arrived in time to be displayed on screen. You should ask them to show you how they got those numbers. Perhaps an even more basic question to ask them is how many ad impressions they actually measured with a javascript tag. These same vendors are reporting IVT ("invalid traffic") in the 1% range, when they didn't measure 9 in 10 ads with a javascript tag. They assume that what they didn't measure has no fraud. That is not a good assumption, right? Perhaps they assume what they didn't measure is viewable too? And remember the case of publishers falsifying the viewability measurements to be 100% viewable 100% of the time. [2018] Newsweek Media Group Websites Ran Malicious Code to Falsify Viewability Measurements

If you've stuck with me this far, here's one last pro-tip for you. I have heard feedback that legacy verification vendors are telling their customers that javascript tags are not necessary for fraud or viewability detection. That's a lie. If you don't run a javascript tag to collect information from the browser, there's no reliable way to measure viewability, bots, or fraud. I won't even get into how bad their tech is when actually allowed to run. The issue at hand here is whether they even measured the ad with a javascript tag. A static image pixel (.gif) does nothing but count the impression when loaded. A javascript tag is necessary for any data collection from the browser and the site or mobile app where the ad ran. You can't do viewability or fraud measurement without it.

So what?

Ask for DSP and ad server reports, so you can compare quantities during the same time period. Those quantities should be 1-to-1 but any single-digit discrepancies are common, acceptable. Run a FouAnalytics in-ad tag to get the third quantity -- what percentage of ads actually made it to the device and got rendered on-screen. Obviously the viewability measurements you've been paying for all along missed these basic things. Remember an ad can't be viewable if it wasn't served in the first place, or didn't arrive in the device in time.

Happy Saturday, Y'all!

Further reading: https://www.dhirubhai.net/today/author/augustinefou