3 ways to improve RTB results — Part 1
About Applift and basic RTB concepts
At Applift we are handling a simple problem to describe but complex to solve — finding the best users for our clients’ apps. In order to achieve this we are using several supply sources. One of them is RTB — Real Time Bidding.
An RTB solution is composed of Campaign Setup — Bidder — Creative — Requests.
Ad Requests — listening to millions of impression requests every second and providing information to the RTB platform about the ad request such as: Location, OS, device, in-app usage, and much more.
Campaign set up — includes all the information a campaign requires in order to run: Budget, targets (location, OS, etc.), placement whitelist, max bid price, app to advertise, etc.
Bidder — Takes into consideration all campaigns available and ad request information and decide in a few milliseconds which campaign to serve and what should be the bidding price.
Creative — Library of creatives including banner, videos, playable.
Companies can use one or more demand side platforms (DSPs) using RTB technology in order to run their campaigns.
The bidder challenge
A bidder is required to take a decision within a few milliseconds (between 100–300ms depends on the ssp). As such it is limited to the amount of data points it can consider as part of its model. Each DSP has its own algorithm for bidding and in many cases this is the secret sauce of a DSP. Consequently data points available to the algorithm cannot easily be added by the end user. Even if one has its own DSP, modifying a bidder algorithm is a slow process that involves many steps and engineers. This black box solution naturally limits the campaign managers ability to influence the success of their campaigns. So what other alternatives does a campaign manager have? As part of the tools available for campaign setup there is an entity called placements (apps with free ad space) whitelist. Ads will only be served to the placements that are listed in this whitelist for a campaign. Campaign managers use this functionality whenever their experience had given them insights into what placements work well with their advertiser’s app and have seen very good performance (conversions to impressions ratio). The question is now how can this be scaled and how can we get those “INSIGHTS”.
Approach 1 — Similar Apps
“I love puzzle games!” If you love puzzle games probably the best place to attract you with a new puzzle game will be while you play another puzzle game. Note: This approach is applicable to only some placements because some advertisers or publishers might be afraid of user churn by displaying a competitor’s app. But, assuming your advertiser’s app or supply source does not mind — here is what can be done.
The goal was to match apps that are similar to each other.
Step 1 — A good place to start is to just reuse the already existing matching engines before building the matching engine in house. Here, Google Play and the App Store provide app matching recommendations to the users. Simply get the stores recommendation for every app that we advertise for. To get the recommended apps for google play we built a simple scraper that would look out for specific keywords in the html page, store the findings in a MongoDB. The App Store provides an API however matching apps where not part of it so we had to scrape their website too. The results were interesting: Between 30–100% of the stores recommendations were not really a good match. At first we filtered manually those that are not similar but we wanted a fully automated solution.
Step 2 — To automate the secondary filtering, we checked the description of those apps and build a model that helped us to match the apps description against each other. The technical details and implementation will be discussed in part 2. This got us to 90–100% matching apps
Step 3 — Now that we had the text analytics model in hand we could check app matching based on all millions of apps in google play and app store. As this is quite a big set we have focused first on those apps (bundle ids and placement) we receive many requests from the different exchanges.
Approach 2 — Historical performance
A more general approach that was successfully used, was to understand which placement categories perform well for which advertiser category. For example, we had noticed that placement apps from education convert well when advertising puzzle apps and placement apps from adventure games convert well when advertising apps classified as action games.
To automate the process we had to do 2 things: a) Assign each app we had (placement and advertising apps) to a specific category and b) Find the well performing correlation between the categories.
First, we looked into historical data to find all those placements that had a very good conversion rate — that was easy. But to classify an app turned out to be tricky. We could have used the App Store or Google Play classification, but for several cases, the categories are defined too broadly, the assignment of apps was inaccurate and the classifications were inconsistent between the App Store and Google Play. To start scaling the process we eventually built our own classification model using the app description. We briefly describe our approach to the problem in part 2 of the blog.
Knowing which app belongs to which category, we now could do a simple lookup in order to populate the whitelist with all the apps belonging to the well performing category for the given advertisers app.
Approach 3 — User behavior
If we could only trace users behavior… but GDPR has its legal limitations. What we wanted to learn is what other apps users have installed on their phones to understand which set of apps are likely being used together. To get this information the App Store and Google Play provide user comments. The same user account leaving comments on different apps can be used as a signal showing that the apps are likely to be used together. Here aside of collecting this graph database stats and creating whitelist the development was quite straightforward.
Conclusion
Overall we have seen really amazing conversion rate of 0.2% between impression to installs using the similarity based whitelist.
One limitation to pay attention to is that a whitelist by definition reduces the amount of impressions that will be served over the campaigns lifetime since only a fraction of the ad space available is allowed to be targeted. In order to also sustain scale one needs to keep the whitelist as broad as possible and think about creative ways of extending it. Above we have mentioned only 3 approach but in our backlog we have quite a few more ideas on how to expand it. (spoiler: image recognition…)
The whitelist approach can be applied to any internal DSP, external DSP or Meta DSP (which is what we are using at Applift) without necessarily knowing what the bidder mechanism is.
Continue reading — Part 2
