Merge branch 'master' into pwseg-sfmc-update

Author: markzegarelli

src/_data/sidenav/main.yml

@@ -24,21 +24,21 @@ sections:
   - path: /guides
     title: An introduction to Segment
   - path: /guides/intro-impl
-    title: Segment developer overview
+    title: Segment for developers
   - path: /guides/intro-user
-    title: Segment data user overview
+    title: Segment for data users
   - path: /guides/intro-admin
-    title: Segment workspace admin overview
+    title: Segment for workspace admins
   - path: /guides/filtering-data
     title: Filtering your Segment data
   - path: /guides/duplicate-data
-    title: How does Segment handle duplicate data?
+    title: Handling duplicate data
   - path: /guides/ignore-bots
-    title: How can I ignore internet bots?
+    title: Ignoring internet bots
   - path: /guides/segment-vs-tag-managers
-    title: What is the difference between Segment and tag managers?
+    title: Segment vs. tag managers
   - path: /guides/what-is-replay
-    title: What is Replay?
+    title: Replay
 
   - section_title: How To Guides
     slug: guides/how-to-guides

src/_includes/content/current-version.html

@@ -14,8 +14,8 @@
 <p>Release Date: {{release.date | date: "%b %d, %Y" }}</p>
 
 <div class="links">
-<a href="https:///github.com/segmentio/{{page.repo}}" target="_blank"><img src="/docs/images/github.svg" /></a>
-<a href="https:///github.com/segmentio/{{page.repo}}/tags.atom" target="_blank"><img src="/docs/images/atom.svg" /></a>
+<a class="no-icon" href="https:///github.com/segmentio/{{page.repo}}" target="_blank"><img src="/docs/images/github.svg" /></a>
+<a class="no-icon" href="https:///github.com/segmentio/{{page.repo}}/tags.atom" target="_blank"><img src="/docs/images/atom.svg" /></a>
 {% if page.repo == 'analytics-android' %}
 <a href="https://maven-badges.herokuapp.com/maven-central/com.segment.analytics.android/analytics"><img style="height: 18px;" src="https://maven-badges.herokuapp.com/maven-central/com.segment.analytics.android/analytics/badge.svg" /></a>
 {% endif %}

src/_includes/content/destination-footer.md

@@ -56,13 +56,15 @@ Segment lets you change these destination settings from the Segment app without
 {% endunless %}
 {% if currentIntegration.previous_names.size > 1 %}
 
+{% unless page.hide-integrations-object == true %}
 ## Adding {{ currentIntegration.display_name }} to the integrations object
 
 To add {{ currentIntegration.display_name }} to the `integrations` JSON object (for example, [to filter data from a specific source](/docs/guides/filtering-data/#filtering-with-the-integrations-object)), use one of the following valid names for this integration:
 
 {% for valid_name in currentIntegration.previous_names %}
 - {{ valid_name }}
 {% endfor %}
+{% endunless %}
 {% endif %}
 
 {% endif %}

src/_sass/components/_markdown.scss

@@ -260,4 +260,8 @@
 a[target="_blank"]:after{
   content: url("/docs/images/external-link-alt-solid.svg");
   margin-left: 4px;
+}
+
+a.no-icon[target="_blank"]:after {
+  content: none
 }

src/connections/destinations/actions.md

@@ -26,6 +26,24 @@ Each Actions-framework Destination you see in the Segment catalog represents a f
 - If you are using Protocols, Destination Actions actions are applied *after* [schema filters](/docs/protocols/enforce/schema-configuration/) and [transformations](/docs/protocols/transform/). If you are using [destination filters](/docs/connections/destinations/destination-filters/), Actions are applied after the filters - meaning that they are not applied to data that is filtered out.
 - Destination Actions can not yet be accessed or modified using the Segment APIs.
 
+## Components of a Destination Action
+
+A Destination Action contains a hierarchy of components, that work together to ensure the right data is sent to the destination. 
+
+At the top level, is the Destination itself. It has two children: **Global Settings** and **Subscriptions**. 
+
+**Global Settings** are where you include authentication information like API keys, and other connection-related information. 
+
+**Subscriptions** handle the individual calls to the destination. In them, you define what type of call you want to make to the destination, and what triggers that call. Individual Destination Actions come enabled with some predefined subscriptions to handle common events like Screen calls, Identify calls, and Track calls. Subscriptions have two components that make this possible: **Triggers** and an **Action**. 
+
+**Triggers** enable you to define *when* the corresponding Action fires. As part of a Trigger, you can use condition-based filters to narrow the scope of the trigger.
+
+**Actions** determine the information sent to the destination. In the Configure action section, you map the fields that come from your source, to fields that the destination expects to find. Fields on the destination side depend on the type of action selected
+
+For example, in the Amplitude (Actions) destination, you define your API and Secret keys in the destination's global settings. Then, the provided Page Calls subscription:
+
+1. Triggers the action on all incoming Page events.
+2. Runs the Log Event action, to map your incoming data to Amplitudes properties.
 
 
 ## Set up a destination action
@@ -87,6 +105,13 @@ The following type filters and operators are available to help you build conditi
 
 You can combine criteria in a single group using **ALL** or **ANY**.  Use an ANY to “subscribe” to multiple conditions. Use ALL when you need to filter for very specific conditions. You can only create one group condition per destination action. You cannot created nested conditions.
 
+> info "Destination Filters"
+> Destination filters are compatible with Destination Actions. Consider a Destination Filter when:
+> - You need to remove properties from the data sent to the destination
+> - You need to filter data from multiple types of call (for example, Track, Page, and Identify calls)
+> 
+> If your use case does not match these criteria, you might benefit from using Subscription-level triggers to match only certain events.
+
 
 
 <!--

src/connections/destinations/catalog/actions-amplitude/index.md

@@ -45,6 +45,9 @@ Session tracking is only available when using Segment's new libraries: [Analytic
 Once you have a mapping, you can follow the steps in the Destinations Actions documentation on [Customizing mappings](/docs/connections/destinations/actions/#customizing-mappings).
 
 
+### Device ID Mappings
+The Amplitude destination requires that each event include either a Device ID or a User ID. If a User ID isn't present, Amplitude uses the a Device ID, and vice versa, if a Device ID isn't present, Amplitude uses the User ID. By default, Segment maps the Segment property `context.device.id` to the Amplitude property `Device ID`. If `context.device.id` isn't available, Segment maps the property `anonymousId` to the Amplitude `Device ID`. This is indicated by the following text in the Device ID field: `coalesce(` `context.device.id` `anonymousId` `)`. 
+
 ### Enable session tracking for Analytics.js 2.0
 
 The session tracking is automatically enabled on Javascript sources.

src/connections/destinations/catalog/braze/index.md

@@ -2,6 +2,7 @@
 title: Braze Destination
 hide-cmodes: true
 hide-personas-partial: true
+hide-integrations-object: true
 ---
 
 [Braze](https://www.braze.com/), formerly Appboy, is an engagement platform that empowers growth by helping marketing teams to build customer loyalty through mobile, omni-channel customer experiences.

src/connections/sources/catalog/libraries/website/javascript/upgrade-to-ajs2.md

@@ -3,7 +3,7 @@ title: Upgrade to Analytics.js 2.0
 strat: ajs
 ---
 
-Analytics.js 2.0 is fully backward compatible with Analytics.js Classic. To upgrade your sources, follow the manual upgrade steps below, or see the schedule for automatic migration. As with all upgrades, Segment recommends that you start development on a non-production source to test the upgrade process and outcome, prior to upgrading your production sources.
+Analytics.js 2.0 is fully backward compatible with Analytics.js Classic when using the default Segment snippet. To upgrade your sources, follow the manual upgrade steps below, or see the schedule for automatic migration. As with all upgrades, Segment recommends that you start development on a non-production source to test the upgrade process and outcome, prior to upgrading your production sources.
 
 ## Manual upgrade
 

src/guides/duplicate-data.md

@@ -1,5 +1,5 @@
 ---
-title: How does Segment handle duplicate data?
+title: Handling duplicate data
 ---
 
 Segment has a special de-duplication service that sits just behind the `api.segment.com` endpoint, and attempts to drop duplicate data. However, that de-duplication service has to hold the entire set of events in memory in order to know whether or not it has seen that event already. Segment stores 24 hours worth of event `message_id`s. This means Segment can de-duplicate any data that appears within a 24 hour rolling window.

src/guides/ignore-bots.md

@@ -1,20 +1,20 @@
 ---
-title: How can I ignore internet bots?
+title: Internet bots
 ---
 
-## But wait, I don't even know what a bot is!
+## What's a bot?
 
 If you stumbled onto this page by accident and don't know what a bot is or are just curious to learn more, the following Wikipedia article provides an awesome summary: [https://en.wikipedia.org/wiki/Internet\_bot](https://en.wikipedia.org/wiki/Internet_bot).
 
 Surprisingly, more than half of all web traffic is made up of bots. While a fraction of them are good bots with a regulated pattern, and therefore beneficial to all online businesses, the majority of them have malicious intents and are mostly unregulated.
 
-## Got it! So is it possible to ignore bad bots?
+## Is it possible to ignore bad bots?
 
-Now that we're level-set on what a bot is, unfortunately Segment does not offer any out-of-the-box feature to filter/ignore bot traffic.
+Segment doesn't offer any out-of-the-box feature to filter or ignore bot traffic.
 
 As such, you generally have two options:
 
-**Handle the filtering at a destination-level:** some of our destination partners, [like Mixpanel](https://help.mixpanel.com/hc/en-us/articles/115004567946-Exclude-Bot-Activity-Web-JavaScript-), filter bots automatically. Whereas others [such as Hubspot](https://knowledge.hubspot.com/getting-started-with-hubspot-v2/how-to-filter-out-traffic-from-your-website-analytics) allow you to set up bot filtering manually. The advantage of filtering bots at a destination level is that it allows you to implement a robust, easy-to-maintain solution. However, as it pertains to Segment, the downside is that bot traffic will _still_ make it to Segment, [affecting your MTU count.](https://segment.com/docs/guides/usage-and-billing/mtus-and-throughput/#how-does-segment-calculate-mtus)
+**Handle the filtering at a destination-level:** Some of Segment's destination partners, [like Mixpanel](https://help.mixpanel.com/hc/en-us/articles/115004567946-Exclude-Bot-Activity-Web-JavaScript-), filter bots automatically. Whereas others [such as Hubspot](https://knowledge.hubspot.com/getting-started-with-hubspot-v2/how-to-filter-out-traffic-from-your-website-analytics) allow you to set up bot filtering manually. The advantage of filtering bots at a destination level is that it allows you to implement a robust, easy-to-maintain solution. However, as it pertains to Segment, the downside is that bot traffic will _still_ make it to Segment, [affecting your MTU count.](https://segment.com/docs/guides/usage-and-billing/mtus-and-throughput/#how-does-segment-calculate-mtus)
 
 **Write custom logic that suppresses bot activity from being sent to Segment:** if you want to prevent bot traffic from making it to Segment in the first place, another option is to write your own custom code. The logic, in pseudo-code, would look something like this if you know a particular characteristic of the bot traffic to filter out, such as the userAgent:
 
@@ -25,17 +25,17 @@ if ! window.navigator.userAgent in robots
   analytics.track
 ```
 
-The benefit here of course is that you would be able to limit the impact that bots have on your MTU count. However, on the flip side, it's much harder to implement and maintain a custom filter.
+The benefit here is that you would be able to limit the impact that bots have on your MTU count. On the flip side, it's much harder to implement and maintain a custom filter.
 
-## If we see a massive MTU spike because of bots, can we apply for a refund?
+## If I see a massive MTU spike because of bots, can I apply for a refund?
 
-As a matter of policy, we typically do not provide refunds for bot-related MTU spikes, as bot traffic is out of our control. However for extenuating circumstances, [you can petition for a refund](https://segment.com/contact/billing), assuming you're able to provide proof of the bot's effect.
+As a matter of policy, Segment doesn't provide refunds for bot-related MTU spikes, as bot traffic is out of Segment's control. However for extenuating circumstances, [you can petition for a refund](https://segment.com/contact/billing), assuming you're able to provide proof of the bot's effect.
 
-## I'm seeing a lot of browser traffic from Boardman; isn't that from Segment?
+## I'm seeing a lot of browser traffic from Boardman; is that from Segment or a bot?
 
-We do indeed use Amazon's hosting services, which are based in Boardman, Oregon. However [many bots also originate from AWS in Boardman as well](https://productforums.google.com/forum/#!topic/webmasters/Ow5baxkjiPI).
+Segment uses Amazon's hosting services, which are based in Boardman, Oregon. However [many bots also originate from AWS in Boardman as well](https://productforums.google.com/forum/#!topic/webmasters/Ow5baxkjiPI).
 
-One way you can confirm whether or not traffic is coming from Segment vs. a bot is to check the userAgent of the inbound call. Ours is:
+One way you can confirm whether or not traffic is coming from Segment vs. a bot is to check the userAgent of the inbound call. Segment's is:
 
 ```js
 'Mozilla/5.0 (' + deviceModel.slice(0, -3) + '; CPU ' + osName + ' ' +