Problem Overview

In a large enterprise non-profit organization with a multi-org setup in Marketing Cloud, where the parent business unit is not connected to Salesforce but the child business unit is connected to Sales Cloud, the contact database has 9.5 million contacts. The current approach involves copying data from the contacts synchronized data extension, filtering it, and inserting the segment value into a standard data extension for each campaign.

However, with each additional campaign requiring its own filtered logic and audience data extension, the Web Analytics connector needs to pass the segment value for all campaigns, making it impractical to reference a specific campaign data extension for the segment value.

Solution Approach

The proposed solution involves creating a non-sendable data extension with the subscriber key as the primary key and a column for the segment value. The existing automation that writes the segment value into the campaign data extension would be modified to populate the segment value in the non-sendable data extension instead.

The Web Analytics connector would then be updated to reference the new non-sendable data extension, allowing it to always look up the segment value in the same place, regardless of the campaign, using the subscriber key to match.

Benefits of the Approach

This approach not only solves the immediate problem but also provides a scalable and flexible solution for future needs, where information or tagging is universal for a subscriber and not campaign-specific. It can also reduce the size and manipulation of campaign data extensions.

The root cause of the issue is the lack of a centralized location to store segment values that can be accessed by the Web Analytics connector across multiple campaigns, highlighting the need for a more integrated and scalable approach to data management in Marketing Cloud.

Implementation Steps

SQL Example

/* Example SQL to create a non-sendable data extension */
CREATE TABLE Segment_DE (
  SubscriberKey INT PRIMARY KEY,
  Segment VARCHAR(50)
);

/* Example SQL to insert segment values into the non-sendable data extension */
INSERT INTO Segment_DE (SubscriberKey, Segment)
SELECT SubscriberKey, Segment
FROM Campaign_DE;

Heads up: Ensure that the subscriber key is correctly mapped and used as the primary key in the non-sendable data extension to avoid data inconsistencies.

Checklist for Implementation

Pre-Implementation Checklist

• Create a new non-sendable data extension with the subscriber key as the primary key.
• Add a column for the segment value in the non-sendable data extension.
• Modify the existing automation to populate the segment value in the non-sendable data extension.
• Update the Web Analytics connector to reference the new non-sendable data extension.
• Test the setup to ensure correct segment value lookup across campaigns.
• Monitor data consistency and performance after implementation.

Frequently Asked Questions

What is the primary key in the non-sendable data extension?

The subscriber key should be used as the primary key in the non-sendable data extension.

Can I use contact attributes instead of a non-sendable data extension?

No, contact attributes may not be suitable due to limitations and the need for a centralized location accessible by the Web Analytics connector across campaigns.

How do I ensure data consistency across campaigns?

Ensure that the subscriber key is correctly mapped and used as the primary key in the non-sendable data extension, and monitor data consistency after implementation.

What are the benefits of using a non-sendable data extension for segment values?

The benefits include a scalable and flexible solution for future needs, reduced size and manipulation of campaign data extensions, and a centralized location for segment values accessible by the Web Analytics connector.