Destinations and Data Activation
Activating segments
A destination is where segments go. Types include cookie destinations (drop a cookie for a partner), URL destinations (redirect with segment IDs), and server-to-server (S2S) destinations. Each destination has configuration (partner, data format, encryption) and segment mappings. Destinations can be real-time or batch.
Key mechanics
- Segment mapping connects a segment to a destination; unmapped segments don't activate.
- Data format and serialization must match the partner's spec (e.g., key-value pairs, segment ID lists).
- Encryption (e.g., hashing) may be required for PII.
- Destination limits (number of segments per destination) apply.
- Test destinations validate delivery before launch.
Traps in questions
- Assuming a segment flows automatically; it needs an explicit mapping.
- Confusing cookie vs URL vs S2S behavior and where the data lands.
- Forgetting data format mismatches cause silent failures.
- Overlooking destination limits when many segments are mapped.
- Ignoring taxonomy and naming conventions that complicate management.
Worked example
A partner wants segment membership as a cookie. Choose a cookie destination, map the segment, set the data format to the partner's key-value spec, confirm any required encryption, and use a test destination to verify the cookie drops correctly before production. Rule of thumb: activation requires three things - a segment, a destination, and a mapping between them; if any is missing, nothing flows.