Skip to main content

Data 360 Segmentation & Activation: Style Guide

The opinionated rules Cleon applies to every Data 360 activation decision — the batch publish vs. real-time data action call at the center, the target discipline, the cost and freshness discipline, consent enforced at the boundary, the patterns to prefer and the ones to refuse, plus a pre-ship checklist for any segment or activation. The discipline document that ties the Segmentation & Activation subcategory together.

Decision framework·Last updated 2026-06-01·Drafted by Lira · Edited by German Medina

This is the page where Cleon stops describing what Data 360 (formerly Data Cloud) activation is and starts saying what we do with it. Salesforce defines the surfaces. The reference pages in this subcategory document each one — building the segment, the activation target, batch versus real-time, the Marketing Cloud bridge, consent — and the gotchas document where a segment quietly fails to become an outcome. This Style Guide is the discipline that keeps a segment trustworthy the day it ships into a channel a real person receives.

Use it as a checklist before any new segment or activation ships. The rules are short on purpose — when a rule needs an explanation, the explanation is in the page it links to. One decision sits above all the others, so it goes first.

The central decision: batch publish vs. real-time data action

Almost every activation choice in Data 360 reduces to one fork: does the destination need a population — who currently qualifies, recomputed on a cadence — or a reaction to one change as it happens? A scheduled segment publish answers the first; a real-time data action answers the second. Get this right and the rest of the subcategory is detail. Get it wrong and you either freeze an event need into a daily batch, or you wire an event mechanism where the job was a recomputed audience — and either way it's a rebuild, not a setting you flip.

Three questions decide it. Answer them in order.

1. Does the destination need a population, or a reaction to one change?

Separate the two questions that hide inside most requirements and look like one: who is in this audience (a population — a segment), and when does the destination act (a cadence, or one event — a data action). A scheduled publish answers "who, as of the last run." A data action answers "react now to this one change." If the destination needs the set of everyone who currently qualifies, it's a segment publish. If it needs to fire off a single record change the moment it happens — no membership, no count — it's a data action (batch vs. real-time). Name which one you're building, out loud, before you build it.

2. If a population — how fresh, and does the rule fit Rapid's window?

A population still has two cadence tiers, and the faster one buys speed by giving up reach. Standard publish runs every 12 to 24 hours and reaches the full engagement horizon — up to two years — into any target. Rapid Segment Publish refreshes as often as hourly, but only over the last 7 days of engagement, only into Marketing Cloud, with a capped count and a cadence you commit to up front (verify your org's current limits). So the freshness question has a second half: does the rule even fit a rapid segment? A rule that depends on behavior older than a week can't be expressed in Rapid no matter how fresh you want it. Decide the freshness the audience genuinely needs, check the rule fits the tier that delivers it, and write the cadence down (building segments).

3. Is this genuinely both a population AND a per-change reaction?

This is the line teams miss. "Email everyone in the high-value segment, and fire a message the instant any one of them abandons a cart" is not one mechanism on a clever setting — it's a segment publish for the population and a data action for the per-change reaction, two builds wired separately, each doing the job it's shaped for. If the requirement is genuinely both, build both. Stretching one to cover both is the rebuild.

This is the exact parallel to the query layer's Calculated Insight vs. live Query call, one layer over — compute a population on a cadence, or react to one change live — and to the same freshness discipline: set the publish cadence to the freshest decision the audience feeds, never to "as fresh as possible."

Target discipline

Design the activation target as deliberately as the segment

A perfect segment activated to the wrong place is just an expensive query (principle 8). The target deserves the same deliberation as the membership rules; it usually gets a fraction of it (activation targets). The segment is reusable, the target is reusable, and the activation is the specific wiring of one to the other — keep the three distinct in your head, and the destination stops getting a default.

Know the destination's contract — identifier, channel, attributes — before the segment is "done"

Every target type declares the identifier it keys on, the channel it drives, and the attributes it acts on, and that contract works backward into the segment (activation targets). An ad platform that matches on hashed email needs the segment to carry an email; a Journey that splits on a loyalty tier needs the tier sent as an attribute. Read the contract first, then build the segment to satisfy it — not the other way around, which is how you discover the audience can't supply the identifier the channel needs after it's built.

Map only the attributes the destination actually uses — and each carries its source's freshness

The attributes that ride along are the only ones the destination gets to act on; there is no "and also pull this" once the activation has shipped (activation targets). Map what the channel personalizes or decides on, and no more — the payload is not free, and there are caps on related attributes. And every attribute arrives carrying the freshness of whatever produced it: a Calculated Insight refreshed daily, riding into an hourly activation, lands a value up to a day old in a column the destination treats as current. The activation transports a value, it does not revalidate it.

Cost and freshness discipline

Filter selectively — cost scales with what the rules scan, not what they return

Cost in Data 360 scales with what you process, not what you store (principle 11), and a segment's processing is whatever its rules scan on every publish. A tight leading filter that eliminates most of the profile early is cheap; a full-profile scan under a pile of ANDs is a recurring bill wearing a logic decision's clothes (building segments). The size of the result and the cost of producing it are different numbers — filter on the most selective condition first, lean on Calculated Insights already computed rather than forcing recomputation, and don't scan two years of history for an audience that depends on the last ninety days.

Set the publish cadence to the freshest decision the audience feeds — and write it down

A segment's membership is a snapshot, not a live view: between publishes it serves the last set it resolved, with nothing in the destination to say the world moved on (principle 6). Set the cadence to the freshest decision the audience genuinely feeds — not to "as fresh as possible," which pays for freshness nobody consumes, and not to a daily publish behind a real-time decision. A scan that runs hourly costs roughly twelve times one that runs twice a day, for the same rules. Then write the cadence down next to the segment, so the next person doesn't assume the list is current when it's on a 24-hour clock.

Consent is non-negotiable

Enforce consent at the activation boundary, never as a remembered filter

Segment logic is consent-blind by design — it counts who matches, and nothing in the rule knows whether a person opted out (principle 9). So consent is enforced below the segment, at the boundary where membership becomes an activation, via Contact Point Filtering backed by the Contact Point Consent DMO (consent and activation). You can bolt an "opt-in = true" filter into a segment's own logic, and that is exactly the trap: it protects that one segment until the next one forgets it. Model consent and data-use purpose alongside the data, apply the filter as a standing convention on every activation into a consent-bearing channel, and make the safe path the only path — an activation into email that cannot be built to ignore email consent.

Filter on consent status AND data-use purpose — not status alone

Consent status (opted in or out for the contact point) is the attribute people reach for first; data-use purpose (marketing, analytics, a specific processing purpose) is the one that makes the enforcement correct (consent and activation). Real consent is permission-for-a-purpose: the person who allowed transactional email but refused marketing is opted in and must be excluded from a marketing activation. Filtering on status alone treats consent as a single on/off switch and ships that person anyway. Both attributes live on the Contact Point Consent DMO, and both belong in the filter — the failure here is the one that reaches a regulator, and it's silent the whole way.

Patterns to prefer

  • A segment publish for any requirement that needs a population, a data action for any that needs a per-change reaction — and both when it's genuinely both.
  • Standard publish by default; Rapid only when the rule fits its 7-day window and the destination is Marketing Cloud.
  • The destination's contract read first — identifier, channel, attributes — and the segment built to satisfy it.
  • Only the attributes the destination acts on carried along, each with its source's freshness known.
  • The most selective filter first, so Data 360 stops scanning early.
  • Contact Point Filtering on every consent-bearing activation, on status and purpose, as the default shape — not a per-segment add.
  • The publish cadence written next to the segment, not held in someone's memory.

Patterns to refuse

  • A daily-published segment behind a "the moment they do X" requirement — a reaction that's up to a day late.
  • A data action where the job was a recomputed audience — a stream of per-change events and no population to send a campaign to.
  • Rapid reached for because hourly sounds better before checking the rule fits a 7-day window and the target is Marketing Cloud.
  • A perfect segment sent to the wrong target — the right people, the wrong place, real compute spent on no outcome.
  • An attribute the destination doesn't use padding the payload, or a stale value carried in as if it were current.
  • Consent as a filter someone remembers to add to each segment, instead of enforced at the boundary on status and purpose.
  • "It published" treated as "it arrived." Publish status in Data 360 and arrival in the destination are two different facts (debugging activation).

The pre-ship checklist before any segment or activation ships

  • [ ] The batch-vs-real-time call was made on purpose — segment publish for a population, data action for a per-change reaction, both if it's genuinely both.
  • [ ] Population: Standard vs. Rapid chosen by the rule (does it fit the 7-day window + Marketing Cloud?), not by the aspiration to be fresher.
  • [ ] The publish cadence is set to the freshest decision the audience feeds, and written down next to the segment.
  • [ ] The destination's contract was read first — identifier, channel, attributes — and the segment carries what the channel keys on and branches on.
  • [ ] Only the attributes the destination acts on are mapped, and each attribute's freshness is known and acceptable.
  • [ ] The rules filter selectively — the most selective condition leads, and nothing forces a full-profile scan the audience doesn't need.
  • [ ] Consent is enforced at the boundary via Contact Point Filtering on status and data-use purpose — not a filter inside the segment.
  • [ ] Arrival is verified in the destination, not just publish status in Data 360.

When all of them fire, the segment or activation is ready to ship.

Related

If you spot a rule missing — or one of these rules being violated in our public work — write to hello@wearecleon.com. We add it, or we fix it and we say so.