In 2020, Marks & Spencer relaunched "Sparks", its digital-first loyalty scheme, offering customers greater personalisation and ease-of-use.
With the change of loyalty program from Points based system to Offer based system and encountering limitations scaling the app with its existing partner, Marks & Spencer made the decision to build in-house rather than opting for an off-the-shelf product.
In order to build the right product, the right people and the right database platform were needed. MongoDB's document-based database enabled Marks & Spencer to achieve the desired scalability, agility and reliability to reach even more customers.
Amit Vij is the head of software engineering at Marks & Spencer, leading its customer engagement portfolio. Computing spoke with Amit to find out how the new and improved Sparks app was made possible thanks to MongoDB's developer data platform.
What features were you looking to provide to customers through the relaunch of the Sparks app?
In 2020, M&S relaunched its digital-first loyalty scheme. Before 2020 it wasn't a digital scheme. You'd have to purchase a physical card, register online and you'd go on a website to see what offers were on the card. You'd have to take that physical card into the store and then go to the tills and scan it. The customer experience was quite modest and quite slow and we could not scale our customer base.
In 2020, we launched a digital-only scheme. You have your digital Sparks card within the mobile app and you can see offers on a real-time basis.
It has been a successful journey; we had 7 million customers we had to transfer over to this scheme and within 3 years we have gone from 7 million customers to 17.2 million customers, with 10 million active customers on Sparks.
Our Sparks customers shop five times more often with us and spend eight times as much. So it was very critical to get this Sparks loyalty programme operating properly.
Why did you decide to build the application in-house rather than buying off-the-shelf?
There are two main reasons for this. Our loyalty scheme was simpler, we moved from a tiered points based loyalty program to an offer-based program. The complexity of building an offer-based system in-house was more palatable to the organisation. When we launched in 2020, we worked with our existing partner. And on the day of the launch, the application went down for six hours. So it wasn't a positive experience for customers or the team that built it. At that point it was decided that the platform it was built on was not scalable, it wasn't on the cloud and it had a lot of issues over the years such as network cables being pulled out and the application going down. So we decided to build this application rather than buy it.
At M&S we have a Tech North Stars system that is guided by principles we want to live up to and we use these as a benchmark whenever we create something new. We look at five key factors when deciding whether we should go and buy something from the market or build it.
The first one, which is very critical, is vitality versus utility. Anything which is a strategic product for us we call a vitality product. For MongoDB for example, database storage is a vitality product. So we are not going to build that ourselves. But for us, our loyalty programme is a vitality product and we wanted to scale it from 20 million to 30 million customers in the next five years. That's a strategic product where we want to own the data ourselves.
The second factor is agility. We wanted to build an application that is agile and scalable. Our business is continually changing and we have to be very adaptive to market demand. With socio-economic factors like Covid, war, floods, and inflation, the market dimensions keep changing. Equally, our tech stack keeps changing as well. What we cannot do is every two years keep swapping our products and changing vendors. So, we wanted to build something where we can scale up.
The third one is we needed an application that can be loosely coupled. We want to build something with a microservices architecture where services are independent of each other and can be reused and deployed on demand. We've already built a new loyalty platform, trialled voice enabled devices and Sparks only pricing. There was no chance of building these on our legacy platform.
Previously, we didn't have cloud capabilities. The application was sitting in a data centre, so we had to move to the cloud to get our data disaster recovery, scale, AI capabilities and availability in place.
And then last but not least, we wanted an application that was reliable by design. We want to ensure our technology works when needed for the right cost as well. By moving to a new platform, we saved £1.4 million in OpEx costs yearly. Obviously, we do have an operational cost of running this ourselves, but having a non-reliable product was very costly for us.
What were the factors that made you decide to go with MongoDB versus one of their competitors?
MongoDB is a document-based database, which was key for us. We followed iterative migration for our programme, which was done in multiple stages. We could not have done it overnight. The data we were receiving from multiple sources was unstructured and in multiple formats. We also wanted easy updates to schemas and fields because we didn't know the right architecture when we started this journey. We wanted a database that could support this.
The other key reasons were availability and scalability. We built in resilience with data stored in multiple regions and MongoDB provided the flexibility and ease of use for engineers to tailor the application to M&S needs.
One aspect we sometimes ignore is the support you get from the technical professional services. The expert opinions, plus the engagement we have had with MongoDB on a day-to-day basis to solve critical problems, to get our platform up and running, and to the scale we wanted has been the game changer.
We have also used MongoDB Atlas Search for some projects that add full text search functionality to our application as well as analytics nodes which allow for real-time analytical queries on our data without impacting our workloads or how customers interact with the application. These are both features that we plan to expand our use of in the future.
How have your developers found working with the MongoDB platform?
When we started designing this application, we used to do 1 million offer allocation an hour. Now we are able to do 1.2 million allocations in five minutes, which is 14.5 million allocations per hour, and 350 million allocations a day. Now this is the scale we wanted to achieve from a business perspective, but to make that happen, engineers need to understand the product in depth.
With the support we have from MongoDB, it has been a seamless process for the engineers to get their hands dirty and actually build this application.
The other aspect I would highlight is the performance. We have achieved API response rate (latency) of less than 100 milliseconds, which was previously more than 1 second, so that's a massive growth for us.
So for our developers, that's a big, big win. If we take the DevOps approach, we haven't had a SEV1 issue on our loyalty platform since moving it to MongoDB. And in the past, we had multiple issues a month. I would say developer life has definitely been made easier with the platform.
What plans do you have to develop the loyalty scheme further?
The first thing is to really go global. The existing platform only tailors to the UK and Republic of Ireland. But Sparks as a brand launched in Q4 last year to global customers. So we have launched it to 4 million loyalty programme customers in India and to 24 pure play markets - France, Germany, Spain, Australia, and the USA are some of those markets.
Because Sparks is such a big brand for M&S, we want to scale it up, making it a key identity for our customers so they are happy to engage with us. In the future, we would like to connect our banking and Sparks programmes and personalise offers and rewards through mobile app. We want to reach 30 million customers in the next three years.
To find out more about MongoDB visit mongodb.com
This post was funded by MongoDB