Do we want to track intent of navigation or the actual navigation.

[tomalec]

This is a follow-up after https://github.com/woocommerce/google-listings-and-ads/pull/393

I separated the thread from the discussion https://github.com/woocommerce/google-listings-and-ads/pull/393#discussion_r603314392, and potentially revisit/settle on our approach for tracking navigation-related events.

We used to track the confirmed redirect after clicking the back-button.

User story

We want to track the user's action of navigating from "A" to "B".

I think the issue boils down to the choice:

1. We want to track user intent to go back.
2. We want to track the actual redirect.

Technical

For the back button example, we coded it specifically, to record the event, after potential confirmation of blocked navigation (leaving unsaved form). The confirmation was specifically coded as back-button click re-action.

woocommerce/navigation package exposes a way to block navigation on the entire page. That's the kind of behavior we could use at scale, as navigation could be performed by distant parts of the UI of this and other plugins.

From the perspective of our plugin's UI element, we cannot predict who, when, and why would use that API to block the navigation.

Also the woocommerce/navigation does not expose a nice way to hook on the time after the blocked navigation was confirmed. (At least none I'm aware of) Therefore, recording a tracking event after the navigation was confirmed could be hard to implement.

[tomalec]

I personally, feel fine with

1. We want to track user intent to go back.

This is itself a piece of valuable information on what the user wanted to achieve, regardless of whether that succeeded or not due to us or somebody else blocking that action. Whether the user actually went "back" or somewhere else we could reason from the page_view event.

[tomalec]

We discussed it today on Dev call, the general summary was:

• We are not the ones actually using the recorded data, so it's hard to judge what is needed/better.
• Tracking just the intent seems fine, unless it's used to track page loads. But there should be a separate even for that.
• Either way, it behaves we need to specify in the event description. So, the peers using that data would be able to interpret it correctly.

---

Then the only action point for this issue is to make sure we document/describe the event precisely.