The Duplicate Fire: Auditing Zendesk's Conversion Event Export

Marketing Academy · Field Work●Analytics & Attribution

MiniAudit· 25 minutes

Zendesk

Objective: Given a real 15-row conversion event export from Zendesk's GA4 property, decide which events deserve a 'key event' flag and which browser/server pairs are double-firing without a shared event_id.

You're the growth analyst at Zendesk auditing the measurement plan before Marketing turns on Smart Bidding for a trial-to-paid campaign. Sales is convinced signups have been undercounted for a month.

Sort the export into real conversions vs upstream signals, then find the purchase-style event that's firing twice.

Before you start

What you'll need

Free path (everything below is enough to finish)

Google Analytics 4

FreePull the raw event log and confirm the duplicate pattern in DebugView

Free, and it's the same property the export came from

Google Sheets

FreeSort and filter the 15-row key-event export

No account friction, works from a CSV export

The process

2 steps

Step 01 of 02

Marking only the real ones as key events

The lesson's playbook says to flag only bottom-of-funnel events as GA4 key events. Upstream signals stay as regular events so smart bidding doesn't optimize toward the cheapest, least valuable action.

The export shows 15 events flagged as key events, including newsletter_signup, pricing_page_view, trial_started, and demo_requested. Which of these should actually keep the key-event flag?

Google Sheets— Import ga4-events-export.csv, freeze the header row, filter the event_name and is_key_event columns.

Procedure

Import ga4-events-export.csv and freeze row 1
Filter to is_key_event = TRUE and read all 15 rows
Flag any event that is not a paid-plan action (page views, newsletter signups, content downloads) as a misclassification
Cross-check the remaining rows against Zendesk's actual revenue events: trial_started, plan_upgraded

Sample output

KEY EVENTS FLAGGED (15 total)
  newsletter_signup        412/day   NOT a conversion
  pricing_page_view        890/day   NOT a conversion
  demo_requested            34/day   borderline, unqualified leads mixed in
  trial_started             61/day   real conversion
  plan_upgraded             19/day   real conversion

Healthy

Only trial_started and plan_upgraded stay flagged as key events; demo_requested moves to a regular event until lead-qualification data is joined in.

Unhealthy

Smart Bidding optimizes toward newsletter_signup because it fires 412 times a day versus 19 for plan_upgraded, and spend drifts toward audiences that read blog posts, not audiences that pay.

What this means

A key event is a business decision about what counts as revenue-adjacent, not whichever event has the most rows.

So what do I do about it?

Symptom	Action	Effort
Cost-per-acquisition looks artificially cheap because it's averaged across 15 event types	Strip the key-event flag down to trial_started and plan_upgraded only, re-baseline CPA	30 min

YouYou can do this yourself, no engineering access required.

Step 02 of 02

Deduplicating browser and server events with a shared event_id

The lesson's Common Mistakes list warns that firing the same conversion from both the browser pixel and the server container without a shared event_id inflates the count, sometimes by up to 2x.

plan_upgraded shows 19 rows/day in the key-event report, but the export's raw event log shows 34 rows for the same day. What does the timestamp/event_id pattern tell you?

Google Analytics 4— GA4 DebugView and the raw Events report, filtered to plan_upgraded for a single day.

Procedure

Open the Events report, filter to plan_upgraded, and export the raw row-level log for one day
Sort by timestamp and look for pairs of rows within 2 seconds of each other with the same user_pseudo_id
Check whether each row's event_id field is populated, and whether paired rows share the same value
Count how many of the 34 raw rows are true duplicates versus real distinct upgrades

Sample output

plan_upgraded, raw log excerpt (2 rows, same upgrade)
  10:14:02   user_884   event_id: (empty)   source: browser tag
  10:14:03   user_884   event_id: (empty)   source: server container

34 raw rows -> 15 duplicate pairs -> 19 real upgrades

Healthy

Both the browser tag and server container send the same event_id for the same upgrade, GA4 collapses the pair into one, and the key-event count matches reality (19).

Unhealthy

Neither source sends an event_id, GA4 counts both, and every revenue report built on plan_upgraded is inflated by roughly 79% for that day alone.

What this means

A raw count nearly double the key-event count, with empty event_id fields on matching timestamps, is the signature of an undeduplicated double-fire, not real growth.

So what do I do about it?

Symptom	Action	Effort
Revenue reports and CPA calculations built on plan_upgraded run high every week	File a dev ticket to pass a shared event_id from both the browser tag and server container	dev ticket

EitherYou or a developer can handle this, depending on your access.

Final deliverable

A one-page conversion-event audit memo: which key-event flags to remove, and a dev ticket describing the event_id fix for the duplicate-firing event.

See a reference example

Sample output

Instacart, conversion event audit (excerpt)

KEY EVENTS TO KEEP
  order_placed        real conversion, no dedup issue found

KEY EVENTS TO DEMOTE
  app_opened          412/day, not a conversion, demote to regular event

DUPLICATE FOUND
  order_placed shows 1,140 raw rows vs 640 key-event rows for the same day, missing event_id on the server-side tag

Success criteria

You're done when you can:

Correctly separates real key events from upstream signals
Identifies plan_upgraded's raw-vs-key-event count gap as a deduplication failure, not real growth