This series of three blog posts will provide an introduction to building a Single View with MongoDB. Part 1 covers an overview of what a Single View might look like and what you should consider while building one, while Part 2 will look at the implementation of a sample data model, and Part 3 will dig into the mechanics of how to move your data into MongoDB.
What’s a “Single View” and Why Should I Care?
So what is a Single View? You might have also heard the terms Data Hub, 360 Degree View, or multi-channel display. All of these terms describe a system that gathers data from multiple, disconnected sources, and aggregates it to provide a single view – hence the name. A single view of what? Well, anything you’d like, potentially. Often people refer to a “Single Customer View”, but you might also want to create a single view of lines of business, products, employees, assets, or innumerable other possibilities. We’ll primarily be discussing a single view of a customer here, but the same principles can be applied to a single view of anything.
Why would you need a single view of data? Most companies have a complicated process for their data. It usually involves multiple data sources of variable structure, ingestion and transformation, loading into an operational data store, and supporting the business applications that need the data. Often there are also analytics, BI, and reporting that require access to the data, maybe from a separate data warehouse. And of course, all of these layers need to comply with security protocols, information governance standards, and other requirements.
Inevitably, information ends up stranded on “data islands,” or in silos, or in your own preferred visual metaphor. Systems are built to handle the requirements of the moment, or a particular application requires a particular data structure, and all of a sudden information on one customer is in a dozen different disconnected places.
Why would you want to bring all of that disconnected data together? Well, not just so that each datum can be with its friends. The use cases for a single view can be almost anything you can imagine:
And so on. Pick an industry, and you can find a dozen business reasons for aggregating disconnected data. A single view is all about working with the data in the way that best matches it, and seeing it in ways that you couldn’t before.
Single View Data Model
OK, enough business speak. Let’s say you’re on board with the idea of creating a Single View. How do you go about it?
Let’s take as an example a retailer with an Internet presence. The disconnected data world might look something like this:
Traditional Mental Model
You see a lot of different types of data here. You have your customers and information about them in blue. In green, you have external data, including information that you might pay third parties for – sentiment analysis, demographic information, etc. In purple, you have your product information. And of course, connecting these together are all the ways customers can interact with products – via leaving reviews and ratings, placing orders, browsing the site, etc.
Now, these many silos of data are logically connected in a lot of different ways. But just by looking at the connections, you can see two big groupings – things related to customers and things related to products (noting that these sets are not mutually exclusive).
Those are some pretty intuitive groupings, so when you transition into a new model to support a Single View with MongoDB, you might reimagine it as looking something like this:
MongoDB Mental Model
What you’ve really created here are two single views: one of customers and one of products. In the old model, if you wanted to see all of the information about a customer, you had to gather it from about 10 places – assuming that was even possible. Now, you’ve pulled it all into one place, so you can quickly and easily see everything pertinent about a given customer. You’ve done something similar with products, so that you can see at a glance how a given product is performing. In addition to looking at all of the data on one customer/product in one place, you can also easily work uniformly across the whole class – e.g., look across all customers and select the ones in a given zip code who purchased a certain product.
It’s important to note that you’re not necessarily dumping all of the related information into a customer object. When you’re looking at a single view of a customer, do you really need all of their actions on your site from the last decade, or everything they’ve ever tweeted about your company and products? Probably not. That doesn’t mean you throw out all of the details – by all means, you should keep them stored on their own – but in the customer object, it probably makes sense to summarize it at a useful level. Traffic highlights from the last 30 days, let’s say, or an aggregate sentiment score.
When you’re making decisions about how to consolidate, ask yourself what makes sense for how you’ll be using the data. Before, Orders were stored on their own. But every order is associated with a customer, so here we’ve embedded the orders data in the customer object. On the other hand, we probably don’t need to store all of the details of ordered products in that customer object, so we’ve linked out to the Products collection to avoid duplication.
What Can I Do With a Single View?
Once you’ve restructured your data in this way, what can you do? Let’s take a closer look at that customer object:
Getting to a Single View of the Customer
- Top traffic: with traffic data, you can look across customers to see who are the most or least active
- Sentiment Score: based on your sentiment scoring, you can perform analytics to see how sentiment varies with other customer data
- Orders: Orders have been embedded in a sensible way, reducing data model complexity
- Locations: Beyond billing and shipping addresses, you can do geographic analysis on IP or mobile locations
- Reviews: with reviews, you can perform native full-text search to discover common descriptions being generated by customers
- Actions: here, you can filter and present the most important data: e.g., the customer recently did x, so a customer service representative should be prepared to discuss that in a conversation with the customer
So there are a lot of new questions we can ask with the new data model. But how would we ask them in MongoDB? Let’s look at some examples, and what the MongoDB query might look like. Of course, these are pseudocode examples – how you construct your own queries will depend on your data model.
What kinds of products has this customer purchased?
distinct( “orders.category”, { “id” : 12345678 } )
How close are they from a point of service right now?
find( “location” : { $near : [40.8768, -73.787] } )
Who are the 10 customers most dissatisfied with out service?
find().sort( { “sentiment”: 1} ).limit( 10)
What should my customer representative mention in the next conversation?
find( { “action.topic” : “talkingpoint”} ).sort( “createdOn” : -1 )
How to Get Started on a Single View
Stay focused, and iterate quickly. Don’t get in over your head and try to consolidate all your data in one go. Pick one important effort with a few data sources as a proof of concept. Consider the data and what questions you might want to ask in order to inform the data model. Then prototype it, and iterate on your prototype.
Be ready for change. Data arrives in many formats, and new sources surface frequently and unpredictably. With an initial single view, you’ll likely start running analytics that create more data, or you’ll discover that you really should be collecting other, additional types of data. Luckily, MongoDB’s dynamic schema makes it easy to evolve your data model, rather than having to reinvent it every time something changes. Your schema should reflect your access patterns; if you change how you’re using the data, you should be ready either to change how it’s organized, or to store it in more than one way.
Ask questions. Start by asking questions. How you structure your data model depends on what you want to learn. For example, if you come up with the following list of queries, you should probably focus on a single view of the customer:
- What is the customer doing that is unusual?
- What are the customer’s peers doing that the customer isn’t doing (but should)?
- What products has the customer purchased, and what is the likelihood that they will buy something new in the next week?
- What will the customer do this week?
- What are customers telling us about themselves, about us, about our products?
- What customers should I focus on, what should I show them, and why?
In this first part of our “Creating a Single View” blog series, we’ve talked about how to change your data model to accommodate a single view with MongoDB, what benefits you get, and how you should start creating a single view. In part 2, coming next week, we’ll look at what your schema should look like and break out some actual JSON.
In the meantime, you can download a white paper to learn more about how MetLife built a single view of the customer with MongoDB.
About the Author - Eric
Eric Holzhauer is a Product Marketing Manager at MongoDB.