Review this article to identify causes for revenue disparity between Swrve and other services. You can identify many causes for revenue differences by comparing the details in the Swrve service with the revenue totals seen in your mobile app store.

You can investigate many revenue differences by reviewing the data received for a specific device. Add your device as a QA device and make a purchase. The item purchased and all purchase details should be displayed on the QA User Logging screen.

Buy In events

Buy_in events don’t have receipt verification as the purchase receipt is not a parameter sent to Swrve. This means that Swrve is essentially a bean counter for revenue, with no validation on in-app purchases. If revenue is much higher than what is accounted for in iTunes Connect or Google Play, this could mean users are having their invalid or cheater purchases counted in Swrve. If server-side receipt verification is in place, and revenue is still high, you may want to double-check that purchases are not being sent multiple times from your server.

Recommendations

• Instrument the IAP event with receipt verification to stop Swrve from receiving false revenue. For more information, see the platform-specific integration guide.
• If a server-side implementation is in place, establish receipt verification before sending Swrve revenue, or send receipts with an IAP event.

No receipts or incorrect receipts

Another sure sign of revenue issues is if only valid_iap events display on the Events report under Swrve. Typically, an invalid_iap event is sent to Swrve when an IAP event is sent for a fake purchase. Swrve marks a purchase as invalid when there is an invalid receipt received. However, similar to the buy_in event, if Swrve doesn’t receive the receipt as a parameter for this event, all revenue for IAP events is counted in KPI reports.

Incorrect receipts can also cause a rejection of the purchase. On recent iOS versions, the receipt is expected to be the transactionReceipt from SKPaymentTransaction, which is base64 encoded.
On Google, the parameters receipt and receipt_signature are expected. These parameters are returned in the intent from Google in IN_APP_PURCHASE_DATA and INAPP_DATA_SIGNATURE respectively.  An example Google receipt is given below:

"receipt": "{"orderId":"GPA.xxxx-xxxx-xxxx-xxxx",
             "packageName":"com.test.packagename",
             "productId":"product-id",
             "purchaseTime":1448276750398,
             "purchaseState":0,
             "developerPayload":"extra",
             "purchaseToken":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}",

Ensure that your team instruments the IAP event with the receipt from Apple or Google. For more information, see the platform-specific integration guide.

A common mistake is to encode the Google receipt—it is expected in JSON format.

When inspecting the purchase on the QA User Logging screen, ensure it was not made through “UNKNOWN_STORE”. If it was, this indicates that purchases are being sent using the unvalidated iap() method rather than the iapPlay() method. These purchases would automatically be counted as valid. We do not recommend sending unvalidated IAP events unless you have already checked the purchase on your side.

IAP versus purchase events

A common mistake is to send purchase events instead of IAP events. Ensure that you are sending the correct type of event for the purchase.

IAP events — sales for real money

If your app has in-app purchases, send the IAP event when a user purchases something with real money, such as virtual currency bundles for a game, virtual items or unlocked functionality. Sending IAP events populates the Top Items report, Item Charts report and revenue KPIs in the Trend reports and on the KPI Metrics dashboard.

Purchase events — sales for virtual currency

If your app has a virtual economy, send the purchase event when a user purchases in-app items with virtual currency, such as gold, coins or gems. Sending purchase events populates the Top Items and Item Charts reports. These are useful for quickly identifying which items are selling across your inventory. When instrumenting purchase information, specify one of your in-app currencies in the currency parameter.

Virtual currencies

A virtual currency must be added in Swrve before receiving IAP purchases for it. Add currencies on the App Settings screen, in the App Currencies section. You need to add these currencies to both your sandbox and production dashboards.

View the device logs on the QA User Logging screen while making a purchase. If IAP events are displayed on the QA User Logging screen, Swrve has successfully received the IAP event. To see the details of the purchase, select Show Raw Event under the IAP event .

Google Server key and iTunes bundle ID

When validating revenue, Swrve uses the Google Server Key and iTunes Bundle ID to verify revenue. Check that these are correct for the app on the Integration Settings screen.

Exchange rates

Exchange rates between platforms can be updated at different times. Swrve updates these exchange rates periodically, but this interval can be different between platforms.

Exchange rates can account for 1-5% differences in total revenue at any time, but if differences are more drastic, consider alternative causes.

Apples to apples

If you’re comparing net revenue from Apple or Google, ensure that the correct multiplier is set in Swrve’s reporting settings. For Apple and Google app stores, net revenue is 0.7x. Therefore, the multiplier set in Swrve must be 0.7 for revenue charts to display net revenue. Otherwise, you are comparing gross revenue to Swrve’s revenue numbers. For more information about configuring the reporting multiplier, see How do I configure how revenue is reported?

Units sold

While revenue can be too high due to cheater purchases, it can also be too low if the correct purchase details are not sent to Swrve. For example, if the amount of item purchases displayed in the Top Items report doesn’t add up to what you’re seeing in Units Sold in your app store, Swrve may not be receiving all of the purchases. Review the Top Items report for incorrect quantities being sent.

In many circumstances this is due to one or more of the following:

• An app version into which Swrve is not integrated. On the Analytics menu, select User attributes and select the App version user attribute to see which versions have been received by Swrve.
• The app is not sending purchase events for all purchases that have been made.
• The app or server is sending duplicate IAP events to Swrve.
• The server is not sending the purchase event to Swrve. In some instances, the purchase event is simply not sent to Swrve either from the client or a server. On the Events report, under Swrve, examine the IAP event to make sure Swrve is receiving traffic for this event.
• Incorrect IAP event parameters. Review the parameters of the IAP event in the Events API documentation. Have your development team review logs and use the built-in QA functionality to see the parameters being sent and received.
• General event or URL errors. All apps using the Swrve SDKs use the batch event, reducing network requests and traffic by combining many events into one request. If there is an error in any event parameter, however, the batch of events is rejected by Swrve. This rejected batch can sometimes include IAP events. Examine your error logs to see any rejected batch requests, or 404 errors for incorrect URLs (correct URLS are detailed in the Events API guide).

Compare units sold on the Top Items report on a daily basis. If the units sold match, but the revenue does not, the prices being sent to Swrve are incorrect. If the amount of a particular item is very low, investigate buying this item by reviewing the QA User Logging screen while making a purchase of this item. An IAP event should be displayed when the item is bought. If not, this purchase is not properly instrumented.

If the units sold in Swrve are higher than in iTunes Connect, Swrve is receiving false revenue. Review the platform-specific integration guide for information on removing cheater revenue.

Total revenue over time

It can be useful to examine revenue figures over a longer period of time. Review the total revenue over time by downloading a week’s worth of revenue by means of a Trend report. Is the revenue now closer to that displayed in iTunes Connect or Google Console?

To track down revenue disparities you can also investigate:

• Returns for Google Play and iTunes. For example, Apple’s Summary Sales Report includes returns in its totals. Swrve does not receive return data. Apple states the recommended refund rate should not exceed 0.1% of sales. For many apps this number is much higher.
• Date of payment processed. For Swrve, this is the exact day/time of occurrence. App stores can even include this revenue on different days.
• Consider what factors changed around that time period. Was a new app version released? Was the app launched in a new market? Check with Swrve that a new currency is supported.
• Minor calculation differences on purchase events sent to Swrve, such as currency exchange and rounding.
• Taking the above points into consideration (and recognizing the amount of real units sold on a daily, weekly, or monthly basis) can help narrow down the chief cause of the revenue disparity.
• Swrve data is based on the timezone that was set in the dashboard. The timezone may differ from other revenue sources.

Subscription revenue

If subscriptions are a primary revenue source, these weekly, monthly or annual subscriptions should be checked regularly and IAP events should be sent to Swrve when the user renews their subscription. Without this, revenue would be low due to missing subscriber revenue. If revenue looks accurate early on, but becomes inaccurate without any app updates, talk to your development team to make sure this situation is properly handled.

Conclusion

If you still have questions after reviewing the above details in your app, please contact support@swrve.com.

To perform a thorough investigation of the issue, Swrve’s support team needs to know:

• If the issue relates to a particular product.
• The exact dates that are affected.
• The true units sold for that specific time period.