[POS as a tab i2] Analytics & enable feature flag

[jaclync]

For WOOMOB-858

Just one review is required.

• @jaclync registers Tracks events when approved.

Description

This pull request adds analytics tracking the ineligible view being shown and when the retry CTA is tapped.

The implementation is based on the plan WOOMOB-856:

In POS ineligible UI:

• 🆕 pos_ineligible_ui_shown with property reason: store_currency|wc_plugin_version|feature_switch_disabled|unknown_wc_plugin|ios_version|other when the merchant sees ineligible UI after tapping the POS tab. This event is also tracked when the ineligible reason changes in the ineligible UI, like after a retry
• 🆕 pos_ineligible_ui_retry_tapped with the same reason property when the merchant taps to refresh POS eligibility in the ineligible UI

Steps to reproduce

Prerequisite: the store is ineligible for POS for two fixable reasons (e.g. unsupported store currency, and POS feature switch disabled in wp-admin > WC Settings > Advanced > Features).

– Launch the app connected to a store in the prerequisite -> POS tab should appear shortly
– Tap on the POS tab –> pos_ineligible_ui_shown event should be tracked with property reason in one of the options store_currency|wc_plugin_version|feature_switch_disabled|unknown_wc_plugin|ios_version|other that matches the ineligible reason
– Fix the first reason
– In the app, tap Retry -> pos_ineligible_ui_retry_tapped event should be tracked with the same reason property. After the ineligible UI is updated with the second reason, pos_ineligible_ui_shown event should be tracked with the corresponding reason property
– Fix the second reason
– In the app, tap Retry -> pos_ineligible_ui_retry_tapped event should be tracked with the same reason property. then it should enter POS

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[dangermattic]

	1 Warning
⚠️	View files have been modified, but no screenshot or video is included in the pull request. Consider adding some for clarity.

	1 Message
📖	This PR contains changes to Tracks-related logic. Please ensure (author and reviewer) the following are completed: The tracks events must be validated in the Tracks system. Verify the internal Tracks spreadsheet has also been updated. Please consider registering any new events. The PR must be assigned the category: tracks label.

Generated by 🚫 Danger

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce iOS Prototype by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS Prototype
	Build Number	pr15918-5163038
	Version	22.8
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	5163038
	Installation URL	2uukto35iu7q8

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[iamgabrielma]

LGTM!

✅ pos_ineligible_ui_shown - store_currency
✅ pos_ineligible_ui_retry_tapped - store_currency
✅ pos_ineligible_ui_shown - feature_switch_disabled
✅ pos_ineligible_ui_retry_tapped - feature_switch_disabled
✅ pos_items_fetched

Nit: Looks like we might be tracking pos_loaded twice when we have non-eligible screens: It tracks it once when we attempt to enter POS but we face the non-eligible view, then tracks again when it passes through the checks and we're allowed into POS. Most likely because the event is tied to the loading screen which we expected to load only once up till now.

[jaclync]

Nit: Looks like we might be tracking pos_loaded twice when we have non-eligible screens: It tracks it once when we attempt to enter POS but we face the non-eligible view, then tracks again when it passes through the checks and we're allowed into POS. Most likely because the event is tied to the loading screen which we expected to load only once up till now.

Thanks for catching this issue! I fixed this in 5163038 by moving the pos_loaded event tracking from the loading view to the dashboard view when the view enters "content" state. I was a bit unsure about the definition of pos_loaded at first, does it mean "upon entering POS in any state" or "upon entering POS when it's ready for use"? After checking the event documentation in Tracks in both platforms, my understanding is the latter from the Android event:

This event measures how many times POS has finished loading. It fires when the user taps on the POS entry point and the app finishes fetching products/coupons/...

To match this behavior, the event is only logged once when the POS reaches the content state where items are loaded. If the store is ineligible for POS, the event won't be logged until the eligibility is fixed.