The Scheduled Data Export integration is available on the [Pro](🔗) plan.
RevenueCat can automatically send data deliveries of all of your apps' transaction data to various cloud storage providers. These are in the form of [gzip compressed](🔗) .csv files delivered daily.
# Setup Instructions
[Amazon S3 Setup ](🔗)
[Google Cloud Storage Setup ](🔗)
# Version Change Log
[Data Export Version 4](🔗) (Latest)
[Data Export Version 3](🔗)
# Transaction Format
_Applicable to the latest version_
All dates and times are provided in UTC.
|Header||Description||Type||Example value||Can be null|
|`||Can be used as a unique user identifier to find all of a user's transactions.||string||`|||
|`||Can be used together with `||string||`|||
|`||Store country of a transaction when known, or an IP-based estimate of a subscriber's country when not known.||string||`||✅|
|`||The product identifier that was purchased.||string||`|||
|`||The display name of the product identifier if one has been set||string||`||✅|
|`||The standard duration of the product if one is known by RevenueCat. May be null if RevenueCat does not know the authoritative duration.
|`||Purchase time of transaction.||datetime||`|||
|`||Expected expiration time of subscription. Null when `||datetime||`||✅|
|`||Expiration time of a grace period (if applicable) for a subscription. Will remain set while a subscription is in its grace period, or if it exited its grace period without renewing. Null when a subscription is not in a grace period or expiration was not due to a grace period.||datetime||`||✅|
|`||Single reference point of a subscriber’s expiration and entitlement revocation; inclusive of each store’s logic for cancellations, grace periods, etc.||datetime||`||✅|
|`||The source of the transaction. Can be `||string||`|||
|`||The revenue (converted to USD) generated from the transaction after accounting for full and partial refunds. Can be null if product prices haven't been collected from the user's device.||float||`||✅|
|`||The gross revenue (converted to USD) generated from the transaction. Remains set for refunded transactions. Can be null if product prices haven't been collected from the user's device.||float||`||✅|
|`||[DEPRECATED] The estimated percentage of the transaction price that will be paid out to developers after commissions, but before VAT and DST taxes are taken into account. (will be either 0.7 or 0.85)
We recommend using `||float||`|||
|`||The portion of a transaction’s price that will be deducted by the store for taxes. VAT & Digital Services Taxes may be withheld by stores depending on the store and country. To learn more about how RevenueCat estimates taxes, [click here](🔗).||float||`|||
|`||The portion of a transaction’s price that will be detected by the store for commission. In stores where taxes are deducted before commission, this value will not equal the published commission from a store, because that commission is calculated on the post-tax revenue.||float||`|||
|`||orderId or transaction_identifier. **Can be used as unique id**.||string||`|||
|`||orderId of first purchase or `||string||`|||
|`||When a refund was detected, `||datetime||`||✅|
|`||When we detected an unsubscribe (opt-out of auto renew).||datetime||`||✅|
|`||When we detected billing issues, `||datetime||`||✅|
|`||The currency that was used for the transaction.||string||`||✅|
|`||The revenue (in the purchased currency) generated from the transaction after accounting for full and partial refunds. Can be null if product prices haven't been collected from the user's device.||float||`||✅|
|`||The gross revenue (in the purchased currency) generated from the transaction. Remains set for refunded transactions. Can be null if product prices haven't been collected from the user's device.||float||`||✅|
|`||An array of entitlements that the transaction unlocked or `||string array||`||✅|
|`||Always starts at 1. Trial conversions are counted as renewals. `||integer||`|||
|`||The offering presented to users.||string||`||✅|
|`||Will be `||string||`||✅|
|`||The [reserved subscriber attributes](🔗) set for the subscriber. Keys begin with `||string JSON||`||✅|
|`||The custom attributes set for the subscriber.||string JSON||`||✅|
|`||Last seen platform of the subscriber.||string||`||✅|
|`||The unique ID of the Experiment that the subscriber is or was enrolled in. Will be null if the subscriber has not been enrolled in an experiment. Learn more about Experiments [here](🔗).||string||`||✅|
|`||The value of the Experiment variant that the subscriber is or was enrolled in. `||string||`||✅|
|`||The last time an attribute of the transaction was modified.||datetime||`|||
\*Available only on our most recent export version
Re-enable integration to update to latest version
If your exports don't contain all of the columns above, you may be on an older export version. To update to the latest version just delete, and re-add the integration from the RevenueCat dashboard.
## A note on transaction data
All transaction data is based on the store receipts that RevenueCat has received. Receipts often have inconsistencies and quirks which may need to be considered. For example:
The expiration date of a purchase can be before the purchase date. This is Google's way of invalidating a transaction, for example when Google is unable to bill a user some time after a subscription renews. This doesn’t occur on iOS.
If you migrated to RevenueCat, Google subscriptions that were expired for more then 60 days before being migrated will not have transaction histories in export files.
Apple and Google do not provide the transaction price directly, so we must rely on historical data for the products that we have. This isn’t 100% accurate in cases where the prices were changed or receipts were imported.
Renewal numbers start at 1, even for trials. Trial conversions increase the renewal number.
Data is pulled from a snapshot of the current receipt state, this means that the same transaction can be different from one delivery to another if something changed, e.g.refunds, and billing issues. You should recompute metrics for past time periods periodically to take these changes into account.
We try to normalize or at least annotate these quirks as much as possible, but by and large we consider receipts as the sources of truth, so any inconsistencies in the transaction data can always be traced back to the receipt
# Sample queries for RevenueCat measures
You can use the following sample queries (written in Postgresql) as starting points for reproducing common RevenueCat measures.
# Sample queries for customized measures
Scheduled Data Exports are a powerful way to add your own customizations on top of the core measures provided by RevenueCat. Check out the following sample queries (written in Postgresql) for some ideas.