Tracking Revenue – Amplitude

Once you begin sending revenue events to Amplitude, there are a few different configuration options which are outlined in this article.

Table of Contents

Sending Revenue Events

Tracking Non-In-App Purchases

IMPORTANT NOTE: Amplitude currently does not support currency conversion. All revenue data should be normalized to your currency of choice before being sent to Amplitude.

Sending Revenue Events

All Revenue events that send revenue as revenue properties will appear in the Revenue LTV chart (including both Verified and Unverified events). See the following documentation for more information on sending revenue events:

iOS SDK
Android SDK
Javascript SDK
HTTP API (set the price, quantity, and/or revenue fields to record the event as a revenue event)
Amplitude Developer

Tracking Non-In-App Purchases

Use our SDKs to call logRevenueV2.
Use our HTTP API to send a purchase event with revenue as one of its parameters.

Note: Verified revenue checks are only done for In-App Purchases.

Revenue Properties

We calculate revenue using price * quantity. Note: you should set these properties via the logRevenueV2 SDK function or by setting the price, quantity, or revenue fields in the HTTP API.

Name	Type	Description	Default
$revenue	Double	(optional) The total revenue of your user's purchase (can be negative). Note: required if you wish the Revenue event to appear in Revenue LTV	null
price	Double	(required) The price of the products purchased (can be negative). Note: revenue = quantity price*	null
productId	String	(optional) An identifier for the product (we recommend something like the Google Play Store product ID).	null
$quantity	Integer	(required) The quantity of products purchased. Defaults to one if not specified. Note: revenue = quantity price* (SDK only)	1
revenueType	String	(optional) The type of revenue (e.g. tax, refund, income).	null
eventProperties	Object	(optional) An object of event properties to include in the revenue event. Note: You will only be able to segment on these properties in the Event Segmentation chart.	null

Note that these properties must be explicitly sent by you via our SDKs or server-side when you log revenue events.

Tracking In-App Purchases (IAPs)

To track IAPs, you would send revenue events the same way you would send regular revenue events by using logRevenueV2 in our SDKs. The difference is that you have the option to validate your IAPs by passing in receipt data with the revenue event.

Verification

To enable revenue verification, copy your iTunes Connect In App Purchase Shared Secret or your Google Play License Public Key into the Settings section of your project in Amplitude. You must put a key for every single project in Amplitude where you want revenue verification. You will also need to pass in receipt data in order for the revenue event to be verified. See each SDK's verification documentation for more information:

There are three different types of revenue events in Amplitude that correspond to the logRevenue call within the SDK; they are separate from the revenue events sent server-side via HTTP API:

'[Amplitude] Revenue': This event will always be logged for revenue events, regardless if revenue verification is turned on or not. However, this event will not populate the '$revenue' property as the '[Amplitude] Revenue (Verified/Unverified)' events do so. Therefore if you wish for the event to appear in Revenue LTV, you must turn revenue verification on. If you have revenue verification turned on and only see an '[Amplitude] Revenue' event in the user activity stream with no corresponding '[Amplitude] Revenue (Verified/Unverified)' event, then this means that the revenue failed verification.
'[Amplitude] Revenue (Verified)': This verified event will be logged whenever there is a legitimate transaction. As a result, the difference between '[Amplitude] Revenue' and '[Amplitude] Revenue (Verified)' are the number of illegitimate app purchases being made. By default revenue events recorded on the SDKs appear in Amplitude dashboards as unverified revenue events. You will have to enable revenue verification in order to see '[Amplitude] Revenue (Verified)' events.
'[Amplitude] Revenue (Unverified)': Unverified revenue events do not mean the event failed verification. It means we did not attempt to verify it since it came through the HTTP API, Javascript SDK, or your project did not have any revenue verification keys inputted. If verification is not on, then this event will be logged for all revenue events.

Note: You can only turn on verification for mobile. Web will always track '[Amplitude] Revenue' and '[Amplitude] Revenue (Unverified)'.

We show any revenue that does not fail verification. This means you may see both '[Amplitude] Revenue (Verified)' and '[Amplitude] Revenue (Unverified)' if for example, you are sending both mobile and web revenue events through our SDKs.

Receipt Validation

We validate based on the receipt from Apple or Google. Here is more information on how Apple and Google verify receipts:

Discrepancies

The discrepancy between reports in the app store and Amplitude can be attributed to factors like time zone differences, event generation bugs, or even piracy.

If the discrepancy is minor and consistent on a day-to-day basis, then the likely cause is the difference in time zone reporting between the app store and Amplitude. Because Amplitude uses UTC, a purchase event uploaded on a certain day according to Amplitude may be reported by the app store as occurring on a different day if the app store is using a different time zone and vice versa. No data is being lost.

Major discrepancies can be the result of client-side errors such as the store purchase callback getting called multiple times for a single purchase. A good practice is to only call these events upon return from a successful store purchase. An example call, which tracks the event property and revenue amount, is:

AmplitudeClient.getInstance().logEvent('IAP', {type='Sale Special'})

AmplitudeClient.getInstance().logRevenueV2("com.company.productid", 1, 2.99)

Another cause for major discrepancies is piracy. A user can circumvent the app store and make purchases that do not show up in the app store reports. To avoid seeing pirated revenue events in your data, we recommend using our revenue verification way to track revenue events. If you suspect your data are being skewed heavily because of piracy, then please contact us here.

Considerations for Developers

Regarding tracking revenue events, there are a few things to take into consideration. Please feel free to check out the Amplitude Developer center for more details.

Backwards Compatibility: The existing logRevenue methods still work but are deprecated. Fields such as revenueType will be missing from events logged with the old methods, so the ability to segment on those revenue events will be limited in the Amplitude platform.
Opting User Out of Logging: You can turn off logging for a given user by calling setOptOut :

amplitude.getInstance().setOptOut(true);

No events will be saved or sent to the server while this is enabled. The opt out setting will persist across page loads. You can reenable logging by calling:

amplitude.getInstance().setOptOut(false);