Monetization through advertising is one of the leading models for generating income through a mobile app or any other mobile product. When you throw in advertising onto your product, you become a publisher. Any publisher’s goal is to maximize advertising revenue, but you cannot calculate your revenue unless you have accurate and fine-tuned analytics in place. This article will further explain what types of ad analytics exist, why the publisher needs to tally up events on their end, what kinds of events we process on iFunny and our other apps, and how we process them. Since FunCorp specializes in the development of mobile apps, we’ll mostly be talking about them in this piece, but the solutions discussed apply to web products just as well.
Better safe than sorry
An advertising SDK added to a mobile app comes with an integrated tool to send analytics to a partner’s server. Events sent from a client will vary depending on the integration model: waterfall, bidding auction, or direct.
Here are a few possible events:
- Bid request event
- Ad request event (bid and ad requests are merged with some SDKs)
- Impressions — by the load (rendered), by impression (shown), by viewing
- Ad click event
- Video watch event — impression start; first/middle/third quartile; complete; impression end card; end card clicks
Requests received from the client enable the partner’s server to calculate:
- Ad/bid requests
- The number or fill rate of responses/requests returned for bids and advertising
- Impressions
- View rates (impressions/responses)
- Impression revenue (Revenue, ARPU, ARPDAU)
- Clicks, CTRs (clicks/requests)
Why we should not trust this information alone:
- Advertising SDKs often come with integrated supplemental solutions for visibility checking and view tracking, such as MOAT, IAS, OM SDKs, or others, each with its nuances.
- Errors also occur in the partner’s SDK. Through testing, some mistakes can be revealed while others cannot.
- The events the partner’s admin will see are events that have made it to the partner’s server, have been correctly unpacked and apportioned in the databases. Errors occur every step of the way.
- If the data is collected in aggregation, then there will be a delay of several minutes to a day or more between the time the event is sent and when it is received at the partner’s databases.
- The partner and the user may be located in different time zones, in which case the data you receive will be different from what you expected.
- Not all the metrics that interest you are available in the partner’s interface.
Implementing in-house analytics will allow the publisher to validate the data received from the advertising platform, identify errors sooner and more accurately, and enhance the metrics at the publisher’s discretion.
Other analytics that could be tapped into:
- Analytics to monitor the mediator’s end when there is a mediator in the advertising procurement loop.
- Analytics to monitor a third-party solution to detect fraud, verify attribution, etc.
Events we send with iFunny
We had spent a long time optimizing the advertising event stream on iFunny before we arrived at the following configuration. What we send:
- Bid request events for each partner.
- Waterfall level or ad creative package load/request event.
- The completed reception of an ad banner event.
- Ad in view event.
- Revenue accrual event.
- Ad click event.
Let’s describe each event in detail —
Ad Requested (1), informing of a bid request
On iFunny, the acquisition of an ad banner starts with receiving the partners’ rates. Find more details on the ad acquisition process in this article.
The purpose of the bidding auction is to find the best deal fast. Rate requests go out concurrently. Then the advertising network will return its best value per viewing if one can be found. When the advertising network has returned a rate, the advertisement to which the rate applies will be obtained with a probability of approximately one.
The bid request event enables you to determine the fill rate and rate receipt speed for a specific network.
Parameters we work with:
- Name of the advertising network.
- Bid receipt result.
- Type of placement.
- Time elapsed before the bidder’s response.
- Additional flags.
The chart below shows the first part of the ad banner acquisition process.
Ad Requested (2), informing of a creative package request
Once the partners’ rates have been received, we go to the mediator. In response to our request, the mediator will return a set of levels organized by CPM rate — a waterfall. In our case, settings for a bid loading may also arrive with the waterfall. For that purpose, the mediator has sets of keywords and definitions presented in advance on their end.
The levels are then perused in sequence until an add banner is successfully received or until the waterfall ends. The app sends a request to the advertising network to receive an advertisement of the appropriate level. Each request like this brings its result, which we will save with the rest of our analytics. Another event enters the picture at this point: a new type of Ad Requested, informing of a creative package request.
The parameters we are interested in are the same. Furthermore, where the partner provides an API to identify a specific creative package, ad campaign, or domain, this information may expose irregularities. It is advisable to enrich your events with these identifiers right away.
Once the app starts requesting the mediator, analytics will begin migrating toward the mediator’s end. We use MoPub. A single MoPub request (/m/ad) will be followed by several waterfall level load events (/m/attempt). To clarify what attempts mean in MoPub terminology, please refer to MoPub documentation.
Ad Attempt
The process of obtaining an ad banner in the app ends once another level has been successfully loaded or a marker of the waterfall’s end has been received. At this point, the app will generate yet another event: Ad Attempt (not to be confused with MoPub attempts). This event is essential because it indicates how much time will elapse before the ad banner appears on the user’s screen.
Therefore, by the time the ad banner is ready to be shown, the following data will have been sent into the analytical systems:
- Bid request results: Ad Requested (1)
- Results of an attempt to load a creative package (or waterfall level) — Ad Requested (2)
- Events for loading waterfall levels to the mediator: /m/attempt
- Completed ad banner acquisition (waterfall’s end) event: Ad Attempt
The ad requests to the mediator and ad creative package requests to the advertising network are also accounted for as events on the mediator’s or partner’s end. Here is what the flow chart of this process looks like:
Ad Viewed
Once the ad banner has been received, the display may begin. The banner display event is called an impression. Surprisingly, a single ad banner may entail several impression type events. Depending on the API capabilities of the specific advertising SDK, the following may go out to the partner:
- Impression rendered: the banner is ready to be shown
- Impression shown: the banner has appeared on screen
- Impression viewable: the banner could have been shown to the user
The difference between the second and third events is that the Impression Viewable will be sent after that banner has stayed on the device viewport for a preset amount of time, usually one second.
Apart from the MRAID impressions, it may take dozens of pixels per impression. For example, when a showcase type banner loads to the web view, it could take a pixel per every item offered.
To keep things simple, we will send the impression event concurrently with banner display on-screen (Impression Shown) to our analytics as the other two impression types may be unavailable, depending on the SDK. We will register the network and the placement for this event.
An impression event for the corresponding ad-unit-a will also go out to the mediator.
Ad Revenue
When an ad is shown, we will immediately register the revenue for our analytics. The advertising SDKs connected via a bidding auction will send a CPM with the bid. For some non-bidding networks, methods can be determined for obtaining revenue from creative package response headings. Also, revenue can come from the mediator.
Ad Tapped
At the moment when a user clicks through the link on the in-view banner, events will be sent to the mediator and the partner. We will save this event to our analytics too.
Banner ads and native ads will not usually yield a high CTR on mobile apps. A significant change in this metric may indicate problems. For example, the script may contain the auto-opening function, or ad scrolling may be impeded.
Full process chart
The events described above constitute the entire process chart. This is a simplified presentation that takes no account of the fact that every interaction will, in reality, require a multitude of network requests, i.e., events. A reliable in-house analytical system will be your trusty guide in ascertaining partner metrics and revenue accounting and detecting irregularities and bugs in both the integrated SDKs and individual ad creative packages and companies.
Video events
Now, we’ll dive deeper into video advertising events because there are so many of them. Let’s take VAST as an example. VAST is a standard video ad serving protocol supported by most video players.
Description from the official documentation. See section: 2.2.5 VAST Tracking, 2.3.4.5 Tracking NonLinear Creative, and more.
We vigilantly monitor to ensure all VAST events get sent on video impressions, but this is where pitfalls come in droves. Why is that? Because the player sends out its events as well. The list of events the player may send will vary depending on the VAST iteration supported, the video file format, and other factors.
For example, here is a list of VAST 3.0 tracking events:
- creativeView
- Start
- firstQuartile
- thirdQuartile
- Mute
- Unmute
- Pause
- Rewind
- Resume
- Fullscreen
- exitFullscreen
- Expand
- Collapse
- acceptInvitation
- Close
- Progress: HH:MM:SS.mmm or a percentage value in the format n%.
There are also events such as Impression, ClickTracking, CompanionClickTracking, Error, etc. Moreover, these events are often replicated for different stakeholders. All these events have to be parsed, saved and sent just at the right time.
To find out the typical errors in video advertising, we have had to add a full breakdown of video reception errors. One of the more frequent mistakes in the absence of Impression tags. The standard requires the script to have an Impression tag as the cost per viewing is attributed based on impressions that have “hit the target.” However, it often transpires that the VAST script-writer will leave the tag empty, and so the publisher ends up with a discrepancy between their impressions and impressions sent to the partner. Here are some points to remember in this regard: VAST scripts can redirect up to 10 times from one server to another, which is to say that if you find no Impression tag in the very first script with the redirect tag VASTAdTagURI, this does not mean that this script had better not be shown. It would be equally wrong to check only the final script with the media files: there may not be any impressions there either, but impressions may be present at the preceding depth levels of VAST. It would be advisable to save them all to the same list, make sure they are not empty, validate if correct, and only add the video ad you have received.
It’s your decision whether to add VAST events to your in-house analytics, but detailed definitions of XML parsing errors, impression hit errors, etc., are highly recommended.
Summary
This article has described what types of ad analytics exist, which types the publisher is advised to add, and how to work with them. By collating the events in the partner’s and publisher’s analytics, it is possible to get a full picture of how well the advertising tools perform in your app, identify room for improvement, and keep suspicious advertising activity under control.
