DOC-27 Updates to Billing and MTU sections (#1180)

* checkin

* first pass, waiting for some amplitude answers

* improve about cloud sources wording, explain obj vs event

* restructure the last section oof

* check in while waiting for more details

* add Protocols section

* further cleanup

* copy edit

* copy edit (thx kiara!)

* brooks edits

* typo, remove confusing wording about when we count

* last round of copy edits, more iteration later

Author: sanscontext

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

@@ -6,22 +6,20 @@ This destination is maintained by Segment.
 
 ## Getting Started
 
-The Repeater destination forwards events from a source back into another source, as though that event occured in the second source.
+The Repeater destination forwards events from a source back into another source, as though that event occurred in the second source.
 
-Events are not cached in the Repeater, so it only handles real-time events. You can specify multiple sources as Repeater destinatons.
-
-*Segment does not double count MTUs for Repeater events.*
+Events are not cached in the Repeater, so it only handles real-time events. You can specify multiple sources as Repeater destinations.
 
 ## Configuration
 
-Add the Repeater as a destination for the source that you would like to replicate events from.
+Add the Repeater as a destination for the source that you want to replicate events from.
 
-Find the source that you would like events to flow to, and copy the write key from that source.
+Find the source that you want events to flow to, and copy the `writeKey` from that source.
 
-Go back to the Repeater destination and add this write key to the write keys list for Repeater.
+Go back to the Repeater destination's settings, and add this `writeKey` to the write keys list for Repeater.
 
 You can do this for as many sources as you need.
 
 ![](images/write-key-settings.png)
 
-Repeater will replay all events it gets to the sources you specified using the write key(s) you specified.
+Repeater sends all events it receives to the sources you specified, identified by the write key(s) you added.

src/connections/sources/about-cloud-sources.md

@@ -28,9 +28,11 @@ Sources are functionally comprised of either one or both of the following compon
 
 ### Sync frequency
 
-When you enable a source and grant us access by pasting an API key or authenticating with OAuth, Segment starts a scheduled job on your behalf which makes requests to the downstream tool, normalizes and transforms the data, and forwards the data to the Segment API. We make an effort to use as few API calls as possible, opting to fetch only data that has changed since the previous sync where possible. This can be an intensive process, especially on first sync, so we have lots of affordances in place for retries and to respect rate limits imposed by the partner.
+You enable a cloud source from the Segment web app, and grant Segment access by pasting an API key or authenticating with OAuth. Segment then starts a scheduled job on your behalf which makes requests to the downstream tool, normalizes and transforms the data, and forwards that data to the Segment API.
 
-### API Call Usage and Collection Selection
+Cloud sources attempt to use as few API calls as possible, and (where possible) only fetch data that changed since the last sync. The syncs might take a long time (especially on the first sync), so the cloud source syncs have robust retry and rate limiting logic.
+
+### API call use and collection selection
 
 We make an effort to be respectful of your API call allotments and limits. For example, in the case of Salesforce, we issue only one query per collection per run, using the absolute minimum number of API calls possible (typically about 350/day).
 
@@ -83,7 +85,7 @@ Sometimes, when the sync job fails due to an unhandled error or is mysteriously
 
 In general, we've focused on pulling all of the collections directly related to the customer experience. We do not automatically pull all collections available from a partner API, since many of them aren't relevant to the customer journey. You can see a list of the collections we pull in the docs [for each cloud source](/docs/connections/sources/catalog/#cloud-apps). Each collection reflects a table in your database.
 
-[Let us know](https://segment.com/help/contact) if you need additional data collected or to change the schema to do the analysis you want. We'd love to know what analysis you're trying to run, what additional data you need, and we'll share with the product team to evaluate.
+[Contact Segment Product Support](https://segment.com/help/contact) if you need additional data collected, or to change the schema to do the analysis you want. We'd love to know what analysis you're trying to run, what additional data you need, and we'll share with the product team to evaluate.
 
 ### What questions can you answer with data from cloud, web, and mobile sources combined in a single warehouse?
 

src/connections/spec/identify.md

@@ -4,18 +4,18 @@ related:
   - "/docs/connections/sources/catalog/"
 ---
 
-`identify` lets you tie a user to their actions and record traits about them.  It includes a unique User ID and any optional traits you know about them like their email, name, etc.
+The Segment Identify call lets you tie a user to their actions and record traits about them.  It includes a unique User ID and any optional traits you know about the user, like their email, name, etc.
 
 {% include components/media-icon.html href="https://university.segment.com/introduction-to-segment/299968?reg=1&referrer=docs" icon="media/icon-academy.svg" title="Segment University: The Identify Method" content="Check out our high-level overview of the Identify method in Segment University. (Must be logged in to access.)" %}
 
-Our recommendation for when and how often you should call `identify` is as follows:
+Segment recommends that you make an Identify call:
 
-- After a user registers
+- After a user first registers
 - After a user logs in
-- When a user updates their info (eg changes or adds a new address)
+- When a user updates their info (for example, they change or add a new address)
 - Upon loading any pages that are accessible by a logged in user (optional)
 
-The first three examples are pretty self-explanatory, but many might ask: why you would call identify on every page load if we're storing the userId in the cookie/local storage?
+The first three examples are pretty self-explanatory, but many might ask: why you would call identify on every page load if we're storing the `userId` in the cookie/local storage?
 
 Let's imagine this scenario:
 
@@ -174,7 +174,7 @@ Reserved traits we've standardized:
   <tr>
     <td>`createdAt`</td>
     <td>Date</td>
-    <td>Date the user's account was first created. We recommend [ISO-8601](http://en.wikipedia.org/wiki/ISO_8601) date strings.</td>
+    <td>Date the user's account was first created. Segment recommends using [ISO-8601](http://en.wikipedia.org/wiki/ISO_8601) date strings.</td>
   </tr>
   <tr>
     <td>`description`</td>

src/guides/duplicate-data.md

@@ -2,13 +2,13 @@
 title: How does Segment handle 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 api has to hold the entire set of events in memory in order to know whether or not it has seen that event already. Segment will store 24 hours worth of event `message_id`'s. Effectively, this means Segment will de-duplicate data that appears inside a 24 hour sliding window.
+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 api 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.
 
-An important point of stress about the above is that Segment de-duplicates on the event's `message_id`, not on the contents of an event payload. So unless you're generating `message_id`s for each event on your end, and trying duplicate data within a 24 hour period, Segment has no built-in mechanism to de-duplicate data.
+An important point remember is that Segment de-duplicates on the event's `message_id`, _not_ on the contents of an event payload. So if you aren't generating `message_id`s for each event, or are trying to deduplicate data over a longer period than 24 hours, Segment does not have a built-in way to de-duplicate data.
 
-Since the api layer is de-duping during this window, duplicate events that are further than 24 hours apart from one another will need to be de-duped in the Warehouse. Segment also dedupes messages going into a Warehouse based on the `message_id`, which is the `id` column in a Segment Warehouse. Note that in these cases you will see duplications in end tools as there is no additional layer prior to sending the event to downstream tools.
+Since the api layer is de-duping during this window, duplicate events that are further than 24 hours apart from one another must be de-duped in the Warehouse. Segment also dedupes messages going into a Warehouse based on the `message_id`, which is the `id` column in a Segment Warehouse. Note that in these cases you will see duplications in end tools as there is no additional layer prior to sending the event to downstream tools.
 
-Keep in mind that Segment's libraries all generate `message_id`s for you for each event payload, with the exception of our HTTP API, which assigns each event a unique `message_id` when the message is ingested, although you could of course override and manually assign a `message_id` if you wanted.
+Keep in mind that Segment's libraries all generate `message_id`s for you for each event payload, with the exception of the Segment HTTP API, which assigns each event a unique `message_id` when the message is ingested. You can override these default generated IDs and manually assign a `message_id` if necessary.
 
 ### What identifiers can the merged profile be queried/updated with?
 

src/guides/usage-and-billing/billing.md

@@ -4,22 +4,22 @@ title: Billing and Account FAQs
 
 ## What is a billing cycle?
 
-On our monthly Team plan, your billing cycle will start the day after your 14-day trial ends. You will be billed on this day each month going forward. 
+On the Segment monthly Team plan, your billing cycle starts the day after your 14-day trial ends. You are billed on this day for each month while you are on this plan. 
 
-On our annual Team plan, you will be billed at the end of your 14-day trail for the sum of the entire year of service at a certain number of MTU. All overages for annual plans are billed at the end of your monthly billing cycle.
+On the Segment annual Team plan, you are billed at the end of your 14-day trail for the amount for an entire year of service including a specific number of MTUs. Annual plan subscribers are billed for MTU overages at the end of each monthly cycle.
 
 
 ## How do I change my plan?
 
-If you already have a Segment workspace, you can change which plan your workspace is on by navigating to the "Usage & Billing" menu, then finding the "Plans" page. You can select your new plan on the "Plans" page.
+If you already have a Segment workspace, you can change which plan your workspace is on by navigating to the "Usage & Billing" menu, then finding the "Plans" page. You can select a different plan from the "Plans" page.
 
-_If you cancel or downgrade your workspace within your 2-week trial period, you will not incur any charges._
+_If you cancel or downgrade your plan during the two-week trial period, you do not incur any charges._
 
-### What if I cancel my workspace before the end of the month?
+### What if I cancel my paid plan before the end of the month?
 
 #### Cancellation on the Monthly Team Plan
 
-If you cancel your workspace or downgrade to a free account before the end of your official billing period on the monthly team plan, you will receive a final bill consisting of a prorated amount for the $120 base + a charge for any MTUs you have used over the allotted 10,000 at the rates posted on our [pricing page](https://segment.com/pricing).
+If you cancel your plan or downgrade to a free account before the end of your official billing period on the monthly team plan, you will receive a final bill for the prorated amount for the $120 base + a charge for any MTUs you have used over the allotted 10,000 at the rates posted on our [pricing page](https://segment.com/pricing).
 
 #### Cancellation on the Annual Team Plan