Add links to Full Segment Implementation (#4110)

sarahrudy · markzegarelli · web-flow · commit 50915db55176 · 2023-01-26T09:03:06.000-08:00
* Add useful links to Full Segment Implementation

* Update 04-full-install.md

* Apply suggestions from code review

Co-authored-by: markzegarelli &lt;mark.zegarelli@segment.com&gt;
diff --git a/src/getting-started/04-full-install.md b/src/getting-started/04-full-install.md
@@ -27,7 +27,7 @@ The other three, Track, Page, and Screen, can be considered as increasingly spec
 A Track call is the most basic type of call, and can represent any type of event. Page and Screen are similar and are triggered by a user viewing a page or screen, however Page calls can come from both web and mobile-web views, while Screen calls *only* occur on mobile devices. Because of the difference in platform, the context information collected is very different between the two types of calls.
 
 > success ""
-> **Tip**! Segment recommends that you always use the Page and Screen calls when recording a page-view, rather than creating a "Page Viewed" event, because the Page/Screen calls automatically collect much better context information.
+> Segment recommends that you always use the Page and Screen calls when recording a page-view, rather than creating a "Page Viewed" Track event, because the Page/Screen calls automatically collect more contextual information.
 
 ## Anatomy of a Segment message
 
@@ -39,21 +39,24 @@ A Track call is the most basic type of call, and can represent any type of event
 ![](images/identify-call.png)
 
 
-The `identify` call allows Segment to know **who** is triggering an event.
+The Identify call allows Segment to know **who** is triggering an event.
 
 ### When to call Identify
 
-Call `Identify` when the user first provides identifying information about themselves (usually during log in), or when a they update their profile information.
+Call Identify when the user first provides identifying information about themselves (usually during log in), or when they update their profile information.
 
-When called as part of the login experience, you should call `identify` as soon as possible after the user logs in. When possible, follow the `identify` call with a `track` event that records what caused the user to be identified.
+When called as part of the login experience, you should call Identify as soon as possible after the user logs in. When possible, follow the Identify call with a Track event that records what caused the user to be identified.
 
-When you make an `identify` call as part of a profile update, you only need to send the changed information to Segment. You can send all profile info on every `identify` call if that makes implementation easier, but this is optional.
+When you make an Identify call as part of a profile update, you only need to send the changed information to Segment. You can send all profile info on every Identify call if that makes implementation easier, but this is optional.
+
+> info "Learn More"
+> [Best Practices for Identifying Users](https://segment.com/docs/connections/spec/best-practices-identify/)
 
 ## Traits in Identify calls
 
-These are called "Traits" for Identify calls, and "Properties" for all other methods.
+These are called [traits](/docs/connections/spec/identify/#traits)for Identify calls, and [properties](/docs/connections/spec/track/#properties) for all other methods.
 
-**The most important trait to pass as part of the identify() call is userId**, which uniquely identifies a user across all applications.
+**The most important trait to pass as part of the Identify call is userId**, which uniquely identifies a user across all applications.
 
 You should use a hash value to ensure uniqueness, although other values are acceptable; for example, email address isn't the best thing to use as a userid, but is usually acceptable since it will be unique, and doesn't change often.
 
@@ -69,7 +72,7 @@ Consider using Identify and traits when:
 
 You can call Identify from any of Segment's device-based or server-based libraries, including [Javascript](/docs/connections/sources/catalog/libraries/website/javascript/), [iOS](/docs/connections/sources/catalog/libraries/mobile/ios), [Android](/docs/connections/sources/catalog/libraries/mobile/android), [Ruby](/docs/connections/sources/catalog/libraries/server/ruby/), and [Python](/docs/connections/sources/catalog/libraries/server/python/).
 
-Here are two examples of calling identify from two different libraries:
+Here are two examples of calling Identify from two different libraries:
 
 
 {% codeexample %}
@@ -102,13 +105,13 @@ analytics.identify( user_id: "12345abcde",
 
 ## Using analytics.reset()
 
-When a user explicitly signs out of one of your applications, you can call `analytics.reset()` to stop logging further event activity to that user, and create a new `anonymousId` for subsequent activity (until the user logins in again and is subsequently `identify`-ed). **This call is most relevant for client-side Segment libraries**, as it clears cookies in the user's browser.
+When a user explicitly signs out of one of your applications, you can call `analytics.reset()` to stop logging further event activity to that user, and create a new `anonymousId` for subsequent activity (until the user logins in again and is subsequently identify-ed). **This call is most relevant for client-side Segment libraries**, as it clears cookies in the user's browser.
 
-Make a `Reset()` call as soon as possible after sign-out occurs, and only after it succeeds (not immediately when the user clicks sign out). For more info on this call, [see the JavaScript source documentation](/docs/connections/sources/catalog/libraries/website/javascript/#reset-or-logout).
+Make a `reset()` call as soon as possible after sign-out occurs, and only after it succeeds (not immediately when the user clicks sign out). For more info on this call, [see the JavaScript source documentation](/docs/connections/sources/catalog/libraries/website/javascript/#reset-or-logout).
 
 ## Page and Screen
 
-The `Page` and `Screen` calls tell Segment what web page or mobile screen the user is on. This call automatically captures important context traits, so you don't have to manually implement and send this data.
+The Page and Screen calls tell Segment what web page or mobile screen the user is on. This call automatically captures important context traits, so you don't have to manually implement and send this data.
 
 | **Page context** auto-captured | **Screen context** auto-captured                    |             |                                                                                                    |
 | ------------------------------ | --------------------------------------------------- | ----------- | -------------------------------------------------------------------------------------------------- |
@@ -125,13 +128,13 @@ The `Page` and `Screen` calls tell Segment what web page or mobile screen the us
 
 You can always [override the auto-collected Page/Screen properties](/docs/connections/sources/catalog/libraries/website/javascript/#default-properties) with your own, and set additional custom page or screen properties.
 
-Some downstream tools (like [Marketo](/docs/connections/destinations/catalog/marketo/)) require that you attach specific properties (like email address) to every `page` call.
+Some downstream tools (like [Marketo](/docs/connections/destinations/catalog/marketo/)) require that you attach specific properties (like email address) to every Page call.
 
 This is considered a destination-specific implementation nuance, and you should check the documentation for each destination you plan to use and make a list of these nuances before you start implementation.
 
 ### Named Page & Screen Calls
 
-You can specify a page “Name" at the start of the page or screen call, which is especially useful to make list of page names into something more succinct for analytics. For example, on an ecommerce site you might want to call `analytics.page( "Product" )` and then provide properties for that product:
+You can specify a page “Name" at the start of the page or Screen call, which is especially useful to make list of page names into something more succinct for analytics. For example, on an ecommerce site you might want to call `analytics.page( "Product" )` and then provide properties for that product:
 
 
 {% codeexample %}
@@ -157,7 +160,7 @@ properties:@{ @"category": @"Smartwatches", @"sku": @"13d31" }];
 
 ### When to Call Page
 
-Segment automatically calls a `page` event whenever a web page loads. This might be enough for most of your needs, but if you change the URL path without reloading the page, for example in single page web apps, you must call `page` manually .
+Segment automatically calls a Page event whenever a web page loads. This might be enough for most of your needs, but if you change the URL path without reloading the page, for example in single page web apps, you must call Page manually .
 
 If the presentation of user interface components don't substantially change the user's context (for example, if a menu is displayed, search results are sorted/filtered, or an information panel is displayed on the exiting UI) **measure the event with a Track call, not a Page call.**
 
@@ -183,9 +186,9 @@ The Track call is used to track user and system events, such as:
 
 ### Events and Properties
 
-Your track calls should include both events and properties. **Events are the actions you want to track**, and **properties are the data _about_ the event that are sent with each event**.
+Your Track calls should include both events and properties. **Events are the actions you want to track**, and **properties are the data _about_ the event that are sent with each event**.
 
-Properties are powerful. They enable you to capture as much context about the event as you'd like, and then cross-tabulate or filter your downstream tools. For example, let's say an eLearning website is tracking whenever a user bookmarks an educational article on a page. Here's what a robust analytics.js Track call could look like:
+[Properties](/docs/connections/spec/track/#properties) are powerful. They enable you to capture as much context about the event as you'd like, and then cross-tabulate or filter your downstream tools. For example, let's say an eLearning website is tracking whenever a user bookmarks an educational article on a page. Here's what a robust analytics.js Track call could look like:
 
 ```js
 analytics.track('Article Bookmarked', {
@@ -201,11 +204,11 @@ analytics.track('Article Bookmarked', {
 });
 ```
 
-With this track call, we can analyze which authors had the most popular articles, which months and years led to the greatest volume of bookmarking overall, which button locations drive the most bookmark clicks, or which users gravitate towards infographics related to Data Planning.
+With this Track call, we can analyze which authors had the most popular articles, which months and years led to the greatest volume of bookmarking overall, which button locations drive the most bookmark clicks, or which users gravitate towards infographics related to Data Planning.
 
 ## Event Naming Best Practices
 
-Each event you track must have a name that describes the event, like 'Article Bookmarked' above. That name is passed in at the beginning of the track call, and should be standardized across all your properties so you can compare the same actions on different properties.
+Each event you track must have a name that describes the event, like 'Article Bookmarked' above. That name is passed in at the beginning of the Track call, and should be standardized across all your properties so you can compare the same actions on different properties.
 
 Segment's best practice is to use an “Object Action” (Noun<>Verb) naming convention for all **Track** events, for example, 'Article Bookmarked'.
 
@@ -234,7 +237,7 @@ Use the following list of objects to see if there is a logical match with your a
 
 ### Actions are Verbs
 
-Verbs indicate the action taken by either a user on your site. When you name a new track event, consider if you can describe the current interaction using a verb from the list below.
+Verbs indicate the action taken by either a user on your site. When you name a new Track event, consider if you can describe the current interaction using a verb from the list below.
 
 If you can't, choose a verb that describes what the user is trying to do in your specific case, but try to be flexible enough so that you could use it in other scenarios.
 
@@ -264,7 +267,7 @@ You can read more about [best practices for Track calls](/docs/connections/spec/
 
 All of the basic [Segment methods](/docs/connections/spec/) have a common structure and common fields which are automatically collected on every call. You can see these in the [common fields documentation](/docs/connections/spec/common/).
 
-### Common properties to send with Track call
+### Common properties to send with a Track call
 
 The following properties should be sent with every Track call:
 
@@ -283,7 +286,7 @@ The following properties should be sent with every Track call:
 
 ### How to call Track
 
-You can make a Track call from any of Segment's client-side or server-side libraries, including [JavaScript](/docs/connections/sources/catalog/libraries/website/javascript/), [iOS](/docs/connections/sources/catalog/libraries/mobile/ios), [Android](/docs/connections/sources/catalog/libraries/mobile/android), [Ruby](/docs/connections/sources/catalog/libraries/server/ruby/), and [Python](/docs/connections/sources/catalog/libraries/server/python/). Here are two examples of calling track from two different libraries:
+You can make a Track call from any of Segment's client-side or server-side libraries, including [JavaScript](/docs/connections/sources/catalog/libraries/website/javascript/), [iOS](/docs/connections/sources/catalog/libraries/mobile/ios), [Android](/docs/connections/sources/catalog/libraries/mobile/android), [Ruby](/docs/connections/sources/catalog/libraries/server/ruby/), and [Python](/docs/connections/sources/catalog/libraries/server/python/). Here are two examples of calling Track from two different libraries:
 
 
 {% codeexample %}
