![\"Monthly](\"https:\/\/static.gosquared.com\/images\/liquidicity\/14_03_25_mrr_01.png\")
<\/p>\n<\/p>\n
MRR (monthly recurring revenue) is arguably the most important metric for SaaS companies to be tracking. At many growing SaaS companies, including GoSquared<\/a>, it’s an invaluable KPI (Key Performance Indicator) and allows us to track growth against churn on a monetary level.<\/p>\n Every single change to any member of your userbase should be tracked. Did they change their name? Did they add a site? Did they start tracking?<\/p>\n Knowing what’s happened to a user over their lifetime is essential – and tracking changes to their subscription is necessary for monitoring MRR.<\/p>\n <\/a><\/p>\n How you define MRR is important to what value it can provide you as a metric. Many SaaS companies have both monthly and yearly plans, so misleading skews need to be avoided.<\/p>\n You could, for example, just add up the amount of money coming into the bank account each month – but that’s not MRR, that’s just the inbound revenue for that month.<\/p>\n MRR is best when segmented into a few different types:<\/p>\n The sum of those 4 metrics gives the net MRR, and each of the metrics individually can be very useful when tracked over time.<\/p>\n Yearly plans (or non-monthly billing cycles) have their values divided by their monthly length. So if a yearly plan cost $240, the value tracked in MRR should be $240 \/ 12 = $20.<\/p>\n All we’re doing is spreading the value of the subscription into equal monthly amounts, as if it’s being paid monthly.<\/p>\n MRR is meant to be an indicator of growth and the amount of revenue you can expect to make on a recurring basis. It’s not meant to be an exact figure, and will almost never match up with actual money in.<\/p>\n If you’re looking for a metric to track actual revenue into your bank, use that instead of MRR – but be aware that it can be misleading.<\/p>\n MySQL is great for tracking internal metrics – it’s easy to query (are your marketing team really going to connect up to MongoDB and know how to use it?) and very reliable.<\/p>\n We have a simple We receive push notifications from Recurly whenever something happens to a subscription, and they’re all stored in the To allow efficient MRR tracking, we exported the subscription change user events and put them into a new Track Everything<\/h2>\n
MRR Definition<\/h2>\n
Segmented MRR<\/h3>\n
\n
Yearly Plans<\/h3>\n
“But that looks like less money than we actually got”<\/h4>\n
Storage<\/h2>\n
user_events<\/code> table in MySQL which allows us to do cohort analysis and much more. We have many millions of rows in this table, and we still aren’t quite tracking everything just yet. This table contains user_id<\/code>, event_type<\/code> and timestamp<\/code> columns, as well as an extra<\/code> column that contains JSON encoded information that could be relevant for the future.<\/p>\nuser_events<\/code> table.<\/p>\nplan_changes<\/code> table, containing user_id<\/code>, timestamp<\/code>, type<\/code>, old_value<\/code>, new_value<\/code>, currency<\/code> and yearly<\/code> columns. The type<\/code> column can be any of created<\/code>, updated<\/code> or expired<\/code>. Note: the value columns will need the be SIGNED to allow some of the querying below.<\/em><\/p>\nSample rows<\/h3>\n
\n