koffeinfritt

@adamdunnage

Apologies, I must have missed your reply.

We are currently running with a workaround to solve this; I will restore the setup in our staging environment and try this week.

Hi James,

Thank you for looking into this and for sharing it with the team. I have now been able to reproduce the issue in a controlled staging test.

The main finding is:

Site Kit writes _googlesitekit_ga_purchase_event_tracked = 1 before the browser request has successfully reached Google Analytics. If that request fails, Site Kit does not retry the purchase on a later page load.

This means that a temporary network problem, browser interruption, blocked request, consent timing issue, or the customer closing the page could permanently lose the purchase event even though the order has already been marked as tracked.

Thank you also for suggesting Conversios and GIA GA4. I would prefer not to introduce a second tracking integration at this stage, as that could create duplicate purchase events and make attribution harder to verify.

I understand that server-side measurement may provide a more robust long-term solution. However, the staging test indicates that the current tracked-marker behaviour is also a separate reliability issue within Site Kit’s existing browser-based flow.

Test environment

I used a password-protected staging clone with a separate GA4 property.

• Site Kit plugin conversion tracking was enabled.
• Google for WooCommerce was disabled to avoid another Google tracking integration.
• Nexi was in test mode.
• FunnelKit’s custom thank-you page remained enabled.
• No production changes were made.

Successful baseline test

I first completed a normal Nexi test-card payment. Nexi returned the browser automatically to the custom FunnelKit thank-you page.

Site Kit successfully sent one purchase event to GA4 with the expected ecommerce data, including:

• transaction_id
• value
• currency
• items
• tax
• shipping
• googlesitekit_event_provider: woocommerce
• event_source: site-kit

The order then contained:

_googlesitekit_ga_purchase_event_tracked = 1

Reloading the thank-you page did not send another purchase, confirming that Site Kit’s duplicate prevention works when the initial request succeeds.

Controlled failed-delivery test

I then completed a second Nexi test-card purchase. Before completing checkout, I used Edge DevTools to block only requests to:

region1.google-analytics.com

Nexi still completed the payment normally and returned the browser automatically to the same FunnelKit thank-you-page flow.

On the first load of the thank-you page:

• Site Kit generated the correct purchase request.
• The request contained en=purchase and event_source=site-kit.
• DevTools showed that the request was blocked before transmission: 0 B, 0 ms.
• The event therefore did not reach Google Analytics.

Immediately afterwards, I checked the order metadata. Despite the failed browser request, Site Kit had already written:

_googlesitekit_ga_purchase_event_tracked = 1

I then removed the network block and reloaded the same valid thank-you URL. GA4 successfully received new page_view and scroll requests with status 204, demonstrating that communication with Analytics was working again.

However, Site Kit did not retry the purchase event because the order had already been marked as tracked.

Conclusion

In both tests:

• Nexi completed the payment and returned the browser correctly.
• The FunnelKit thank-you page loaded correctly.
• The WooCommerce purchase data was available.
• Site Kit generated the correct purchase event.

The reproducible failure is the order of operations:

1. Site Kit marks the order as tracked server-side.
2. The browser attempts to send the purchase event.
3. If browser delivery fails, the stored marker prevents any later retry.

This does not appear to be caused by Nexi omitting the standard WooCommerce flow or FunnelKit preventing the purchase event from being generated. In this test, the event was generated correctly but could not recover from a failed browser delivery.

I have screenshots showing:

1. The successful baseline purchase and its ecommerce parameters.
2. The blocked Site Kit purchase request showing 0 B.
3. The tracked order metadata already set to 1.
4. The subsequent successful GA4 requests after unblocking, with no purchase retry.

I would be happy to share these if they would help the team.

Thank you again for taking the time to investigate this.