@@ -24,7 +24,7 @@ might be returned if their support values are different.
24
24
25
25
The runtime of the aggregation depends on the data and the provided parameters.
26
26
It might take a significant time for the aggregation to complete. For this
27
- reason, it is recommended to use <<async-search, async search>> to run your
27
+ reason, it is recommended to use <<async-search,async search>> to run your
28
28
requests asynchronously.
29
29
30
30
@@ -73,7 +73,7 @@ aggregation might require a significant amount of system resources.
73
73
The minimum set size is the minimum number of items the set needs to contain. A
74
74
value of 1 returns the frequency of single items. Only item sets that contain at
75
75
least the number of `minimum_set_size` items are returned. For example, the item
76
- set `orange, banana, apple` is only returned if the minimum set size is 3 or
76
+ set `orange, banana, apple` is returned only if the minimum set size is 3 or
77
77
lower.
78
78
79
79
[discrete]
@@ -123,15 +123,15 @@ In the following examples, we use the e-commerce {kib} sample data set.
123
123
124
124
125
125
[discrete]
126
- ==== Aggregation with two analized fields
126
+ ==== Aggregation with two analyzed fields
127
127
128
128
In the first example, the goal is to find out based on transaction data (1.)
129
129
from what product categories the customers purchase products frequently together
130
130
and (2.) from which cities they make those purchases. We are interested in sets
131
131
with three or more items, and want to see the first three frequent item sets
132
132
with the highest support.
133
133
134
- Note that we use the <<async-search, async search>> endpoint in this first
134
+ Note that we use the <<async-search,async search>> endpoint in this first
135
135
example.
136
136
137
137
[source,console]
@@ -228,8 +228,8 @@ of documents containing the item set by the total number of documents.
228
228
The response shows that the categories customers purchase from most frequently
229
229
together are `Women's Clothing` and `Women's Shoes` and customers from New York
230
230
tend to buy items from these categories frequently togeher. In other words,
231
- customers who buy products labelled Women's Clothing more likely buy products
232
- also from the Women's Shoes category and customers from New York most likely buy
231
+ customers who buy products labelled ` Women's Clothing` more likely buy products
232
+ also from the ` Women's Shoes` category and customers from New York most likely buy
233
233
products from these categories together. The item set with the second highest
234
234
support is `Women's Clothing` and `Women's Accessories` with customers mostly
235
235
from New York. Finally, the item set with the third highest support is
@@ -269,8 +269,8 @@ POST /kibana_sample_data_ecommerce/_async_search
269
269
// TEST[skip:setup kibana sample data]
270
270
271
271
The result will only show item sets that created from documents matching the
272
- filter, namely purchases in Europe. Using `filter` the calculated `support` still
273
- takes all purchases into acount. That's different to specifying a query at the
272
+ filter, namely purchases in Europe. Using `filter`, the calculated `support` still
273
+ takes all purchases into acount. That's different than specifying a query at the
274
274
top-level, in which case `support` gets calculated only from purchases in Europe.
275
275
276
276
@@ -279,7 +279,7 @@ top-level, in which case `support` gets calculated only from purchases in Europe
279
279
280
280
The frequent items aggregation enables you to bucket numeric values by using
281
281
<<runtime,runtime fields>>. The next example demonstrates how to use a script to
282
- add a runtime field to your documents that called `price_range` which is
282
+ add a runtime field to your documents called `price_range`, which is
283
283
calculated from the taxful total price of the individual transactions. The
284
284
runtime field then can be used in the frequent items aggregation as a field to
285
285
analyze.
0 commit comments