I have spent 5+ years in the subscription business. Mainly, I was building in-house analytics from scratch. Now I found more and more projects that try to fulfill empty areas of services for the subscription business. Some people ask me to provide some insights and the main question is usually: why do subscription businesses have to build in-house data solutions? Let me try to answer the question here.
How complex analytics stack in subscription business could be was covered by CTO of Scentbird Andrei Rebrov. However, it is a high-level overview of what tools subscription services are using. Let’s go a little bit deeper into technical details.
Let’s start with some really simple statement: subscription business by its nature is more complex than regular e-commerce. Why?
Subscription business does not create revenue in one purchase. In most cases, you stay far behind customer cost with one sale. The idea of a subscription business is to attract and make one-time customers into regular loyal customers. To do that subscription businesses have to make every purchase quite cheap (compared to regular e-commerce) and offer some value over time for the customer: discounts, exclusive products, fast shipping, good support, etc. You could not just take money for one purchase and forget about the client as you already do your profit. It is a relationship with a history and a subscription business that put a lot of effort into it.
A subscription business should offer a really different product to a regular shop. E-commerce could offer just everything you could find in a grocery store, but with delivery to the door and it will work. For a subscription service to be successful sometimes means that the product does not exist yet. You should invent it (or smartly combine existing products), promote it, sell it, and support it. If we go deeper with the term “invent” it could mean setting up supply chains for raw ingredients for producers who craft that product for you and organizing delivery, sorting, and storage of your unique product.
I hope, that two points show how complex the backoffice of subscription service could be. It is not just reselling.
Ok, now we could go a little bit deeper into issues of analytics for subscription services.
How do you know how many users your subscription service has? It is the basic metric, but it is not simple at all. Let’s compare a regular e-commerce service to a subscription one in terms of the calcalution of users.
E-commerce service metrics about users (feel free to point me that I missed something):
How many make a purchase?
How many users sign up or they do purchase without signing up?
How many users asked for a refund?
Subscription service metrics about users:
How many users sign up?
How many make the first purchase?
How many make a second, third…, n purchase?
How many users use a trial subscription (most services have that one)?
How many users asked for a refund?
How many users canceled subscriptions intentionally?
How many users canceled subscriptions unintentionally (e.g. payment system report that a credit card was not chargeable)?
How many users could not pay for the next subscription cycle because of technical issues with payments?
More and more other questions could appear here. Before getting the total number of subscribers the service has that month we need to answer every question on that list and process all the corner cases (e.g. if with a trial subscription already a subscriber or he should be after the first real charge? if users asked for a refund for first purchase is not a valid subscriber?). The mechanics have a lot of moving parts and you should take all of them into account.
Payments and taxes
Payment is one of the most complex aspects of a subscription service. The root of that is coming from the nature of subscription service: you do not get a product right after payment, it is about doing advanced payments for getting some product next week/next month. From a technical perspective, it is the same: you pay money and get some product, but from a financial perspective it is not.
If a user pays you on the 29th of the current month and your delivery would be next month, how you should consider that payment? Is it revenue for the current month or for the next month? Is it revenue by the way or just advanced payment? If the user would change his mind and want his money back before shipment but during the next month how should you amend the finance stats for the previous month? You could say all problems have regular e-commerce service also. Correct, but it is a one-time headache. In subscription service, a user could pay for 6 or 12 months in advance and financial reports should be shaped to make proper processing of such advanced payments over a long period of time for big amount of users.
Moreover, during 12 month period you could get some extra corner cases: changing the price of a subscription plan, a partial refund for some shipments, and some bonus shipments were done for free during that period of time (so that shipment should not affect finance reports). It is a very very complex area. And taxes… Just skip them, as there are many more questions that arise on every question mentioned above.
Supply chains and logistics
You have a unique product, do you remember? it should be also taken into account in analytics and finance reports. You just need to pick up the knowledge about the area regular e-commerce does not face with. It is possible that you could just outsource all activity to some 3rd party company and it will work until some level. But next, you could face several issues:
Your product is so unusual, that most logistic companies have no tools or abilities to work with it at an efficient level. For example, Scentbird is dealing with perfume. Perfume is flammable: transportation, sorting, and storing should be done in a very special way. Most of the 3rd party companies does not deal with flammable products in that enormous amount as subscription service does.
The amount of monthly shipments is so huge, that the regular way to process those shipments is not efficient. The process that managed to pack and ship 10k packages monthly of any kind of product could not be scaled up to 100k packages just by increasing headcount 10x times.
If you produce your own product from scratch then the supply chains you have built could be good for producing a small amount of product, but it does not scale well once again. You could outsource it to a bigger company that could handle it (spend more and more money) or reinvent all the processes and dive into that area by yourself.
In the end
There are tons of minor issues in subscription services and all of them make a big difference. Any big subscription business is unique and has a lot of customization. It means that they could not share the same boxed analytics solution.
Do get me wrong: it is still a lot of common areas that could be served by some 3rd party service like marketing analytics or web-site analytics. However, there hardly ever could be a tool so flexible that it could be used by any subscription service in terms of finance.
P.S. You could always reach me for consulting in areas: subscription services, analytics, and big data architecture.