Merge pull request #1698 from segmentio/evanSegment-jo-corrections

[WIP] Journeys Corrections

Author: markzegarelli

src/personas/journeys/faq-best-practices.md

@@ -11,12 +11,19 @@ title: Journeys Best Practices and FAQ
 When you create a multi-branch split, do not create overlapping conditions that might lead a user to qualify for more than one step at a time.
 
 For example:
-  - If a multi-branch split has the following conditions, a user who has performed both `webinar attended` and `registration form submitted` will end up in both branches.
+  - In the case where a multi-branch split is based on the conditions `registration form submitted` and `webinar attended`, a user may satisfy both conditions, and therefore is eligible for both paths.
   - To set a priority, branch 2 should then be `who performed registration form submitted and did not perform webinar attended` to ensure mutual exclusivity
 
 ### Add time windows whenever possible
 
-Where possible, add a time window when defining conditions to ensure that users exit the step or Journey, rather than remain at the step forever. This prevents Journeys from collecting stale users which can muddle your data for analytics, or cause you to over-target.
+Using selective time windows ensures that Journeys carefully target the most high-priority audiences. For example, in a repeat purchase campaign, the initial entry condition may look for all one-time purchasers, then filter out users who have new transactions in the past 7 days.
+
+### Suppress targeting with journey lists
+
+Unlike lists associated with Personas Audiences, users who are added to a journey list cannot be subsequently removed. Lists are typically associated with advertising campaigns, and you must take additional steps if you wish to ensure that users do not continue to be targeted with ads after they achieve some goal. A typical implementation pattern is:
+1. Use a send to destination step to add users to the initial targeting list.
+2. Create additional journey steps to model the conditions where a user should be removed from targeting. Create a second send to destination step for the removal list.
+3. When configuring targeting conditions in the destination interface, use boolean logic to include only those users who are in the initial list AND NOT in the removal list.
 
 ### Review your Journey in drafts first
 

src/personas/journeys/send-data.md

@@ -41,18 +41,6 @@ When the user enters the step:
 }
 ```
 
-When the user leaves the step:
-
-```json
-{
-  "type": "track",
-  "event": "Audience Exited",
-  "properties": {
-    "j_o_first_purchase__opened_email_dje83h": "false"
-  }
-}
-```
-
 #### Identify calls
 
 When the user enters the step:
@@ -66,20 +54,9 @@ When the user enters the step:
 }
 ```
 
-When the user leaves the step:
-
-```json
-{
-  "type": "identify",
-  "traits": {
-    "j_o_first_purchase__opened_email_dje83h": "false"
-  }
-}
-```
-
 ### List destination
 
-The destination receives a list of users who qualify for that step of the Journey. This list is constantly updated by Segment. 
+The destination receives a list of users who qualify for the associated journey step. Unlike lists associated with Personas Audiences, users who are added to a journey list cannot be subsequently removed. See [best practices](/docs/personas/journeys/faq-best-practices#suppress-targeting-with-journey-lists) for techniques to suppress targeting with journey lists.
 
 For more information, see [Using Personas Data](/docs/personas/using-personas-data/).