Forecasting in AdsAdvisor: calculating forecasts for mid-core games

Greetings from the AdsAdvisor team! In this series of articles, we’re sharing deeper insights into our service. In this first installment, we'll explore how our team addresses one of the key challenges in game development: building accurate forecasts. During the course of this discussion, we'll also differentiate between how forecasts are generated for Android and iOS platforms.

First some background: forecasts for in-app purchases (IAP) and advertising monetization are calculated using a similar approach: both models rely on installs and their associated payments. 

Notably, our forecasting model intentionally excludes in-game metrics, as these can vary widely across projects and influence forecasts in a different way. Instead, we adhere to the principle that "money predicts money."

How we calculate forecasts for Android

Let’s start by breaking down our process for performing Android forecasts for IAP and advertising monetization. To accurately compute forecast coefficients, we analyze a defined number of installs and purchases within specific cohorts. We categorize these cohorts by platform, traffic type, and country. (If a particular category lacks sufficient data, we merge it with a larger category to ensure robust analysis.)

The training data derives from a predetermined past period, the size and parameters of which can be adjusted during the integration and setup phase. For entirely new projects, we utilize whatever data is currently available. 

If desired, we can also apply coefficients from similar projects in the studio’s portfolio. Once the project accumulates enough of its own data, we transition to forecasting based on that tailored dataset.

Forecast coefficients are updated every two weeks and remain fixed for the following two weeks. Importantly, users gain access to updated coefficients one week before implementation, allowing time for analysis and adjustments.

We can also set coefficients at the client’s request, which may be necessary if the project undergoes significant changes in its internal mechanics.

Typically, we do not recalculate forecasts based on optimization types, though we can accommodate client requests. However, adding smaller sections can negatively impact accuracy, which is somewhat paradoxical. This happens because reducing the amount of training data for the section might diminish the accuracy gained from considering the optimization type.

Notably, when calculating forecasts, we only include complete days, which significantly stabilizes the forecast's behavior in the early days of each cohort's life. This approach helps eliminate systematic underestimation during those initial days, a crucial factor for decisions regarding scaling or reducing purchases.

How we calculate forecasts for iOS

With the introduction of iOS 14.5, Apple implemented significant changes to user attribution through the App Tracking Transparency (ATT) framework. Prior to this update, developers could use the IDFA (Identifier for Advertisers) to track users unless they had manually disabled it, resulting in nearly 100% attribution coverage.

Now, each application must request user permission for tracking, necessitating consent in both the device settings and within the app itself. If either condition is not met, attribution is lost, and statistics default to organic traffic for Self Report Network (SRN) channels, as probabilistic or similar attribution methods are unavailable. Consequently, the permission rate has plummeted to around 30-40% of total installations.

Currently, the methods of attribution are distributed as follows:

• Google, Facebook, TikTok on iOS: SKAN attribution.
• Unity, Applovin, Iron Source (amongst others on iOS): probabilistic attribution.

We refer to our forecasts for iOS traffic as "smart forecasts." These are derived by redistributing basic forecasts (for consent traffic) in proportion to the Conversion Value obtained from SKAdNetwork.

Our forecasting process begins with calculating estimates for probabilistic sources, followed by organic traffic, which is modeled separately, and concludes with SRN sources.

However, smart forecasts come with limitations! Since SKAdNetwork attribution does not provide country-specific information, smart metrics should be analyzed at the placement and campaign levels rather than by country.

For SRN sources, the primary attribution tool is the SKAN framework. There are specific nuances in calculating SKAN metrics; by default, the encoding typically reflects the dollars spent in the first 24 hours.

Unfortunately, this can lead to a significant underestimation of payments from high-spending players, or "whales." To address this issue, we now offer our clients a customized scheme developed using an ML clustering model, assisting with both calculations and implementation.

Let’s finish up with a recap: the forecasting for mid-core games in AdsAdvisor is grounded in comprehensive analysis of user and payment data, segmented by key indicators such as country and traffic type.

As we’ve seen here, our methodologies differ for Android and iOS: Android forecasts rely on robust data volumes and internal analyses, while iOS employs a flexible smart forecasting approach that accounts for the limitations of SKAdNetwork attribution. This dual methodology enables more accurate revenue predictions, even amidst constrained information.

Ultimately, these insights assist in optimizing traffic purchases and making informed decisions regarding project scaling! Thanks for reading, and stay tuned!