All Resources
Blog
Podcast
Case Studies
Events
Ebooks
Use casesData for subscriptions podcast - Episode #5
Taking Apart the Usage Data Software Options on the Market
Guest
Demed L’Her
CTO at DigitalRoute
Guest
Demed L’Her
CTO at DigitalRoute
Episode description
What’s the best way to build the modern usage-based pricing tech stack? Homegrown systems, iPass, ETL, pure-play vendors or perhaps, a purpose-built solution?
In this episode, our host Behdad Banian is once again joined by Demed L’Her, CTO at DigitalRoute. Together, discuss the best options for creating a usage-based pricing infrastructure.
Highlights
So if we look into just about any industry, we see people measuring success by some unit of usage. In the past, it was boxes shipped, number of cars built, and others. But now we’re moving towards more granular levels of usage.
For a streaming company, it may be the number of minutes a video was streamed. For a cement company, it could be the cubic meters of cement delivered, but also the distance traveled.
And these can change for businesses; a payroll management company may charge per paychecks prepared, and then the next month, they may charge for every dollar of transaction.
It’s very messy, usually. In many cases the data sits in old legacy systems. In some cases it’s just in the form of spreadsheets. They are stored in some text formats in JSON or CSV files.
You may be able to reach them through APIs in some cases, when they’re stored in databases. The data may be tied to some customer ID and may have a timestamp as well.
The usage data tends to be very chatty, it’s not a continuous stream, but rather bursts and at a much higher volume than what downstream systems can handle.
So first we’ve got homegrown systems, which is what most companies start with. With these, most companies run a script, to get data from the logs and feed it into billing systems. These work for a while, but you start facing difficulties when you want to scale up or try to expand your services.
Secondly, we have ETLs and integration tools. These tools are really good at what they do, but they simply aren’t built for usage-based subscription systems.
They’re largely event-driven systems. You have an event in one system, these connectors send them to other systems. But they’re not built to aggregate multiple events, summarize it, and then send it to billing systems.
Then, we have billing vendors, who we often work with. They do offer some basic level of data collection, but they’re simply not enough for this use case.
That’s why we partner with them. They can focus on building better billing systems, while we focus on getting the data right.
And then we have pure-play vendors. Most of them are very new to this, and we welcome them with open arms, because they bring more awareness about what we do. Most of these companies have a narrow focus and are trying to solve specific problems.
Well, you should do your homework. Before making a choice, you should look into the track record of the vendors and their capabilities. You shouldn’t go too narrow. If you want to stay agile here, you may have to experiment with a few different models.
Usage data is where the revenue is. You need the solution that can keep up.
First, don’t underestimate the requirements. It’s fairly easy to build a script to process a CSV file, but that’s not enough.
For example, if you’re working with financial data, leakage may seem like a small thing at first. But as you scale up, working with terabytes of data every day, the cost adds up.
Second, don’t assume this is a one-time job. This is not a “set it and forget it” thing.
You’ll be offering services in one way today, and tomorrow you’re thinking you want to add a free tier, or maybe you want different classes of customers. So you need to go back and work on it again.
Third, if you’re going to do this in-house, think about the cost in terms of people. When you get started, it’s one person putting two hours at the end of the week.
When you scale up, you have a ten-person team handling your scripts. As you move on to new countries, build multiple database clusters, and add on disaster recovery on top of all of this. Think of the cost if you’re going to be doing all that on your own.
Relevant links