— How we work

Reconcile repeated GA4 export events without inventing unique users

Reconcile repeated GA4 export events at a defined grain without timestamp-only deduplication or invented counts of unique qualified prospects.

4 min readUpdated 2026-11-05By AptixLabs studio
Raw export: Preserve source rows; Event grain: Parameters and identity; Reconciliation: Repeat versus delivery; Business measure: Attempts are not buyersAptixLabs · 2026-11-05

Explanatory diagram with synthetic or proposed states; not product UI. View full-size diagram

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.

Current primary documentation

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.

Illustrative event-row reconciliation
RowTimestampMeaning
attempt ASame sample timestampFailed attempt retained
attempt BSame sample timestampSuccessful retry retained
generate_lead BAfter persistence boundarySaved-enquiry signal
Repeated event ID, if supportedInspect delivery contextApply 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

B2B SaaS content attribution

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.

Need help with digital marketing for health & fitness brands?

Tell us about your product, existing stack and the problem you need to solve. We can discuss integration scope, implementation tradeoffs and a practical first milestone.

Start a conversation