anchor.diff:  TIP: If your detectors use metric or sum analytical functions, set the
   `interval` of the date histogram aggregation to a tenth of the `bucket_span`
   that was defined in the job. This suggestion creates finer, more granular time
  -buckets, which are ideal for this type of analysis. If your detectors use count or rare functions, set
  -`interval` to the same value as `bucket_span`. For more information about
  -analytical functions, see <<ml-functions>>.
  -
  -//TBD: Add more examples from https://github.com/elastic/prelert-legacy/wiki/Configuring-aggregations-on-a-datafeed
  +buckets, which are ideal for this type of analysis. If your detectors use count
  +or rare functions, set `interval` to the same value as `bucket_span`. For more
  +information about analytical functions, see <<ml-functions>>.
  
positive.code: distributes these calculations across your cluster. You can then feed this
  aggregated data into {xpackml} instead of raw results, which
  reduces the volume of data that must be considered while detecting anomalies.
  //TBD: Are "aggregated" and "summarized" equivalent terms? Are customers more
  //familiar with one or the other? If so, I'll use one term throughout.
  
  There are some limitations to using aggregations in {dfeeds}, however.
  Your aggregation must include a buckets aggregation, which in turn must contain
  
negative.code: `airline` and `responsetime`. Since you must create the job before you can
  create the {dfeed}, synchronizing your aggregation and field names can simplify
  these configuration steps.
  
  IMPORTANT: If you use a `max` aggregation on a time field, the aggregation name
  in the {dfeed} must match the name of the time field, as in the previous example.
  For all other aggregations, if the aggregation name doesn't match the field name,
  there are limitations in the drill-down functionality within the {ml} page in
  {kib}.
  
  When you define an aggregation in a {dfeed}, it must have the following form:
  
  