Duplicate GA4 Events After a Redesign: How Do You Check Triggers in Website Code, GTM and Plugins?
If one action produces multiple identical GA4 events after a redesign, first map the test action to its sending sources before deciding which configuration to disable. Original website code, Google Tag Manager (GTM) and plugins may all send events. Removing one directly could turn duplication into missing events.
Investigation requires people who can inspect the relevant settings, use preview and debugging tools, and check business records. Report totals alone can reveal unusual trends but cannot establish which code produces duplicates. Selecting one specific form and one controlled submission usually makes evidence easier to find than checking every event across the website at once.
Break one interaction into observable actions
A button click, a browser form submission, successful server-side saving and the appearance of a success page are different actions. For each event to be checked, specify its name, trigger condition, target data stream and expected count. For example, if a custom event means “this request has been saved,” it should not be sent once on the button click and again in the success callback.
Confirm the name and condition against the actual implementation. Do not assume that any event name inherently represents completion. GA4’s enhanced measurement guidance includes form_start and form_submit. An automatically collected form submission event still requires a separate check that the corresponding record was saved in the business system.
Submit one request clearly marked as a test, retaining a local verification identifier and submission time. Record the number of business records and the number of specified events separately. Two identical events for one record suggest an analytics sending issue. Two business records also require checking form retries or duplicate writes; removing an analytics tag cannot solve that problem.
Record website code, GTM and plugin sources separately
Ask developers to check direct event-sending code in page templates and success callbacks. Ask the analytics configurator to check deployed GTM containers, event tags and triggers. Then check analytics switches in CMS plugins, form components or themes. For each source, record its destination, event name and trigger condition.
Also confirm which version the live page uses. A GTM draft visible in the admin interface may not have been published, and changing a template does not prove that old plugin settings have been removed. Before-and-after configuration screenshots, container versions and plugin inventories can help identify new and inherited sources.
For example, suppose the old code sends an event after successful submission while a new GTM tag listens for the same success action. Both may execute correctly yet count the same action twice. This is a hypothesis to test, not a cause established merely by finding GTM installed on the page.
Compare trigger order and received events in one controlled test
Before testing, fix the page, language, browser, consent state and configuration version. Avoid changing rules while submitting tests. Define expectations for success and failure, then observe in this order:
- Enter preview mode from the relevant GTM workspace and connect the page being checked.
- Complete the specified action only once. In Tag Assistant, inspect which event fired which tags and which tags did not fire.
- Keep the Tag Assistant preview connected and confirm that debug mode is enabled on your device. Then select the corresponding device in GA4 DebugView and check event names, times and parameters.
- Compare business records in the admin system, and mark duplicate or missing events beside their specific actions and sources.
Google’s GTM preview documentation explains tag firing, order and data inspection, while its DebugView documentation covers debug events received by Analytics. The tools show different things and should be checked together. Browser network request counts are not directly equivalent to event counts either; inspect the actual payloads.
If a GTM tag does not fire, first check the action and trigger conditions. If it fires but does not appear in DebugView, check the destination, debug state and receiving conditions. Privacy controls or Analytics cookie consent that has not yet been granted may affect debug visibility. Do not immediately reinterpret “not visible” as “no business submission.”
Correct trigger sources without hiding different problems behind one switch
Once two sources are confirmed to send the same action, agree which one to retain and who maintains it. Preserve the original configuration and version record when disabling a duplicate source, verify the change in a test environment or authorized scope, then publish it to production.
GTM offers tag firing options such as once per event and once per page load. Limiting one tag to once per event does not disable original website code or another plugin; two independent sources still need separate handling. Switching to once per page could also miss a second genuine completion on the same page.
If failed attempts are being counted, change the completion condition rather than simply reducing the count. GTM’s form trigger guidance explains differences between validation options, but cannot replace checking actual business records, especially for custom components’ sending behavior. For the definitions of broader business metrics, see the website redesign measurement plan.
After fixing the issue, test failures, retries and a second action for omissions
Retest at least normal completion, validation failure, submission after a failure, a second completion on the same page, and another language or mobile entry involved in the redesign. For each case, state which analytics events may appear, which event should be sent only when the business condition is met, and what records the business system should retain.
The local test identifier is for team comparison; there is no need to put the entire inquiry into an analytics event. Google’s PII requirements prohibit sending personally identifiable information such as email addresses and personal mobile numbers to Analytics. Check event parameters and page URLs for that information as well.
Completion means each event has one explainable maintenance source or clearly divided responsibilities, counts for the selected actions match the agreement, failures and retries are not mixed together, and retesting the live version produces consistent results. Add the results to the website launch verification checklist, recording the change time and scope. Whether inquiry quality improves requires a separate business assessment.
Frequently asked questions
When duplicate events appear, can we first disable the entire plugin or GTM?
First confirm the duplicate source and what other tasks that configuration performs. Disabling the whole setup may also stop valid events. Make changes within the confirmed scope and retest.
If the business system receives one request but GA4 receives two events, did the customer submit twice?
That cannot be concluded directly. Compare the business record with the actions and sources of both sends to distinguish duplicate analytics events from duplicate business data writes.
Link copied
