Aggregates and Running Aggregates
Aggregates are custom customer attributes that are calculated from already existing data. They help you calculate aggregated information for every customer. An example of aggregate would be calculating a customer's lifetime value: In your report, you would use sum>purchase>total_price
.
Running aggregates are custom event attributes, which is the main difference to aggregates. They help you calculate aggregated information for any event. Running aggregates can be used in almost any analytical part of Bloomreach Engagement.
Aggregate types | |
---|---|
minimum / maximum | Returns the smallest / biggest value from the dataset. |
sum | Sums values in the dataset. For example, sum > purchase > total_price will return the total spend. |
count | Count the number of data points. For example, count > purchase will return the number of purchases. |
avg (average) | Returns the average of all values of that specific event. |
first / last | Returns the value of the first / last occurrence of that event. |
exists | Returns either 1 or 0. For example, if a customer never purchased before, then exists > purchase will return 0 and vice versa. |
most common | Returns the most common value, such as the most viewed item. |
count distinct | This counts distinct values in a data set, such as how many different categories a specific customer viewed. |
distinct values | Lists all the unique values within an aggregate. |
For the most common
aggregate type, in case there are two (or more) equal outcomes, Bloomreach Engagement picks the first one that occurred in the event history.
Important
When using decimal numbers, make sure to denote them by
.
(e.g.12.34
) as otherwise,sum
,avg
or other mathematical aggregates will not work properly
Grasping aggregates and running aggregates and the difference between them might be a bit tricky at the beginning. That's why we created this short video that explains the topic for you. We do recommend watching it as you will be using (running) aggregates very often in Bloomreach Engagement.
Create a (running) aggregate
It can be created in two ways:
- Go to
Data & Assets
>Data manager
>Definitions
>New definition
. - Aggregates/running aggregates can also be created when selecting customer attributes/events for your analysis wherever it is possible. If you wish, you can also save them for later use (so next time it appears in the list) by clicking on the save button as shown below.
The process of creating an aggregate is simple:
a. Select the calculation operator (sum, first, last ...)
b. Select the event with which you want to calculate the aggregate. For example Count > purchase
calculates the number of purchases for all customers.
c. You can specify the metric further by adding an attribute of the event. For example Sum > purchase > total_price
will calculate the total revenue generated by each customer.
Running aggregates: The difference between including/excluding the event itself
Running aggregates contain one additional setting, which is deciding whether to include or exclude the event itself from the calculation. This setting is relevant when the anchor event is identical to the event from which the running aggregate is calculated. See the 2 Use Cases about calculating revenue and conversion rate by country below for a better understanding.
'Skip first' function
You can skip any number of values for the first
, last
and most common
aggregates. For example, you can use the aggregate "first purchase timestamp > skip 1", which will give you the timestamp of the second purchase of that particular customer.
For distinct aggregate, it has 100% precision if there are less than 10k unique values. If there are more values, it has around 97% precision.
Group by attribute
Why use grouping by attribute
The Grouping feature organizes events based on specific attributes, allowing you to track specific event changes for each customer. It only takes the first or last value, for example, the most recent update. It's useful for industries like travel or hospitality when you need the most recent update on event attributes.
Remember, though, that you can only group events using attributes in the Data Manager schema, ensuring alignment with available data fields.
Example 1: Find the updated final destination for flight bookings
Here, customer John has booked several flights. Each booking event has an ID and the final destination values.
Events sharing the same ID indicate they're part of the same trip but with John altering the final destination.
ID | Original destination | Updated final destination |
---|---|---|
789 | Prague | Brno |
456 | Bratislava | New York |
123 | Dallas | Mumbai |
Grouping by attribute allows you to see the latest destination by grouping based on an attribute shared by the bookings. This case applies an event filter for ‘bookings’ and groups by ‘IDs’.
Then, instead of looking at all the events, the feature only looks at the last one and finds the newest information for each booking.
Example 2: Find the lifetime value of a customer
Here, customer John has purchased several times. Each purchase has its unique ID and a ‘purchase_status’ value. As shown below, John decided to return a purchase with the ID 789.
Grouping by attribute allows you to find out John’s real lifetime value by considering only purchases with the ‘purchase_status’ = ‘success’, automatically excluding returns.
The Grouping feature which is applied before the filter, ensures that only purchases that haven’t been returned are counted in.
How grouping by attribute works
- Create an Aggregate:
- Define aggregation, event type, and filters.
- Enable Grouping:
- Select an event attribute for grouping.
- Choose to aggregate values from either the First or Last event in each group.
- Save the Aggregate:
- Use this aggregate as a normal one.
Aggregates can be used for personalization through Jinja, as well as for analytics.
Example use cases
Aggregates
Aggregates can be used for filtering and segmenting customers or in expressions. They are usually used in campaign filters. Check out these examples to see what kind of insights are available through aggregates. Notice every analysis related to a customer.
How many purchases does a customer have in total?
How many times customer visited our page in the last 30 days?
What is a customer’s total lifetime value?
What is the average customer purchase when using loyalty points for purchase?
What was the referrer of a customer’s first visit to the webpage?
How many emails has the customer received from us in the last 14 days?
What was the last product the customer viewed?
Running aggregates
What is the revenue per country?
If you don't track country
as an attribute of the purchase
event, then you need to retrieve it from the session_start
event using a running aggregate. For every purchase in the past Bloomreach Engagement will look a the last session_start > country
that preceded that purchase and will attribute that purchase to the country which is tracked there.
Note: Changing the including/excluding
operator does not make a difference here. Read the next use case for further explanation.
What is the conversion rate per country?
The metric (conversion rate) is, in this case, a formula that uses two types of events – session_start and purchase – meaning that the report cannot be broken down by an attribute of one, or the other. As mentioned above, the attribute ‘country’ is tracked for event session_start, but usually not for event purchase.
The running aggregate you will need for this report looks like this:
Here, it is crucial to switch from excluding to including. We essentially have two anchor events in this case – session_start
and purchase
. The running aggregate will look for the country of the last session_start
both before every purchase
event and before every session_start
event, including that very event. In other words, the including/excluding
setting matters here because the running aggregate is calculated from one of the anchor events - session_start
.
The report will look like this:
You may have noticed that, in this case, you have to insert the running aggregate into Rows, before inserting the Metric. Once you insert a formula that uses two types of events under Metrics, you won't be able to choose an event attribute (or running aggregate) under Rows anymore. So make sure to start with Rows in such cases.
What was the referrer for the last session_start of this event (for example: purchase)?
When was the last time a specific weblayer was viewed by any customer?
When was the last time an email was delivered to any customer?
Grouping by attribute
- Travel companies: Track new events for updates on trips, flights, or accommodations.
- Insurance companies: Maintain a record of the latest state of contracts.
- Count purchase aggregation: Create an aggregate for each user to get the number of purchases. Without this feature, you would also count purchases that have resulted in a return (Success - Return). However, with 'Group by' you can exclude such purchases like this:
- Count Purchase
- Where
Status = Success
- Where
- Group by ID and aggregate only the most recent events (Last events). This ensures that purchases marked as "Success" are genuinely the latest ones, and any subsequent "Return" status events are excluded.
- Count Purchase
Updated 9 days ago