Skip to content
ChangelogBook a demoSign up

How Customer Studio features work together

AudienceMarketers and marketing teams building campaigns with Customer Studio.
Prerequisites
  • A configured schema
  • Basic familiarity with audiences and syncs

Customer Studio helps marketers build campaigns:

  • Audiences decide who qualifies.
  • Journeys evaluate who should enter, wait, branch, exit, and sync on each scheduled run.
  • Syncs send customer data to your marketing tools.
  • Experiments create treatment and holdout groups so you can measure impact in Intelligence.

Together, these features let you build campaigns like welcome series, abandoned cart reminders, and re-engagement workflows.

Customer Studio doesn't send messages directly. It prepares and delivers customer data to your downstream tools: email platforms, ad platforms, and CRMs handle the actual message delivery.


What you'll learn


Start with your campaign goal

Choose the goal closest to what you're building. Each pattern combines audiences, journeys, syncs, and experiments to reach a specific outcome.

If you're new to Customer Studio, skim the next two sections first, then jump to the pattern that matches your goal.


The campaign workflow

A typical campaign moves through these stages.

1. Define your audience

Audiences determine who qualifies for your campaign. They filter on customer attributes, event history, and computed traits (like lifetime value or days since last purchase) defined by your data team.

For example: customers who added an item to their cart but haven't purchased in 24 hours.

Audiences can be used directly in syncs or as the starting point for journeys.

2. Coordinate the journey

Journeys manage scheduled workflows that need timing, branching, exits, or state carried across steps. Use a journey when you need:

  • Delays between actions
  • Different paths based on customer behavior
  • Exit conditions
  • Multiple messages or actions over time

For example: wait two days after signup → send onboarding email → check whether the customer activated → send reminder if needed.

Journeys don't send messages themselves. They determine when someone qualifies for each step, then trigger syncs that send data to your downstream tools.

3. Deliver data to your tools

Syncs connect Customer Studio to your destinations. A sync determines:

  • Which destination receives the data
  • Which fields are sent
  • How records are created or updated (through sync mode)

Your downstream tools handle the final action — sending an email, showing an ad, or updating a CRM record.

4. Measure results

Experiments create treatment and holdout groups so you can compare what happens with and without your campaign. Intelligence is where you measure incremental impact: conversions, revenue, engagement, and other outcomes.

For example:

  • Treatment group — receives your campaign.
  • Holdout group — does not receive your campaign.

Compare the two groups to measure lift.


When to build a journey vs. sync your audience

Not every campaign needs a journey.

Sync your audience directly when:

  • You need one activation step
  • Audience membership already contains the required logic
  • There is no timing or branching

For example: sync all high-value customers to your ad platform every day.

Build a journey when:

  • The campaign has multiple steps
  • You need controlled timing between steps (for example, wait two days after signup before sending a reminder)
  • Members should follow different paths based on behavior or attributes
  • Members should exit when they complete a goal
  • You need to remember information as a member moves through the workflow

For example: send a welcome email, wait three days, check whether the user activated, then send a follow-up.

Rule of thumb: if there is no timing, branching, or multi-step logic, sync your audience directly to its destination. If your campaign has multiple steps or decision points, build a journey.


Plan the full campaign

Once you know which features you'll use, plan how they work together. Consider how campaigns handle overlap, how they share lifecycle state, which rules filter data before delivery, and how you'll validate the setup before launch.

Manage overlap across campaigns

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

Priority lists vs. journey exclusions

MechanismHow it worksBest for
Priority listRanks overlapping audiences when data is sent. Each audience member is assigned to the highest-priority audience they qualify for. When a journey's entry audience belongs to a priority list, ranking also determines which journey an audience member can enter first.Choosing which campaign should activate the audience member when multiple campaign audiences qualify.
Journey exclusionsPrevents an audience member from entering a journey if they are already in another specified journey.Preventing concurrent journey participation across campaigns.

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 audience member before exclusion logic takes effect.

Shared lifecycle-state trait

Use this pattern when several lifecycle campaigns need to stay aligned to the same customer stage.

A shared lifecycle-state trait is one field in your warehouse — such as current_lifecycle_stage — that stores each person's current lifecycle stage. Customer Studio and your downstream tools all read that same field instead of maintaining separate stage logic.

For example, you might define stages such as:

  • new_customer
  • active
  • at_risk
  • winback

Use the trait to:

  • Build stage-based audiences, such as everyone whose current_lifecycle_stage = winback.
  • Start or stop journeys when a person enters or leaves a stage.
  • Pass the same field to downstream tools such as Braze or Attentive so channel logic stays aligned.

Example

Imagine you run both a welcome journey and a winback journey. Without a shared lifecycle-state trait, each journey might define "active" differently — one from purchase recency, one from product usage — and those definitions drift over time.

With a shared field such as current_lifecycle_stage, you define the stage once upstream and then:

  • Build audiences from that field.
  • Use those audiences as journey entry points.
  • Add exit criteria when someone changes to a new stage.
  • Map the same field into downstream messaging tools.

Your audiences, journeys, and downstream tools all read one shared lifecycle model.

When to use this pattern

Reach for it when:

  • Multiple journeys need to coordinate from the same lifecycle definitions.
  • Multiple teams are building lifecycle programs at the same time.
  • Multiple downstream tools need the same lifecycle-stage field.
  • You're seeing lifecycle definitions drift across audiences, journeys, and destinations.

When not to use this pattern

Skip this if your problem is simpler:

A shared lifecycle-state trait doesn't replace those controls — it gives them a shared lifecycle model to work from. It's an advanced pattern; most teams should get the basics right first, then add this when multiple programs or tools need to coordinate from the same lifecycle definitions.

These features apply at different stages, not in a single "after qualification" layer. Destination rules filter records at sync time without changing audience membership. Subsets restrict which rows a team can view and activate when building audiences — an upstream constraint applied before syncs run. OneTrust provides consent data that can be enforced through subsets, destination rules, and sync configuration.

Destination rules

Destination rules filter records before data is sent to 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 audience member should be sent to that destination

Destination rules don't affect journey logic. Journey counts can look correct while destination delivery counts are lower because filtering rules removed some audience members before data was sent.

Subsets control 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 (including any subsets scoping the audience upstream)
  2. Priority list behavior
  3. Destination rules
  4. 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 audience members qualify.
  2. Priority lists: Confirm ranking if the campaign audience belongs to a priority list.
  3. Journey logic: Run a journey test to validate branches and conditions.
  4. Sync configuration: Run a test sync to validate mappings and payload structure.
  5. Destination rules: Review any 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.

LayerWhat can reduce countsHow to check
Audience (upstream)A subset already scoped the audience before it reached this stageConfirm which subsets applied when the audience was built
Priority listA higher-priority audience claims the audience memberReview audience ranking and overlapping audience membership
Destination rulesA rule removes the audience member before data is sentReview destination-specific rules
ConsentThe audience member does not have valid consentReview consent status in the warehouse or OneTrust
Destination platformThe destination applies its own suppression or deduplicationReview destination delivery logs

Campaign patterns

Each pattern shows how to combine Customer Studio features to reach a specific outcome. The structure is the same for every pattern — goal, audience, journey, sync, coordination, measurement — so you can compare them side by side.

Recover abandoned carts

Goal: Bring back shoppers who added items to a cart but didn't check out.

How to build it:

  • Audience — Customers with an active cart and no purchase in the last few hours.
  • Journey — Event-based entry on cart_abandoned. Wait 2 hours → send email → wait 24 hours → segment on purchase → send SMS with a discount to non-purchasers.
  • Sync — Trigger with Insert on each send tile so each member receives each message once.
  • Coordination — Exit criteria on purchase so members leave on the next run after the purchase is detected.
  • Measurement — Attach an A/B Split tile with an experiment to compare discount vs. no-discount branches, or run a global holdout.

Welcome new users

Goal: Onboard new users with a multi-step welcome sequence that adapts to what they do (or don't do).

How to build it:

  • Audience — Users with a signed_up event in the last few days.
  • Journey — Event-based entry on signed_up. Set a context variable for the signup path (self-serve vs. sales-assisted). Segment on activity → send activation email → 3-day delay → if no first-action event, send reminder → end.
  • Sync — Trigger with Insert for each send. Map the context variable so the destination can personalize.
  • Coordination — Journey exclusions to prevent overlap with promotional campaigns during the first week.
  • Measurement — Track completion of onboarding goals in Intelligence. Run an A/B Split on the reminder message to test copy variants.

Re-engage inactive customers

Goal: Bring back customers who haven't interacted in 60+ days with a staged sequence.

How to build it:

  • Audience — Customers with no activity in 60 days and valid contact info.
  • Journey — Audience-based entry on a daily schedule. Three-touch sequence: email 1 → 4-day delay → email 2 → 7-day delay → final incentive email.
  • Sync — Trigger with Insert. Optionally add a parallel cohort sync (Upsert or Mirror) to maintain a "re-engagement" audience in your ad platform while the journey runs.
  • Coordination — Journey exclusions to prevent overlap with active-customer campaigns. Exit criteria on any engagement event.
  • Measurement — Run an experiment with a holdout group to measure incremental reactivations.

Coordinate multiple campaigns

Goal: Run welcome, active-customer, re-engagement, and winback campaigns without customers receiving conflicting messages.

How to build it:

  • Audience — One per campaign (new, active, lapsed, churned).
  • Journey — One per campaign, each on its own schedule.
  • Sync — Configure per journey. Downstream destinations handle delivery.
  • Coordination — A priority list ranks the audiences. Journey exclusions prevent simultaneous participation. A shared current_lifecycle_stage trait coordinates state across workflows.
  • Measurement — Compare campaign performance side by side in Intelligence dashboards.

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

How to build it:

  • Audience — Customers who qualify for the campaign regardless of channel.
  • Journey — Controls campaign timing and branching. Segment on channel preference or activity.
  • Sync — One per channel (email, SMS, push).
  • Coordination — Destination rules on each sync enforce per-channel consent and eligibility before data is sent. Audience membership stays stable while filtering controls what actually reaches each destination.
  • Measurement — Attach an experiment to a channel-routing branch to test whether routing improves outcomes.

Measure campaign impact

Goal: Measure whether a re-engagement campaign produces incremental lift versus doing nothing.

How to build it:

  • Audience — Everyone eligible for the campaign.
  • Journey — Runs the treatment path for anyone who receives the campaign.
  • Sync — Trigger sync inside the journey delivers the messages.
  • Coordination — Attach an experiment that splits the audience into treatment and holdout groups. The holdout receives nothing.
  • Measurement — Intelligence compares outcomes (conversions, revenue, engagement) between the treatment and holdout groups to compute lift.

Avoid common setup mistakes

  • Putting consent logic inside journey branches. Consent should usually be enforced before data is sent, through destination rules.
  • Using journey exclusions as the only overlap mechanism. Exclusions prevent simultaneous journey entry, but they don't 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 members already in progress.
  • Skipping priority-list validation. A higher-priority audience can claim audience members before a campaign starts.
  • Testing only the journey. The journey test doesn't model destination rules, consent filtering, or priority-list behavior.

What's next

  • Journeys — Build and run multi-step lifecycle workflows.
  • Priority lists — Control which campaign audience activates each audience member.
  • Destination rules — Apply filters to specific destinations before data is sent.
  • Experiments — Create treatment and holdout groups to measure campaign lift.
  • Plan your data model — Decide which campaign logic belongs upstream versus in Customer Studio.

Ready to get started?

Jump right in or a book a demo. Your first destination is always free.

Book a demoSign upBook a demo

Need help?

Our team is relentlessly focused on your success. Don't hesitate to reach out!

Feature requests?

We'd love to hear your suggestions for integrations and other features.

Privacy PolicyTerms of Service