Campaign Deployment Granularity
Click here to see this page in full context

 Campaign Deployment Granularity

Overview

This topic describes how your solution configuration can impact how data is tracked and recorded within Engage+. We recommend that you first read Permission Management, Multi-Division Client Accounts, and Email Bounce Handling before reading this topic, as those topics contain important background information on some of the concepts presented here.

This topic uses the term "handle" to refer to a specific value that can be used to contact a consumer via a marketing channel. Examples of "handles" could be an email address, a mobile phone number, a Push Notification ID, or a LINE ID. The term "handle" is intended to refer to the value itself, regardless of any complicating factors, such as sending tables, brand identifiers, or Parent / Child systems. When functionality is described as applying to a handle, then this functionality is the same in every channel.

Intuitively, it might seem that all information about a consumer (sending history, opens, clicks, reads, bounces, etc.) would be tracked at the handle level. If you have a consumer named John Smith, and his email address is 'john.smith@yahoo.com,' then it might seem like everything you know about this consumer is tied to that one email address. And it is possible to design a solution where that statement is true.

However, when you start factoring in Engage+'s more complex features -- namely, Parent / Child systems, Sender Profiles, multiple sending tables, and brand identifiers -- then the situation becomes more complicated. It's important to understand how these features impact how data about your consumers is tracked and managed, so that the Onboarding team can help you design a solution that best meets your marketing strategy and business requirements.

Campaign Granularity

All Campaigns deployed from Engage+ must start within a selected System (see Multi- Division Client Accounts for more information on Systems), from a designated table. This table is typically referred to as the "deployment table," or the "sending table." You must have at least one sending table that you use for deploying Campaigns, but you can optionally have more than one sending table. For example, you could have a 'Recipient' table that you use to send out promotional Campaigns, like special offers, and an 'Order' table that you use for sending transactional Campaigns, like shipping notifications.

Each sending table must include at least one, and optionally more than one, Sender Profile (see Sender Profiles for further details) that controls the "from" information, and manages and tracks each recipient's eligibility for being contacted.

Within the sending table, Clients store the handles that they'll use to contact their consumers. Clients will often use a handle as the table's Unique Identifier, which means that each handle must be unique, and therefore can only appear once in the sending table. However, it's possible for the same handle to appear multiple times within the same sending table. For example, if a Client uses a brand identifier column, and a consumer can be contacted by multiple brands, then that consumer's handle would appear in more than one physical record within that sending table.

The combination of these four elements -- System, sending table, Sender Profile, and record -- is utilized to track send events and all Campaign-related activity in Engage+. This information is not tracked at the level of the handle itself.

For a Client with a single System, a single sending table, a single Sender Profile, and a single brand, the situation is straightforward. All information about a handle will be tracked and stored within the single record for that consumer.

 

However, Clients often have multiple Systems, multiple sending tables, multiple Sender Profiles, and / or multiple brands, which can create a much more complicated scenario, even when contacting a consumer via the same handle.

It's important to understand this aspect of the platform because of the following implications:

Scenarios

This section describes different scenarios, or use cases, in order to further examine how Systems, sending tables, Sender Profiles, and records work together to track and manage activity.

Scenario 1 -- Different Records

In this scenario, the Client has a single System, deploys Campaigns from the same sending table, has only one Sender Profile, but utilizes a <brand_id> column to distinguish between multiple brands. With this configuration, the same outbound channel handle could potentially appear multiple times in the sending table because of the different brand identifiers. The Client is creating and deploying Campaigns for multiple brands, and the same handle is promoted in each of these Campaigns, but from different physical records.  

In the example depicted below, the same handle ("john.smith@yahoo.com") is a customer of three different brands. Therefore, the same handle appears in three different physical records. The Client deploys Campaigns for Brands A and C, using a Filter to identify the correct target audiences. For Brand A, this handle has an eligible Status ID of "100," and the message is successfully deployed. However, this same handle for Brand C has an ineligible Status ID of "1500," so this consumer is automatically suppressed from the Brand C Campaign.

In this example, you can see how the same handle is eligible to be contacted by one brand, but not by another brand, because each physical record maintains its own separate Status ID field.

The implications of this configuration are as follows:

Scenario 2 -- Different Sender Profiles

In this scenario, the Client has a single System, deploys Campaigns from the same sending table, but different Sender Profiles have been created for each brand that the Client supports. The handle is the Unique Identifier for the sending table. With this configuration, the same outbound channel handle will appear only once within the sending table. The Client is creating and deploying Campaigns for multiple brands, and the same handle is promoted in each of these Campaigns, but from the same physical record.

In the example depicted below, the same handle ("john.smith@yahoo.com") is a customer of two different brands. Therefore, the same handle appears once in the sending table, but with two different corresponding Status ID fields -- one for each Sender Profile. The Client deploys two Campaigns, using the two different brand-specific Sender Profiles. For Sender Profile A, this handle has an eligible Status ID, and the message is successfully deployed. However, this same handle for Sender Profile B has an ineligible Status ID of "1500," so this consumer is automatically suppressed from the Brand B Campaign.

In this example, you can see how the same handle is eligible to be contacted by one brand, but not by another brand, because each brand-specific Sender Profile maintains its own separate Status ID field.

The implications of this configuration are as follows:

Scenario 3 -- Different Sending Tables

In this scenario, the Client has a single System and a single Sender Profile, but deploys Campaigns from two different sending tables -- one for promotional marketing purposes, and another one for remarketing purposes. With this configuration, the same outbound channel handle could appear in both tables.

In the example depicted below, the same handle ("john.smith@yahoo.com") is present in both sending tables. The same Sender Profile has been assigned to both tables. Each table maintains its own corresponding Status ID field for that Sender Profile. The Client deploys two Campaigns -- one each from the Recipient table and the Remarketing table. In the Recipient table, this handle has an eligible Status ID of "100," and the message is successfully deployed. However, this same handle on the Remarketing table has an ineligible Status ID of "1500," so this consumer is automatically suppressed from the remarketing Campaign.

In this example, you can see how the same handle is eligible to be contacted by Campaigns generated from one sending table, but not from the other sending table, because each table maintains its own separate Status ID field for the Sender Profile.

The implications of this configuration are as follows:

Scenario 4 -- Different Systems

In this scenario, the Client has a Parent / Child architecture with a Parent system and two brand-specific Child systems. The Client uses a single sending table, and this table is configured so that records are viewable by the Child systems based on whether or not the consumer's handle belongs to the brand represented by that Child system. In this scenario, the Client creates and deploys Campaigns directly from each Child system for the brand in question. The Client utilizes a single Sender Profile.

In the example depicted below, the same handle ("john.smith@yahoo.com") is a customer of both brands, and therefore is accessible to both Child systems. Each table maintains its own corresponding Status ID value for the Sender Profile. The Client deploys two Campaigns -- one each from the Brand A Child System and the Brand B Child System. In the Brand A Child System, this handle has an eligible Status ID of "100," and the message is successfully deployed. However, this same handle in the Brand B Child System has an ineligible Status ID of "1500," so this consumer is automatically suppressed from this brand's Campaign.

In this example, the same handle belongs to both brands, and therefore is available in both brand-specific Child systems. You can see how the same handle is eligible to be contacted by Campaigns generated from one Child system, but not from the other Child system, because each Child maintains its own separate Status ID value for the Sender Profile.

The implications of this configuration are as follows:

Back to Getting Started with Engage+

 

 

 Copyright © Marigold    Marigold Engage+ Online Help v24.8.0  August 2024