Categorizing your subscribed customers
Auto-categorize your paying customers and track their recurring revenue, renewal date, and more
To enable auto-categorization of your subscribed customers, navigate to Settings -> Lifecycle Tracking -> Subscribed Customers (or get there via Quick Jump). There, you'll see a handful of options you'll need to configure in order to correctly categorize your subscribed customers.
By default all Accounts are subscribed Accounts. Vitally will then check your Trial, Churn, and Account Track rules (under lifecycle tracking) to see if any of those accounts match those rules. If they do, those accounts are then categorized appropriately.
*If an Account does not match any other rules, it will remain a Subscribed Account even if they do not match those rules.
Please note* Account Track Rules take precedence over Churn Rules. If an Account meets both set of rules, Vitally will follow Account Track Rules.
Select the trait(s) that specifies each customer's revenue - e.g. the
mrr trait. If you select multiple traits here, we'll set the account's revenue to the first trait they have a value for.If ANY value is found in this trait, this will switch an account to Subscribed account. So for example, if you have manually churned an account and notice that it reverts back to a subscribed account - it's likely that this trait has a value.
Option 2 below is HIGHLY RECOMMENDED to accurately track Accounts that meet specific track rules otherwise any and all Accounts that have a value in this trait will be marked as Subscribed.
Sometimes, you may send revenue data even if the customer isn't paying you yet. For example, let's say this is your setup:
For trials
- An account can view your available pricing plans and choose one to start a 30-day trial on
- When an account starts their trial with their selected plan, you set a
revenuetrait to the price of their selected plan and aisTrialtrait totrue.
For trials converting to paid plans
- The trial can view your available pricing plans and select one to start paying for.
- When the account submits their payment for their selected plan, you update their
isTrialtrait tofalse
In this scenario, both your trials and your paying customers have the
revenue trait set. But, trials aren't yet paying, so it's best to exclude them from revenue tracking until they actually convert to a paid plan (otherwise, your MRR will be inflated). To do that, you'd want to configure this step to only track customers where isTrial is set to false:
If you have customers paying in multiple different currencies and want Vitally to automatically convert your revenue into a single currency (for accurate revenue reporting), follow these steps:
- First, configure the currency you'd like to convert all revenue in to (and thus use in reports in Vitally) by following the instructions here. We call this your home currency.
- Then, ensure you send Vitally an account trait that tracks the ISO 4217 currency code that the account's revenue is tracked in. For example, if you select a
revenuetrait in option #1 above and have some customers with arevenuevalue in Euros and others in USD, then be sure to track a trait with a value ofEURfor those paying in Euros and a value ofUSDfor those paying in USD. Note that the code can be sent in any case - e.g.USD,usd,uSDare all valid values. - Finally, select the trait that tracks the customer's currency in this option.
Vitally will then automatically convert your customers' revenue, regardless of currency used, into your selected 'home currency'. Vitally currently supports over 65 currencies with exchange rates updated daily.
Currently, Vitally automatically adds a
currency account trait to your accounts whenever you connect any of our current supported revenue integrations - i.e. Stripe, Recurly, and Chargebee. Thus, all you need to do if you're using one of those integrations is select that currency trait here!
If at all possible, we recommend tracking renewal dates alongside revenue. This way, you can use that data when filtering and creating Indicators (e.g. flag unengaged customers with a renewal in less than 7 days). So here, you'll want to identify the event properties or traits that track the start and end of a customer's subscription (if available).
Option 5 is only applicable when you select "Total Subscription Period Cost" in Option 6. In this scenario, we will use the difference between the date traits defined in Options 4 and 5 to determine the subscription duration.
This step simply allows you to specify whether revenue is always sent as MRR, ARR, or as the Total Subscription Period Cost (value of the entire subscription period). If you select Total Subscription Period Cost here, we'll simply calculate a customer's MRR by dividing revenue values by 12 if the subscription period is longer than 1 month. If it is not, we won't modify the revenue value and will assume it is MRR.