Reword event metric expensiveness warning [doc only]

docs/user/reference/metrics/event.md

@@ -10,12 +10,19 @@ Each event contains the following data:
 - The name of the event.
 - A set of key-value pairs, where the keys are predefined in the `extra_keys` metric parameter, and the values are strings.
 
-{{#include ../../../shared/blockquote-warning.html}}
+{{#include ../../../shared/blockquote-info.html}}
 
-##### Important
+## Are you sure you need an event metric?
 
-> Events are the most expensive metric type to record, transmit, store and analyze,
-> so they should be used sparingly, and only when none of the other metric types are sufficient for answering your question.
+> Event metrics are able to carry a lot of information. As such they can be used in place
+> 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
+> 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).
 
 ## Recording API
 

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

@@ -24,7 +24,7 @@ If the value is true or false, use a [boolean metric](../../reference/metrics/bo
 
 If the value is a string, use a [string metric](../../reference/metrics/string.html). For example, to record the name of the default search engine.
 
-> **Beware:** string metrics are exceedingly general, and you are probably best served by selecting the most specific metric for the job, since you'll get better error checking and richer analysis tools for free. For example, avoid storing a number in a string metric --- you probably want a [counter metric]../..(/reference/metrics/counter.html) instead.
+> **Beware:** string metrics are exceedingly general, and you are probably best served by selecting the most specific metric for the job, since you'll get better error checking and richer analysis tools for free. For example, avoid storing a number in a string metric --- you probably want a [counter metric](../../reference/metrics/counter.html) instead.
 
 If you need to store multiple string values in a metric, use a [string list metric](../../reference/metrics/string_list.html). For example, you may want to record the list of other Mozilla products installed on the device.
 
@@ -60,8 +60,6 @@ If you need to know the time between multiple distinct actions that aren't a sim
 
 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).
 
-> **Important:** events are the most expensive metric type to record, transmit, store and analyze, so they should be used sparingly, and only when none of the other metric types are sufficient for answering your question.
-
 ## 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.