GA4 BigQuery: Event Date vs. Event Timestamp

In GA4’s BigQuery export, event_date is a date formatted for the property’s reporting time zone, while event_timestamp records the event time in UTC as a timestamp value. Around midnight, the two fields can display different calendar dates without either being wrong.

What each field represents

event_date is commonly used for daily reporting because it follows the property time zone and is formatted as YYYYMMDD. event_timestamp is a UTC timestamp in microseconds. Convert it to a standard timestamp before using it in SQL; dividing or casting it without checking the unit can produce misleading dates.

The export also includes event and user context that can help interpret timing. Some collection and processing scenarios introduce differences between an event’s occurrence and its receipt, so inspect the relevant fields for the question you are answering.

• Use event_date for property-local daily reporting.
• Use event_timestamp for event ordering and precise time analysis.
• Keep the reporting time zone explicit in every downstream dashboard.

Why dates disagree near midnight

Imagine an event recorded shortly after midnight UTC while the property’s reporting time zone is several hours behind UTC. Its UTC timestamp can fall on one calendar day, while the property-local event_date remains on the previous day. A query that compares the UTC date directly with event_date can therefore shift activity between daily buckets.

This becomes more visible when combining GA4 with CRM systems, ad platforms, or warehouses that use different time zones. A date mismatch is not necessarily a tracking defect; first determine each system’s time basis and the event’s intended reporting date.

• Document the time zone used by each source.
• Avoid mixing local dates and UTC dates in one trend line.
• Use a consistent boundary for daily, weekly, and monthly comparisons.

Use the right field in analysis

For property-aligned daily totals, group by event_date. For path sequencing, sessionization, or latency analysis, use the timestamp and convert it deliberately to UTC or the chosen business time zone. Do not derive session dates from timestamps without checking how the session itself is defined.

When reconciling totals, compare a short interval with known events and inspect sample rows. A clear time-zone convention prevents false discrepancies, especially around daylight-saving changes and events close to midnight.