Order GA4 Events by event_timestamp, Not event_date

In the GA4 BigQuery export, event_timestamp is often underused or misapplied. A common error is to order events by event_date or by the _TABLE_SUFFIX of the daily events_ tables. event_timestamp is not a date: it is an INT64 count of microseconds since the Unix epoch, in UTC, recording the moment the event was logged on the client. That precision is what gives the data a trustworthy timeline.

The distinction from event_date matters. event_date is a YYYYMMDD string in the property's reporting time zone, and it determines which daily table an event lands in. For any property not set to UTC, an event close to midnight carries an event_date that differs from the UTC date of its event_timestamp. Ordering by date also discards the sequence within a day. Without event_timestamp, user journeys cannot be sequenced accurately, sessions that cross midnight cannot be stitched, and attribution windows become imprecise.

Conversion needs the same care. TIMESTAMP_MICROS(event_timestamp) preserves full precision. Dividing down to seconds, or casting to a coarser type before ordering, makes events that occurred milliseconds apart tie or appear out of order, which destabilises LAG()-based sessionisation and can merge or split sessions incorrectly.

A dbt pipeline can enforce these expectations. Standard tests such as not_null and dbt_expectations.expect_column_values_to_be_of_type('int64') provide a baseline. Custom tests can check that each event_timestamp falls within a plausible window of its event_date, allowing for the property's time zone. This catches device clock problems and pipeline anomalies before they reach downstream models.

Ignoring the true nature of event_timestamp causes a cascade of problems: unstable sessionisation, attribution models that miscredit conversions, and compromised causal analysis of in-session events. Collection tools designed for precise timestamps, such as Robin Signals, help at the source, but the analyst still has to validate and interpret the values correctly in BigQuery.

Handling event_timestamp properly is a mark of analytical maturity. It is the difference between describing what happened and being able to explain why.