Hour of day dimension: intraday timing patterns
Hour of day is the dimension that buckets events into one of 24 hours (00-23) so you can read intraday rhythms — when traffic peaks, when conversions happen. Like day of week, it is computed from the event timestamp in the property's reporting time zone. Daylight-saving transitions and a globally distributed audience both complicate it: the hour is your clock's hour, not the visitor's.
What this means
The hour of day dimension converts each event's timestamp into a 0-23 hour. Grouping by it shows the shape of a day: morning ramps, lunchtime dips, evening peaks. It is commonly paired with day of week to build an hour-by-weekday heatmap of when an audience is active.
GA4 exposes this as a numeric hour derived from the same timestamp that feeds the date and weekday dimensions.
Daylight saving and time zone
Because the hour is assigned in the property's reporting time zone, daylight-saving transitions create artifacts: a 'spring forward' day has a missing hour and a 'fall back' day has a doubled hour, which can dent or spike a single bucket. Changing the reporting time zone shifts every event's hour and is not retroactive in GA4.
For a worldwide audience, the hour reflects your clock, so a global 'peak hour' blends many local times. Read it as an operational signal in your zone, not as each visitor's local hour.
- Buckets events into 24 hours (00-23) from the timestamp
- Assigned in the property's reporting time zone
- Daylight-saving transitions distort single-hour buckets
How it appears in analytics and logs
An hour-of-day value places an event in a 24-hour bucket in the property time zone. Apparent shifts in peak hours can be daylight-saving artifacts or audience time-zone spread rather than real behaviour change.
Diagnostic use case
Use hour of day to spot peak windows for publishing, support, or sends, while accounting for daylight saving and the fact that the hour is in your reporting time zone.
What WebmasterID can help detect
WebmasterID derives the hour from first-party event timestamps, so intraday patterns are available without visitor profiling or third-party data.
Common mistakes
- Ignoring daylight-saving artifacts in single-hour buckets.
- Treating the reporting-zone hour as each visitor's local hour.
- Assuming a time-zone change re-buckets historical hours.
Privacy and accuracy notes
Hour of day is derived from a timestamp, not from identity. WebmasterID computes it first-party with no personal data involved.
Related pages
- Day of week dimension
Day of week is the dimension that groups events by weekday (Sunday through Saturday, or a 0-6 index) so you can see weekly patterns. It is derived from each event's timestamp interpreted in the property's reporting time zone. The big caveat: weekday boundaries depend on that time zone, so a global audience spanning many zones will have its 'days' defined by your reporting clock, not theirs.
- Country dimension (coarse, edge-derived)
The country dimension assigns each visit a country, derived by looking up the visitor's IP address in a geolocation database — often at the CDN edge. It is intentionally coarse: country-level, not address-level. VPNs, proxies, mobile carrier routing, and corporate egress can all place a visit in the wrong country, so it is a strong aggregate signal and a weak per-visit one.
- Region and city dimension
The region and city dimensions place a visit below country level — a state/region and a city — derived from IP geolocation. They look precise but are the least reliable geo tier: IP-to-city mapping is approximate, mobile and carrier routing can place a visit hundreds of kilometres off, and many visits resolve only to country, showing '(not set)' for city. Use them for rough regional skew, never as a real location.
- Web analytics
Read intraday patterns from first-party timestamps.
Sources and verification notes
- Google Analytics Help — [GA4] Dimensions and metrics (hour)Defines the hour dimension and its time-zone-based derivation.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.