31–39 of 39 posts
Earlier quoted context omitted.
ARR is always MRRx12. You're talking about a revenue model.
I think the confusion here stems from the terms "annual run rate" and "annual recurring revenue" sharing the same acronym
https://www-priceintelligently-com.cdn.ampproject.org/i/s/ww...
https://www-profitwell-com.cdn.ampproject.org/i/s/www.profit...
I never found the right solution (ChartMogul has issues with when they recognize revenue. It's based on payment instead of the period the invoice/subscription is for). Anyone have any tips to share about what they use?
I'm assuming that when you say "instead of the period the invoice/subscription is for" you mean that the invoice isn't being split and recognized across a multi-month service period. Most products will call this Revenue Recognition. Some basic SaaS analytics/metrics products don't offer this functionality but it can be a hassle even with the ones that do. The accuracy will always depend on clean invoicing hygiene whe…
Is there an open source alternative to ChartMogul? I feel like it makes sense, at least I'd like to avoid having to share financial information with a 3rd party, would much rather use some self-hosted open source solution.
Depending on how technical you are, similar visualizations can be produced in Google Sheets/Excel or Metabase. The issues are: 1) exporting/importing the data (manual CSV, via API, sourced from an existing DB, etc...) then 2) knowing which questions to ask and how to visualize answers to those questions You could also code a custom dashboard using something like D3.js
[1] https://workspace.google.com/marketplace/app/probe/108508041...
This is a nice writeup, could be an intro of tech people to business metrics you mention. I also code Ruby so +1 :-) I would be cautious about rolling your own implementation like this though.
1. This is not your core business. Eventually you want to start segmenting things by verticals, geography etc. You will want to visualise them. It takes time, which you want to spend building your product.
2. There are many important details in how you calculate certain metrics. Either you dive into the topic and again waste time, or you start having metrics which are custom, not really comparable with benchmarks or just plain wrong.
Maybe you just spent 1hr on this and that’s ok. Just make sure you spend your time on your product domain, because that’s what’s probably gonna make you happier (unless you pivot into saas metrics world!)
I never found the right solution (ChartMogul has issues with when they recognize revenue. It's based on payment instead of the period the invoice/subscription is for). Anyone have any tips to share about what they use?
I keep hearing that people aren't getting everything they want out of Baremetrics. What is it that they have a problem with?
> What is it that they have a problem with? We struggle a lot with “fake churn” in baremetrics. By that, I mean any time a customer on a credit card subscription upgrades to a “pay by invoice” tier, it shows as a churn of the credit card subscription and as new revenue for the invoice subscription. This makes churn wildly inaccurate and we spend a couple hours per month adjusting the numbers to get accurate data. FWI…
https://help.chartmogul.com/hc/en-us/articles/115005750705-M...
2nd option is if you are not creating a new subscription is to have the invoice service date start before cancelling the credit card - that would result in expansion (by invoice amount) and contraction (by credit card amount) and ultimately your MRR would be ok with no churn.
I'd be cautious multiplying your MRR x 12 to establish ARR. Things like seasonality or promotions could overestimate your ARR by using inflated subscription numbers. Additionally, if customers are not contractually obligated to stick around for a year, that calculation may not account for month-to-month churn.
ARR is always MRRx12. You're talking about a revenue model.
Are you saying that ARR is meaningless for heavily seasonal businesses?
Earlier quoted context omitted.
ARR is always MRRx12. You're talking about a revenue model.
> ARR is always MRRx12. Are you saying that ARR is meaningless for heavily seasonal businesses?
Your Ruby ActiveRecord query is so under optimized, you are loading a ton of records that instantiate objects and then apply a filter on this huge array. I'm pretty sure you could make it 100x faster.
