Consent on Profile

src/_data/sidenav/main.yml

@@ -577,7 +577,7 @@ sections:
     - path: /privacy/consent-management/configure-consent-management
       title: Configure Consent Management
     - path: /privacy/consent-management/consent-in-unify
-      title: Consent in Unify
+      title: Consent Stored on the Profile
     - path: /privacy/consent-management/consent-in-retl
       title: Consent in Reverse ETL
     - path: /privacy/consent-management/consent-faq

src/engage/profiles/csv-upload.md

@@ -5,7 +5,7 @@ plan: engage-foundations
 You can use the Profiles CSV Uploader to add or update user profiles and traits. This page contains guidelines for your CSV upload and explains how to upload a CSV file to Engage.
 
 > info ""
-> When you upload a CSV file, Engage generates internal Identify calls using Segment's Tracking API and sends them into the [Engage output source](/docs/unify/debugger/). 
+> When you upload a CSV file, Engage generates internal Identify calls using Segment's Tracking API and sends them into the [Engage output source](/docs/unify/debugger/). If you need to update consent preferences for your profiles, you must generate a [Segment Consent Preference Updated](/docs/privacy/consent-management/consent-in-unify/#segment-consent-preference-updated-event) event. For more information, see the [Consent on the Profile](/docs/privacy/consent-management/consent-in-unify/) documentation. 
 
 ## CSV file upload guidelines
 

src/privacy/consent-management/consent-in-retl.md

@@ -7,9 +7,6 @@ With Consent Management in Reverse ETL, you can enforce your end-users' consent
 
 To enforce consent stored in your warehouse, build a Reverse ETL model that identifies consent categories. You can create a "consent to" column mapping in a new data model or update an existing data model to include a "consent to" mapping. 
 
-> info "Consent in Reverse ETL supports Reverse ETL-supported Actions destinations and Segment Connections"
-> At this time, Consent in Reverse ETL does not support adding consent to Segment Profiles using the Segment Profiles destination. To enforce consent data in your classic Segment destinations, use the [Segment Connections destination](/docs/connections/destinations/catalog/actions-segment/). 
-
 ## Prerequisites
 
 > info "Consent management edit and update capabilities limited to Workspace Owners"
@@ -121,9 +118,6 @@ from CONSENT_PREFERENCES;
 
 After you set up categories in the Segment app and create a SQL model that extracts consent information, connect your downstream destinations to complete the consent enforcement process. 
 
-> info "Consent in Reverse ETL supports Reverse ETL-supported Actions destinations and Segment Connections"
-> At this time, Consent in Reverse ETL does not support enforcing consent in the Segment Profiles destination. To enforce consent data in your classic Segment destinations, use the [Segment Connections destination](/docs/connections/destinations/catalog/actions-segment/). 
-
 To add your first destination:
 1. Navigate to **Connections > Destinations** and select the **Reverse ETL** tab.
 2. Click **Add Reverse ETL destination**.
@@ -146,10 +140,10 @@ Segment automatically adds the [consent object](/docs/privacy/consent-management
 
 Open the Source Debugger for your Reverse ETL source and confirm that the [consent object](/docs/privacy/consent-management/consent-in-segment-connections/#consent-object) appears on every event and that the consent object has the categories you mapped in [Step 2: Identify consent columns](#step-2-identify-consent-columns).
 
-<!--- ### Segment Profiles
-Open the [Profile Explorer](/docs/unify/#profile-explorer) and verify that your profiles contain the [Segment Consent Preference Updated](/docs/privacy/consent-management/consent-in-unify/#segment-consent-preference-updated-event) event. --->
+### Segment Profiles
+Open the [Profile Explorer](/docs/unify/#profile-explorer) and verify that your profiles contain the [Segment Consent Preference Updated](/docs/privacy/consent-management/consent-in-unify/#segment-consent-preference-updated-event) event.
 
 ### Reverse ETL Actions destinations
 Segment automatically filters out data from users who have not consented to the category mapped to your destination. 
 
-To verify that this behavior is working as intended, open [Delivery Overview](/docs/connections/delivery-overview) for a RETL-supported Actions destination and view the events that were successfully delivered to the destination. The events in your destination should only come from users that consented to send data to the category that your supported Actions destination belongs to.
+To verify that this behavior is working as intended, open [Delivery Overview](/docs/connections/delivery-overview) for a Reverse ETL-supported Actions destination and view the events that were successfully delivered to the destination. The events in your destination should only come from users that consented to send data to the category that your supported Actions destination belongs to.

src/privacy/consent-management/consent-in-segment-connections.md

@@ -41,7 +41,9 @@ Segment requires every event from all of your sources to include the end user co
 
 ```
 
-Events without the consent object will continue to flow to destinations without consent enforcement.
+Events without the consent object will continue to flow to destinations without consent enforcement. 
+
+Segment events without a context or consent object or that have an empty context or consent object do not impact [consent preferences on the Profile](/docs/privacy/consent-management/consent-in-unify) and these events will flow to all destinations.
 
 ## Reconcile consent conflicts
 

src/privacy/consent-management/consent-in-unify.md

@@ -1,15 +1,52 @@
 ---
-title: Consent in Unify
+title: Consent Stored on the Profile
 plan: consent-management
 redirect_from: "/privacy/consent-in-unify"
 ---
 
-> info "Consent in Unify and Twilio Engage is currently unavailable."
-> However, Segment's OneTrust consent wrappers automatically generate the Segment Consent Preference Updated Track event, which will be required for future integrations with Unify and Twilio Engage.
+Segment uses the [consent object](#consent-object) on Segment events, including the [Segment Consent Preference Updated](#segment-consent-preference-updated-event) Track event, to evaluate and store consent preferences on the Profile. Consent on the Profiles serves as the source of truth of an end user’s consent preference when enforcing consent in Twilio Engage or Linked Audiences.
 
-Segment uses Profiles in [Unify](/docs/unify/) as the source of truth of an end user's consent preference when enforcing consent in Twilio Engage. To get consent preference on the Profile, Segment requires the use of the [Segment Consent Preference Updated event](#segment-consent-preference-updated-event) and [Identify](/docs/connections/spec/Identify) events to route events to Unify. The Segment Consent Preference Updated and Identify events should include the [consent object](/docs/privacy/consent-management/consent-in-segment-connections/#consent-object).
+> info "Consent on the Profile is in private beta"
+> Storing consent preferences on the Profile is actively in development and some functionality may change before it becomes generally available.
+
+## Consent object
+
+Segment requires every event from all of your sources to include the end user consent preferences, captured by your CMP or your application logic, in the form of the **consent object**. The consent object is a JSON object nestled inside of the [context object](/docs/connections/spec/common/#context) with the following format:
+
+> success ""
+> The JSON keys in the consent object should represent the `categoryId` for each consent category. 
+
+```json
+{
+"context": {
+  "consent": {
+    "categoryPreferences": {
+        "Advertising": true,
+        "Analytics": false,
+        "Functional": true,
+        "DataSharing": false
+      }
+    }
+  }
+}
+
+```
+
+Segment events without a context object or consent object or events that have an empty context or consent object do not impact consent preferences on the Profile.
+
+However, if you send events with consent categories that are set up in your CMP but not included in your consent object (a consent category is "missing" from your consent object) or if you have consent categories for which you haven't yet collected consent preferences, Segment sets consent preferences for those categories to `false`. 
+
+This behavior includes:  
+- Segment setting a value of `false` on a Profile for all consent categories for which consent has never collected. 
+- Segment setting a value of `false` on a Profile for each consent category in any events with an empty `context.consent.categoryPreferences` object.
+- Segment setting a value of `false` on a Profile for categories not addressed in an `context.consent.categoryPreferences` object.
+- Segment setting Profiles that have consent categories which have never been collected to `false` during a Profile Merge. This might result in a [Profile level conflict](#profile-level-conflict). 
 
 ## Segment Consent Preference Updated event
+
+> success ""
+> The Segment Consent Preference Updated event is generally available (GA). 
+
 Every time an end user provides or updates their consent preferences, Segment requires you to generate a **Segment Consent Preference Updated** event. If you are using [Segment's OneTrust consent wrappers](/docs/privacy/consent-management/configure-consent-management/#step-2-integrating-your-cmp-with-segment), Segment automatically generates a Segment Consent Preference Updated event. This event is required to add the end user’s consent preference on their Profile in Unify.
 
 For example, if an end user agreed to share their information for functional and advertising purposes but not for analytics or data sharing, the Segment Consent Preference Updated [Track call](/docs/connections/spec/track/) demonstrating their new consent preferences would have the following format:
@@ -20,10 +57,6 @@ For example, if an end user agreed to share their information for functional and
   "type": "track",
   "event": "Segment Consent Preference Updated",
   "userId": "u123",
-  "traits": {
-     "email": "[email protected]",
-     "phone": "555-555-5555",
-  }
   "timestamp": "2023-01-01T00:00:00.000Z",
   "context": {
     "consent": {
@@ -52,4 +85,64 @@ In addition to enforcing consent in Connections, you may want these preferences
 If you use Destination Actions to send consent information to your destinations, the Segment Consent Preference Updated event should **only** include information about a user's consent preferences because this event is sent regardless of an end-user's consent preferences. 
 
 > info "Sharing consent with Classic Destinations is not available"
-> Segment only supports sharing consent with Actions Destinations. 
+> Segment only supports sharing consent with Actions Destinations. 
+
+## Storing consent preferences on the Profile
+Segment stamps consent preference on every Segment event from streaming and Reverse ETL sources to store them on the Profile. 
+
+> warning "Storing consent on the Profile is in private beta"
+> Reach out to your sales contact or [request a demo](https://segment.com/contact/demo){:target="_blank"} to participate in the private beta.
+
+### Device-level conflicts
+A device-level conflict occurs when conflicting consent preferences linked to one user ID are collected from two distinct devices.
+
+> success ""
+> Segment uses `anonymousId` to approximate device identification, as some of Segment's libraries don't track `deviceId`.
+
+For example, if an end-user didn't consent to Advertising on their mobile phone, but later consented to Advertising on their desktop computer, this user would have a conflicting consent preference for the `advertising` category.
+
+By default, Segment relies on the latest consent preferences collected for a user and would set the `advertising` category to `true` given that the **latest** consent preference collected (from the desktop computer) consented to the `advertising` category. 
+
+If you would like to use a different method of conflict resolution, you must build an approach to address and resolve conflicting consent preferences in your website or mobile app and then send the updated consent back to Segment. 
+
+Examples of other conflict resolution strategies include:
+- **Rely on a single source of truth for consent preferences**: Apply the consent preferences found in your single source of truth across all of a user's devices.
+- **Ask user to resolve conflict**: Ask a user for consent preference information and apply their preferences across all of a user's devices. If this new request for consent preferences results in a conflict with the information stored in your single source of truth, prompt your user to resolve the conflict and provide their consent preferences. 
+
+> success ""
+> An end user's Profile with device level conflicts will always result in a consent status of `true` or `false` for the conflicting consent categories.
+
+![A diagram showing different consent preferences being reconciled for a single Profile.](images/device-level-consent-conflict.png)
+
+### Profile-level conflict
+A Profile-level conflict occurs when two distinct userIDs with different consent preferences are merged into one Unify Profile. A Profile-level conflict can also occur when a userID and an anonymousID (one without a linked userID) are linked to the same Profile by an external ID, like an email address or phone number, and the consent preferences of both Profiles do not match. 
+
+![A diagram showing different users linked to one Profile.](images/profile-level-consent-conflict.png)
+
+To avoid Profile-level conflicts, Segment recommends that you take the following steps:
+
+* **Ensure your Identity Resolution rules have exactly 1 identifier (for example, `user_id` or email or `phone_number`) that uniquely identifies a profile or person**: Set this identifier to have a priority of 1 and limit your identifier to 1 value ever. With a unique, persistent identifier for each profile, there can never be a profile level conflict between two users on the same Profile. Segment evaluates and stores events with `ids` that are discarded due to a maximum value limit violation on the existing Profile.
+* **Only collect any additional identifiers when that unique identifier is present**: For example, if consent is initially captured for an anonymous ID and email, but no `user_id` (the unique identifier), it will create a profile (P1). Later, if the same email is captured with a `user_id`, a different anonymous ID, and updated consent preferences, a second profile is created. Since both profiles share the same email, a profile merge will occur, potentially leading to conflict in consent preferences.  
+* **Maintain the default `reset()` behavior**: When a user explicitly logs out of your application, call `analytics.reset()` to prevent any further event activity from being associated with the previous user and generate a new `anonymousId` for subsequent activity until a user logs in again. This helps you avoid ambiguity when multiple people use a shared device.
+
+> success ""
+> Profile conflicts only impact Profiles used in Engage spaces.
+
+## Enforcing consent in Twilio Engage
+Consent enforcement in Twilio Engage and Linked is currently unavailable during the public beta. Segment stores consent preferences as traits on the Profile. 
+
+> warning ""
+> Consent stored on the Profile does not automatically enforce consent in Twilio Engage or Linked Audiences.
+
+## Validating consent preferences stored on a Profile
+You can validate consent is present on the Profile by looking for the consent trait provided for a Profile on the consent tab.
+
+- **If the value is `true`**: Your user consented to have their data used for this purpose
+- **If the value is `false`**: Your user did not consent to have their data used for this purpose
+- **If the value is `conflict`**: At the time this Profile was merged, there was a conflict in the consent preferences recorded for a consent category. For more information about consent conflicts, see the [Profile-level conflict](#profile-level-conflict) documentation.
+
+
+## Troubleshooting consent preferences stored on the Profile
+
+### If I have 2 sources connected to a Unify space and only 1 is set up to collect consent, which consent preferences does Segment record?
+Consent preferences collected in the [consent object](/docs/privacy/consent-management/consent-in-segment-connections/#consent-object) from the source are used to store consent on the Profile. Sources with no consent object do not impact what is stored on the Profile. If the source generates an empty consent object, Segment interprets this as an end-user failing to consent to any category. As a result, the consent preference will be updated to `false` for all consent categories.

src/unify/csv-upload.md

@@ -4,6 +4,9 @@ plan: unify
 ---
 You can use the Profiles CSV Uploader to add or update user profiles and traits. This page contains guidelines for your CSV upload and explains how to upload a CSV file to Unify.
 
+> warning "Consent preferences cannot be updated using the Profiles CSV Uploader"
+> If you need to update consent preferences for your profiles, you must generate a [Segment Consent Preference Updated](/docs/privacy/consent-management/consent-in-unify/#segment-consent-preference-updated-event) event. For more information, see the [Consent on the Profile](/docs/privacy/consent-management/consent-in-unify/) documentation. 
+
 ## CSV file upload guidelines
 
 Keep the following guidelines in mind as you upload CSV files: