Player Feature - Optimal Time of the Day

An in-depth look into Optimal Time of the Day, a system Player Feature: how it can be used, the objective of using it, and the logic of how it has been set up.

Optimal Time of the Day is a Player Feature in the Singularity Model that estimates, for each player, their preferred time of day to send communications (such as Activities or Lifecycles) to maximise engagement and key outcomes (e.g. deposits and sessions).
Optimal Time of the Day is a system Player Feature.
✅ This means that it has been created by FT and is available to use as part of the Singularity Model.
🧠 Please note that system Player Features cannot be edited or deleted. If you want to make changes, you must create your own version of the Player Feature.

⚙️ Feature Type

All Player Features must be connected to a Feature Type. Think of the Feature Types as the settings that define the language that we use to talk about important pieces of information. The Player Feature uses these settings and relates them to a player.
The Player Feature: Optimal Time of the Day is created based on the Feature Type: Time of Day.
The classes and slugs that are required by the Player Feature, are created and defined in the Feature Type.
📚 Further reading:
​Feature Types​
​Setting up Player Features​
​Movements​

🚀 Objective

The objective of the Optimal Time of the Day Player Feature is to:
  1. Target each player at their individual, data-driven optimal hour of the day (preferred send time).
  2. Automatically handle Multiple time zones by assigning an optimal hour in UTC, independent of the player’s local time.

🔍 How it works?

The send-out time is predicted based on conversion outcomes (e.g. deposits) from past campaigns across different hours of the day.
When there is not enough reliable conversion data, the model looks at when the player is usually active (e.g. when they log in or place bets) and sends the message shortly before that activity happens.
If no optimal time can be determined due to lack of data, the model falls back to the hour when the player most often deposits. If the player has never deposited, it uses the player’s registration hour.
The model follows this order:
  1. Use conversion data when it is sufficient.
  2. If not, use player activity patterns (login, betting).
  3. If activity data is limited, use the hour with the most deposits.
  4. As a last fallback, use the player’s registration hour.

🧠 Prediction Logic

Stage 1 – Conversion Rate–based Optimal Time

This stage uses past campaign performance to identify the most effective send-out time for each player.
For each player and each time-of-day bucket, we compute:
  1. Activity fires: number of communications sent in that time bucket
  2. Conversions: number of those communications that led to a deposit (within a defined attribution window)
  3. Conversion rate: conversions / activity fires
To ensure reliability, this stage is only used when there is sufficient campaign coverage (i.e. enough sends across enough time buckets). Additionally, only time buckets with:
  1. at least 6 Activity fires, and
  2. a conversion rate strictly greater than 0.2 are considered.
The time bucket with the best conversion rate is selected as the player’s Optimal Time of the Day.

Stage 2 - Player Activity-based Optimal Time prediction

If conversion data is not sufficient or reliable, the model falls back to player behaviour. It analyses when the player is usually active (e.g., when they log in, play, or place bets) and selects a send time shortly before the player’s peak activity.
Only the latest 100 sessions are taken into consideration to reflect the most recent patterns in user behaviour.

Stage 3 - Max Deposit Hour

If neither Stage 1 nor Stage 2 can provide a reliable prediction (for example, the player has low activity but some deposit history), the model uses deposit behaviour. The hour when the player has made the most deposits is selected as the optimal time.

Stage 4 - Registration Hour.

For players who have never deposited and have insufficient activity data, the final fallback is the player’s registration hour, which is used as their optimal time.
Evaluate Optimal Time of the Day
Evaluate Optimal Time of the Day

Possible outcomes (Classes)

As a result of this process, each player is assigned to exactly one hourly UTC class: 00:00 UTC (00:00–00:59) 01:00 UTC (01:00–01:59) 02:00 UTC (02:00–02:59) … 23:00 UTC (23:00–23:59)
When used inside an Activity or Lifecycle, the communication is sent at the start of the assigned hourly class. For example:
  1. Class 12:00 UTC → sends at 12:00 UTC
  2. Class 16:00 UTC → sends at 16:00 UTC

🔄 Movements

Movements define how players can move from one class to another within a Player Feature. They can either be:
  1. Real-time movements, triggered immediately by player actions (such as payments or registration), or
  2. Time-based queries, which run at a scheduled time and evaluate the player base to determine whether a player should move to a different class.
​
📚 Read more:
​Movements​
​Real-Time Movements​
​Time-Based Queries ​
For Optimal Time of the Day, there is one active movement responsible for updating player classes:
Active Processes
Active Processes

Evaluate Optimal Time of the Day

  1. Type: Time-Based Query
  2. Schedule: Every day at 03:00 UTC
  3. Scope: Evaluates the eligible player base (players excluded from communications may still be evaluated for classification purposes).
  4. Responsibility: Computes or updates each player’s Time of Day class using the multi-stage prediction logic described below (conversion → activity → deposits → registration).

🧠 Queries

Most of the Player Features in the Singularity Model make use of time-based queries. Queries are good for determining states of player inactivity, something a real-time movement is unable to determine.
Our queries are created using ClickHouse and are included in the Singularity Model for you to use.
🧠 Please note that the slug from the Feature Type class must match inside the query.
If you want to write your own queries, you can use the Query Editor or ask Fast Track for assistance. You can find the query editor in: Insights & Analytics menu - Data Studio - Query Editor.
Evaluate Optimal Time of the Day
Evaluate Optimal Time of the Day

🏁 What's Next

Dashboards

After some time, once the computation Triggers have fired, you'll be able to see that players have now been assigned to one of the classes of Player Feature. You can see this happen in the Player Distribution dashboard inside the Player Feature:
Player Distribution
Player Distribution

Segmentation

Following this, you can use Optimal Time of the Day when creating Segments for Activities and Lifecycles. You will be able to find Optimal Time of the Day amongst the Segment Fields when you’re creating a Segment.
Segment Field
Segment Field

Use Inside an Activity

Any Player Feature that has been set up using the Feature Type Time of Day, can be selected from inside an Activity or Lifecycle to determine the send-out time.
🚀 Learn how:
Continue reading here to learn how to use the Optimal Time of the Day player feature from inside an Activity.