Viewing Sample Update to LTV Reports Request & Response

Jump to: Update | Parameter Changes | New LTV Report Parameters | Endpoint Example | Example Output | API Reference

Update

TUNE has deployed a new system for LTV reports. This new system is several times faster and far more accurate than the previous system.

Currently, the database for the old system is not being consistently updated. Using the new endpoint is a matter of converting the old queries to the new.

Previously, there were two endpoints: one for click reports and another for install reports:

https://api.mobileapptracking.com/v2/advertiser/stats/ltv/click/find.json
https://api.mobileapptracking.com/v2/advertiser/stats/ltv/install/find.json

Now there is a single endpoint for both click reports and install reports:

https://api.mobileapptracking.com/v2/advertiser/stats/ltv/find.json

Parameter Changes

Nearly all the parameters used with the old endpoint will work with the new with these minor changes:

Endpoint Example

The transformation for this old endpoint:

https://api.mobileapptracking.com/v2/advertiser/stats/ltv/install/find.json?
&fields%5B%5D=publisher_id
&fields%5B%5D=rpi
&fields%5B%5D=currency_code
&filter=((site_id+%3D+'532')+AND+(test_profile_id%3D0+OR+test_profile_id+IS+NULL))
&sort=rpi+desc
&group%5B%5D=publisher_id
&start_date=2014-08-01
&end_date=2014-08-31
&response_timezone=America%2FLos_Angeles
&interval=day
&cohort_type=install
&cohort_values=cumulative
&api_key=YOUR_API_KEY_HERE

Renders this new query:

https://api.mobileapptracking.com/v2/advertiser/stats/ltv/find.json?
&fields%5B%5D=publisher_id
&fields%5B%5D=rpi
&fields%5B%5D=currency_code
&filter=((site_id+%3D+'532')+AND+(test_profile_id%3D0+OR+test_profile_id+IS+NULL))
&sort=rpi+desc
&group%5B%5D=publisher_id
&start_date=2014-08-01
&end_date=2014-08-31
&response_timezone=America%2FLos_Angeles
&interval=year_day
&cohort_type=install
&aggregation_type=cumulative
&api_key=YOUR_API_KEY_HERE

Example Output

The output for the call has also been adjusted to be more sensible. Rather than separating aggregate values into their own interval lists, single interval list per grouping contains all aggregates in each interval. Non-aggregate fields are now contained in a single meta object that comes after the interval list.

An example of old output:

{
  status_code: 200,
  response_size: "26012",
  data: [
      {
        site_id: 35852,
        publisher_id: 21384,
        test_profile_id: 0,
        cpi: "1.000000000",
        rpi: "1.972901769",
        currency_code: "USD",
        site: {
          name: "MAT Android App"
        },
        publisher: {
          name: "MAT Publisher"
        },
        cpi_interval: {
          1: {
            interval: "1",
            value: "1.000000000"
          },
          2: {
            interval: "2",
            value: "2.000000000"
          },
          ... more intervals ...
        }
        rpi_interval: {
          1: {
            interval: "1",
            value: "0.010000000"
          },
          2: {
            interval: "2",
            value: "0.340000000"
          },
            ... more intervals ...
      }
    }
  ]
}

Compared to the new:

{
  status_code: 200,
  response_size: "6031",
  data: [
    {
      data: [
        {
          cpi: 1.00,
          rpi: 0.01
        },
        {
          cpi: 2.00,
          rpi: 0.34
        },
      ... more intervals ...
      meta: {
        cpi: 1.00,
        currency_code: "USD",
        publisher_id: 21384,
        rpi: 1.97,
        site_id: 35852,
        publisher: {
          name: "MAT Publisher"
        },
        site: {
          name: "MAT Android App"
        }
      }
    ]
  }
]
}

API Reference

/advertiser/stats/ltv/find.json