Setting up events and conversions in GA4 seems simple, but duplications, inconsistent names and events firing more than once are frequent errors, and they distort reading. A clean configuration, with a few well-defined, tested and documented events, is the basis of any reliable analysis.
The essentials in a definition
Setting up events and conversions in GA4 without duplication requires a plan: define which actions matter, use consistent names, mark them as key events and decide where each event originates (on the site, in Google Tag Manager or on the platform). Documentation on events and key events guides names and parameters. Duplication arises when the same event is created in several places.
Events, parameters and conversions
An event is a recorded interaction (page view, click, form submission, purchase). Parameters give context (value, currency, product). A conversion is an event marked as important to the business. Choose few conversions that reflect real objectives, instead of marking everything.
Fewer conversions, more meaning.
Define and name
Create a measurement plan: which actions matter, what name and parameters each event carries, where it fires. Use consistent naming conventions. Distinguish main events (purchase, qualified lead) from intermediate ones (checkout start, contact click). Document everything.
The plan precedes implementation.
Events and conversions in GA4 without duplication
- Create a measurement plan
- Name with consistent conventions
- Deduplicate with IDs
- Test and compare with the CRM
Avoid duplications
Check whether the same event fires through two routes (for example, tag and commerce platform), or on each load of the confirmation page. Use transaction IDs to deduplicate purchases. Test in preview and real time. Validate values and currencies.
A duplicated event distorts all of the return.
A duplicated event distorts everything that comes after.
Maintain and verify
Test after each change to the site or tag manager. Compare GA4 conversions with the sales system or CRM. Investigate large differences. Keep a change log. Periodically review whether events still reflect the business.
Measurement is continuous maintenance.
Decision table
| Source of duplication | How to avoid it | Check |
|---|---|---|
| Event in code and in the tag manager | Define a single origin | Inspect events sent |
| Equal recommended and custom events | Use the recommended name | Review the event list |
| Thank-you page reload | Unique transaction identifier | Test refreshing the page |
| Events created and imported | One primary conversion per action | Compare with the database |
Common mistakes to avoid
- Marking everything as a key event. It dilutes what matters.
- Inconsistent names. It hampers reporting.
- Not testing. Errors reach reports.
How to measure the result
Compare purchase events with orders and check for duplications in debug reports.
Limits and exceptions
Naming recommendations and event limits change; confirm the documentation. Events depend on consent. Always test after site changes.
Illustrative example
Illustrative example: a store finds purchase is recorded twice: in code and in the tag manager. It keeps only one origin, uses the transaction identifier to avoid repetition on reload and validates against orders. Conversions come to match reality.
In practice: checkpoints
Write a one-page measurement plan, with the events, parameters, where they originate and the owner. Test each event in debug mode before marking it as a key event, and repeat tests after site changes. Check duplication when reloading the thank-you page and when using the back button. Compare counts with the database weekly and record differences and causes. Name events in a consistent pattern, avoid personal data in parameters and archive events you no longer use. Make sure that conversions imported into ad platforms match the definitions you use in reports, and review the list of key events every quarter to keep only those that guide real decisions.
Frequently asked questions
How many conversions should I mark?
Few, those reflecting business objectives.
How do I avoid duplicate purchases?
With a transaction ID and testing.
How do I verify?
In real time and by comparing with the sales system.
How many key events should I have?
Few, matching the most important business actions.
How do I test?
With debug mode and the tag manager preview.
Define an event plan, a single origin per event, consistent names, unique transaction identifiers and validation against the database.
Sources and recommended reading
Last editorial review: October 2026. Informational content; always confirm current conditions in the official sources before deciding.