Skip to main content

Activation targets: where a Data 360 segment goes, and what travels with it

A segment is potential energy until it activates somewhere it does work. This is the target decision: what an activation target is, the destination types Data 360 supports, and the activation object plus attributes that decide what data actually rides along to the channel.

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

A segment is a list of people Data 360 (formerly Data Cloud) knows how to find. It does nothing until it activates — leaves the platform and lands somewhere it can drive a message, an ad audience, a file an external system picks up. This page is about that landing: the activation target, the destination a segment publishes to, and the contract that destination imposes on what you send.

The decision here is narrow and load-bearing: where does this segment go, and what travels with it. Principle 8 states it plainly — design the target as deliberately as the segment, because a perfect segment activated to the wrong place is just an expensive query (Data 360 principles, principle 8). The mechanism of how it publishes — batch on a schedule versus a real-time data action — is a sibling page (batch vs. real-time activation), and the deep Marketing Cloud Engagement bridge has its own (activating into Marketing Cloud). Here the subject is the target itself.

What an activation is

An activation is the act of publishing a segment's members — plus a defined set of attributes — to an activation target. The target is the destination: a connected system Data 360 is configured to deliver to. You build the target once (a Data 360 admin role configures the connection and the data space it belongs to), and then each activation points a segment at it, names the attributes and contact points that ride along, and sets the schedule.

So three things are distinct, and worth keeping distinct in your head:

Segment           → who: the audience, evaluated against the data model
Activation target → where: the connected destination (built once, reused)
Activation        → the publish: this segment, these attributes, to that target, on this schedule

The segment is reusable across many activations; the target is reusable across many activations; the activation is the specific wiring of one to the other. Confusing the three is how teams end up rebuilding a target per segment, or assuming a segment "is" its destination when it can go to several.

The activation object decides what can travel

When you configure an activation you pick an activation object (Salesforce also calls it the activation membership object) — the entity the activation publishes on, typically Individual or Unified Individual. That choice is not cosmetic: the attributes available to send are the ones reachable from that object. Pick the unified profile and you publish resolved people with the profile attributes hanging off them; pick a finer object and you are publishing something else.

On top of the object's own attributes you add additional attributes (also called related attributes) — the profile fields, contact points, and Calculated Insight values you want to ride along to the destination so it can personalize or make decisions. A Calculated Insight value travels here the same as any attribute, carrying whatever grain and freshness the CI computed (consuming query results). Two constraints worth knowing before you design the payload:

  • Related attributes have to sit on a single data model object path reachable from the segment's entity — you can't pull an attribute that lives off an unmodeled traversal. The relationship the model didn't draw is the attribute the activation can't send.
  • There are limits on how many related attributes an activation carries (Salesforce documents a cap — verify the current number for your org). The payload is not free; send what the destination uses, not everything you have.

The destination types

Data 360 supports a few categories of activation target, and the category shapes what the activation has to provide — the identifier the destination keys on, the format it expects. The real ones:

  • Marketing Cloud Engagement. The segment publishes into MC as an audience the email/mobile tooling and Journey Builder can use. The activation is keyed on a contact point — an email or a mobile number, chosen to match the segment's channel — because that is the identifier MC sends to. This is the destination Cleon wires most often, and it has its own deep page (activating into Marketing Cloud); the point here is that the target type is "Marketing Cloud Engagement," and choosing it commits you to a contact-point identifier.

  • Advertising / ad-audience platforms. Targets that push segment members to ad networks — Google, Meta, LinkedIn, Amazon Ads — to build or refresh a custom audience. These match on whatever identifier the ad platform accepts (a hashed email, a device or platform ID), and the activation's job is to supply the identifier the match needs. The destination's contract is the match key; get it wrong and the audience comes back thin or empty.

  • File storage / cloud storage. Targets that drop the segment as a file into Amazon S3, SFTP, Google Cloud Storage, or Azure Blob Storage for an external system to pick up. Here the "channel" is a file in a bucket, and the contract is the file's shape — which columns, which identifier — that the downstream consumer parses. This is the general-purpose escape hatch when the destination isn't a first-class connector.

  • Salesforce and partner targets. Other connected Salesforce destinations and partner platforms exposed as targets. The category list grows; the constant is that each target type declares the identifier and format it needs, and the activation is built to satisfy that declaration.

There is also a different mechanism in the platform — a data action, which pushes a real-time event to an external system rather than publishing a segment's membership — and it is easy to conflate with activation. The batch-publish-versus-real-time-action distinction is exactly the sibling page (batch vs. real-time activation); for the target decision, what matters is that an activation target is where segment membership lands, and the destination type you pick dictates the identifier and shape you owe it.

Principle 8, made operational

The reason any of this is a design decision and not a form to fill in: the target has a contract, and the contract works backward into the segment and the payload. An ad platform that matches on hashed email needs the segment to carry an email — if the audience you built resolves people who have a mobile but no email, that target is the wrong target for that segment. An MC Journey that splits on a loyalty tier needs the tier sent as an attribute — if you didn't model the tier reachable from the activation object, the Journey can't branch on it no matter how good the segment is.

So the order of operations is: know the destination's contract first — the identifier it keys on, the channel it drives, the attributes it acts on — and let that shape what the segment must contain and what the activation must carry. That is principle 8 in practice: the target is designed as deliberately as the segment, because the segment's value is entirely realized — or entirely wasted — at the moment it lands.

One thread that runs underneath every target and never gets to be optional: a person who opted out of a channel must not be activatable into it, and that enforcement belongs to consent, not to the good intentions of whoever built the segment. It has its own page (consent and activation) — flagged here because the target decision is exactly where it bites.

Related

Reference: