Improve Shopper Tracks performance

[malithsen]

Describe the issue

Shopper usage tracking utilizes Ajax requests to record activity at various touchpoints during the checkout process. Each record event emits a separate Ajax request. For high-traffic stores, there can be a high amount of Tracks originated requests hitting the merchant server.

We need to investigate ways to reduce the number of requests going to the merchant server. One option is making these requests in batches. One thing to be cautious of with such an approach is that we need to store the correct timestamp of the user action (not the request timestamp). This will require some refactoring of tracks_build_event_obj function.

Additionally, we can also consider introducing a new filter to disable front-end tracking altogether when needed.

[haszari]

Labelling as checkout payments since the majority of shopper tracking will be related to checkout flows in some way.

Some drive-by thoughts:

Additionally, we can also consider introducing a new filter to disable front-end tracking altogether when needed.

Would this be an additional setting/option on top of global tracking options? IMO we should keep settings related to tracking opt-in/out in one place and simple to use. Ideally, all tracking would respect the Woo wide opt-in setting. If it's worthwhile adding a sub-setting then perhaps this should be at the Woo level.

Shopper usage tracking utilizes Ajax requests to record activity at various touchpoints during the checkout process. Each record event emits a separate Ajax request. For high-traffic stores, there can be a high amount of Tracks originated requests hitting the merchant server.

We need to investigate ways to reduce the number of requests going to the merchant server. One option is making these requests in batches.

Do we know this is a problem? If so, ideally we could define the problem with data / numbers, and relate to merchant or shopper impact.

I also wonder if this problem (tracks performance) is unique to WooPayments shopper events, or if there's a fix/solution already available (either in tracks system or in WPCOM or Jetpack code).

[glagonikas]

Would this be an additional setting/option on top of global tracking options? IMO we should keep settings related to tracking opt-in/out in one place and simple to use. Ideally, all tracking would respect the Woo wide opt-in setting. If it's worthwhile adding a sub-setting then perhaps this should be at the Woo level.

As it stands, none of those tracks appear to respect the global woo setting in WooCommerce ➔ Settings ➔ Advanced ➔ WooCommerce.com ➔ Usage Tracking. In our case, we've explicitly set the global settings to "off" and the platform_tracks still occur.

Disabling platform_tracks using the filter add_filter('wcpay_frontend_tracks', '__return_empty_array', 20); removes some, but there are still some, like the Apple & Google Pay are hardcoded and cannot be removed using this filter.

Do we know this is a problem? If so, ideally we could define the problem with data / numbers, and relate to merchant or shopper impact.

We reported this as we noticed a large number of admin-ajax.php requests on our checkout caused by WooPayments. On very large websites, uncached requests (of any type) take a couple of seconds to complete. Even though those are async and do not really affect the customer, they still incur a load on the servers, because the entire code is loaded.

On quiet days, those will go unnoticed, but during large promotions, you want the site to run as efficiently as possible and reduce the number of uncached requests and therefore the overall server load, so as a minimum, WooPay should respect the global setting.

The Stripe plugin doesn't have such tracking and if those requests were hitting your own servers, they wouldn't cause a load issue, but this is not the case.

Also, I don't see why you need to use /wp-admin/admin-ajax.php instead of a different Ajax handler. Doesn't it make sense to use /wp-admin/admin-ajax.php for backend-related ajax? why bring /wp-admin/ on anything front-end?

I'd treat this as a bug rather than enhancement, considering the global setting is not respected, forcing you to use a filter and even then, some tracking cannot be disabled

[sverleis]

As per a customer request, I'm switching this label to "bug" rather than "enhancement" since:

1. WooPayments is tracking when the global settings are off and
2. Even when customers use the filter, some tracking is not disabled