Update spec doc

Author: rchinn1

src/connections/spec/identify.md

@@ -12,7 +12,7 @@ Segment recommends that you make an Identify call:
 - After a user logs in
 - When a user updates their info (for example, they change or add a new address)
 
-The first three examples are pretty self-explanatory, but many might ask: why you would call identify on every page load if you'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 you're storing the `userId` in the cookie/local storage?
 
 Calling Identify in one of Segment's [libraries](/docs/connections/sources/) is one of the first steps to getting started with Segment. Refer to library-specific documentation for more details.
 
@@ -51,6 +51,8 @@ Beyond the common fields, an Identify call has the following fields:
   {% include content/spec-field-user-id.md %}
 </table>
 
+> info ""
+> Note that these traits coming in from your source events are called [custom traits](/docs/unify/traits/custom-traits/).
 
 ## Example
 
@@ -109,7 +111,8 @@ In these cases, you should use an Anonymous ID.
 
 The Anonymous ID can be any pseudo-unique identifier. For example, on your servers you can use a session id. If you don't have any readily available identifier, you can always generate a new random one—Segment recommends [UUIDs](http://en.wikipedia.org/wiki/Universally_unique_identifier){:target="_blank"}.
 
-**Note:** Segment's [browser and mobile libraries](/docs/connections/sources/) **automatically** use Anonymous IDs to keep track of users as they navigate around your website or app, so you don't need to worry about them when using those libraries.
+> info ""
+> Segment's [browser and mobile libraries](/docs/connections/sources/) automatically use Anonymous IDs to keep track of users as they navigate around your website or app, so you don't need to worry about them when using those libraries.
 
 Here's an example of a JavaScript event for an anonymous user:
 
@@ -127,17 +130,18 @@ A User ID is usually the unique identifier that you recognize a user by in your
 
 Segment recommends using database IDs instead of simple email addresses or usernames, because database IDs _never_ change. That guarantees that even if the user changes their email address, you can still recognize them as the same person in all of your analytics tools. And even better, you'll be able to correlate analytics data with your own internal database.
 
-**Instead of using an email address or a username as a User ID, send them along as [traits](/docs/connections/spec/identify#traits).**
+> success ""
+> Instead of using an email address or a username as a User ID, send them along as [custom traits](/docs/unify/traits/custom-traits/).
 
-## Traits
+## Custom traits
 
-Traits are pieces of information you know about a user that are included in an Identify call. These could be demographics like `age` or `gender`, account-specific like `plan`, or even things like whether a user has seen a particular A/B test variation.
+[Custom traits](/docs/unify/traits/custom-traits/) are pieces of information you know about a user that are included in an Identify call. These could be demographics like `age` or `gender`, account-specific like `plan`, or even things like whether a user has seen a particular A/B test variation.
 
-Segment has reserved some traits that have semantic meanings for users, and will handle them in special ways. For example, Segment always expects `email` to be a string of the user's email address. Segment sends this on to destinations like _Mailchimp_ that require an email address for their tracking.
+Segment has reserved some custom traits that have semantic meanings for users, and will handle them in special ways. For example, Segment always expects `email` to be a string of the user's email address. Segment sends this on to destinations like _Mailchimp_ that require an email address for their tracking.
 
 You should **only use reserved traits for their intended meaning**.
 
-Reserved traits Segment has standardized:
+Reserved custom traits Segment has standardized:
 
 | **Trait**     | **Type** | **Description**          |
 |---------------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -146,7 +150,7 @@ Reserved traits Segment has standardized:
 | `avatar`      | String   | URL to an avatar image for the user  |
 | `birthday`    | Date     | User's birthday         |
 | `company`     | Object   | Company the user represents, optionally containing: `name` (String), `id` (String or Number), `industry` (String), `employee_count` (Number) or `plan` (String) |
-| `createdAt`   | Date     | Date the user's account was first created. Segment recommends using [ISO-8601](http://en.wikipedia.org/wiki/ISO_8601) date strings.       |
+| `createdAt`   | Date     | Date the user's account was first created. Segment recommends using [ISO-8601](http://en.wikipedia.org/wiki/ISO_8601){:target="_blank"} date strings.       |
 | `description` | String   | Description of the user |
 | `email`       | String   | Email address of a user |
 | `firstName`   | String   | First name of a user    |
@@ -159,6 +163,7 @@ Reserved traits Segment has standardized:
 | `username`    | String   | User's username. This should be unique to each user, like the usernames of Twitter or GitHub.             |
 | `website`     | String   | Website of a user       |
 
-**Note:** You might be used to some destinations recognizing special traits by slightly different names. For example, Mixpanel recognizes a `$created` trait when the user's account was first created, while Intercom recognizes the same trait as `created_at` instead. Segment attempts to handle all the destination-specific conversions for you automatically. If you need help understanding if a specific field will be converted to a destination, take a look at Segment's [open source integration code](https://github.com/segment-integrations?q=&type=all&language=&sort=){:target="_blank"}, view the destination's documentation, or [contact Segment support](https://app.segment.com/workspaces?contact=1).
+> info ""
+> You might be used to some destinations recognizing special traits by slightly different names. For example, Mixpanel recognizes a `$created` trait when the user's account was first created, while Intercom recognizes the same trait as `created_at` instead. Segment attempts to handle all the destination-specific conversions for you automatically. If you need help understanding if a specific field will be converted to a destination, take a look at Segment's [open source integration code](https://github.com/segment-integrations?q=&type=all&language=&sort=){:target="_blank"}, view the destination's documentation, or [contact Segment support](https://app.segment.com/workspaces?contact=1){:target="_blank"}.
 
 **You can pass these reserved traits using camelCase or snake_case**, so in JavaScript you can match the rest of your camel-case code by sending `firstName`, while in Ruby you can match your snake-case code by sending `first_name`. That way the API never seems alien to your code base. Keep in mind that not all destinations support these reserved traits, so sending these traits in camelCase and snake_case can result in two sets of traits in other destinations.