Definition

A variable is built with several components:

• Name: A label displayed in the builder to identify the variable
• Function: The method used to process and combine (aggregate) the selected data
• Field: The specific data field used to perform the computation (sum, average...)
• Optional Filter(s): List of criteria used to select a relevant subset of your data

List of supported functions and their descriptions:

Example

Suppose we want to check if the average payout transaction over the last 7 days exceeds €15,000. Here’s how we can achieve this:

1. Select the Function: Choose the "Average" function to calculate the mean value of the payout transactions.

2. Choose a name for the variable: it does not impact how it's computed, but will help make your rule more readable in the builder
3. Choose an aggregation function: the type of aggregation that you want to compute
4. Choose an entity and field to aggregate on: Choose the target field on which you want to aggregate. You will be able to add filters on this table's field in the following step
5. Add filters: Add the relevant filters that you want to filter on, on the target field table.

6. Save and View: After saving, the variable will be displayed in the builder, showing the specified condition.

Filters

Available options

Filters work similarly to comparison operators in the formula, but with some limitations specific to how they are used.

They work in the context of a target table, that is to say the table (or data model entity) whose field we want to aggregate.

• The left-hand field must be a reference to a field from the target table, while the right-hand field can take any value allowed in the builder (except nested aggregate variables)
• The comparison operators between the values are more limited than in the formula builder. In particular, approximate string matching is not available in filters. You can still use operators like >, =,\< etc, as well as the is in list and is not in list operators.

Necessity of using filters

It is almost always important to specify a sufficient set of filters in the variable, so that the aggregation can be computed quickly. Marble will make sure to index the values as best as possible to ensure a quick computation, but an aggregate that averages over all values in the database is bound to be slow, and may lead to critically slow response times and/or timeouts.

See below an anti-pattern and an improvement on it.