Reconcile GA4 export rows at a defined event grain before deduplicating them. Equal timestamps do not establish duplicate delivery, and an exported event count does not by itself establish unique prospects or users.
Fix the period, table scope and event definition
Record property, stream, reporting timezone, date range and whether the query uses complete daily tables or another export form. Avoid counting overlapping daily and intraday data twice. Define the event you are comparing and the filters used in the interface. Google’s report-versus-BigQuery guidance describes legitimate differences in settings and available data; a mismatch does not automatically prove a broken tag. Preserve the query revision and observation time so a later export update can be distinguished from a change in the event contract.
Additional current primary reference
Inspect parameters without multiplying rows
GA4 export parameters are repeated records. When extracting one parameter, use an approach that preserves the intended event grain rather than blindly joining multiple repeated arrays and multiplying rows. Google’s basic-query examples demonstrate date filtering and parameter extraction patterns; adapt them to the actual schema and event version. Retain available event and batch metadata as diagnostic context. No one field should be declared a universal event identity without verifying its contract. A timestamp plus event name can still describe separate legitimate interactions delivered close together.
| Row | Timestamp | Meaning |
|---|---|---|
| attempt A | Same sample timestamp | Failed attempt retained |
| attempt B | Same sample timestamp | Successful retry retained |
| generate_lead B | After persistence boundary | Saved-enquiry signal |
| Repeated event ID, if supported | Inspect delivery context | Apply documented reversible policy |
Trace two fictional attempts and one outcome
A synthetic visitor submits a form, receives an error and retries successfully. Two attempt rows share a timestamp in the illustrative extract but have different attempt identifiers and outcomes. Keep both attempts. The successful persistence event is a separate semantic boundary; it should not be manufactured by collapsing visually similar rows. AptixLabs’ inspected contact source emits an attempt before persistence and generate_lead after a successful write. That source ordering explains intended meaning, not a guarantee that every analytics row arrives exactly once or represents a unique buyer.
-- Illustrative shape; substitute the authorized dataset and complete dates.
SELECT event_name, COUNT(*) AS rows
FROM `example_project.analytics_demo.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20261001' AND '20261007'
AND event_name IN ('contact_submit_attempt', 'generate_lead')
GROUP BY event_name;Separate duplicate delivery from repeat behavior
If the application has a documented immutable event identifier, inspect repeated deliveries of that identifier with their payload and transport evidence. Keep the raw export and a reversible reconciliation view rather than destructively deleting rows. Document cases the available fields cannot resolve. Retries can be legitimate diagnostic events, while repeated transmission of one completed event may need deduplication under a defined policy. Do not infer that two browser identifiers are the same person from timing or shared campaign context. Business account matching requires its own permitted evidence and review.
Compare like-for-like totals and report residuals
Match reporting identity, timezone, event filters and export scope before comparing counts. Review modeled or processed report behavior under Google’s current guidance instead of forcing the export to equal every interface total. Validate a small event sample, then aggregate. Keep attempts, saved enquiries and reviewed qualified accounts in separate measures. The sample and query here are illustrative; no GA4 property was queried. The output should explain which differences were resolved and which remain unassigned, without converting uncertain rows into invented unique users or sales outcomes.
GA4 leads versus form attempts
Bring the event contract and a synthetic row sample to separate repeated interactions from delivery uncertainty.
B2B SaaS development: scope and acceptance
Can I deduplicate GA4 rows by timestamp?
Timestamp equality alone is insufficient. Preserve legitimate repeats and use a documented event-identity contract when available.
Does generate_lead count unique qualified prospects?
Not by itself. Repeated activity, delivery limits and business qualification need separate reconciliation.
