Plan your campaign workflow

Before you build a campaign, decide which Customer Studio feature should handle each job: audience qualification, timing, overlap, consent, and measurement. Use this page to plan campaigns that combine audiences, journeys, syncs, experiments, and governance features.

What you'll learn

• How Customer Studio features for campaigns work together
• Which feature should handle each part of the campaign
• When to use journeys instead of an audience sync
• How to manage overlap across campaigns
• How consent and access rules apply at sync time
• How to validate each layer before launch
• Common campaign patterns

How Customer Studio features for campaigns work together

The core Customer Studio flow is:

1. Define a schema
2. Build audiences and traits from that schema
3. Sync those audiences to destinations

Campaign planning features build on that foundation.

Schema defines which records, events, and fields are available for campaign logic. Audiences, traits, journeys, and syncs all depend on the schema. If a required field changes upstream, downstream campaign assets can break.

Audiences define who qualifies for a campaign. They are the starting point for most campaign workflows and feed into syncs, journeys, experiments, and priority lists.

Syncs deliver campaign data to destinations. Messages are not sent from Customer Studio directly. A campaign action only happens when a sync sends data to a downstream tool.

Campaign planning tools control timing, sequencing, overlap, and reuse:

• Journeys handle step order, delays, branching, and exits, but they do not run in real time. Journeys evaluate on a fixed schedule, so entry, movement, exits, and sends only happen when the journey runs.
• Priority lists decide which audience wins when a user qualifies for multiple competing audiences.
• Experiments split eligible users into treatment and holdout groups so you can measure lift.
• Templates let teams reuse approved sync and journey configurations.

Governance features control what can actually be delivered:

• Destination rules apply destination-specific eligibility or consent rules at sync time.
• Row-level access limits which records a team can see and activate.
• OneTrust integration enforces consent before data is sent downstream.
• Data masking redacts or hashes sensitive fields before delivery.

Choose which feature to use

Start with the campaign job you need to do, not with the feature list.

• If you only need to keep a segment updated in a destination, an audience sync may be enough.
• If you need timing, sequencing, or branching, use a journey.
• If you need to resolve conflicts between campaigns, use a priority list or journey exclusions.
• If you need channel-specific eligibility or consent enforcement, use destination rules.
• If you need lift measurement, use an experiment.

Start with one or two campaign patterns you care about most instead of designing a universal framework upfront.

When to use journeys

Not every campaign needs a journey. Many campaign use cases can be handled with a single audience synced on a schedule.

Use a journey when:

• The campaign has multiple steps with timing between them
• Users should follow different paths based on behavior or attributes
• You need in-flow experimentation with A/B Split tiles
• Users should exit early when they complete a goal or become ineligible
• You need to persist state or variables through the flow

Use an audience sync alone when:

• The campaign is a single activation step
• There is no sequencing, branching, or delay logic
• Audience membership already expresses all required logic
• You want the simplest possible campaign setup

Rule of thumb: if the campaign has one action and no timing logic, start with an audience sync. If it has multiple steps or decision points, start with a journey.

Manage overlap across campaigns

When you run multiple campaigns at once, the same user can qualify for more than one. Without explicit overlap controls, users can enter competing campaigns or receive conflicting downstream messages.

Priority lists vs. journey exclusions

Use priority lists to rank competing campaign audiences. Use journey exclusions to prevent simultaneous journey enrollment. In more complex setups, use both.

Stagger campaign schedules

If two campaigns evaluate on similar cadences, offset their run times. That reduces the chance that both process the same user before exclusion logic takes effect.

Use a shared campaign-state trait

For more advanced coordination, maintain a trait such as current_lifecycle_stage upstream. Use it across audiences, journeys, and syncs so every campaign checks the same state signal.

Apply consent and access rules at sync time

Destination rules, row-level access, and consent enforcement all apply after audience qualification and journey evaluation. That means a user can qualify for a campaign and appear in journey counts, but still be filtered out before delivery.

Destination rules

Destination rules add sync-time filtering for a specific destination. They do not change audience membership.

Use destination rules when:

• Consent differs by channel
• Destination-specific business rules apply
• The campaign audience is correct, but not every eligible member should be sent to that destination

Row-level access and consent

Row-level access controls which records a team can view and activate. OneTrust integration enforces consent before data leaves the warehouse.

When counts look lower than expected, check these layers in order:

1. Audience definition
2. Priority list behavior
3. Destination rules
4. Row-level access
5. Consent enforcement

Validate each layer before launch

If a campaign uses multiple Customer Studio features together, validate each layer independently instead of assuming the full workflow is correct.

Pre-launch checklist

1. Audience: Preview membership and confirm the right users qualify.
2. Priority lists: Confirm ranking if the campaign audience belongs to a priority list.
3. Journey logic: Run a simulation to validate branches and conditions.
4. Sync configuration: Run a test sync to validate mappings and payload structure.
5. Destination rules: Review any sync-time filters on the destination.
6. Live validation: Start with a small test audience and monitor the first runs end to end.

Debugging count mismatches

When journey counts and destination counts do not match, the drop usually happens in a layer between campaign qualification and delivery.

Campaign patterns

These examples show how different Customer Studio features can work together in campaign workflows.

Staged lifecycle campaigns with overlap control

Scenario: Run welcome, active-user, re-engagement, and winback campaigns without conflicts.

How to build it:

• Priority list ranks campaign audiences
• Separate journeys manage timing and messaging for each campaign
• Journey exclusions prevent concurrent participation
• Shared state trait coordinates campaign stage across workflows

Channel routing with consent enforcement

Scenario: Deliver a campaign through email, SMS, or push based on channel eligibility and consent.

How to build it:

• Journey controls campaign timing and branching
• Audience defines campaign eligibility
• Destination rules enforce per-channel consent and delivery rules
• Experiment measures whether channel routing improves outcomes

This separates campaign eligibility, campaign timing, delivery rules, and measurement into the right layers.

Campaign measurement with holdout

Scenario: Measure the incremental lift of a re-engagement campaign.

How to build it:

• Audience defines the eligible campaign population
• Experiment creates treatment and holdout groups
• Journey runs the treatment flow
• Intelligence measures outcome differences between groups

Avoid common setup mistakes

• Putting consent logic inside journey branches. Consent should usually be enforced at sync time through destination rules.
• Using journey exclusions as the only overlap mechanism. Exclusions prevent simultaneous journey entry, but they do not rank competing audiences.
• Duplicating audience logic in destination rules. Put shared campaign eligibility in the audience. Reserve destination rules for destination-specific logic.
• Editing live journeys instead of replacing them. Large structural changes can affect users already in progress.
• Skipping priority-list validation. A higher-priority audience can claim users before a campaign starts.
• Testing only the journey. Simulation does not model destination rules, consent filtering, or priority-list behavior.

What's next

• Journeys — Build and run multi-step campaign flows.
• Priority lists — Control which campaign audience activates each user.
• Destination rules — Apply sync-time delivery rules by destination.
• Experiments — Measure campaign lift with treatment and holdout groups.
• Plan your data model — Decide which campaign logic belongs upstream versus in Customer Studio.