Top 5 Reasons You Can't Bid on Traffic in a White-Label DSP
While marketing gurus equate automation software to magic, we want to keep things straight. Automated media buying, DSPs, and programmatic are not a panacea from ad fraud, high CPMs, and ineffective bidding. Like any other tool, they need a capable hand to set good defaults and make tech work for your business and not against.
This is the 1st day of your white-label DSP trial. You wake up, turn on your PC, check out the list of a carefully prepared list of SSP connections, and proceed to set up their endpoints. After the bulk of work is done, you move on to creating your test ad campaign to ensure this software will work for you.
So, you estimate budget and flight dates, adjust targeting options, upload creative, and press on a "launch" button. That's a basic setup of a programmatic campaign we got used to in a self-serve DSP, so now everything should work perfectly.
In the next couple of hours, you impatiently check out real-time reports to see the first results. In the evening, you are surprised to find that your analytics tab is... empty. The DSP simply doesn't bid on impressions, and the programmatic request is continuously declined.
We have some clients that encountered this issue, and in most cases, it doesn't mean that anything is wrong with the software or your account. Moreover, the problem can be even not on your side. We gathered TOP-5 reasons why it happens and how you can handle it by the end of today. Let's make your DSP bid again!
Keep reading or watch Dmitry Chebatkov, Product Owner at Epom DSP, revealing the most common reasons why a DSP doesn't bid and what you can do about it.
Basics of RTB Auction Bidding on Traffic
Any advertiser that decided to bring their programmatic in-house has to learn the basics of an auction dynamics from the tech side. As an owner of a white-label RTB platform, you are now on your own in terms of managing your supply partners. To do this properly, you need to understand each step of the ad serving process, including the ones made on the seller's side.
So, here is what's happening every 100 milliseconds while the RTB auction is triggered.
- The user visits the website.
- An ad tag or header wrapper makes the browser send a bid (ad) request to the supply-side platform. Or several SSPs, if the publisher uses many.
- An SSP then uses an endpoint to deliver the programmatic request to the DSPs it's connected to and asks for a bid response. It also indicates which auction it's going to run: 1st-price or 2nd-price.
- A DSP collects bids from all advertisers connected to it (in case of a self-serve one). In the case of a white-label, your bid will compete with bids received from other DSPs connected to a certain SSP.
- Once bids are collected, a DSP sends a bid response to SSPs.
- An SSP then runs an auction, where the highest bidder wins. Depending on the type auction, an SSP pays the highest price or the 2nd price + $0.01 to the publisher.
- Then the tag/bidder triggers the ad impression on the website.
It might be hard to grasp what bid response, bid request, impression beacon, and some other concepts I acknowledge represent. Now I'm going to dwell on each of the essential stages of the RTB auction dynamics.
Essential Elements of RTB Auction Dynamics Explained
A paragraph before, I also mentioned the fifth one: the code that makes the whole auction happen. It can be an ad tag, a header bidder, or an SDK in case of in-app advertising. We dedicated an entire article to each of them, follow the links below, and give them a good read.
Once the ad tag or whatever else triggers the RTB auction, we're dealing with a bid (ad, programmatic) request.
What is a Bid Request?
A bid request is a chunk of code sent to the DSP using an SSP endpoint, which you might have already set up. It contains data necessary for the advertiser to bid on a specific inventory. Thus, the bid request usually comes with information about a website, ad placement, device, bid requirements such as price floor, and user data required for precise targeting.
DSPs whose advertisers are interested in the audience this certain user belongs to receive the bid request and automatically place their bids according to their campaign settings defined before. The DSP selects the winner among all bidders and sends a bid response to the SSP.
What is a Bid Response?
A bid response is a string of code similar to the programmatic bid request, but the one that a DSP sends to an SSP while all advertisers place their bids on a certain inventory slot. It contains data regarding the creative type, size, ad format, other ad attributes along with bid price and website domain or app ID.
What is an RTB Auction Win?
Win in an RTB auction means the fact that inventory sale happens, and the advertiser who placed the highest bid will serve the ad. This advertiser receives a win notification, and the ad markup occurs.
What is an Ad Impression?
The number of ad impressions shows the number of times an ad was displayed to the user. It's the most common metric to assess the scope of an ad campaign and calculate its effectiveness by comparing it to ad clicks and other engagements. Each impression is tracked with the impression beacon, a pixel that sends data back to the RTB platform.
Each side embeds its beacons to track impressions. Thus, the final code of the creative usually contains two or three pixels generated by a DSP, an SSP, and an ad server.
Coming back to the question of why you can't bid on the traffic in a white-label DSP, the brief answer is that there is an error in one of these codes. Let's find out which one of the common reasons could be yours and fine-tune your auction bidding strategy.
Reason #1: An SSP Can't Pass a Bid Request — Wrong SSP Endpoint Setup
Every RTB platform is different in terms of the supported version of the oRTB protocol, impression beacon type, trace output type, and bid response requirements. If you launched a test campaign and found out that none of your bids are won, the first thing to check out is the SSP endpoint you set up in the Endpoint Manager.
First, cross-reference these values with parameters provided to you by your supply partner. If everything matches, send templates of your typical bid responses to the SSP and check out whether they accept responses of that type. Make sure their bid request corresponds with your DSP's requirements.
While your test ad campaign is running, monitor analytics and cross-check impression statistics in your reports and reports of your partner's SSP. Make sure there are no substantial discrepancies in analytics.
Reason #2: Mismatch Between Your Targeting and SSP Traffic
Every SSP is different in terms of traffic type as well. Some of them have only video desktop traffic
available; others work with publishers who offer audiences located in, let's say, the USA and Canada, and
the rest of them may be connected only to specific categories of websites, for example, international news.
Now, imagine that you have all these three SSPs connected to your white-label DSP (or RTB bidder). Yet, you need to run an in-app display campaign targeted at the users from Germany who visit websites that belong to car-related categories. Do you think your DSP will bid on that traffic in this case?
For sure, it won't. You won't receive any impressions on your ads because they won't meet specifications your supply partner sends in their programmatic request. They want you to show ads relevant to American users that read the news on desktop, and not to the audience you bid on. Such misalignment in targeting options and actual traffic leads to SSP's inability to deliver relevant impressions.
How to deal with this? Launching a new campaign, choose SSPs that can provide you with traffic that matches your targeting preferences.
An important thing to know: not all DSPs assign category tags to their publisher's inventory. If the SSP you pick today doesn't do that, just bid on all categories at a time.
Reason #3: Bid Response Was Rejected Due to Strict Max Limits
Each SSP sets a time max limitation for bid responses received from DSPs. A DSP needs to fit into this
timeframe while sending its bid response, otherwise it won't be accepted. As a result, you won't bid on SSPs
traffic and won't win any impressions.
What causes latency in bid responses? The issue number one is that some SSPs set harsh limitations, so it becomes hard to fit in their timeframe if your DSP's servers are located on the other side of the planet. For example, Epom servers were initially located in the USA, and it could cause some latency while sending bid responses to the DSP with strict limits located in Europe like Bidswitch.
If you work with such SSPs and your servers are far away from their servers, the only way to handle this is to establish new servers in another location. If you own a white-label DSP, talk to your software provider.
Reason #4: Bid Price is Too Low to Beat the Competition
This reason is the most trivial one. Here, you technically bid on ad space, but don't get any impressions because the bid price is too low, and your competition easily beats you. The average CPM needed to win an impression in an RTB auction varies depending on an SSP and the type of traffic it provides. So generally, you'll need to test different CPMs and see which one will work for this particular ad campaign.
Reason #5: Impression Beacon Didn't Count an Ad Impression
We've come to the errors on the latest stage of auction dynamics. Most likely, your impression beacon
doesn't work correctly and hasn't reported that the impression happened.
This occurs when page load is not completed and the user closes the page too soon. An SSP sends you a bid request, you send a bid response, the impression is won, but the ad server doesn't have time to place the ad within the proper inventory slot, so the impression doesn't occur.
Another reason is discrepancies between several impression beacons. Not only your DSP tracks impressions: an SSP that provides inventory and an ad server that shows the ads on the page also need their own beacons to trace the number of impressions. An ad tag usually contains the ad server's beacon, then it is wrapped into DSP's container with its own impression beacon, and lastly, an SSP adds the final layer to this code by embedding its own pixel.
Any small error in this multilayered code can cause a fatal discrepancy, when your impressions will only be counted in an SSP, but not in a DSP, and vice versa.
The third and the last case is when you use other ad serving platforms aside from a white-label DSP, where you generate your JS invocation code. Some of our clients use both Epom ad server and Epom DSP, so they usually don't upload an image in a DSP, but use an ad tag instead.
The problem? If you run ad campaigns in an ad serving platform with the same code, there are usually certain limits for impressions served per day. These limits apply to all campaigns that use this invocation code, so if the limit in an ad server is exhausted, your RTB platform can't serve any more impressions as well. Check this out while embedding your code in a DSP and increase the number of daily impressions or turn off the campaign in an ad server.
How to Make Your DSP Bid Again: Brief Checklist
Summarizing everything said above, here is a checklist of what you should look at if you notice that your RTB bidder doesn't work properly:
- SSP Endpoint Setup. Make sure that your DSP receives a bid request with all required data.
- Targeting Options. Align your traffic preferences with the type of traffic provided by an SSP.
- iAB Category. Some SSPs don't pass category data with their bid request. Keep that in mind while adjusting your targeting.
- Time Max Limits. Check out if your bid response arrives at an SSP within a designated time frame. If not, consider choosing another SSP or replace servers.
- Bid Price. Test several CPMs to determine which price to set for this particular traffic source to bid higher than your competition.
- Impression Beacon. See if your impression beacon reports impressions and how this data correlated with your supply partner's data.
- Creative Limits. If you use other ad serving platforms, make sure your daily limits are not exceeded.
As you can see, the errors can be not only on your side, but also on the side of your DSP provider or supply partner. To minimize the chance of these errors, choose a responsible software provider and monitor all stages of your RTB auction dynamics while setting up the ad campaign with entirely new settings.
Looking for a reliable real-time bidding solution with 99% uptime, ongoing maintenance, and prompt bug fixes? Consider testing Epom white-label DSP.Try Epom DSP