1 .Set up in-app analytics

You need to be able to deep dive into user behaviour within your app. For example, if you have a game, how many users are reaching Level 10, how many seconds do they play on the first day, what features are not helpful to customers, and why are they churning? Most MMP companies focus on attribution and don’t offer such in-depth in-app analytics. I have seen customers implement this with their own custom systems like Tableau dashboards in which they own the data stack. Alternatively, you can use a SaaS like GameAnalytics, MixPanel, or our solutions.

2. Set up attribution for performance marketing

As an app creator, you might use performance marketing to buy users for your apps or games. However, you need to know how those guys are performing and if they are performing because of your marketing efforts or the product you built. To do this, you need to connect the in-app analytics you set up in the previous step with your performance marketing data, gathered by marketing attribution technology.  There are several things to take into account before you reach out to a performance marketing network that will advertise for you - like Meta, Google, and the smaller players.

Create Cohorts

Cohorts are a great way to measure how the users you brought in one month compared to the users you bought in the previous month. When you cluster user groups based on install timeframe and user lifetime into cohorts, you can easily compare how they perform after seven days, after 30 days, etc. This will help you measure KPIs, like retention, how many users come back, how much revenue those users have generated, or how many play seconds they have in the total.  You don’t need externally-generated device IDs to cluster users into cohorts or daily views as your backend can easily generate your own user IDs during installation this will allow you to identify particular user behaviour.

But for other forms of tracking, an external device ID is useful. 

Mobile User Tracking based on Device Ids

Why device IDs were useful

There are a few reasons why Device IDs were helpful or why they were used in the past. 

• Identify the source of an app installation on a user level. For example, when a user clicks on a banner ad, the advertisement network that is responsible for the banner sends a device ID to the platform responsible for attribution e.g. the MMP. When the user later installs the app, the attribution software collects the device ID and matches it to the advertising history of the user with the same device ID. This allows the attribution software to tell you which user saw what ad and how their conversion happened.
• Easy retargeting. As a company, you can look at the collective list of Device IDs of site app visitors and see which users are doing a lot of shopping and ordering food. You can then arrange for an ad to be shown to the user with that Device ID to bring them back to your app.
• Better Targeting. You can target users better by using the information you already know about them to present the right advertisement for them on an external site. This was a feature that those who used Meta’s advertising services benefited from. Meta - as a social network - has strong user profile data- they know how old each user is, their location, etc… They then used that data to create technology that powered advertising in third-party apps. By the way, if Meta shows ads inside third-party app inventory most of the users are not aware that Meta is responsible, because they are working in the background. This meant that if your company used Meta’s advertising services, Meta would show the right ads for the targeted user based on their interests. In order to utilize the same targeting options featured in Meta’s own app in other apps, Meta depended on Device Identifiers to display an ad targeting a particular audience (e.g. people that have a university degree) inside a third-party mobile app. 

How companies adapted to the iOS update that removed access to device IDs

Meta can still access the device Id on Android devices but 2 years ago Apple’s iOS killed the use of Device IDs for advertising. Suddenly, the method used by Facebook Ads didn’t work as well on iOS.  Since then the industry has adapted so they can not continue with behaviour targeting, which harms Meta’s eCPMs (how much money is earned with one ad impression). For example, Apple has introduced a new technology (SKAN (StoreKit Ad Network, or SKAdNetwork)) to allow attribution, but in an anonymised way. 

Fingerprinting

A common way to attribute users on the user level is by fingerprinting. A fingerprint is a hash that encapsulates many things about the user’s device and browser, and in the age of non-existing device IDs, they were thought of to be a more unique identifier than just an IP address. Attribution companies use fingerprints to match the user that clicked on the ad to the user that installed the app. They can also re-identify users that are using a web browser and a mobile app too. 

Challenges with Potential Fraud Attempts with Fingerprinting

There are a few problems with this fingerprinting-based attribution:1) Fingerprinting-based attribution does not lead to unique results and the accuracy is not always given. 2) It’s harming user privacy concerns. 

Interestingly is that Apple introduced the SKadnetwork attribution framework to increase user data protection after removing the device Id, but the concept of fingerprinting user-based attribution is mainly still working.  The question is for how long, because with the launch of global VPN services from Apple and Google, this method will no longer work as easily. 

So how can you know that the click you are paying for belongs to a real user and can be attributed to a potential app install? Uber had this problem when they paid for app installs that didn’t actually happen.

This method of ad fraud is called click injection, in which a third party fires off many requests and then ends up trying to steal the attribution of the original ad.

These fraud attack methods were a big problem 4-5 years ago, but now the industry has adapted. Apple for example suggests you use their Skadnetwork solution they offer in their attribution model and for Android, Google has developed a technique to prevent it by providing a bunch of sophisticated timestamps to identify fraudulent clicks.  For example when a click happens and a user is redirected to the play store and clicks on the INSTALL button, but then in between somebody sends a second click the play store services on the device provide two different timestamps. They do this by giving the publisher or the tracking company a timestamp of when the user opens the Play Store and another one for the click on the INSTALL button. Based on this, the company can combine the two timestamps with the ad click timestamp which means fraudsters do not have the option to send a second click in between and manipulate the valid attribution. This means that click spamming, which was common five years ago, no longer works that way. 

A word on advertising fraud

In the digital industry, wherever somebody can earn money, there will always be fraud. That's also what the big companies are facing. That's what the smaller ones are facing. As much as the industry has adapted to prevent fraud, there are studies still saying that ad spend fraud exists at the rate of 15-20% so this is still somehow happening, but I think it's getting much smarter. So it's not like there's a stupid script that just executes clicks. I think they have some device farms which are real devices that are not manipulated, and then maybe the scale is a little bit different, but still, still can trick the system somehow if they want.

I think you have to really dedicate resources to prevent advertising fraud. Even as a small publisher, you should take a look at the users you have brought by advertising so you can figure out what's going on. I would really recommend that you employ people skilled in this field.

3. Monetize 

There are two ways to earn money  - in-app purchases (virtual items or subscriptions)  or advertising revenue. For the purpose of this article, we will be talking about ad-based revenue. 

Most of the big mobile games with lots of traffic are monetized by digital advertising like mobile ads. To do this, you need to set up a complex tech stack to make that happen in a profitable and good way. Here are some insights:

What are popular in-game advertising options?

The main formats that are shown in games are interstitial video, rewarded video, and display banner advertisements.

Interstitial advertisement 

Interstitial advertisements are full-screen video ads that run for 20-30 seconds at certain points in the game. Usually, users have to watch these for 10 seconds before they can click them away. Interstitial advertisements have to be shown at natural transition points - not randomly - in accordance with Google’s new Play Store rules.

Rewarded Video advertisement

A rewarded video is when the user is offered a reward for watching an ad. Sometimes games present it as: either you can pay to get this virtual item that you need to progress OR you can watch this video and get this item as a reward. Rewarded video differs from interstitial ads in that the user is rewarded for watching the video and you can’t cancel it in between. 

Display banner advertisement

 A display banner displays an ad at the bottom of the screen during play. 

How to choose an ad network partner

There are many advertising networks you can partner with - from big ones like Google and Meta to mid-size companies who are also doing wonderful work. The way the mobile advertising industry was set up 5-10 years ago is that each advertising network has its own SDK. This means if you want to benefit from, let's say, 10 great advertising network companies with good demand (advertisers that book inventory), you need to integrate all those 10 different SDKs which is rather challenging. Furthermore, how do you know, at any given time, which SDK to use for the highest CPM (revenue for the ads) and which network to use? You used to have to do that manually by writing rules that decided on which network to use based on what worked well in the past. Thankfully mediation platforms have emerged to help make choosing the right network SDK for an impression on the fly. 

What are Mediation Platforms 

 A mediation platform is a software company that helps you prioritise which ad network SDK to use inside your game based on historical data or real-time auctions.  For example, they might compare the eCPM (effective cost per mille - how much revenue an app publisher earns for one-thousandth impression displayed on the network) of one advertising network in the US to another and use it to prioritise which networks ‘win’ advertising impressions. This was quite groundbreaking when it launched 5-6 years ago but there are a few problems with that. 

Why auction-based bidding works best for app publishers

The old way of assigning a network based on eCPM has several drawbacks

• They use historical data - It is silly for mediation platforms to use historical data because maybe today you have better quality users and they have higher CPMs on one SDK network now. 
• It is often not a user-level decision - Sometimes you have certain information about a particular user that would make them a more attractive target for advertisers who would be prepared to pay a higher price. The desktop programmatic world was always deciding on the user level, but it was not the case in mobile.

What is Auction-logic

Auction logic or bidding logic is when every ad impression is auctioned off in real-time and the network with the highest bid wins the impression and can load its own mobile SDK to show the ad. The auction logic that decides which SDKs to show in the end is similar to its counterpart in the desktop programmatic world. Since it was introduced ~4 years ago, this bidding logic has become increasingly popular and many mediation platforms now use it. 

Why the future will be bidding-only.

I think this entire solution to decide which ad impression wins based on historical data and not on real-time prices that are paid for the auction or for the impression is really bad for the publishers. Using that  (eCPM and historical data) means the ad networks are getting more money and not the publisher itself. That's the reason why I think that in the future everything will go in the bidding-only direction because then the competition on the inventory is really fair. Publishers will be able to decide which ad impression they sell to. It can be automatically done by the system as there is an auction in place in real-time that lets the highest price win the impression. Besides, the management overhead for publishers is heavily reduced with a bidding-only solution.

The hybrid data-based and auction-based solution. 

Now as a publisher you can set it up so you have a bidding source (real-time bid for each impression) or non-bidding source (using eCPM which is based on historical performance) competing for the impression.  But this is easier said than done. It costs a lot of overhead to integrate both bidding sources - deciding which option to place where and how it should change over time. On top of that, it is not really accurate.

How we built our own Mediation Platform

Last year, we created our own layer to mediate which ad network wins the impression. We did it because we owned a lot of inventory of games and apps and we were never able to sell those video ad impressions to external advertisers - most impressions went to Google and Facebook. We realised that there was a weird situation in the market where only those companies were earning money and there was no transparency on how the basic auction logic works.  We decided to build mediation software in a more transparent way so that every publisher that uses it can know the reason why a particular impression was won by a particular network by focusing on the bidding-only approach. By doing so we believe that we can provide a solution to publishers that increases their revenues. 

The stack we used in our mediation layer

There are 2 parts to the process: the demand side (holding the auction) and the supply side (rendering the ads).

Demand-side - OpenRTB handles the auction When you demand an ad to serve as an impression, it is the auction lawyer's logic who decides who wins the impression - we do this by using OpenRTB.  OpenRTB, founded by IAB, is a popular protocol that integrates with Google and other big players. But it was only introduced on the mobile side 3-4 years ago when bidding became popular so the typical ad networking logic with SDKs was not built with it in mind so it’s not an end-to-end solution for mobile. 

Supply-Side - Rendering the ad - the Network SDK Ad network logic still uses the network SDK to render the ads in the end, even if the auction is held via OpenRTB I think a reason behind this is that the big ad networks don't want to change that because it gives a little bit of power away, because they want to keep all control for rendering the ads. If we could use OpenRTB for both handling the demand and the rendering,  it would basically bring everybody on eye level, which may be not every player in the industry likes.

Conclusion: In this blog post we discussed what goes into scaling & monetizing a mobile app or game - from setting up your analytics (both for in-app user behaviour and attribution)  to monetization.