eggheadgames / app_earnings Goto Github PK

Process Google Play, Amazon Android app store csv report files into a text json summary by application and in-app purchase.

License: MIT License

Ruby 100.00%

app_earnings's Introduction

app_earnings

Process App Store monthly "raw" CSV files into a report by Application and IAP. Currently supports Google Play and Amazon Android marketplace data.

Background

Egghead Games is an independent app developer who has to provide monthly royalties to various licensors based on sales. None of the existing tools like Distimo or App Annie provided data that was sufficiently accurate to make payments. The stores provide data files (usually CSV) with the raw data, but processing these by hand or spreadsheet is painful. This command utility takes the CSV files and outputs sales by app and in-app purchase within the app. It takes into account refunds and currency conversions, so that the amounts given should exactly correspond to the payments made by the app store.

Description

The Google Play and Amazon Android Marketplaces provide monthly earning reports in the form of CSV files.

This command line utility processes the transactions, groups them by app and in-app purchase (IAP), and produces the net dollar amount for each app. It includes the following features:

handles returns
provides sub-totals for IAPs, so you can see how much individual IAPs are earning.
uses Amazon exchange rates to ensure that all amounts are in your final currency
should handle non-USD Google Wallet accounts (though this is untested)
JSON output is available, to make further processing simpler

By default, it provides simple text output.

Installation

Install it yourself as:

$ gem install app_earnings

Usage

This will show the full set of current commands and options:

app_earnings help

Google Play Marketplace

To process a Google Play monthly earnings report csv file into a text sales report:

app_earnings play PlayApps_201401.csv

Alternatively, you can get a JSON version of the data with:

app_earnings play PlayApps_201401.csv --format json

Amazon Android Marketplace

To process Amazon monthly earnings report files into a text sales report:

app_earnings amazon EarningsReport-Jan-1-2014-Jan-31-2014.csv PaymentReport-Feb-1-2014-Mar-1-2014.csv

Note that the payment report must be for the month after, as Amazon payments happen a month in arrears.

Alternatively, you can get a JSON version of the data with:

app_earnings amazon EarningsReport-Jan-1-2014-Jan-31-2014.csv PaymentReport-Feb-1-2014-Mar-1-2014.csv --format json

Contributing

Fork it ( http://github.com/eggheadgames/app_earnings/fork )
Create your feature branch (git checkout -b my-new-feature)
Commit your changes (git commit -am 'Add some feature')
Push to the branch (git push origin my-new-feature)
Create new Pull Request

app_earnings's People

Contributors

Stargazers

Watchers

Forkers

domenicosolazzo rahul1n kalwant11 s7amb370 spitfire133 totokalag

app_earnings's Issues

Handle missing `Product id` and `Sku id` codes in Google reports

As of Feb/March 2017, Google Play Payment reports are missing the Product id and Sku id fields. This is only for lines where the sales report code starts with "GPA".

The lack of these fields makes generating Google Play reports either fail outright, or not attribute all sales correctly.

I've worked around this as follows:

Create a list of product ids & sku ids from a previous play report as follows:
a. install csvkit - https://csvkit.readthedocs.io/en/749/
b. run the following command on a previous play report file that has all possible products and skus:

grep -v GPA PlayApps_xxxxxx.csv | 
csvcut -c 7,8,10 | 
sort -u | 
grep -v "Product Title" | 
sed -e '1s/^/Product Title,Product id,Sku id\'$'\n/' >map-names.csv

Hack the source code of app_earnings/google_play/parse.rb so it reads as follows:

require 'csv'

module AppEarnings::GooglePlay
  # Converts a csv file to a hash.
  class Parser
    attr_accessor :file_name

    def initialize(file_name)
      load_fixup
      @file_name = file_name
    end

    def extract
      @extracted_data = []
      options = { headers: true, header_converters: :symbol }

      CSV.foreach(@file_name, options) do |row|
        hash_row = row.to_hash
        hash_row = do_fixup(hash_row) if hash_row[:product_id].nil?
        @extracted_data << hash_row
      end
      @extracted_data
    end

    def load_fixup
      @fixup_table = []
      options = { headers: true, header_converters: :symbol }

      CSV.foreach("map-names.csv", options) do |row|
        @fixup_table << row.to_hash
      end
    end

    def do_fixup(row)
      fix = @fixup_table.select {|f| f[:product_title] == row[:product_title]}[0]
      row[:product_id] = fix[:product_id]
      row[:sku_id] = fix[:sku_id]
      row
    end
  end
end

That's it.

Hopefully Google stop producing files like this. Otherwise, I'll make an effort to clean this up and merge it into the code in a more elegant fashion.

validate that Amazon Report and Payment file cover the same date ranges

Currently it's possible to run:

app_earnings amazon EarningsReport-Mar-1-2014-Mar-31-2014.csv PaymentReport-Mar-1-2014-April-4-2014.csv

And get ouput that seems plausible. However, there are no payments in the PaymentReport that match dates in the EarningsReport. Please fail with a message saying that the dates don't match (and what dates they are) as this is a point of frequent confusion. E.g. an error like:

Incompatible data ranges. The file EarningsReport-Mar-1-2014-Mar-31-2014.csv summary has dates from 3/1/2014,3/31/2014. The PaymentReport-Mar-1-2014-April-4-2014.csv has dates from 2/1/2014,2/28/2014.

This should be easy to detect using the Summary section of the Payment report.

Yoko

Earn money online app

Amazon refund amount not handled

In my latest EarningsReport, I have a refund amount in GBP, like this:

Amazon.co.uk,3/1/2014,3/31/2014,"1234",-2,99.99,GBP,(1.67),GBP,0.00,GBP,98.32,GBP

The final amount in my report is off by the exactly the amount of 1.67 GBP when converted at the exchange rate given in the corresponding PaymentReport. It appears that the refunds column is being ignored completely in this scenario and hence the total doesn't match at the end. (Interestingly, perhaps, there are 2 refunds mentioned in the report details, but again, perhaps they aren't being calculated? Not sure ...)