Case Study - App Sales Tracking System

Concrete Software's System to Track Game Revenue and Other KPIs

Concrete Software developed an internal system to track revenue and other key performance indicators (KPIs) for its games. The system pulls daily analytics data from ad networks, app stores, and analytics systems, and generates reports from the data.

It handles common issues that occur during the data upload process, and has some advanced reporting capabilities, such as forecasting average revenue per user (ARPU).

Problem Statement

Tracking App Revenue and other Metrics

Concrete Software has several Android and iOS games, each of which have integrations with different ad networks, app stores, and analytics systems. We wanted a central way to track game revenue and other metrics such as ARPU, for the following purposes:

  • Data-Driven Decisions - From the daily reports, we needed the ability to determine if changes made to applications made a difference to the apps’ revenue and other KPIs, and to view those KPIs cumulatively across revenue channels.
  • Business Performance Management - We needed the ability to make high level budgeting decisions based on the total revenue being reported on our major revenue channels.
  • Ad Network Performance Analysis - We wanted the ability to view an ad network’s performance, and based on that to increase/decrease its usage within Concrete Software’s games.

We also needed the following system capabilities

  • Low Latency Reports - In a previous system implementation, the reports took a long time to generate. (multiple minutes in some cases) We needed better performance to make the analysis faster.
  • Fault Tolerant - We call 3rd party APIs to get the analytics data, and needed the ability for the system to handle errors from the APIs and perform needed retries, because the APIs could often be unreliable.
  • Maintainable - We wanted the system to mostly run on its own, without developers having to look into a lot of issues or frequently update parts of the system.

Solution Architecture

Microservice-based Sales System

Concrete Software's cloud services team designed and implemented a microservice-based sales system:

Under a Microservices approach, the system is broken up into multiple loosely coupled services, and each service serves a specific business purpose. The system has the following services:

  • Upload Manager - Manages analytics upload workflows, defined within Amazon SWF (Simple Workflow Service)
  • Product Service - Manages products and product mappings. Product mappings define how product IDs in an external system map to product information within our system. If unknown external product IDs are found, the following happens:
    1. The upload workflow is paused.
    2. The Product Service calls our CloudFace service to request product mapping info from employees. (by email)
    3. Eventually an employee submits a CloudFace form with the required product mapping information, and it’s saved to the Product Service’s database.
    4. The Product Service resumes the affected upload workflows.
    5. The upload workflows complete successfully and save the analytics data to the Redshift database.
  • Partner Service - Looks up metadata on Concrete Software’s partners and their revenue channels (app stores, ad networks, etc) out of its DynamoDB tables.
  • Sales Processor - Executes analytics upload workers for the requested SWF workflows. It handles analytics uploads in a robust way:
    • There are a lot of possibilities for errors when calling the partner analytics APIs. In most cases, the upload workflows will go through a series of automatic retries when an error occurs, and send a final error email if it is not able to resolve the issue in the end.
    • It downloads analytics files to an S3 bucket, so they don’t have to re-downloaded upon retry.
  • Sales Site - Contains a website interface for employees to work with the system. Employees use it for two main purposes:
    • View reports from the analytics data
    • Manage analytics uploads (view upload status and manually execute workflows)

The system also has the following advanced features

  • Ad Network Special Deal Handling - Sometimes our account managers setup special deals with ad networks, for example for Concrete Software to receive a minimum price per ad impression (eCPM) from the network for a period of time, and that deal is not reflected in their analytics data. We setup the ability to define these special deals within Partner Service’s metadata, so the minimum eCPM will be applied during analytics processing.
  • Product Mapping Smart Defaults - When requesting new product mappings from employees, it defaults the employee’s product choice based on past product mapping choices and product naming conventions.
  • Smart Email Notifications - Sends a single email on all daily analytics upload activities to business users, and detailed individual error notifications to system developers.
  • Outlier Detection - During analytics processing, it looks at past analytics values, and based on historical analysis, if a downloaded data point is outside the expected range, it reports a warning to business users and developers.
  • Advanced Reporting Features - The Sales Site’s reports are custom-built using Java Server Faces (JSF) and JFreeChart, and have the following features:
    • Several Dimensions Available - Revenue Channel, App, App Variation (app+store), Country, Ad Type, In App Purchase, In App Purchase Category, Revenue Type (In App Purchase, App Sales, or Ads), App Category
    • Several Metrics Available - Revenue, Ad Impressions, Ad Impressions Per User, eCPM (revenue per 1000 impressions), ARPDAU (Average Revenue Per Daily Active User), Ad Requests, Ad Clicks, Ad Views, Ad Views Per User, Ad Conversions, Sales Quantity, Sales Amount, New Users count, Active Users count, Sessions count, User retention rates, ARPU (forecasted revenue per user over 1 year)
    • Nested Drilldowns - For example, ability to select the PBA Bowling Challenge app, followed by the Google Play revenue channel, followed by the US country, followed by the Video Ad Type, and view any/all of the above metrics, filtering by the intersection of those values.
    • Missing Data Detection - Indicates if data from certain sources are missing data, and how recently they have been updated through, so users can know if the reports are complete.
      • If a user is viewing country-specific data and it’s missing the country-specific data but global data is available, we provide the ability to substitute estimated values from the global data.
    • Date Range Filtering and Comparison against Past Time Periods (comparison graphs)
    • Low Latency - The reports perform well because they query against an Amazon Redshift database, which has reasonable performance for complex queries of structured data.
      • The reports also minimize memory usage because of not needing to cache data on the Sales Site instance.

Project Outcomes

All solutions were implemented and work well
  • Updated analytics data is automatically imported into the system each morning. The system automatically works past most issues it encounters from the partner analytics APIs and sends a daily email to business users detailing the new uploaded data.
  • The reports generally take less than 5 seconds to render, and provide our account managers the information they need to manage Concrete Software’s games.
  • Business managers are able to view cumulative revenue data daily to be able to make high level company decisions around spending and other areas.
  • System developers have not needed to perform regular maintenance of the system. Most system changes have been for feature additions, such as Royalty Reports and Adjust Integration.

TCO Analysis Performed

  • All services are implemented in a way that use very little CPU power and memory, so we were able to implement services using low-cost t2.small EC2 instances and Lambda functions. The Lambda calls are infrequent, so the compute cost is low. The DynamoDB cost was not high because the calls to it are also infrequent. Otherwise, the main cost is the Redshift database.
  • We use AWS reservations for the Redshift database, DynamoDB read/write capacity, and EC2 instances to help reduce costs.

Find out More

Contact us to find out more about this case study and our cloud services team.

You can also email us directly at