MRR Charts - How to do it

Do you have a single batched revenue event? Why not fire a revenue event per user per transaction? (i.e. 5 payment events at $1,200 each, with a unique user property for each event). If you’re doing the revenue drawdown kind of thing (e.g you get paid $1,200 at once, but you only want to recognize $100 of revenue for each month), then you’ll definitely have to make a custom event, I'm pretty sure amplitude doesn’t support that kind of revenue reporting natively, and it’s pretty uncommon outside of media publications that do it for print-advertising audits.

So the big thing I’ll start with is that amplitude isn’t good for this kind of revenue reporting, I’ll get more on that below, but if you want to carry ahead then there’s a couple of thoughts on how i’d handle this (also i’m not a huge expert here).
First, there’s a fundamental question on revenue recognition. Amplitude, as far as I know, can’t project future revenue forward like that. Especially when it comes to acknowledging 1/12th of the annual revenue each month. It would be much easier to do in excel or another platform. You can however look back at already incurred revenue. And the Amplitude formulas might help here, if you were to go to the ‘Segmentation’ chart, and say pick ‘Any transaction even’t’ You could then adjust ‘Measured as’ to something like dividing total revenue for a period by 12, then diving among unique users:

(REVENUETOTAL(A)/12)/UNIQUES(A) 
 

But this is only going to give the value in the lookback period and doesn’t help at all.

The other option could be to reinstrument your revenue events. let’s use a subscription example where you process payments on some processor and then apply a subscription entitlement to a user on your own system. Imagine a user called ‘Richguy’ spent $6000 on 5 subscriptions for his friends (user1, user2, user3 etc).

You could generate several events. A single revenue event for the purchase of the actual item 

subscriptionPaid ($price = “6000”; quantity = 1, SKU=”annual_plan”, currency = “USD”, user = “Richguy”, recipient = [“user1”,”user2”,”user3”,etc]

Then a revenue event for each person the item is given to

subscriptionStarted ($price = “1200”, SKU=”annual_plan”, user=’user1”, currency=”USD”, payer=”Richguy”

subscriptionStarted ($price = “1200”, SKU=”annual_plan”, user=’user2”, currency=”USD”, payer=”Richguy”

subscriptionStarted ($price = “1200”, SKU=”annual_plan”, user=’user3”, currency=”USD”, payer=”Richguy”

and so on…

If you wanted to make this really really convoluted you could actually just those second events every 30 days for $100, but this would be a PIA to maintain if you start to diversify subscription tiers or options. 

Also since this is a subscription we’re assuming you’ve got events coming from some payment processor (like stripe or whatever), and then an event for each person who gets an entitlement. Depending on your payment processor you might actually be able to send over itemised revenue events, in which case you’ll be able to skip that first event and just record each individual transaction in amplitude itemised. Or Potentially passover a single event that contains a quantity of 5 and $1200 each 
subscriptionPaid ($price = “1200”; quantity = 5, SKU=”annual_plan”, currency = “USD”, user = “Richguy”, recipient = [“user1”,”user2”,”user3”,etc]

Both of these let you look at ARPU easily enough, but I’d try to avoid having two events probably isn’t because if you ever get sloppy you could easily wind up double counting revenue, and it’s just messier to maintain. 

The best option though is probably to use Amplitude only for things like high level ARPU and overall runrate, and do MRR reporting somewhere else