Ascent360 can build two fundamentally different types of databases for our clients. These are typically defined as:
- 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".
- 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.
Examples:
- Multi-Brand Database: A parent company with multiple separate child business entities may choose to maintain multiple separate Ascent360 databases that roll up into a "Multi-Brand" Conglomerate database. If the marketing efforts, source systems, and permissions for one database have no bearing on the efforts, systems, and permissions of another database, it is often best to use a Multi-Brand approach. Permissions, integrations, and reporting will be maintained separately. For reporting that groups together the metrics of multiple databases, Ascent360 will configure a conglomerate database for the client.
- Single Brand Database: The vast majority of Platforms that Ascent360 builds are single brand databases. A single brand database is appropriate for clients that maintain one business entity and control one singular marketing effort. Businesses that have multiple store locations will generally still maintain one Ascent360 database.
Single Brand Database Considerations
Locations in a Single Brand Database
Ascent360 uses "Location" as the primary method for segmenting a single brand database into multiple store locations. Most often, this information comes directly from the integration but can be derived as well.
Individuals within a Single Brand Database:
Individuals within a single brand database are all fully de-duplicated as a part of the matching and cleansing process and assigned an Ascent360 ID. Individuals will have the same "Ascent360" unique identifier if matched across multiple sources or locations.
Aggregates and Permissions in a Single Brand Database:
In a single brand database, all aggregate metrics or email permissions for an individual are 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.
Client 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. Ascent360 does not restrict user permissions based on location (if this is important, you may want to use a Multi Brand database).
Ascent360 can limit user permissions based on platform feature only.
Multi Brand Database Considerations
A multi brand database has a parent-child structure. In effect, multiple separate Ascent360 CDPs can roll up into a conglomerate, or parent CDP. The conglomerate view is not a separate database with the same CDP functionality as a child, but is primarily used to aggregate reporting from related child databases.
Individuals in Multi Brand Databases:
While data from child databases does roll up into the parent view, child databases do not share data. In the example below, John Smith is effectively considered a separate individual in each child database. Though he maintains a separate Ascent360 ID between each database, he shares the same ConglomID to determine that this is the same individual at the conglomerate level.
Aggregates in Multi Brand Databases:
Aggregates and Derived Variables are calculated at the child level, not at the parent Level.
Because the marketing efforts of one brand have no bearing on the efforts of another brand, aggregates are kept separate between child databases.
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:
Like aggregates, permissions are managed at the child 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 Email Permission Management
Reporting and Marketing:
As shown below, each Brand database will allow users to create reports, create segments, create campaigns and schedules and conduct their marketing activities. Because permissions are managed at the child level, it is infeasible to create segments, campaigns, or schedules at the parent level.
Client Access Rights for Multi Brand Databases:
Permissions are set for either the parent database or for child databases. A user with access to the parent database can see all children.
