AI Optimization of Push Notification Send Time

AI optimization of notifications: where manual logic breaks

Manual campaign logic almost always looks the same: the schedule is configured once — "weekday morning by head office time" — and after that all segments receive messages on this single schedule. While the base is local, the scheme works.

As soon as it contains users from several time zones, part of the audience starts receiving pushes at inconvenient hours.

Night delivery hits response from two sides at once. The user wakes up to a stack of accumulated notifications, reads them in a hurry, and swipes them away without looking — the message is wasted, and interest in the app is reduced.

During the day, on the contrary, the notification arrives in the middle of the workday and gets lost among others.

The first thing that declines is the open rate. In the summary report, the figure still looks tolerable: strong segments pull up the average, while by time zone the discrepancy is measured in multiples.

It is hard to notice this manually: to catch the moment, you need to compare response by each segment, device type, and message type.

Then manual logic stops scaling. There are dozens of segments, hundreds of events in the app, each user has their own rhythm — but the schedule is one for all.

Send-time optimization is needed precisely so that the delivery moment is chosen not by a general rule, but by the behavior of a specific person. Let's break down how this is addressed.

What adaptive notification delivery time provides

Adaptive delivery time is when the app does not send to everyone at one moment, but selects a window for a specific user: based on their open history, time zone, and time since the last launch.

The setting is recalculated on fresh data, so the window shifts along with changing habits rather than being fixed once at setup.

• Open rate. Sending in a personal window raises the open rate versus sending "to everyone at the same time" — we calculate the effect on a control group so as not to confuse it with seasonality.
• Click-through rate. Open and click-through are different metrics: a notification arrives on time but leads to a generic screen, and there are no click-throughs. Therefore, along with the time, we select the entry point.
• Unsubscribes from campaigns. Some unsubscribes are a reaction to an inconvenient moment, not to the content. Shifting the window removes this class of losses without editing the copy.
• Delivery failures. Invalid device addresses are cleaned on a schedule: the delivery failure rate falls, and the sender reputation with Firebase Cloud Messaging remains clean.
• Activity-based segmentation. New users, the core, and "sleeping" users need different windows and different frequency: a single setting creates skew — too frequent for some, too rare for others.

We record metrics before changes and compare over equal periods; otherwise, growth in opens can easily be attributed to seasonality. If opens grow while unsubscribes rise, the window is too aggressive, and the rule is revised.

Methods for selecting send time: comparison of modes

The choice of mode is determined by two things: how much data has been accumulated about a specific user's behavior and how homogeneous the base is by time zone. Below are five approaches encountered in production operation, with their real limits.

In practice, hybrid mode is assembled as follows: the forecast serves segments with history, the time zone rule covers the remainder, and for critical campaigns a manual window remains with priority above automation.

The share of segments under the forecast grows as events accumulate, and the mode switches without rewriting the send logic.

How we implement send-time selection: stages of work

The work goes from data to model and from model to your team, without a "implemented and left" scheme.

First, we understand what actually exists: which events come from the client, where they are lost, how unsubscribes and opens are recorded, how much history has been accumulated for each segment.

If there is little data or it has gaps, send-time selection will produce an unstable result — this is determined at the first stage, not after launch.

1. Data and current logic audit. We reconcile events in the storage with what actually goes to devices, check the completeness of history, duplicates, and delays. The output is a list of gaps and a decision on which ones we close with collection and which we work around.
2. Event flow scheme. We record which signal is born where, how it reaches the calculation loop, and with what delay the decision returns. The scheme is agreed before code — otherwise training is built on data that does not yet exist at send time.
3. Segment setup. We divide the audience by behavior and activity, not by rough cuts: a new user and a sleeping user have different open dynamics. For rare segments, we set rules so the decision is not built on a few observations.
4. Training and calibration. The model calculates the preferred send window for each recipient; we constrain it with contact frequency, quiet hours, and your rules.
5. Testing on part of the traffic. We enable selection on a share of the audience and keep the rest as a control group: we compare open rate, time to open, and unsubscribes. We expand only after a sustained advantage over a horizon of several weeks.
6. Handover and team training. We provide configurations, the scheme, the retraining policy, and the rollback procedure, and conduct a review with your engineers and marketing. After that, the system lives on your side — we remain on support.

What the client retains after implementation

Implementation does not end with launch to real users — the client receives a set of artifacts that allow the system to be operated, developed, and, if necessary, rolled back without us. We hand over each item to the project repository and review it with your team during handover.

• Event flow scheme. A diagram of the event path: from the user's action in the app to delivery and open, with points where time selection connects. It shows where events are lost and which service is responsible for what.
• Segmentation policies. Rules for dividing the audience by activity, time zone, open history, and visit frequency. They are stored in configuration, not in code — a segment changes without an app release.
• Frequency rules. Daily and weekly send limits per user, "quiet hours," priorities between campaign types. It separately describes what the system does when two campaigns conflict.
• Monitoring policy. Metrics and thresholds: delivered rate, opens, unsubscribes, complaints, send delay. It specifies who monitors, how often, and what to do when thresholds are exceeded.
• Documentation. A description of the time selection logic, input features, applicability boundaries, and known weaknesses — so that the work does not depend on one engineer.
• Rollback procedure. A step-by-step return to a fixed send schedule: toggle, reaction time, result check. Rollback does not require rebuilding the app.

These artifacts are the condition under which optimization can be changed and disabled on your own, without contacting us for every edit.

Case study: how the open rate grew without increasing campaign volume

An app with several hundred thousand active users sent pushes in fixed waves: marketing — in the morning by office time, service — immediately on event.

The base included people from different time zones, so some messages arrived at night or at hours when the person had not opened the app for weeks. The open rate held around 4–5%, while complaints about inappropriate messages grew faster than the audience.

We added a model that calculates a personal delivery window for each user: local time, login history, day of the week, reaction to past messages.

Sending goes through Braze, while the window calculation lives on our side — the schedule is rebuilt once a day, so delays of the external service do not affect it. Segments and the number of messages per user remained the same: only the send moment changed.

The growth cannot be attributed to seasonality: the control group on a fixed schedule showed the previous figures. The effect does not hold by itself — the window is recalculated, and unsuccessful scenarios are disabled.

If the model starts spreading messages to late hours, the limiter returns them to the daytime interval: the open rate declines slightly, but night deliveries do not appear.

What to do if campaigns are already running on a fixed schedule?

You can switch without stopping campaigns: adaptive send-time selection is an add-on to the current send logic, not a replacement.

While notifications go out on a fixed schedule, the new layer calculates in parallel which window each of them would have gone out in with adaptive selection. This shadow mode does not affect the recipient and does not require rewriting existing scenarios.

After a few weeks, history accumulates that is comparable with the current logic: the same segments, events, and notification types, only with an additional field — the recommended window and the feature by which it was selected.

We do not overwrite old delivery and open records but append them alongside, so reports, exports, and dashboards continue to be built without changes, and past periods remain comparable.

We switch to adaptive in stages: first 5–10% of the audience, prioritizing inactive segments and quiet hours, where the cost of error is minimal. If metrics decline, rollback is one toggle to the fixed schedule, and subscription state and accumulated history are not lost.

We keep the comparison on a control group that remains on the current schedule. We look at the open rate in the first hours after sending, unsubscribes, and delivered rate by segment, not the overall figure for the app.

If adaptive loses on a segment, we leave a fixed schedule for it: the model suggests a window, but frequency limits and quiet-hour rules remain decisive.

Questions engineers ask before connecting

Before connecting send optimization, the team asks five questions: whether there is enough data volume, how time zones are accounted for, what about night restrictions, who is responsible for model error, and how to separate the effect from seasonal growth in activity.

How are time zones accounted for?

The timestamp is stored in UTC, while the send window is calculated in the recipient's local time. Daylight saving time and user relocation are tracked by the last known region — otherwise part of the audience receives a notification at night.

What about night restrictions?

Quiet hours are set by campaign policy and take priority over the forecast. Even with a high predicted open probability, sending in a night window is blocked, and the notification is moved to the morning boundary.

Who is responsible for model error?

Each campaign runs with a control group and stop rules for frequency, unsubscribes, and open decline. A deviation from the forecast above the threshold stops the campaign automatically, and the order of checks is fixed by the Delivery Quality Control Policy.

How to separate the effect from activity seasonality?

The comparison is not with last week, but with a control group that sends on a fixed schedule. Seasonal spikes are fed into the model as a separate feature, so the increase in opens is not attributed to holidays.

Let's discuss the task and come back with an estimate and plan

To propose a send-time optimization scheme, it is enough for us to understand which events you already record: sends, opens, clicks and target actions, unsubscribes.

At the start, production access and code changes are not needed — an export by channels and an agreed list of scenarios that you are ready to hand over to the model's control are enough.

In return, we will come back with a plan: how features are collected, by what rule the audience is divided into groups, how the send moment is selected, and how to return everything to a fixed schedule if the result turns out to be worse.

• What we need from you: a list of scenarios and channels, an export of send and reaction history over a comparable period, frequency and "quiet hours" restrictions.
• What we will prepare in return: a feature scheme, draft audience grouping rules, and a control option — some segments remain on the previous schedule for comparison.
• Order of stages: data review, event collection setup, pilot on one scenario, expansion to the rest, and a policy for regular revision of rules.
• Timelines and reporting: we agree on checkpoints by stage; at each one, a report measuring opens, clicks, and unsubscribes relative to the control group.
• Rollback points: we define at which metric deviations the rule is disabled and campaigns return to the previous schedule.
• Who is involved: on your side — the campaign owner and the person who confirms scenarios; on ours — a data engineer and a mobile app developer.

Describe the task and the current send scheme — we will come back with an estimate, work plan, and order of stages.