Webinar: Making A Single View of the Customer Real with MongoDB
Download as PPT, PDF4 likes6,096 views
The document discusses MongoDB's capabilities as a leading NoSQL database, emphasizing its dynamic schema, high scalability, and rich querying for creating a single view of customer information. It highlights various use cases, particularly in the financial sector, illustrating how organizations like MetLife have successfully implemented MongoDB for enhanced customer service and operational efficiency. Additionally, it outlines the business value of data integration and the necessity of modern databases in managing complex data systems effectively.
![Joint Bank Account Document
{
_id : ObjectId("4e2e3f92268cdda473b628f6"),
accountID: 9874983789,
accountType: “Checking”,
ownershipType: “Joint”
accountOwners: [
{ firstName : ”John",
lastName: “Smith”,
address: “52 Vanderbilt Ave.”, …},
{ firstName : ”Anne",
lastName: “Smith”,
address: “52 Vanderbilt Ave.”, …} ]
openDate: ISODate("2013-02-15 10:00”)
…
}
> db.accts.find( { accountOwners: {$elemMatch: {
lastName: “Smith”,
address: “52 Vanderbilt Ave.”}}} )
26](https://image.slidesharecdn.com/mongodbsingle-131204125841-phpapp01/85/Webinar-Making-A-Single-View-of-the-Customer-Real-with-MongoDB-25-320.jpg)
![General document per customer per
account
{
_id : ObjectId("4e2e3f92268cdda473b628f6"),
sourceIDs: {
ABCSystemIDPart1: 8397897,
OR creditCardNumber: 8392384938391293
ABCSystemIDPart2: 2937430,
OR mortgageID: 2374389
OR policyID: 18374923
ABCSystemIDPart3: 932018 }
accountType: “Checking”,
accountOwners: [
{ firstName : ”John",
lastName: “Smith”,
contactMethods: [
{ type: “phone”, subtype: “mobile”, number: 8743927394},
{ type: “mail”, address: “58 3rd St.”, city: …} ]
possibleMatchCriteria: {
govtID: 2938932432, fullName: “johnsmith”, dob: … } },
{ firstName : ”Anne",
maidenName: “Collins”,
lastName: “Smith”, …} ],
openDate: ISODate("2013-02-15 10:00”),
accountFeatures { Overdraft: true, APR: 20, … }
}
27](https://image.slidesharecdn.com/mongodbsingle-131204125841-phpapp01/85/Webinar-Making-A-Single-View-of-the-Customer-Real-with-MongoDB-26-320.jpg)
![Query For First Product and Then All
// Customer knows his/her account number
> db.accts.find( {accountNumber: 9789732839} )
// Use looked up account to find other accounts
db.accts.find( {matchCriteria.ssn: 8973829438} )
// In reality, it’s more complicated
> db.accts.find({
$or: [ {mc.fullName: “johnsmith”, mc.dob: “01/01/1970”},
{mc.ssn: 8923784789},
{mc.homePhone: 29838923845}, … ] })
30](https://image.slidesharecdn.com/mongodbsingle-131204125841-phpapp01/85/Webinar-Making-A-Single-View-of-the-Customer-Real-with-MongoDB-29-320.jpg)
![Query For All Products Without ID
// Customer only knows phone number
> db.accts.find({ contactMethods.number: 9789732839
lastName: “Smith” } )
// Confirm correct result w/ customer, then pull all accounts
// Same query as before to pull all accounts
> db.accts.find({
$or: [ {mc.fullName: “johnsmith”, mc.dob: “01/01/1970”},
{mc.ssn: 8923784789},
{mc.homePhone: 29838923845}, … ] })
31](https://image.slidesharecdn.com/mongodbsingle-131204125841-phpapp01/85/Webinar-Making-A-Single-View-of-the-Customer-Real-with-MongoDB-30-320.jpg)
![Why [Not] an RDBMS
37](https://image.slidesharecdn.com/mongodbsingle-131204125841-phpapp01/85/Webinar-Making-A-Single-View-of-the-Customer-Real-with-MongoDB-36-320.jpg)
![Why [Not] Other NoSQL DBMSs
38](https://image.slidesharecdn.com/mongodbsingle-131204125841-phpapp01/85/Webinar-Making-A-Single-View-of-the-Customer-Real-with-MongoDB-37-320.jpg)
Webinar: Making A Single View of the Customer Real with MongoDB
- 1. Making A Single View of the Customer Real with MongoDB Marcelo Rocha DaSilva Senior Solutions Architect, MongoDB @SQLorNot
- 2. MongoDB The leading NoSQL database General Purpose 2 Document Database OpenSource
- 3. MongoDB Vision To provide the best database for how we build and run apps today Build –New and complex data –Flexible –New languages –Faster development 3 Run –Big Data scalability –Real-time –Commodity hardware –Cloud
- 4. Fortune 500 & Global 500 • 10 of the Top Financial Services Institutions • 10 of the Top Electronics Companies • 10 of the Top Media and Entertainment Companies • 8 of the Top Retailers • 6 of the Top Telcos • 5 of the Top Technology Companies • 4 of the Top Healthcare Companies 4
- 5. Global Community 5,000,000+ MongoDB Downloads 100,000+ Online Education Registrants 20,000+ MongoDB User Group Members 20,000+ MongoDB Days Attendees 20,000+ MongoDB Management Service (MMS) Users 5
- 6. MongoDB and Enterprise IT Stack CRM, ERP, Collaboration, Mobile, BI Data Management Online Data Offline Data RDBMS Infrastructure OS & Virtualization, Compute, Storage, Network 6 Security & Auditing Management & Monitoring Applications
- 8. MongoDB and Enterprise IT Strategy Legacy Apps Strategic On-Premise SaaS, Mobile, Social Oracle MongoDB Teradata Hadoop Compute Scale-Up Server Commodity HW / Cloud Storage SAN Local Storage / Cloud Network Routers and Switches Software-Defined Networks Database Offline Data 8
- 9. MongoDB Features • JSON Document Model with Dynamic Schemas • Full, Flexible Index Support and Rich Queries • Auto-Sharding for Horizontal Scalability • Built-In Replication for High Availability • Text Search • Advanced Security • Aggregation Framework and MapReduce • Large Media Storage with GridFS 9
- 10. MongoDB Business Value Enabling New Apps Faster Time to Market 10 Better Customer Experience Lower TCO
- 11. Data Integration • Data Integration is about processes and knowing the data well. • Old technologies make progress very difficult and slow • MongoDB enables easy/incremental approach to Enterprise Data View 11
- 12. • Extract customer info from many source systems as often as desired • Load into one database and application • Link data together for each customer • Query for all customer and associated product info at once • Enable CSRs, RMs/Agents, customers, etc. to know all customer and product information at once 13
- 13. Single View of a Customer – Why MongoDB? • Dynamic schema => can handle vastly different data together and can keep improving and fixing issues over time easily • High scale/performance => directly impacts customer experience or CSR MTTR so every second counts • Auto-sharding => can automatically add processing power as customers and products are added • Rich querying => supporting ends users directly requires multiple ways of access and key/value is not sufficient • Aggregation framework => database-supported roll-ups for analysis on data hub for customer information by marketing, sales, etc. • Map-reduce capability (Native MR or Hadoop Connector) => batch analysis looking for patterns and opportunities in data hub 14
- 14. And We’ve Done it Before • MetLife Leapfrogs Insurance Industry with MongoDB-Powered Big Data Application • New York—May 7, 2013—10gen, the MongoDB company, today announced that MetLife, Inc. selected MongoDB as the data engine for “The Wall”, an innovative customer service application that went live last month. … • http://www.10gen.com/press/metlife-leapfrogs-insurance-industry-mongodbpowered-big-data-application 15
- 15. High Level Data Flow Source Source database 11 database Source Source database 22 database ETL or Custom app OLTP/real-time access Document •per product •per customer CSR Application CSR Application Customer Customer Application Application … Agent/RM Agent/RM Application Application Source Source database N database N 16 Queue to Update Queue to Update Source Systems Source Systems
- 16. Case Study: Tier 1 Global Insurance Provider Single global view of customers’ product portfolio and interactions Problem • Siloed view of customer across products • Changing policy definitions takes months or more • Source systems are critical but stuck on old technology 17 Why MongoDB • Leverage dynamic schema to include evolving policy details Results • Able to deliver in 3 months with $2M, when previous attempts costing $25M failed with no results • One data hub across all • Unified customer view for contact channels for consistent customer view call center and web site with changes available to • Leverage replication for all channels high availability to reduce • Dramatically lower cost pressure on ops team through less and shorter • Leverage sharding to calls scale linearly
- 17. Case Study: Tier 1 Global Insurance Provider Source Source database 11 database Custom app exports JSON OLTP/real-time access CSR Application CSR Application Source Source database 22 database Customer Customer Application Application … Source Source Database 40 Database 40 18 Document •per product •per customer Agent/RM Agent/RM Future phases Future phases Application Application
- 18. Pre requisite Data Analysis
- 19. What questions to answer to feed into design? • What is the scope of customer info to aggregate? – Start with a manageable amount – Focus on satisfying particular valuable purposes (e.g minimizing MTTR and re-routed calls) – Need executive political support to get time from all groups • How to link data across customers and products? – Identify the rules both exact and fuzzy – Specify common fields – Try to normalize but dynamic schema is tolerant – Can always refine rules as you go even based on human feedback 20
- 20. Load Data into MongoDB
- 21. Customer Records in Source Systems, e.g. banking Personal Bank Accounts Personal Bank Accounts •Account ID •Account ID •Open date •Open date •First name •First name •Last name •Last name •Joint First Name •Joint First Name •Joint Last Name •Joint Last Name •Joint SSN •Joint SSN •Address •Address •City •City •State •State •Zip •Zip •Address 22 •Address •Home phone •Home phone •Work phone •Work phone •APR •APR •Account type •Account type •Branch ID •Branch ID •Region ID •Region ID •…. •…. 22 Credit Cards Credit Cards •CC number •CC number •SSN 11 •SSN •Full name 11 •Full name •Address 11 •Address •City 11 •City •State 11 •State •Zip 11 •Zip •SSN 22 •SSN •Full Name 22 •Full Name •Address 22 •Address •City 22 •City •State 22 •State •Zip 22 •Zip •Primary phone 11 •Primary phone •Mobile phone 22 •Mobile phone •Issue date •Issue date •Reward type •Reward type •…. •…. Mortgages Mortgages •Mortgage ID •Mortgage ID •Borrower name •Borrower name •Borrower SSN •Borrower SSN •Borrower address •Borrower address •Borrower city •Borrower city •Borrower state •Borrower state •Borrower zip •Borrower zip •Co-borrower SSN •Co-borrower SSN •Co-borrower name •Co-borrower name •Co-borrower address •Co-borrower address •Co-borrower city •Co-borrower city •Co-borrower state •Co-borrower state •Co-borrower Zzp •Co-borrower Zzp •Mobile phone •Mobile phone •Effective date •Effective date •Term •Term •Interest •Interest •Money down •Money down •Principal loan •Principal loan •Total loan •Total loan •…. •….
- 22. Bank Account JSON Document { _id : ObjectId("4e2e3f92268cdda473b628f6"), accountID: 9874983789, accountType: “Checking”, firstName : ”John", lastName: “Smith”, address: “52 Vanderbilt Ave.”, homePhone: “123-456-7890”, workPhone: “897-389-8987”, openDate: ISODate("2013-02-15 10:00”) … } > db.accts.find( { accountID: 9874983789} ) 23
- 23. P&C Policy Document { _id : ObjectId("4e2e3f92268cdda473b628f6"), policyNumber: 2398439343, policyType: “Homeowners”, firstName : ”John", lastName: “Smith”, address: “52 Vanderbilt Ave.”, homePhone: “123-456-7890”, workPhone: “897-389-8987”, openDate: ISODate("2013-02-15 10:00”) … } > db.policies.find( { lastName: “Smith”} address: “52 Vanderbilt Ave.” ) 24
- 24. Bank Account JSON Document { _id : ObjectId("4e2e3f92268cdda473b628f6"), accountID: 9874983789, accountType: “Checking”, firstName : ”John", lastName: “Smith”, address: “52 Vanderbilt Ave.”, contactMethods: { mobile: “389-897-8987”, home: “983-893-3873”, email: “[email protected]”, work: “298-389-8983” } openDate: ISODate("2013-02-15 10:00”) … } > db.accts.find( { “contactMethods.mobile”: “983-893-3873” } ) 25
- 25. Joint Bank Account Document { _id : ObjectId("4e2e3f92268cdda473b628f6"), accountID: 9874983789, accountType: “Checking”, ownershipType: “Joint” accountOwners: [ { firstName : ”John", lastName: “Smith”, address: “52 Vanderbilt Ave.”, …}, { firstName : ”Anne", lastName: “Smith”, address: “52 Vanderbilt Ave.”, …} ] openDate: ISODate("2013-02-15 10:00”) … } > db.accts.find( { accountOwners: {$elemMatch: { lastName: “Smith”, address: “52 Vanderbilt Ave.”}}} ) 26
- 26. General document per customer per account { _id : ObjectId("4e2e3f92268cdda473b628f6"), sourceIDs: { ABCSystemIDPart1: 8397897, OR creditCardNumber: 8392384938391293 ABCSystemIDPart2: 2937430, OR mortgageID: 2374389 OR policyID: 18374923 ABCSystemIDPart3: 932018 } accountType: “Checking”, accountOwners: [ { firstName : ”John", lastName: “Smith”, contactMethods: [ { type: “phone”, subtype: “mobile”, number: 8743927394}, { type: “mail”, address: “58 3rd St.”, city: …} ] possibleMatchCriteria: { govtID: 2938932432, fullName: “johnsmith”, dob: … } }, { firstName : ”Anne", maidenName: “Collins”, lastName: “Smith”, …} ], openDate: ISODate("2013-02-15 10:00”), accountFeatures { Overdraft: true, APR: 20, … } } 27
- 27. Querying for single view
- 28. Index any fields: arrays, nested, etc // Compound indexes > db.accts.ensureIndex({accountID: 1, lastName:1}) // Index on embedded docs and arrays >db.accts.ensureIndex( {contactMethods.mobile: 1}) // Index on any depth > db.accts.ensureIndex( {“owners.matchcriteria.ssn”: 1} ) 29 // Full text search > db.accts.ensureIndex ( { address1: “text”, address2: “text” } )
- 29. Query For First Product and Then All // Customer knows his/her account number > db.accts.find( {accountNumber: 9789732839} ) // Use looked up account to find other accounts db.accts.find( {matchCriteria.ssn: 8973829438} ) // In reality, it’s more complicated > db.accts.find({ $or: [ {mc.fullName: “johnsmith”, mc.dob: “01/01/1970”}, {mc.ssn: 8923784789}, {mc.homePhone: 29838923845}, … ] }) 30
- 30. Query For All Products Without ID // Customer only knows phone number > db.accts.find({ contactMethods.number: 9789732839 lastName: “Smith” } ) // Confirm correct result w/ customer, then pull all accounts // Same query as before to pull all accounts > db.accts.find({ $or: [ {mc.fullName: “johnsmith”, mc.dob: “01/01/1970”}, {mc.ssn: 8923784789}, {mc.homePhone: 29838923845}, … ] }) 31
- 31. Text Search Example (e.g. address typo so do fuzzy match) // Text search for address filtered by first name and NY > db.ticks.runCommand( “text”, { search: “vanderbilt ave. vander bilt”, filter: {name: “Smith”, city: “New York”} }) 32
- 32. Analyzing/Aggregating Options • Custom application code – Run your queries, compute your results • Aggregation framework – Declarative, pipeline-based approach • Native Map/Reduce in MongoDB – Javascript functions distributed across cluster • Hadoop Connector – Offline batch processing/computation 33
- 33. Aggregate: Total Value of Accounts //Find total value of each customer’s accounts for a given RM (or Agent) sorted by value db.accts.aggregate( { $match: {relationshipManager: “Smith”}}, { $group : { _id : “$ssn”, totalValue: {$sum: ”$value”} }}, { $sort: { totalValue: -1}} ) 34
- 34. Why MongoDB is the most capable?
- 35. Single View of a Customer – Why MongoDB? Dynamic schema => can handle vastly different data together and can keep improving and fixing issues over time easily High scale/performance => directly impacts customer experience or CSR MTTR so every second counts Auto-sharding => can automatically add processing power as customers and products are added Rich querying => supporting ends users directly requires multiple ways of access and key/value is not sufficient Aggregation framework => database-supported roll-ups for analysis on data hub for customer information by marketing, sales, etc. Map-reduce capability (Native MR or Hadoop Connector) => batch analysis looking for patterns and opportunities in data hub 36
- 36. Why [Not] an RDBMS 37
- 37. Why [Not] Other NoSQL DBMSs 38
- 38. Summary of Value
- 39. Before MongoDB Solution CSR Application CSR Application CSR Application CSR Application CSR Application CSR Application CSR Application CSR Application CSR Application CSR Application 40
- 40. With MongoDB Solution CSR Application CSR Application Single Customer Single Customer Portal Portal 41
- 41. Short-term Value over the Long-Term 1. CSR Application – – – – – Minimize calls routed to other call centers Shorter MTTR because CSR has all information More efficient staffing because can pool CSRs better More effective cross-sell/upsell Better customer satisfaction 1. Customer portal – Minimize calls needed at all – Better customer service – More effectively cross-sell/upsell 42
- 42. Short-term Value over the Long-Term 3. Regulatory Compliance Initiative – Minimize KYC or other regulatory risks – Turn compliance costs into costs savings or revenue generation 3. Marketing – Analyze buying patterns more completely – Target much more accurately for better results 3. Relationship Manager or Agent Application – Effectively cross-sell/upsell and increase wallet share – Provide better, more complete customer service 43
- 43. Summary • MongoDB is the most capable for a single view of a customer • Dynamic schema can handle data from numerous different systems all in one place • Fast, flexible querying, analysis, & aggregation is necessary to get maximum value • High performance both on a single machine and automatically across a cluster by auto-sharding • MongoDB has all these features with low TCO • 10gen has helped others with this and can help you 44
- 44. For More Information Resource MongoDB Downloads www.mongodb.org/download Free Online Training education.mongodb.com Webinars and Events www.mongodb.com/events White Papers www.mongodb.com/white-papers Customer Case Studies www.mongodb.com/customers Presentations www.mongodb.com/presentations Documentation docs.mongodb.org Additional Info 45 Location User Data Management [email protected]
Editor's Notes
- #5: Customers (not just users)
- #7: This is where MongoDB fits into the existing enterprise IT stack MongoDB is an operational data store used for online data, in the same way that Oracle is an operational data store. It supports applications that ingest, store, manage and even analyze data in real-time. (Compared to Hadoop and data warehouses, which are used for offline, batch analytical workloads.)
- #9: MongoDB is aligned with strategic IT initiatives – like new apps in mobile, etc.; commodity hardware and cloud computing; Hadoop; and so on Just like enterprises are focusing now on apps in mobile, SaaS, and social, and spending less time on innovating on legacy apps… Enterprises are increasingly looking at moving away from Oracle and other proprietary systems to modern data stores like MongoDB to support new app development (and even for migrate legacy applications)
- #10: MongoDB provides agility, scalability, and performance without sacrificing the functionality of relational databases, like full index support and rich queriesIndexes: secondary, compound, text search, geospatial, and more
- #12: Customers (not just users)
- #23: JSON document – contains key value pairs, different types, values can also be arrays and other documents
- #24: JSON document – contains key value pairs, different types, values can also be arrays and other documents
- #25: JSON document – contains key value pairs, different types, values can also be arrays and other documents
- #26: JSON document – contains key value pairs, different types, values can also be arrays and other documents
- #27: JSON document – contains key value pairs, different types, values can also be arrays and other documents
- #28: JSON document – contains key value pairs, different types, values can also be arrays and other documents