Many of our posts have focused on re-engagement strategy, but we’d like to take a look at the nuts and bolts of what makes app re-engagement and in-app advertising actually work. To help us with this, we spoke to our supply side platform (SSP) partners at BidMachine to give us some insights on how their SSP works, what they specialize in, and how they envision the future of in-app advertising.
The first aspect that differentiates BidMachine’s inventory from most players in the market is that our inventory is 100% in-app. We focus entirely on the in-app vertical, both on iOS and Android. Secondly, we are very proud of the fact that more than 95% of our traffic is SDK-based. The flow is very straightforward: SDK > BidMachine > Demand Partner. Our goal is to have 100% SDK traffic by the end of this year.
We work with a worldwide audience, but we do have a strong core that includes countries such as the US, Germany, Canada, the UK, Russia, Brazil, France, Australia, Italy, Japan, South Korea, India, and Indonesia.
In terms of ad formats, we cover all standard mediation in-app ad types: small banners, MREC, full-screen banners, playable ads, native, video interstitials, and rewarded videos.
The main criteria we have is whether a publisher can follow the flow I mentioned before — SDK > BidMachine > Demand Partner. We strive for less intermediaries and want to ensure the inventory is as close to our demand partners as possible and that there will be little to no reduction in the end revenue the publisher sees. To give this visibility to our demand partners, we require publishers to be compliant with app-ads.txt.
After the publisher is onboarded and integrated, we have a dedicated fraud team investigating suspicious app stats and behaviors and thoroughly checking all apps. We check for COPPA apps to see whether there are incentivized placements or real money being offered in the app, which we do not allow. We also make sure there are no ad placements that lead to forced clicks or actions. We check whether apps have obscene content, and whether they comply with the CCPA and GDPR regulations when applicable.
We support both first and second-price models in our inventory. Until the end of 2019, there wasn’t any difference—both models had pretty much the same access to the inventory. We were improving our auction logic this year to reduce requests that are not important for DSPs and to improve their performance. But first-price auction participants ended up having access to more unique users at a reduced QPS, which enabled more users to be visible and decreased server costs for our partners.
Slowly but surely, first-price auctions are changing the future of the app industry, bringing more transparency to publishers about how much their traffic is worth and increasing competition between buyers. This is good for publishers but not necessarily the best scenario for the buyer side.
Quite a few DSPs are still struggling (some even resisting) with the shift from second to first-price models. Because their bidding/buying algorithms are not ready for a “pure” first-price auction as there is no floor price passed in the request. Second price algorithms are pretty mature for DSPs and they tend to be very precise when it comes to how much they should pay for a specific user. With first price models they need to start almost from scratch. The open support and push from big platforms in our industry towards the first price model is definitely something that will accelerate the transition.
Our advice for the transition to first price would be to build a bidding/buying algorithm that doesn’t rely on price floors in the request and the buyer can bid exactly how much they are willing to pay for the impression (or at least with that step already planned). There won’t be any base floor prices once the full shift from the traditional waterfall model to a bidding model takes place.
Yes, our sales team is always going after new publishers to onboard to our platform. We have a few big publishers going through the integration process right now, and soon we will share more details about that with our partners.
At the moment, we are working on making it easier for publishers to integrate our SDK and developing automation tools for a more efficient set-up.
If publishers feel like they want to get more out of programmatic, we also give publishers an opportunity to acquire their own exchange by leveraging BidMachine technology and existing relationships with demand partners, through a SaaS model.
We see trends that are continuing to evolve, e.g. increased privacy of mobile users. Both Apple and Google now give more control to users with how and when their information is shared across the ad ecosystem. It will surely lead to a different way of tracking (or assuming) events within an app, and at the same time, it might shed more light on contextual advertising.
There is a continuous shift from second price to first-price auctions as buyers update their bidder logic and get more confident in buying traffic that way. Publishers continue to strive for more transparency and control when it comes to ways the traffic is bought in their apps. Demand buyers are more concerned about the traffic origin and how far away they are from the actual source (app-ads.txt, sellers.json).
Also, more transparency does not necessarily mean less hops in the supply chain: indeed, the way companies approach the SPO (Supply Path Optimization) is slightly changing. The original goal of the SPO was to eliminate unnecessary intermediaries by uncovering them all. However, the process of automatically eliminating them regardless of the benefit they can bring to advertisers or demand partners was, perhaps, not thought through. The benefits may include aggregating high-quality inventory, providing advanced metrics and custom information, giving access to more unique users, etc.
As we are a technology/engineering-focused company, it didn’t have a huge impact on how we work. We were ready to add the required parameters to our requests. The most difficult part was educating publishers since not all of them understood how GDPR would affect their revenue.
In the beginning, we were only giving publishers guidelines on how to create their own consent window but now we have a fully-fledged consent management platform that can be used by publishers.
Another non-tech-related aspect of it was registering as an official IAB vendor for Framework 1.1. And now we are doing the same when the Framework 2.0 goes live.
If the client uses our own CMP, we make sure they are compliant and collect consent correctly. If they do not, we make sure that once the consent is given, we pass it along the supply chain. If it is not given, we act accordingly and don’t collect and pass their information to our partners, abiding by GDPR guidelines.
Yes, we give the publisher the possibility of using our own CMP. We also have guides on how they should implement their consent windows if they don’t want to use our consent management platform. Our team is always ready to help the publishers.
We have a few solutions being investigated at the moment by our engineering and legal teams to understand how exactly we can help our demand partners, who are sometimes highly dependent on device IDs in their purchase logic. The immediate impact we expect not only for us but also for the in-app environment as a whole is a decrease in spend and revenue for publishers if the vast majority of users opt-out to share their unique identifiers.
Thanks to the team at BidMachine for taking the time to talk with us!
What's a day in the life of a DSP like? Read our Q&A with BidMachine now!
How have Adikteev's re-engagement strategies helped clients to meet their goals? Read our case studies to learn more!