“Data-Driven Thinking” is written by members of the media community and contains fresh ideas on the digital revolution in media.
Today’s column is written by Marc Goldberg, CRO at Method Media Intelligence.
Can prebid cure all that ails you? In a word … no.
The RTB protocols were put into place so that sellers and buyers could “talk” to each other about the details of an auction. Sellers, of course, want buyers to see what they have to sell. All of this happens in milliseconds and data is provided in the bid request to help with the decision.
The codes
The reasons behind why a buyer wins or doesn’t win an auction can vary widely. The RTB protocols provide lists of signals as to why a bid was not offered for an impression. This is the 5.24 section in the specifications, which are publicly available.
If a publisher didn’t receive a bid, the buyer could communicate back with the no-bid codes that translates to something along the lines of, “You didn’t get our money because your prices were not in line with our bid strategy.” These codes help sellers learn and optimize.
But codes do more than only indicate when an auction didn’t receive a bid. There are also loss codes that help to explain why a bid was lost for the buyer.
The following table is a list of the potential reasons an exchange can give as to why a bidder didn’t win an impression. (See Section 5.25, “loss reason codes,” OpenRTB Spec v2.5.)
Taken together, the intent of these codes is to ensure that market dynamics are informed by a feedback loop that helps to create a robust and healthier marketplace.
If you look at no-bid code 6, for example, which is related to an “unsupported device,” this is a situation in which a seller sent information to the auction using the wrong format. Perhaps it was mobile inventory for a desktop request. Having received the code, publishers can troubleshoot and see if everything is correctly set up.
No-bid codes 4 and 5 are “suspected non-human traffic,” while code 5 refers to “cloud data center or proxy IP.” Again, the intent of the code is to enable sellers to understand why their impressions are not filling.
So, if a reputable seller received a notification that its traffic was suspected to be non-human traffic, that publisher would ideally dig in to better understand what’s going on. How is this happening to me?
But what if a malicious seller receives code 4 or 5? Then, it’s, “Damn, they caught me – guess it’s time to switch IP addresses or traffic vendors.”
IP addresses
Is it that easy, though, to switch IP addresses? Why, yes it is. Just Google it or watch this video. You can even buy IP proxies by category. I’m not making this stuff up.
Real screen grab from a traffic seller that will remain nameless, because who wants to drive real traffic there?
The traffic vendors that exist in the underbelly of the internet hang out in plain sight. Again, Google it, or look through our collection of posts on LinkedIn, all offering “traffic” for sale.
If we take a step back, it’s fair to say that using IP addresses as proxies to detect invalid activity has worked for your search campaigns in the past two decades.
Consider the user experience. A user from IP address 123.456.789 searches for something and then clicks on a link once. If that same IP address clicks on the same link several times, you’d identify that it as suspicious activity. You’d conclude that this user is not an actual person but rather a bot because multiple clicks on the same link is not what a real user would do.
But consider this: if an IP address is suspected of bad behavior, that decision is made after the suspicious activity already transpired. The IP address is identified as malicious and it is placed on a list. This is beneficial to search engines, because it helps them protect their advertisers from invalid activity. Search advertisers generally run more DR and performance-type campaigns with defined KPIs that are tied to a specific outcome, like a sale.
The IP address approach can, indeed, help detect this suspicious activity for searches – but the display user experience is quite different.
User behavior varies on publisher pages. If a user visits a news site and consumes one page to see a sports score, followed by maybe 10 pages in a gallery and then the consumption of three or four articles, that person is a highly desirable news junkie.
Multiple clicks from one IP address is plausible, which makes detecting suspicious activity not as reliable for display if you’re just relying on IP. Someone that clicks on 20 pages would be deemed invalid – even though that is the most coveted user.
Prebid “protection”
That’s why the list-based approach works for auctions. Auctions are fast and response codes don’t disrupt the bidding process. But prebid IVT protection is not only reliant on bidstream data, such as IP address and user agent lists, but is also limited to IP addresses and UA lists.
Limited means that vendors are all playing with the same information. Nothing in a prebid solution is proprietary. And reliance should be concerning to anyone reading this, because limited information is not reliable.
Returning to our hypothetical news junkie example, loss code 5 has identified a bad IP. For the “bad guys” the losses are temporary and a nuisance, while for the buyers that win is only temporary and provides a false sense of security. IP address 123.456.789 is now on the list, but a bad guy will be running the same game from IP address 987.654.321, or whatever, tomorrow. Once caught, a bad actor simply repeats the cycle using the endless supply of IP addresses available.
There is a lot of misconception about what Prebid IVT protection can do.
Buy-side vendors are not looking for mouse movement. They are limited to what is available in the auction. A user’s behavior is not at all close to the speed of an auction, and therefore prebid detection can’t perform more than basic block and tackling on static lists, such as IP and user agent.
In a prebid environment, a mouse movement would destroy the exchange mechanics, which is why it’s not available to use. Loss code 2 (“impression opportunity expired”), demonstrates this. Again, an auction is fast, which is why the rules are based on being able to serve auctions at scale.
The reality is, no prebid solution on its own is effective. So, what are you getting when you pay for it?
The shame in this game is that most DSPs offer a free solution, which makes third-party verification seem redundant since it’s based on all of the same bidstream signals.
If you’re reluctant to trust your DSP and you need a “trusted” third party, don’t pay for a prebid solution. This is where you need to complement prebid with a postbid solution.
Prebid IVT is ripe for the taking and let’s be clear, people are taking. Don’t get me wrong, prebid does catch some IVT and, when coupled with a postbid solution, you will see your invalid traffic issues markedly improved.
But while these flaws still exist, you need to go in with your eyes open.
Follow Marc Goldberg (@MarcJGoldberg) and AdExchanger (@adexchanger) on Twitter.
