careers
Smart pricing at Tulip Assist
How do you implement a brand new pricing system? Our colleague Ruaidhri Hogan, software developer at Gomibo, tells more about it in this blogpost.
Combining the intelligence of a modern e-commerce platform with the security of insurance
Tulip Assist is a company that is part of the Gomibo Group. We provide an insurance product for Belsimpel and other resellers that allow customers to feel reassured about their device’s safety for a monthly premium. If your phone is stolen or broken in an accident, we’ve got you covered. At Tulip Assist Development we build the web platform used by the customers, customer service, finance and return/repair teams. Our digital platform is the backbone of the business and we work hard to keep it working smoothly while adding complex new features every day!
My name is Ruaidhri. I moved to Groningen as an international student in 2016 to study Computing Science at the University of Groningen. After working alongside my studies for a few years I became a full time developer at Tulip Assist in 2021. Since joining the team a big part of what I have been working on is the product pricing. This involves using all of the data available to us to accurately price our insurance plans so we can keep our insurance premiums as competitive as possible.
Together with our data driven development team I have been implementing a new pricing model for our insurance premiums that works on one basic principle: The longer we insure a device, the more data we have on a device’s reliability. The more data we have, the more we can make predictions about how likely that device is to suffer damage and model our products accordingly.
Being this smart about our pricing model is one of the aspects that makes working at Tulip Assist a unique challenge. We’re not only basing our prices solely on how much a device costs the consumer and how much it will cost them to repair or replace it but utilizing the data that we gather passively simply by insuring devices to adjust our pricing on the fly. Our ability to adapt to how a device performs means our premiums are often considerably lower than our competition and makes the project a unique challenge to work on.
As an interesting aside:
- Not only can we predict how likely it is for a device to suffer damage, we can also predict how likely a device is to be stolen.
- Some aspects of a device that you would think are irrelevant actually do have an impact on how reliable a device is. For example some devices are more likely to be damaged based on the colour of the device!
For this new model our system must gather statistical data from our historic and active policies to make predictions about how reliable specific devices are likely to be and apply this knowledge to derive accurate premiums going forward. A big part of how this model works was the central theme of my Bachelor’s thesis which I completed at Tulip Assist.
A unique challenge that I faced during this project was integrating complex data science into an existing web application that was not built for it. Our backend application is written in PHP. This wasn’t exactly built for crunching big numbers. In fact the data we’re working with is so dense that the initial solution when tested on a production data set took over 14 hours to calculate prices for all devices we offer insurances on (That’s approximately 60,000 prices across 6,000 devices and 10 different products per day).
After that setback I worked hard with the help of my team and other colleagues to identify inefficiencies in both data storage and algorithmic complexity to integrate a solution that instead does the same work in under an hour. This was done primarily by:
Eliminating as-required API calls and batch retrieving data — This model needs a lot of contextual knowledge about the devices its working with like brand and series information. Initially we were retrieving this data on the fly via an API which resulted in a lot of network waiting and occasionally re-retrieving data we’ve already got once. It was better in this case to retrieve all of this data at the start of the job and store it in memory for quick access resulting in a massive speed up.
Identifying and eliminating N+1 style ORM queries — If you don’t know about the N+1 problem I would encourage you to read about it! Initially we were lazy loading a number of objects and then repeatedly triggering new queries every time we wanted to access a relation causing orders of magnitude more queries than required. Changing just a few queries with eager loading made a big difference here.
Caching calculated data for one device that may be beneficial for another device — As an example: A lot of the data needed for one Apple device is often the same for all Apple devices.
It was necessary for the resulting system to be usable by our internal teams to tweak the model so that we are able to monitor and adapt to extreme cases. This element of the project involved some complex front-end work to build components that enabled that functionality. It is a challenge to take what is an inherently complex process and present it to our non-technical teams teams in a way that is not only easily understood but easily manipulated / managed. The components we built were to allow for testing, monitoring and configuration of the model by our finance & business development teams. Functionality we’ve implemented includes:
- Monitoring and comparison of prices both current and historic.
- Tweaking of model heuristics.
Warning of potential upcoming large changes in a product price.
The final unique difficulty that made this project so interesting is — ironically — auditing. Audits are a part of every company but especially so in the world of insurance! No matter how clever and unique your pricing model is, you must always be able to explain how it works and prove it works in that way.
This is another reason why our front-end needs to be clear and the data used be available in perpetuity. That’s another difficult idea in the world of data science: When you’re using bucket loads of data every day in your models: how do you store it all for an auditor to read? We are generating tens of thousands of prices every day and being naive about how you’re storing that much data will quickly slow your database down to a crawl.
That’s an interesting question with a fascinating answer, but if you want that answer you’ll have to come and ask me for it. We’re always looking for new talent within the Gomibo Group. Check https://werkenbijbelsimpel.nl/ for more information.
Thanks for reading!