Bug 1734454: Encourage the use of events for user behavior (#1827)

docs/user/reference/metrics/event.md

@@ -14,12 +14,9 @@ Each event contains the following data:
 
 ## Are you sure you need an event metric?
 
-> Event metrics are able to carry a lot of information. As such, they can be used in place
+> Events are best-suited to measuring user behavior, where the frequency of events is relatively low and the order of the events matters. Therefore, events should be the default choice for most user-behavior telemetry.
-> of other metric types. However, their complexity means they are an
-> expensive metric type to record, transmit, store and, most importantly, analyze.
 >
-> Make sure to use events only when their complexity is unavoidable,
+> For other types of telemetry (e.g. performance or stability), events may be too expensive metric type to record, transmit, store and, most importantly, analyze. In those cases, consider lighter metrics, such as [counters](counter.md).
-> e.g. when it is necessary to know the order of events relative to one another.
 >  
 > When in doubt, refer to the
 > [metric type choosing guide](../../user/metrics/adding-new-metrics.mdl#choosing-a-metric-type).

docs/user/user/metrics/adding-new-metrics.md

@@ -34,6 +34,13 @@ If you need to store multiple string values in a metric, use a [string list metr
 
 For all of the metric types in this section that measure single values, it is especially important to consider how the lifetime of the value relates to the ping it is being sent in. Since these metrics don't perform any aggregation on the client side, when a ping containing the metric is submitted, it will contain only the "last known" value for the metric, potentially resulting in **data loss**.  There is further discussion of [metric lifetimes](#when-should-the-glean-sdk-automatically-clear-the-measurement) below.
 
+
+### Are you measuring user behavior?
+
+For tracking user behavior, it is usually meaningful to know the over of events that lead to the use of a feature.  Therefore, for user behavior, an [event metric](../../reference/metrics/event.html) is usually the best choice.
+
+Be aware, however, that events can be particularly expensive to transmit, store and analyze, so should not be used for higher-frequency measurements.
+
 ### Are you counting things?
 
 If you want to know how many times something happened, use a [counter metric](../../reference/metrics/counter.html).  If you are counting a group of related things, or you don't know what all of the things to count are at build time, use a [labeled counter metric](../../reference/metrics/labeled_counters.html).
@@ -56,10 +63,6 @@ If you need to measure the relative occurrences of many timings, use a [timing d
 
 If you need to know the time between multiple distinct actions that aren't a simple "begin" and "end" pair, consider using an [event](../../reference/metrics/event.html).
 
-### Do you need to know the order of events relative to other events?
-
-If you need to know the order of actions relative to other actions, such as, the user performed tasks A, B, and then C, and this is meaningfully different from the user performing tasks A, C and then B, (in other words, the order is meaningful beyond just the *fact* that a set of tasks were performed), use an [event metric](../../reference/metrics/event.html).
-
 ## For how long do you need to collect this data?
 
 Think carefully about how long the metric will be needed, and set the `expires` parameter to disable the metric at the earliest possible time.