According to internal logs, some calypso_page_view paths coming from Checkout are reported without replacing passed parameters with corresponding variables. In the following examples I'll be using [variable] to denote the places where these parameters appear (e.g. [site] means that example.wordpress.com was recorded in our logs, instead of :site):
/checkout/[site_id]/personal/checkout/[site]/theme:[theme_name]/checkout/domain_map:[domain]/renew/[product_id]/checkout/offsite_redirect/renew/[product_id]/checkout/thank-you/[site]/[product_id]/checkout/value_bundle/renew/[product_id]/[site]For more details on how to obtain the logs, please check out the parent issue https://github.com/Automattic/wp-calypso/issues/16902 and p7jreA-1xN-p2.
For a recent related fixes, please check out https://github.com/Automattic/wp-calypso/pull/23027 and https://github.com/Automattic/wp-calypso/pull/17938.
@markryall would you be able to look into this one too, since you already did some similar work in https://github.com/Automattic/wp-calypso/pull/23027?
Hmm - yes - I can see there still a whole lot of checkout related calypso_page_view events with those incorrect paths.
I can't seem to reproduce them however - whenever I test the various routes covered in the test plan for the PR, I see the expected placeholders - even if I specify a site that I don't own (in which case, it'll switch to the site selector).
I realise now that the approach I took in #23027 is deprecated now. It was just a slight improvement on what was already there.
Perhaps the checkout page component should determine which was the selected route and register the page view with the page view tracking component. It'll be quite complicated however as there are a heap of different checkout routes (even though it seems likely that many are actually no longer used).
To prevent data from being lost, we need @rodrigoi's changes to land first in https://github.com/Automattic/wp-calypso/pull/23911 if we'd like to use the PageViewTracker to update usages from bare analytics calls in client/my-sites/checkout/controller.jsx
We should also consider removing sectionifyWithRoutes since this is getting some cases incorrect.
Note that rerunning the query I still see errors like /checkout/[site_id]/personal though I'm having a difficult time reproducing locally.
Likely a race condition with the controller?
To prevent data from being lost, we need @rodrigoi's changes to land first in #23911
Sorry @gwwar, I did the very same assign/in progress/figure out/unassign/backlog the other day and totally forgot to write the reason. 🤦♂️