GA4 Duplicate Events: Find the Extra Event Without Losing Real Activity

When one action appears twice in GA4, trace that action before disabling tags. The extra record might come from a plugin and Google Tag Manager both sending the same event, a success callback running twice, a replayed order confirmation, or a reporting rule that combines different measures. The right repair removes the extra record while preserving the next legitimate action.

This guide covers finding and removing duplicate GA4 events. To set up form tracking from the start, see how to set up and test GA4 lead form tracking, and for a wider review of tags and triggers, see how to audit and clean up a Google Tag Manager container.

Start with one event and one reproducible journey. You do not need to audit the entire property to investigate a doubled enquiry form. You do need to know what should count once, where the second record first appears, and how you will prove that the correction still records a genuine second enquiry.

A doubled form event, followed all the way through

Consider a hypothetical maintenance company. Its enquiry form should send one generate_lead event after the application accepts a new request. The application accepts the first test enquiry once. A website plugin sends generate_lead, and a GTM tag sends another generate_lead to the same intended stream.

Here is the small trace from the guide’s fictional teaching files. The references identify invented test records; they are worksheet fields, not instructions to send enquiry identifiers to GA4.

The correction has a specific reason: two independent senders represented the same acceptance. In this example the plugin remains responsible, and the overlapping GTM event is removed. Another site might sensibly retain GTM instead. Choose the maintained, correctly tested implementation rather than assuming one installation method is always better.

The last row matters as much as the first. A “send only once per session” rule could make the original symptom disappear while also losing SYN-L102. The correct result for the two accepted enquiries is two events, one for each enquiry. A total of two would still be wrong if both records described SYN-L101 and the second enquiry was missing.

The supplied offline checker was rerun against these teaching files: the corrected one-enquiry and two-enquiry cases passed, and their deliberately doubled baselines were rejected. This verifies the example’s logic and record relationships. It does not establish that a particular plugin, website or Google account was tested.

For your implementation, the same investigation continues beyond the worksheet. Confirm one receiving record, identify each sender in the browser or server trace, then check the intended event in GA4 DebugView and the processed report. The sections below show what to inspect at each branch and what result would support a correction.

Choose the right branch before changing anything

Use this compact sequence when the symptom first appears:

1. Are the reports counting the same thing? Align the event, metric, property, stream, dates and filters. If the measures differ, resolve the comparison first.
2. Did two real actions happen? Two deliberate clicks or two accepted enquiries may both belong in the count. Keep them if the measurement is per action.
3. Did one action create two business records? Investigate the application or form handling. Analytics may be reflecting a real duplicate in intake.
4. Did one business occurrence create two events? Identify overlapping tags, repeated listeners, automatic/manual overlap or repeated callbacks.
5. Was one event delivered through more than one route or attempt? Inspect browser, server and queue evidence together.
6. Does the duplication appear only in reporting? Check generated-event rules, filters, joins and aggregation before editing website code.

If the evidence stops halfway through, keep the finding unresolved. Two close timestamps suggest a place to investigate, but cannot establish the cause on their own. A narrow unanswered question is more useful than a broad rule that drops everything resembling a repeat.

Some incidents have two faults. A double click might create two intake records, and two tags might send each record twice. Removing one tag would leave the duplicate intake records. Repairing the form alone would leave every genuine enquiry doubled in Analytics. Follow each path far enough to understand what remains.

First, write down the number that looks wrong

“Conversions are doubled” is a useful alert, but an incomplete diagnosis. Open the report and record its actual metric label. Is it Event count, Key events, New leads, users, sessions or rows in an exported spreadsheet? Note the selected event and reporting period.

For a lead-form incident, a practical statement is: “One newly accepted request produces two generate_lead occurrences in the same destination during a controlled test.” That gives the investigation a clear target. “The dashboard is twice the CRM” leaves several different explanations open.

GA4’s New leads metric in the Lead acquisition report counts unique users with generate_lead. Event count counts occurrences. One recognized user can send two genuine enquiries. A CRM can merge them into one opportunity. These differences do not establish duplicated collection.

Key-event counting creates another distinction. A key event can count once per event or once per session. Five occurrences in one session can therefore contribute differently to key-event totals. Google’s counting-method guidance explains the choices. Switching methods can change a displayed total while leaving a duplicated source event untouched.

Match the date range and timezone, particularly around midnight. Check whether one report includes several streams, whether a comparison is active, and whether a dashboard has its own filters. When a colleague sends a screenshot, ask for the underlying report settings instead of comparing the large number in isolation.

Finally, check processing time. Google’s data-freshness documentation explains that processing can take 24 to 48 hours and results can change. Use DebugView to inspect a controlled event sequence and a later report to inspect processed totals. Repeatedly refreshing an incomplete report will not tell you which sender produced an extra event.

Reproduce the smallest possible case

Choose a safe test that creates one unambiguous occurrence. For a form, submit one synthetic enquiry and have someone verify its receiving record. For a page view, start with a fresh load. For a purchase, use an approved test checkout that cannot charge a real customer or trigger fulfilment.

Keep the test conditions stable. Record the browser, device, consent state, environment and relevant release version. If the baseline has analytics permission and the second run denies it, a lower count cannot be attributed solely to the proposed tag change.

Open the diagnostic tools before taking the action. In GTM, Preview connects the site to Tag Assistant and lets you inspect the workspace configuration before publication. Select the specific timeline event and examine fired tags, trigger conditions and resolved values. Google’s Preview instructions describe the connection process.

Remember that Preview is capable of sending real requests. It is not automatically an offline sandbox. Use a designated test property or the approved live-test arrangement, and keep operational notifications under control. Do not create dozens of test enquiries while the sales team assumes they are customers.

Your first trace needs only four things:

• The deliberate action
• The receiving application’s outcome
• The code or tag that sent each measurement
• The intended destination

Give each separate action a simple test label in your notes. Record application references only where permitted and keep them out of public screenshots. The label helps distinguish “the same action sent twice” from “two actions sent once each.”

Look for the earliest point where the second record appears. If the application produces two accepted records, begin there. If it produces one acceptance but the data layer receives the success message twice, investigate that integration. If the data layer has one message and two tags fire, the likely repair is in the sending configuration.

When a plugin and GTM both send the event

Many sites accumulate analytics integrations over time. A plugin was installed during the original build, a marketer later added GTM, and custom code arrived with a new form. The existence of those components is ordinary. The problem begins when more than one sends the same event for the same outcome to the same destination.

Limit your inventory to the affected event. Identify the plugin setting, GTM tag, theme setting or application handler that can send it. For each one, note the trigger and destination. Do not uninstall the first analytics-related plugin you find: it may manage consent, the Google tag or events unrelated to the incident.

Return to the hypothetical form. The trace should establish one success acknowledgement and two generate_lead senders. Inspect the GTM tag’s Measurement ID and the plugin’s configured destination. If they intentionally send to different properties, that is a different arrangement from two events entering one stream.

To test the overlap, change one identified sender in an isolated or otherwise approved configuration. Pause the overlapping event tag rather than deleting the whole container. Repeat the same accepted enquiry. The expected result is one remaining sender, the same accepted business outcome and the same permitted parameter values.

Then test a failed form and a new second enquiry. If the plugin sends on click while GTM waits for acceptance, retaining the plugin solely because it was installed first would preserve the wrong meaning. Choose the source that meets the business definition and survives the negative cases.

Once the retained path is decided, check what else depended on the removed path. A tag may provide a shared setting or trigger another tag through sequencing. A plugin may also handle ecommerce events. The repair should be narrow enough that a doubled lead event does not become missing purchases, missing page views or changed privacy behaviour elsewhere.

If both implementations are difficult to understand, the next useful step is a focused ownership review. The broader Google Tag Manager audit guide covers container structure and release management. The immediate incident still needs its one-event before-and-after trace.

When one GTM tag fires more than once

A single named tag can be invoked by different events. A form tag might fire on the Submit click, a form-submit signal and a custom acceptance signal. Each trigger can describe a separate moment in one customer journey, even if the marketer intended all three as alternative ways to detect success.

Select each relevant event in Tag Assistant rather than reading only the summary. Ask which event caused the tag to fire and what the application had established at that moment. If it fired before the form returned its success response, that instance cannot reliably mean an accepted enquiry.

Google’s 8 October 2026 GTM release note adds a timely check: configuration commands now appear as gtag.config events, which can match broad wildcard Custom Event triggers. If your event began firing on unrelated configuration activity, inspect that matching rule. The release note identifies a possible mechanism; your own trace must establish whether it explains this incident.

Inspect the trigger configuration. Multiple firing triggers operate as alternatives: satisfying one can fire the tag. Google explains this in firing triggers and exceptions. Adding an acceptance trigger beside an old click trigger does not make the tag require both.

Check advanced sequencing as well. A setup or cleanup sequence may invoke a tag through a path that is less obvious from its ordinary trigger list. Review the actual firing explanation before deciding a trigger is unused.

The usual repair for the form example is one authoritative acceptance trigger. If attempt tracking is useful, give it a separate diagnostic event name and keep it outside the lead total. The lead-form setup guide follows that application-to-GA4 route in detail.

Why “Once per event” may not solve it

GTM’s tag firing options control firing within their defined scope. Once per event does not mean once per accepted enquiry across every message your application emits. If the same acceptance is pushed into the data layer twice as two events, the tag can still be eligible on each.

Once per page can conceal a repeat on that page while dropping another genuine submission before a reload. A timer-based exclusion can suppress two fast legitimate actions and still allow a delayed duplicate. These controls need a reason tied to the intended measurement, rather than being used as a generic way to make a chart smaller.

When the success callback runs twice

Sometimes the container is doing exactly what it was told. It receives enquiry_accepted twice, and the correct tag responds twice. Changing the tag can hide the symptom while leaving the application integration faulty.

A developer should inspect where the success listener is registered and removed. A component that mounts repeatedly can add another listener each time. A form integration can also call the same measurement function from both the network-response handler and the UI confirmation handler.

Reproduce the first submission after a fresh page load, then repeat the navigation that precedes the fault. Does opening and closing a modal twice change the number of messages? Does returning to the form through client-side navigation create an extra listener? These controlled differences can locate the cause without guessing from a minified script name.

The correction should make the application’s success announcement correspond to the accepted occurrence. Removing a duplicate listener or centralizing the success handler may be enough. Where a provider legitimately repeats acknowledgements, the integration needs a repeat guard tied to the original accepted request.

Avoid creating a new request identifier every time the callback runs. That makes a repeated acknowledgement look like a new occurrence. Conversely, a single permanent flag such as “lead already sent” can lose all later enquiries from the same page or browser. The application must distinguish a replay from a new accepted request.

After the repair, deliberately exercise the lifecycle that caused the problem: reopen the modal, navigate away and back, or let the provider repeat its acknowledgement. Then submit a genuinely new enquiry. A test that only reloads the page before every submission can miss the exact condition that created the duplicate.

When page_view doubles on a load or route change

Page views have two common investigation points: the initial document load and a later navigation inside a single-page application. Test them separately. A fix for one does not prove the other is correct.

Google describes automatic page-view collection and manual page views in Measure pageviews. A manual page_view can overlap the default event produced by the Google tag. Setting send_page_view to false controls the default configuration page view where applied; history-based enhanced measurement has its own control.

For the initial-load test, open one page and identify every source of page_view for that load. Look for a Google tag added by a plugin as well as GTM, a manual page-view tag, or repeated configuration code. Match the destination and inspect the page location before deciding two visible requests describe the same view.

For the route test, move from one virtual page to another without reloading the document. If both history-based measurement and a custom route tag send page_view, one transition may be counted twice. Google’s single-page application guidance discusses choosing a suitable method and checking the changing page information in DebugView.

Retain one deliberate implementation for the qualifying route transition. Then test the journey from the initial page through two routes and back again. Count views and inspect their page_location, page_title and referrer information. One event carrying the previous screen’s details is still wrong even when the total looks correct.

Define what qualifies as a page transition for your application. Opening an accordion or changing a sort order may alter the interface without representing a new page. Avoid treating every state update as a view unless that is the intentional measurement definition.

A per-session suppression is especially damaging here. People can view several pages, revisit an earlier page and complete more than one navigation in a session. Preserve that activity while removing the overlapping source.

When a form or confirmation page repeats

Separate three questions: did the visitor try again, did the application accept another request, and did Analytics record another lead? Those answers can differ.

Suppose someone double-clicks Submit. The application might recognize one operation and return the same accepted result twice. It might accidentally create two intake records. Or the person might later submit a genuinely separate request. The browser’s click count alone cannot determine which happened.

For a completed-enquiry definition, use the receiving application’s outcome. Google’s enhanced measurement form events provide interaction signals, but the application’s acceptance state still needs testing. A required-field rejection should not become a confirmed lead.

If the application creates two unwanted records, investigate its duplicate-submission handling. An idempotency mechanism can let retries of one operation return the original result rather than create another record. Its scope and lifetime belong to the application’s design. Analytics suppression should not be used to conceal duplicate sales tasks in the CRM.

A confirmation-page rule introduces another failure path. The visitor can reload, bookmark or revisit the page. An event based only on that page view may fire again even though no new enquiry or order exists. Test the direct URL, reload and browser navigation explicitly.

The preferable repair depends on the provider. A documented acceptance callback may be available. A guarded confirmation state may support a reliable one-time signal. If neither exists, describe the measurement as confirmation-page visits and explain its limitation instead of claiming verified enquiries.

Be careful with failure followed by success. A broad “already attempted” flag can consume the only permitted event on a rejected form, then suppress the valid correction. Your regression should include a missing required field, its correction and one accepted submission. The expected lead increase is one.

Also test keyboard submission. A repair attached only to a button’s mouse-click handler can behave differently when a visitor presses Enter. The success signal should follow the application’s accepted outcome regardless of how the visitor initiated the form.

When purchase events repeat

Purchases have a documented protection that should not be generalized to every event. Google Analytics can deduplicate purchase events using the same transaction_id in web streams. Google’s transaction-ID guidance says this does not apply to app streams and warns against using one transaction ID for different users or orders.

Inspect the actual transaction value sent for one order. It should be a non-personal identifier for that order and remain stable when the same order is represented again. An empty string or a fixed placeholder can cause undercounting. A freshly generated ID on every confirmation-page visit defeats recognition of the same order.

Use two separate test questions. First, does revisiting the same completed order create another source purchase event? Second, does a genuinely new order get its own distinct transaction reference and retained purchase event? A correct same-order replay result cannot prove that new orders survive.

The teaching files include a case with the right number of purchase events but reused transaction references. It fails because the records no longer correctly represent the separate orders. This is why a total-only check is weak evidence for an ecommerce repair.

Still investigate overlapping purchase senders. A downstream deduplication safeguard can mask an unnecessary duplicate without clarifying which implementation is responsible. Different payloads, identities or destinations may make that ambiguity important later.

Do not send personal information in transaction IDs. Keep names, emails and phone numbers out of order references sent to Analytics. The business can retain its permitted internal mapping without exposing customer details in the measurement identifier.

When browser and server paths overlap

A server-side setup adds another place where an event can be created or forwarded. It also makes browser-only evidence incomplete. One browser request does not prove that an independent backend did not send a second event for the same accepted outcome.

Draw the actual path in a few words: browser to server container to Analytics, or browser directly to Analytics plus backend to Analytics. The first may be one routed event. The second may be two independent representations of the same occurrence. Trace the forwarding and final destination before counting the visible hops as duplicates.

Google’s server-side testing guide explains inspecting incoming requests, event data and outgoing tag activity in server-container Preview. Match those observations to the browser test. Keep event objects distinct from network requests: one request can contain more than one event, and one event can pass through several processing stages.

If a queue retries an event, record the original occurrence and each delivery attempt separately in operational evidence. A later attempt timestamp does not necessarily mean a new business outcome. Ask where the retry policy is implemented and what response or uncertainty causes another attempt.

For Measurement Protocol, a 2xx response establishes HTTP receipt, not that correct data was processed into reports. Google’s reference also advises correcting request errors rather than blindly retrying the same unsuccessful request. A success-looking response should not be treated as a complete acceptance test.

Choose a clear owner for the final event sent to each destination. If browser and backend collection intentionally coexist, obtain the integration’s documented handling for duplicate representations and test that specific behaviour. Do not assume that an event_id parameter creates a universal GA4 deduplication rule for leads, clicks and page views. The purchase transaction rule has a documented scope; an arbitrary identifier has no equivalent guarantee established by the sources used here.

Exactly-once reporting is a stronger claim than most browser-and-network tests can support. A sender may be uncertain whether a request was received before a connection failed. Document the application’s chosen handling and the remaining uncertainty while ensuring the underlying enquiry or order survives independently of Analytics.

When collection looks right but the report doubles

If the controlled collection trace has one expected event, inspect how it becomes the reported number. Start inside GA4 with event-creation and modification rules, then move to the dashboard or export.

Google’s event-generation guidance distinguishes creating an event from an existing event and modifying an event. A source event and a derived event can both exist. If a dashboard adds them together under a generic “leads” label, one journey can contribute twice even though each individual rule is behaving as configured.

For example, a form success produces generate_lead, while a confirmation-page rule produces enquiry_complete. A dashboard totals both names. The first question is which one reliably represents acceptance. Removing an unrelated page-view tag would not solve the dashboard’s mixed definition.

Next inspect joins. A spreadsheet or reporting tool can join one event row to two matching campaign-reference rows. The final table contains two rows without any second event being sent. Check whether the join key is unique on the lookup side, whether a one-to-many relationship is intended and whether aggregation occurs before or after the join.

Be equally careful with totals assembled across dimensions or periods. A person can appear in several groups, and a unique-user count is not generally additive across those groups. If a dashboard’s “total” is the sum of overlapping populations, a website tag change addresses the wrong problem.

Compare the smallest exported sample you can safely inspect with the corresponding source report. Keep the event name, metric definition, date range and filters aligned. If only one dashboard differs, that narrows the investigation substantially. If several independent surfaces show the same event duplication, return to the collection and transformation path.

Do not erase source events merely because a downstream report is confusing. Preserve the valid measurement and fix the calculation or label that misrepresents it.

Read DebugView without overclaiming what it proves

In GA4, open Admin, Data display, DebugView with debug mode enabled for the test device. Select the relevant device, perform the controlled action and inspect the event sequence and parameters. Google’s DebugView instructions explain using Tag Assistant or Preview for device debugging.

A pair of matching events is a useful symptom. To name the cause, connect them to the application and sender evidence. DebugView alone may not tell you which WordPress plugin, callback or independent server process produced each one.

An empty DebugView is also ambiguous. Check the property, device, destination, debug configuration and collection permission. Client-side privacy controls and analytics-cookie consent can affect visibility. Avoid declaring a form broken simply because its analytics event is unavailable in that view.

If debug_mode was added manually, remove the parameter after testing rather than relying on a false value to disable it. Keep test-traffic handling separate from debug visibility. Google’s filter comparison explains that active data-filter exclusion has permanent effects on affected incoming data; it should not be casually enabled as a duplicate-event repair.

For a Measurement Protocol integration, the validation endpoint can reveal payload issues. Validation events do not populate reports, and the endpoint does not establish every credential or end-to-end delivery condition. A clean validation response, a fired GTM tag and a processed report answer different questions.

Use each tool for its own checkpoint, then make the conclusion as narrow as the evidence permits. “One event appeared for this controlled test” is stronger and clearer than a general promise that all future tracking is accurate.

Test the repair for undercounting

Once the suspected cause is corrected in an approved test configuration, repeat the original baseline under the same conditions. Then challenge the repair with the case it is most likely to suppress incorrectly.

For a doubled accepted-enquiry event, the essential set is small:

These expectations apply to the stated accepted-enquiry definition. A click-measurement event has its own contract. The goal is to preserve each event’s intended meaning rather than forcing every interaction into a one-per-person model.

Check parameters and destinations as well as totals. Two events can be numerically correct while both use the first form’s details. A page view can carry a stale route. A purchase can reuse an old transaction reference. A repair that changes where valid data goes is still a failed repair.

Test the fault’s actual conditions. If duplication only follows a route change, include that route change. If it only appears after consent updates, review the relevant consent transition with the responsible implementer. Keep unrelated privacy settings unchanged while isolating the measurement cause.

After publication, run the approved production verification. The staging environment may have different plugins, consent settings or container versions. Google describes the distinction between verifying and publishing in its tag release instructions.

Finally, revisit the processed report for the matching time window. If source behaviour is corrected but reporting is still pending, keep that final check open. A smaller immediate chart is not enough to declare the incident resolved.

What to do when you cannot reproduce it

Intermittent duplication needs a narrower next question, not a more aggressive filter. Compare a failing observation with a clean one. Look for differences in navigation, form version, consent state, device, redirect path or release timing.

Ask whether the symptom began after a specific change. A plugin update, new route listener or dashboard join is a useful lead, but remains a hypothesis until its behaviour is connected to the extra record. Check the relevant version history and reproduce the changed path where possible.

If only production shows the issue, inspect the production installation inventory and release versions before assuming the test environment covers them. A theme-level tag can be absent from staging. A separate mobile form can use a different integration. An embedded provider can return through another confirmation flow.

Keep the investigation bounded to the affected event and journey. Record what you observed, what remains unknown and what evidence would distinguish the remaining possibilities. For example: “Browser sender verified once; backend sender status unavailable” tells the server owner exactly what to check.

Do not deploy a global time-window suppression because two events happened close together once. That can turn an intermittent overcount into a persistent undercount while making the original cause harder to see.

Keep a short record the next person can use

A useful incident note can be six lines: what happened, what one occurrence means, where the extra record came from, what changed, which valid repeat survived and whether destination/report checks are complete. Add the release time and responsible person.

For a more technical investigation, the existing GA4 duplicate-events kit contains blank logs, acceptance templates, fictional traces and an offline Python checker. The wider fields help when a case spans several producers or server attempts; they are optional supporting material, not a prerequisite to understanding the fault.

The checker reads the local files without contacting Google. Its ten teaching cases include overlapping producers, valid repeats, form failures, confirmation reloads, retries, route views and purchase references. It also rejects intentionally damaged examples so a correct total cannot hide a missing occurrence or wrong destination.

Keep untouched tests marked as not run. A blank cell should mean unknown, not zero. Use zero only when a relevant checkpoint was actually inspected and no event was present. Store sensitive diagnostic evidence in a restricted location and put only a safe reference in shared notes.

Explain the reporting break after the fix

Removing a doubled sender can make lead totals fall sharply even when customer demand is unchanged. Record when the definition or implementation changed and which journeys were affected. Use that date when interpreting campaign and website trends. Doubled form events inflate the enquiry counts a lead generation program is judged on, so fix them before comparing sources.

Do not automatically halve historical totals. A duplicate may have affected only one form, one device or one period. Reconstructing earlier business outcomes requires evidence about that period. Where an intake or order ledger exists, reconcile an appropriately defined sample or cohort instead of applying a convenient multiplier.

Tell the people using the report what changed in ordinary language: “The form was counted by both the plugin and GTM. The plugin now sends the accepted-enquiry event once, and a new second enquiry still counts.” Add any remaining coverage limitation and the date from which the corrected measurement applies.

The final test is straightforward: one intended occurrence produces the expected record, an invalid occurrence stays out, and a genuine repeat survives. If you can show all three and explain the reporting effect, the repair has a defensible basis. If the extra record still has no identified source, ask Canada Create to review the specific event and journey.

Frequently asked questions

Why does a GA4 form submission event fire twice?

A common cause is two senders for one action, such as a website plugin and a Google Tag Manager tag both sending generate_lead. A success callback that runs twice or a confirmation page that reloads can do the same. Trace one test submission to find where the second record first appears.

How should repeated GA4 purchase events from one order be handled?

First confirm whether one order produced one business record and then two events, or two records. A replayed order confirmation page or overlapping browser and server paths can send the purchase again. Whatever the fix, check that a genuinely new order still records its own event.

What is a good example of a GA4 custom event for lead forms?

The guide uses generate_lead, sent once after the application accepts a new enquiry. Its fictional trace shows the first enquiry producing two emissions, one from a plugin and one from GTM, then one after the overlapping GTM sender is removed. A second, separate enquiry must still produce its own event.

Why might GA4 key events reports disagree with the lead count?

Different measures count different things. GA4's New leads metric in the Lead acquisition report counts unique users with generate_lead, while Event count counts each occurrence. Align the metric, property, stream, dates and filters before deciding anything is duplicated.

Can automatically collected GA4 events overlap with manually created events?

Yes, automatic and manual measurement can both record the same action, which is one branch the guide checks. Doubled page_view events on a load or route change are a common sign. Confirm which sender should stay responsible before removing either.

Will limiting a GA4 event to once per session stop duplicates?

It can hide the symptom while losing real activity. In the guide's example, a once-per-session rule would also drop a genuine second enquiry. Remove the extra sender instead, so each accepted enquiry still produces exactly one event.

Is GA4 DebugView enough to prove a duplicate event is fixed?

DebugView helps confirm what a test session sent, but check the processed report as well. Two close timestamps suggest where to look without proving the cause. Keep any finding open until the evidence supports it.

How do I make sure a fix for duplicate GA4 events does not cause undercounting?

Retest with two separate, real actions after the change. Two accepted enquiries should produce two events, one for each enquiry; a total of two is still wrong if both describe the first enquiry. Keep a short record of the test so the next person can repeat it.