Multi Brand Database vs. Single Brand Database

Ascent360 can build two fundamentally different types of databases for our clients. These are typically defined as:

  1. Multi Brand Database, Conglomerate database or Multi Resort Database: This type of database is typically used by clients who have multiple brands, resorts or hotels that all want to communicate with customers as separate brands. Hereafter in the documentation this will be called a "Multi-Brand Database".
  2. Single Brand, Single Resort or Retail "Location" based Database: This type of database is typically used by a brand that only has one brand within the ownership portfolio OR it may be a retailer with lots of locations or a resort / hotel with only one brand name. Typically this means that our client will market to their customers under a single brand. Hereafter in the documentation this will be called a Single Brand Database.


  • Multi Brand Database:  Johnson outdoors would be a good example of a Multi Brand Database.  Johnson Outdoors owns many brands such as Eureka Tents, Jetboil, and Minn-Kota Motors.  An end consumer typically does not know, care or understand that Jetboil is owned by Johnson Outdoors.  All of the individuals in the Jetboil database are treated separately from the individuals in the Eureka Database.  Even if the same person exists in both databases, they will be treated separately.  They will each have their own email permission, their total lifetime spend will be different and either their Customer Status may be different (In the Eureka database, John Smith may be a "Customer" and if he also exists in the Jetboil database he may be a "Prospect").  The same people do not need to be in both databases.
  • Single Brand Database:  A good example of a single brand database would be "Alpine Shop".  Alpine shop has 5 store locations, but they market to their customers under only one brand.  Each person in the Alpine Shop database will be de-duped and will have a unique "Individual ID".  They will each have their own email permission and lifetime spend will be a calculation against 100% of the records associated with them in the database.  It may be true that an individual will shop a different store locations or even via the Alpine Shop eCommerce site, however the person will not be in different store location databases.  Their transactions will be tagged with the location of the store but each store will not treat customers as different people like different brands will.

How the Single Brand Database Works:

A single brand database is pretty simple conceptually.  If a client has just one brand such as the Alpine Shop example above, than we should use a Single Brand Database.

Using Locations to Sub-divide a Single Brand Database:

Most of the time, a Single Brand database does have some of the same ideas as a multi brand database.  This is why Ascent360 has created the concept of "Locations".  As an example, a retailer may have many locations.  Sally Smith may buy products from Store 1 and then later other products from Store 5.  The sales manager at Store 5 may be very interested to know that Sally has been a customer of his store.  He may even want to communicate with Sally via email message.  To make this happen successfully, the data that we ingest should include the Store number or "Location ID".  Another example may be a ski resort.  The ski resort may have 2 hotels, a spa, a golf course and "The Mountain".  The manager at Hotel A, may want to know that Sally stayed at his hotel while the owner of the ski resort will want to know all of Sally's transactions.

Individuals within a Single Brand Database:

Individuals within a single brand database are all fully "De-duped" and assigned an Ascent360 ID.  As shown below there will not be a ConglomID.  However every transaction will be tagged with a Location.  The location could be the Store ID for a retailer or the Property ID for a Hotel Chain.

Aggregates and Permissions in a Single Brand Database:

Aggregates and permissions are really simple in a single brand database.  Basically they are set at the database level.  This means that all spend metrics or email permission for an individual is the same across the whole database.  This also means that we do not try to create metrics or aggregates for each location.  So as an example, we do not try to store the email permission for an individual at a specific store.

Access Rights for Single Brand Databases:

A user who has access to see and use data for Brand A, will have access to see ALL of the data from ALL locations.  We do not restrict users to only see some data from some locations.  (If this is important, you may want to use a Multi Brand database).  NOTE:  Users can be setup that do not have access to specific features in our system, so as an example, a user may be blocked from creating or exporting segments from the database and be allowed to see just reports.  We will not limit those reports to just a few locations however...they will be able to see all locations.

How the Multi Brand Database Works:

A multi brand database has a "Parent Child Structure".  This means that there is a Parent Account with lots of "Children" or brands within it.  A multi brand database is very similar to many different single brand databases that all share the same "Parent".  To be very clear, the Parent is really more of a view into all of the Child databases and is not a separate database itself.  As the image below shows, there are three brand databases.  The parent view can see all children.

Individuals Across Databases:

In the below example, we have three Brand databases all with the same person named John Smith.  As you can see, in each database John has a different Ascent360ID.  This effectively means that he is a different individual in each database.  However there is a ConglomID that is the same across all three databases.  This is how we know that John is really the same person across all three databases (or across the conglomerate) .

Aggregates in Multi Brand Databases:

Aggregates and Derived Variables are calculated at the brand level, not at the Parent Level.  As shown in the example below.  You can see that the total spend for John Smith is $500 in Brand A.  This is because for that brand John has spent a total of $500.  He has made 3 purchases and the last time he purchased was October 10th, 2018.

Why are the fields calculated at the brand level?  If you put yourself in the shoes of the VP of Marketing or the Head of Ecommerce for Brand A, they are really only trying to market the products for Brand A.  It is not really helpful for them to know how much John spent on products with Brand B.  If they want to send a post purchase email, it will need to be based upon a transaction with Brand A.  It is true that the CEO may want to know about cross brand purchases, but this will come from the reporting and business intelligence functionality, not the marketing functionality.

An individual can live in each Brand Database and roll up to the parent.  As an example:

  • John Smith Skied at “Brand A” in 2016 and bought a Season Pass in "Brand A" in 2016 for $500.  He also took lessons at "Brand B" in 2015 for $100 and again at "Brand B" in 2016 for $100.  
  • John would be in the "Brand A" Database.  His lifetime spend would be $500 and his “years customer” would be 1.  He would also be in the "Brand B" database.  His Total spend would be $200 and years customer would be 2
  • John would be in the “Parent" database (for reporting only).  John would have 3 transactions and a lifetime spend of $700.
  • John would be available to email from Brand A and Brand B.   If he unsubscribes from Brand A, than he would still be subscribed at Brand B

Permissions for Multi-Brand Database:

Permissions are stored at the brand level and not the parent level.  So John Smith may be subscribed to email for Brand A, but Unsubscribed for Brand B.  There is no concept of a multi brand permissions.  (this would typically break the common email permission laws.)

For a much more detailed understanding of how email permissions work please see here.

Reporting and Marketing:

Perhaps the most important concept for the multi brand database  is how it will be used by our clients.  As shown below, each Brand database will allow users to create reports, create segments, create campaigns and schedules and conduct their marketing activities.  At the parent level (Multi Brand Conglom) it is only possible to create reports. (Since permissions are all stored at the brand level, than you cant really have permissions across brands.  So, at the Parent level, only reports can be create.  You can't create segments, campaigns, schedules etc across brands.

Permissions for Multi Brand Databases:

Permissions are set for either the parent database or for child databases.  This means that an individual with access to the parent database can see all children.  This is how User A is setup in the below example.  User B is allowed only to see data from Brand B.  This is great news to the executives at the Parent company.  What this means is that User B can not see the data from Brand C.  It also means that User B can not accidentally send emails to individuals in Brand C.

Marketing from a Multi-Brand Database:

It is not possible to market directly from the "parent" in a multi brand database.  The marketing will occur from each of the child databases where permissions will be stored.