Window BTS Tutorial
Last updated
Last updated
In this tutorial we'll introduce a new type of BTS: the Window BTS, and will learn how a Window BTS consumes session data produced in the first tutorial in order to generate time aggregated data.
Try the code from this example .
For this second tutorial we'll introduce the concept of boosts to the game we defined previously.
In order to make the game more exciting a user can now activate a boost when starting a play session. While the boost is active, games become easier. Chances of winning a game are increased.
When the player activates a boost, the game_start event will include a "boost": true property:
There are a couple of restrictions with boosts though:
A player can activate a boost only once.
The boost will be active for just 3 days.
We expect our players will be encouraged to play more often during the next 3 days after activating the boost.
The following change is made to the streaming BTS from the previous tutorial to take into account the boost information.
This will set the value of boost in the aggregate to True if any of the events in the aggregate have the boost set to true.
The goal of this tutorial is to collect aggregated session data that validates our assumption.
In order to confirm our hypothesis we're interested in comparing two figures:
The average number of games played by session before activating the boost
The average number of games played by session while the boost is active
We will obtain this data by aggregating the original session data obtained in the first tutorial into an series of records containing the desired information:
user_id
last_7_days.avg_games_per_session
next_3_days.avg_games_per_session
09C1
4.82
5.61
B6FA
2.73
3.09
NV9T
8.11
12.52
6CF3
9.89
14.74
This result shows our players have increased the games played per session after activating the boost.
In order to obtain the output described before, Blurr will perform time-based aggregation over the historic session data obtained with the Streaming BTS in the first tutorial. This transformation is defined in a Window BTS:
As we can see, the structure of a Window BTS is pretty similar to the Streaming BTS. There are 2 new elements though: SourceBTS and Anchor
As we mentioned before, a Window BTS will use session data produced by a Streaming BTS as data input. This is indicated in SourceBTS:
sessions is the Name given to the Streaming BTS in its header:
In time-based aggregations, data is aggregated around Anchor Points. This a key concept in time-based transformations. In our example, an Anchor Point is the session in which the boost is activated for a user:
The Name given to source BTS above is used to access the BTS's properties. i.e in this case sessions.sessions_stats.boost
It's time to bring back the concept of Identity introduced in the previous tutorial:
So far, we've thought of the Identity as a mandatory field that is part of both the original events and session data.
In a Window BTS the Identity also has a role: grouping data that is aggregated around Anchor Points. The Identity ensures that our output has one record per user.
Our Window BTS performs 2 different aggregations:
Over all sessions 7 days before the Anchor Point.
Over all sessions 3 days after the Anchor Point.
How each aggregate is calculated is defined in the Window Aggregates:
This Window Aggregate is responsible for aggregating data over the previous 7 days before the boost activation.
WindowType and WindowValue are used to indicate the how many days/hours of data from/since the Anchor Point are being collected:
Source is used to lookup input data from the Streaming BTS.
In this case the input is session data produced in session_stats Aggregate in sessions Streaming BTS:
Data is aggregated using the Value expression of a Field:
We're interested in the name of games played by session, which is the result of dividing the number of games played in all sessions by the number of sessions:
This is calculated with the following Python expression:
It's important to note that in context, source is not a list of sessions, but an object containing list of session_fields instead.
For example, the value of games_played for the first session collected is accessed as:
Instead of
The shape of source object therefore looks like this:
Within expressions you can use any Python function applicable to lists, such as len(source.session_id) sum(source.games_played) or even more complex operations like
We can preview the result of the transformation using blurr transform command.
To preview a window transformation we need to pass both the Streaming and Window BTS as arguments:
Each entry consists of an array with 2 items:
user_id, the Identity from the Streaming BTS.
An object with the remaining values of the record.
Note:- It will print once for each user in the raw events file wether the window aggregates exist or not.