Unify Your Selling Channels in One Product Catalog

Edouard Servan-Schreiber, Ph.D.Director for Solution Architectureedss@mongodb.com

2

Who is MongoDB:

MongoDB (from humongous) is an open-source, game-changing operational database technology, designed to enable information capture, sharing and distribution to meet the needs and behaviors of today’s digitally-oriented society.

Who is MongoDB?

Retail at War: How to Differentiate?

• Retail Information

• Personalized Selling

• Existing applications

& technology?

4

• A document model (holds mixed, variant data)

• Ability to add new & different data (agility)

• Ability to ask real-time questions based on right now

update (complex querying & in-place updating)

• Geo-Location built-in

• Power of traditional data bases (full consistency,

durability, atomic operations)

• Near linear expansion (scaling via sharding)

• MongoDB is a unique fit for frictionless retail

MongoDB powers

Systems of Engagement

1. “Global Product 360”

Theme: Product details & location up-to-minute;

Vendors, payment

4 Use Cases: Modern, Seamless Retail

2. Consolidated Customer View

Theme: Single View of Customer, Consumer 360

4 Use Cases: Modern, Seamless Retail

3. Channel Innovation (Ecommerce, Mobile, Social etc.)

Theme: Back-end system integration, product details & geo-location up-to-minute

4 Use Cases: Modern, Seamless Retail

4. Relevant Personalization:

Via technology to consumer

Theme: Relevance & convenience

Embedding into daily life

4 Use Cases: Modern, Seamless Retail

9

Traditional Mental Model

10

MongoDB Mental Model

11

Retail Data Platform

12

Systems of Engagement

The Product Catalog Problem

14

Single view of a product, one central service

• Flexible schema containing all useful data

• Read volume high and sustained, 100k reads / s

• Can seamlessly take write spikes during catalog

update

• Advanced indexing and querying

• Geographical distribution for HA and low latency

Merchandising Objective:

“Global Product Service”

15

1. One department in charge of master product works hard at fitting

data into SQL tables

2. Resulting data sits in a SQL server with a couple replicas. It's

forbidden to hit it more than 100 times / sec

3. Other departments need to access the data way more often for

their own services

4. Other departments need more information that is not available

since it did not fit in that long devised rigid SQL schema

5. ETLs and Message Buses are put in place for other teams to try

figure it out themselves…

6. Data becomes inconsistent, fragmented, not up-to-

date…Problem visible both internally and by customers!

The Reality: Many catalogs

16

Product Information Complexity

Ecommerce Shop

Catalog

Stores

Catalog

Content Management

Catalog

Product

Merchandising

Operations

Master

Catalog

Department 4

Catalog

Search

Catalog

Store Associates

Catalog

Message

Bus

ETLs

Dozens of catalogs!

18

• Read intensity

– 100K+ reads per second (think peak time)

– Omnichannel means it is not acceptable to lose a sale because your IT crawls

• Flexibility

– Each facet of the business needs slightly different data

– And they each want to change it often

• Who has the system of record when you have

12 copies around??

What is hard about this?

19

MongoDB Data Layer

Product Information

MongoDB Architecture

Items Pricing Promotions

VariantsRatings &

Reviews

Product Service API

…

Digital ShopStore +

AssociatesInventory SCMS Public API Search, CMS, …

20

Product Page – What does it mean?

Product

images

General

Informatio

n

List of

Variants

External

Informatio

n

Localized

Description

21

• Item: the overall product info (e.g. Levi’s 501)

• Variant: a specific variant of an item (e.g. in black size 6)

which typically has a specific SKU / UPC

– Note: each model can have thousands of variants, each variant

can have hundreds of attributes

• Price: price information may vary based on the store, the

variant, etc

• Hierarchy: the item taxonomy

• Facet: facets to search products by

• Vendors: a given sku may be available through several

vendors if the site is a marketplace

Retail Product Model - Overview

22

> db.item.findOne()

{ _id: "301671", // main item id

department: "Shoes",

category: "Shoes/Women/Pumps",

brand: "Guess",

thumbnail: "http://cdn…/pump.jpg",

image: "http://cdn…/pump1.jpg", // larger version of thumbnail

title: "Evening Platform Pumps",

description: "Those evening platform pumps put the perfect finishing touches on your most glamorous night-on-the-town outfit",

shortDescription: "Evening Platform Pumps",

style: "Designer",

type: "Platform",

rating: 4.5, // user rating

lastUpdated: Date("2014/04/01"), // last update time

… }

Product - Item Data Model

23

> db.variant.findOne()

{

_id: "730223104376", // the sku

itemId: "301671", // references item id

thumbnail: "http://cdn…/pump-red.jpg", // variant specific

image: "http://cdn…/pump-red.jpg",

size: 6.0,

color: "Red",

width: "B",

heelHeight: 5.0,

lastUpdated: Date("2014/04/01"), // last update time

…

}

Product – Variant Model

24

MongoDB Data Store

Product Catalog - Data Layer Design

Don’t do it all in a single collection!

SummariesItems Pricing

PromotionsVariantsRatings &

Reviews

#1 Obtain

results

25

The summary relies on the following parameters:

• department e.g. "Shoes"

• An indexed attribute

– Category path, e.g. "Shoes/Women/Pumps"

– Price range

– List of Item Attributes, e.g. Brand = Guess

– List of Variant Attributes, e.g. Color = red

• A non-indexed attribute

– List of Item Secondary Attributes, e.g. Style = Designer

– List of Variant Secondary Attributes, e.g. heel height = 4.0

• Sorting, e.g. Price Low to High

Product – Summary Model

26

• Get item by id

db.definition.findOne( { _id: "301671" } )

• Get item from Product Ids

db.definition.findOne( { _id: { $in: ["301671", "301672" ] } } )

• Get items by department

db.definition.find({ department: "Shoes" })

• Get items by category prefix

db.definition.find( { category: /^Shoes\/Women/ } )

• Indices

productId, department, category, lastUpdated

6. Product: Representative Queries – Item

27

• Because now I can do NEW things much more

easily

• Suppose you want to enable search based on

weather…..

– “winter coats”

– “shoes for the rain”

– ….

• Suppose you want to build a universal shopping

cart to work across multiple brands and devices

Why is this important?

28

{ "_id": "3ZZVA46759401P", // the item id"name": "Women's Chic - Black Velvet Suede","dep": "84700", // useful as standalone for indexing"cat": "/84700/80009/1282094266/1200003270","desc": { "lang": "en", "val": "This pointy toe slingback ..." },"img": { "width": 450, "height": 330, "src": "http://..." },"attrs": [ // global attributes, easily indexable by SE

"heel height=mid (1-3/4 to 2-1/4 in.)","brand=metaphor","shoe size=6","shoe size=6.5", ...”weather=cold"

],"sattrs": [ // global attributes, not to be indexed

"upper material=synthetic","toe=open toe", ...

],"vars": [

{ "id": "05497884001","img": [ // images],"attrs": [ // list of variant attributes to index ]"sattrs": [ // list of variant attributes not to index ] }, …

] }

Search – Summary Model

29

• No need to change a data model

• No need to make this change in

multiple catalogs

• When YOU come to my site, I can get

the weather of YOUR location and

show a homepage with items aligned

to YOUR environment

– This is demonstrated to be very

effective

– Think of the poor stores trying to sell

sandals last spring in Manhattan….

• This took almost no effort !

What’s marvelous about this?

30

• Persist your cart across

devices and sessions

• Extend the service across

all your brands

• Leverage MongoDB’s tag

aware sharding to persist

and replicate over

multiple continents

• Deliver low latency

everywhere

Universal Shopping Cart

31

• Retailers need to identify HOT and NEW events

• Need to know what is going to happen before it happens

– Purchases, add to cart, browse, click

Identify Product Trends

32

• In slices of 10 minutes, just increment the events

as they come

• Can maintain multiple trending metrics and

change flexibly

• Leverage results of past hour to make content

dynamic

• This requires no Hadoop, Kafka, Storm nor Spark

Simple Real Time Analytics

Tracking samples:{ "_id" : ”*********" , ”cart_count" : 14, “purchases”: 2}{ "_id" : ”**********" , "cart_count" : 2}{ "_id" : ”*********" , "cart_count" : 10138}{ "_id" : ”**********" , "cart_count" : 1648}{ "_id" : ”*********" , "cart_count" : 10852}

Single operations to insert / update:Db.track.update( { _id: ”123498745" },

{ $inc: {cart_count: 1 } })

33

• Retail is changing and requires dynamic engagement

across all channels

• The known IT models cannot support this appropriately

• MongoDB can support these new systems of engagement

by simplifying the data infrastructure and making changes

flexible

• MongoDB built assets for a Retail architecture

• Enables powerful new business value through

– Single view of product

– Universal shopping cart

– Streaming analytics

– Single view of customer

– ….

Take Aways

Thank You !