Revenue

Quick Reference

CalculationDescription

Total Revenue

Total value of your Revenue Property, within the date range of the report. Not to be confused with “Lifetime Value”. You can verify which property we’re using in your site’s mappings.

Average {Daily/Weekly/Monthly} Revenue

Total of the Revenue Property / Number of Days in the report. You can verify which property we’re using in your site’s mappings.

Lifetime Value

A prediction of how much revenue a customer will be worth. Calculated as Average Revenue per Customer/ Total Churn Rate

Avg Customers / {Day/Week/Month}

The average number of paying customers per Day/Week/Month

Avg {Daily/Weekly/Monthly} Churn

The average rate that paying customers churn per Day/Week/Month

Churn

The number of customers who stop paying. You can configure this to count people based on whether they’ve done a cancelation event or have not paid in X days.

Introduction

Chances are, you are using analytics to increase the number of people using your product so that they can ultimately increase your revenue. The Revenue Report gives you an overall picture of your revenue. Furthermore, you can segment your paying customers using your existing Sandstorm properties.

đź‘ŤFor example, you might be interested in:

  • How much revenue did I make this month compared to last month?

  • Which of my pricing plans is contributing the most revenue?

  • Which ads have brought in the most paying customers?

  • What referring sites do most paying customers come from?

Revenue Report video

How do I pass in revenue data?

The Revenue Report looks for a single Sandstorm Property across all customers. In our examples, we call this property Billing Amount. But you can use any other property name, as long as you are consistent across all customers. Typically, you’ll only include the net amount, minus tax and shipping:

Example

# Ruby example. When madeup@person.com is billed for $29.99, execute:
KM.identify('madeup@person.com')
KM.record('Billed', {'Billing Amount' => 29.99 })

Refunds can also inform your total revenue. Pass in the refunded value under the same Billing Amount property with a negative value.

Example

# Ruby example. When madeup@person.com is refunded $29.99, execute:
KM.identify('madeup@person.com')
KM.record('Refunded', {'Billing Amount' => -29.99 })

Remember, there are many ways to send us event data. You might find it most accurate to import data from another data source that’s already keeping track of each transaction.

Creating your Revenue Report(s)

The revenue report lets you choose how you want to calculate your revenue for your specific business model. You can create as many Revenue Reports as you’d like to measure different sources of revenue and/or different payment periods.

  • Calculate revenue from: the property which you want to calculate revenue from for this report.

  • Show revenue in X buckets: how you want to display your revenue graph in terms of days/weeks/months (graph is limited to 60 data points)

  • Calculate churn by: choose how your business defines churn by a time period (no purchase activity), an event that happens (such as cancellation), or both.

By default, the Revenue Report will use a churn time period with 30 days as the definition of churn. Customize this to your needs when building your own Revenue Report.

Only positive revenue properties are used for calculating churn rates i.e. with a default 30-day churn calculation a customer who had a revenue property amount of $10 in April 1st and no revenue property in May 1st would be considered churned. The same customer who had a negative amount (-$25) in May 1st or an amount of $0 in May 1st would also be considered churned.

Choosing a custom churn time period

If your business defines churn as a period of time (common for E-Commerce businesses), then you’ll be able to choose from common definitions of churn as well as defining your own custom time period to fit your use case.

🚧

There is a limit of 750 days for a custom churn period, which is over 2 years. Of the businesses we interviewed, none defined churned longer than that duration. If you have concerns about defining churn as more than 2 years of no payment received, please write to support@sandstorm.co with your use cases.

Choosing a custom churn event

If your business defines churn as an event such as cancellation (common for SaaS businesses), then you’ll be able to choose any event that you’ve tracked with Sandstorm to use as the churn event.

Total Customers

The revenue report can also look into your data to see how many paying customers you still have.

  • Paying Customers: - the number of people we count as still “actively paying”. That is, this is a count of people who we have recorded Revenue from, and who have not churned. Churn is explained in the next section.

  • Paying Customers Gained: - the number of people whose first recorded Revenue happened in the time frame you’re looking at.

  • Paying Customers Lost: - the number of people who have churned

Lifetime Value

Lifetime Value (LTV) is a prediction of how much a single customer will provide you in their time as a paying customer. There are many mathematical models for calculating LTV. Our report uses this one:

Lifetime Value = Average Revenue per Customer / Total Churn Rate

To simplify further:

Lifetime Value = (Total Revenue / Total Customers) / (Total Number of People who Churned / Total Customers) Lifetime Value = Total Revenue / Number of People who Churned

This means that if no one has churned, we can’t make a prediction of your customers’ LTV (we can’t divide by 0).

Segmenting Revenue

As mentioned above, you can segment your revenue and customers using your existing Sandstorm properties. Some example questions you might answer:

đź‘ŤQuestions:

  • Which of my pricing plans is contributing the most revenue?

  • Which ads have brought in the most paying customers?

  • What referring sites do most paying customers come from?

🚧Note:

Remember that we track a person’s lifecycle on your site, which includes every referral source they took to reach your site. Choosing First Ever or Last Ever lets you attribute a person to either the first property they received (usually for Referrer or Campaign Name), or to the most recent property.

Last updated