Times of Day

When your product gets used, in each device's own local time. Sessions or any custom event counted into a weekday by hour grid over whole months, with the peak slot, the busiest day, and the weekend share.

What the punch card shows

Times of Day answers "when" for one source at a time: sessions, or any custom event. Every occurrence in the period is placed into one of 168 cells, a weekday by an hour, and the grid shows where they pile up. The darker the cell, the more happened at that hour on that weekday, added up over every week in the period.

Four numbers summarize the grid: the total, the single strongest cell, the strongest weekday, and how much of the activity falls on the weekend. Two bar charts fold the grid one way each, by hour and by weekday, and a table gives every cell as a number.

Counts are occurrences. A profile that opens the app every morning contributes one session per morning, and a custom event fired ten times contributes ten. The page never counts profiles.

Whose clock the hours follow

The hour and the weekday of every occurrence are the device's own. The SDK sends the local hour and weekday with each request, and the server files the occurrence under them without converting. A session at 9 in the morning in Tokyo and one at 9 in the morning in Lisbon both land in the 9 o'clock column, even though they are eight hours apart in real time.

That is the point of the page. "When is the audience active" is a question about its day, not about the server's, and the grid answers it in the reader's terms: the 9 o'clock column is everyone's 9 o'clock. The cost is that the grid cannot be lined up with a clock on the wall; the Sessions section and Online Profiles do that, in the project's time zone.

Only the calendar month an occurrence belongs to follows the project's time zone, which matters for the period picker but not for the shape of the grid.

Use Cases

Find the daily rhythm

Know the shape of a normal day and a normal week.

1. Open Times of Day. Sessions is picked; leave it, since sessions are the broadest measure of being active.
2. Pick Last 3 months as the period. One month is enough for a product with steady traffic; three smooth out holidays and a slow week.
3. Read the Peak slot and the Most active day, then the grid. A working-hours product shows a block from 9 to 6 on weekdays and little else; a consumer app shows an evening band that carries into the weekend.
4. Read By hour of day for the daily curve on its own, and By day of week for the weekly one. A weekend share above a third usually means a leisure product.
5. Come back after a change. The rhythm rarely moves on its own; when it does, something changed in who the audience is.

Time a message or a release

Choose the hour at which a push message, an in-app message, or a release reaches the most profiles while they are active.

1. Pick the event you want in progress when the message lands: Sessions for "the app is open", or a specific event for a moment inside it.
2. Read the strongest cells in the grid for the weekday you plan on. The darkest hour of that row is the best hour; the cells just before it are where a message gets seen as the audience arrives.
3. Read By hour of day for the hours to avoid: the small hours are where a message wakes its audience.
4. Remember whose clock this is. The grid is in each device's local time, so "9 in the morning" is 9 in the morning everywhere. A message scheduled in local time follows the grid; one scheduled at a single server time does not, and for a global audience it hits some regions at their quiet hours.
5. Check the source again after the message went out. A new band at the sending hour on the event's grid is the message working.

Check whether a behavior has its own hours

See whether one behavior happens at different hours than general use does.

1. Read the grid for Sessions first and note the peak slot.
2. Switch the source to the event you are interested in: purchases, a support request, a feature.
3. Compare the two grids. A behavior that follows the session grid happens whenever the audience is around; one with its own band happens at a moment of its own, a lunch-break purchase, an evening ritual, a Monday-morning report.
4. Compare the weekend shares. A behavior with a much lower weekend share than sessions is a work behavior.
5. Use the finding where hours matter: when to staff support, when a promotion is seen, when a scheduled job should not compete with live traffic.

FAQs

Why is there a peak at 3 in the morning?

Because it is 3 in the morning on the device. A real audience in another time zone looks the same as bots, scheduled jobs, or devices with a wrong clock; the Activity Map, which places profiles by country, tells which it is.

Can I pick a date range?

No. The record is kept per calendar month, so the choice is this month, the previous month, the last three, or all time.

Is "This month" the calendar month or the last 30 days?

The calendar month, from its first day to today. The page takes the month from your computer's date, while occurrences are filed by the project's time zone, so the two can differ for a few hours at the turn of a month.

Why is the grid empty for an event I know is sent?

The aggregator counts events as they arrive; an event that started being sent recently has a short history, and one sent before the aggregator ran has none. Check the period as well: a new event has nothing in the previous month.

Why does the total differ from the Custom Events section?

The Custom Events section follows the header's date range in the project's time zone; this page adds up whole months. Over the same calendar month the two agree.

Does the grid count profiles or occurrences?

Occurrences. A profile with three sessions on Monday morning adds three to that cell.