Bricktowntom is committed to exceeding your expectations by providing a positive, enjoyable experience while visiting my site. Thank you for considering Bricktowntom's Market Place. I appreciate the trust you have placed in me!!
Case Study: Builds Single Customer View with MongoDB

Case Study: Builds Single Customer View with MongoDB

This article was originally published on MongoDB. Thank you for supporting the partners who make SitePoint possible.

Transforms customer experience, fights fraud, and meets the demands of the GDPR with MongoDB Atlas and Apache Kafka running on AWS.

In a world where standards and speed in online retail are getting ever higher, one retailer, has consistently been able to differentiate itself around its core focus: customer experience.

At the beginning of 2017 it was clear there was a big opportunity to use customer data more effectively, to drive:

  1. Continued improvement to the customer experience
  2. Faster identification of fraud
  3. Compliance with the EU’s new GDPR personal privacy regulations

AO responded by starting a new team, giving them the mandate to build a 360-degree single view platform of all its customer data.

To ensure they could move quickly and keep the team focused on business goals, the team chose to use the MongoDB Atlas database service in the cloud. We spoke with Jon Vines, Software Development Team Lead at, about the experience of building the single customer view application, his development philosophy, and the impact it’s having at AO.

Can you start by telling us about is one of the UK’s leading online electrical retailers. At AO, what really drives us and makes us special is how obsessed we are with the customer’s experience. We make sure that our employees are empowered to make the call on what’s best for each and every customer, that means no scripts or rules in the contact centre, we just do what we think is right. Our guide has always been to ask whether our mum would be proud of the decisions we make every day and whether we feel we would have treated our own Nan in the same way.

That philosophy extends right through to the core technology decisions we make. For instance, the third of our three core business model pillars is infrastructure. We know it’s incredibly important to have systems that are scalable and extendable while making sure we get all the benefit of operational gearing and pace from our investments and long-term growth.

With quality infrastructure as such a key part of AO’s strategy, what was your team trying to achieve?

We were tasked with pulling together the many sources of customer information within AO, to build a single, holistic view of each of our customers. Our data is spread across many different departments, each using their own technology.

The ultimate goal is to deliver one source of truth for all customer data – to drive a host of new and enhanced applications and business processes. This enables our staff, with the appropriate permissions, to access all the useful data we have at the company, from one single place, and all from one easy-to-consume operational data layer.

Can you tell us a little bit about what apps will consume the single view?

There are three core apps we are serving today:

  • Call center: For us, it is all about the customer and relentlessly striving to make our customers happy. Evaluating our contact centre systems showed us that we could enhance our customer journey by exposing more data points that were not currently available to our agents. This allows us to provide a better level of customer experience.
  • Fraud: Anything in the fraud grey area gets passed to our fraud team for the personal touch. As our company grows, we’re constantly looking for ways to be more efficient and effective. This is where the single view comes in. The high-throughput, low-latency capabilities and the aggregation of multiple disparate data sources makes it the perfect vehicle to provide additional decision support and anomaly detection for our fraud team.
  • GDPR: We need to be able to tell customers what personal data we store about them. Our marketing teams need to be able to see customer’s preferences in relation to communications with us. The single view makes all of this much easier.

This is just the start. There are many more projects that are under development.

So how did you get started with the single view project?

The team was formed in May 2017, and our first task was to identify source data and define the domain we were operating in. We have a lot of historical data assets that need to be blended with real-time data. This meant working with multiple instances of Microsoft SQL Server, and various data repositories and message queues hosted on Amazon Web Services (AWS), including SQS. We had to figure out a way to extract that data cleanly, without impacting source systems.

We spent several months cataloging our data assets, before turning to prototyping and technology selection. We started development in October 2017 and went into production just three months later in January 2018. The key to this development velocity was the underlying technology we selected to power the single view platform.

What are you using to move data from your source systems?

As a business we were already running in AWS, so we first looked at Kinesis, but decided on using Apache Kafka and Confluent Open Source. We can use Kafka’s Connect API to extract data via the Change Data Capture streams on existing data sources, with Kafka streaming and transforming the source data into our single view data model. This allows us to extract data without creating dependencies on other teams who we would otherwise have to rely upon to publish this data, or give us access to their source systems.

Once the data is in Kafka, it opens up a multitude of potential downstream applications. The single customer view is just the first of these. We can also use the oplog in MongoDB to extract data into Kafka, which allows us to decouple our microservices architecture in a very natural way.

How about the database layer?

It was clear that legacy relational databases would never give the schema flexibility we needed, so we explored more modern database options.

The post Case Study: Builds Single Customer View with MongoDB appeared first on SitePoint.

Source: Site Point


Republished by Blog Post Promoter