[DOCS] Improves influencer documentation (elastic#2221)

Author: szabosteve

docs/en/stack/ml/anomaly-detection/ml-influencers.asciidoc

@@ -5,35 +5,49 @@ suspicions about which entities in your data set are likely causing
 irregularities, you can identify them as influencers in your {anomaly-jobs}.
 That is to say, _influencers_ are fields that you suspect contain information
 about someone or something that influences or contributes to anomalies in your
-data.
-
-Influencers can be any field in your data. If you use {dfeeds}, however, the
-field must exist in your {dfeed} query or aggregation; otherwise it is not
-included in the job analysis. If you use a query in your {dfeed}, there is an
-additional requirement: influencer fields must exist in the query results in the
-same hit as the detector fields. {dfeeds-cap} process data by paging through the
-query results; since search hits cannot span multiple indices or documents,
-{dfeeds} have the same limitation. 
-
-Influencers do not need to be fields that are specified in your {anomaly-job}
-detectors, though they often are. If you use aggregations in your {dfeed}, it is
-possible to use influencers that come from different indices than the detector
-fields. However, both indices must have a date field with the same name, which you
-specify in the `data_description`.`time_field` property for the {dfeed}.
+data. Influencers can be any field in your data.
+
+You can pick influencers when you create your {anomaly-job} by using the 
+**Advanced job wizard**.
+
+.**Requirements when using the {ml} APIs to pick influencers**
+[%collapsible]
+====
+* The influencer field must exist in your {dfeed} query or aggregation; 
+otherwise it is not included in the job analysis.
+* If you use a query in your {dfeed}: influencer fields must exist in the query 
+results in the same hit as the detector fields. {dfeeds-cap} process data by 
+paging through the query results; since search hits cannot span multiple indices 
+or documents, {dfeeds} have the same limitation.
+* If you use aggregations in your {dfeed}, it is possible to use influencers 
+that come from different indices than the detector fields. However, both indices 
+must have a date field with the same name, which you specify in the 
+`data_description`.`time_field` property for the {dfeed}.
+* Influencers do not need to be fields that are specified in your {anomaly-job}
+detectors, though they often are.
+====
 
 Picking an influencer is strongly recommended for the following reasons:
 
-* It allows you to more easily assign blame for anomalies
-* It simplifies and aggregates the results
+* It allows you to more easily assign blame for anomalies.
+* It simplifies and aggregates the results.
 
 If you use {kib}, the job creation wizards can suggest which fields to use as
 influencers. The best influencer is the person or thing that you want to blame
-for the anomaly. In many cases, users or client IP addresses make excellent
-influencers.
+for the anomaly. In many cases, categorical data fields – like users or client 
+IP addresses – make excellent influencers.
+
+The **Anomaly Explorer** in {kib} lists the top influencers for a job and shows 
+the most influental values for every anomaly. It also enables you to filter the 
+data by a given influencer. 
+
+TIP: Do not pick too many influencers. For example, you generally do not need 
+more than three. If you pick many influencers, the results can be overwhelming 
+and there is a small overhead to the analysis.
 
-TIP: As a best practice, do not pick too many influencers. For example, you
-generally do not need more than three. If you pick many influencers, the results
-can be overwhelming and there is a small overhead to the analysis.
+Refer to 
+https://www.elastic.co/blog/interpretability-in-ml-identifying-anomalies-influencers-root-causes[this blog post]
+for further details on influencers.
 
 
 end::influencers[]