Tracking: Fix hosting flow related issues

[ddc22]

Related to #

Proposed Changes

Tracking events generated on hosting flow surfaced an issue in tracking that's related to the stepper framework.

Previously whenever a flow was marked as a signup flow via isSignupFlow a calypso_signup_complete was logged whenever the flow started. However when the user is not logged in we redirect the user to the signup framework to log them in. This results in a signup start being logged.

Due to this requirement a change in the tracking approach is suggested in more fine grain controls for events logged by the framework.

wp-calypso/client/landing/stepper/declarative-flow/internals/index.tsx

Lines 165 to 169 in e974e3b

	useEffect( () => {
	if ( flow.isSignupFlow && isFlowStart() ) {
	recordSignupStart( flow.name, ref, signupStartEventProps );
	}
	}, [ flow, ref, isFlowStart ] );

However if the user is not logged in they will be redirected tht e

Testing Instructions

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• https://wpcalypso.wordpress.com/devdocs/docs/testing/index.md for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-107520

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-107520&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-107520&env=a8c-for-agencies

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~30 bytes added 📈 [gzipped])

name           parsed_size           gzip_size
entry-stepper        +51 B  (+0.0%)      +30 B  (+0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~1059 bytes added 📈 [gzipped])

name                           parsed_size           gzip_size
videopress-tv-flow                  +249 B  (+0.5%)      +80 B  (+0.4%)
write-flow                          +197 B  (+0.1%)      +72 B  (+0.2%)
videopress-flow                     +197 B  (+0.0%)      +78 B  (+0.0%)
transferring-hosted-site-flow       +197 B  (+0.5%)      +76 B  (+0.5%)
sensei-flow                         +197 B  (+0.0%)      +73 B  (+0.0%)
plugin-bundle-flow                  +197 B  (+0.1%)      +79 B  (+0.1%)
link-in-bio-tld-flow                +197 B  (+0.0%)      +71 B  (+0.0%)
import-hosted-site-flow             +197 B  (+0.0%)      +74 B  (+0.0%)
import-flow                         +197 B  (+0.0%)      +67 B  (+0.0%)
copy-site-flow                      +197 B  (+0.0%)      +76 B  (+0.0%)
build-flow                          +197 B  (+0.1%)      +76 B  (+0.2%)
new-hosted-site-flow                +136 B  (+2.2%)      +41 B  (+2.0%)
update-design-flow                  +104 B  (+0.0%)      +41 B  (+0.0%)
with-theme-assembler-flow            +52 B  (+0.1%)      +26 B  (+0.3%)
update-options-flow                  +52 B  (+0.1%)      +26 B  (+0.5%)
trial-wooexpress-flow                +52 B  (+0.1%)      +22 B  (+0.4%)
tailored-ecommerce-flow              +52 B  (+0.5%)      +24 B  (+0.7%)
start-writing-flow                   +52 B  (+0.3%)      +22 B  (+0.4%)
site-setup-flow                      +52 B  (+0.1%)      +26 B  (+0.2%)
site-migration-flow                  +52 B  (+0.1%)      +25 B  (+0.4%)
reblogging-flow                      +52 B  (+0.7%)      +23 B  (+0.9%)
podcasts-flow                        +52 B  (+0.0%)      +22 B  (+0.0%)
newsletter-post-setup-flow           +52 B  (+0.1%)      +19 B  (+0.1%)
newsletter-flow                      +52 B  (+0.3%)      +19 B  (+0.4%)
migration-signup                     +52 B  (+0.1%)      +23 B  (+0.3%)
link-in-bio-post-setup-flow          +52 B  (+0.1%)      +18 B  (+0.1%)
link-in-bio-flow-domain              +52 B  (+0.2%)      +24 B  (+0.3%)
link-in-bio-flow                     +52 B  (+0.3%)      +22 B  (+0.5%)
hundred-year-plan                    +52 B  (+0.2%)      +21 B  (+0.2%)
google-transfer                      +52 B  (+1.0%)      +25 B  (+1.3%)
free-post-setup-flow                 +52 B  (+0.2%)      +23 B  (+0.5%)
free-flow                            +52 B  (+0.1%)      +20 B  (+0.3%)
domain-user-transfer-flow            +52 B  (+0.0%)      +22 B  (+0.0%)
domain-transfer                      +52 B  (+1.0%)      +26 B  (+1.4%)
design-first-flow                    +52 B  (+0.3%)      +25 B  (+0.5%)
connect-domain                       +52 B  (+0.2%)      +24 B  (+0.3%)
blog                                 +52 B  (+1.8%)      +26 B  (+2.0%)
assembler-first-flow                 +52 B  (+0.1%)      +23 B  (+0.2%)
ai-assembler-flow                    +52 B  (+0.1%)      +18 B  (+0.1%)
entrepreneur-flow                    -25 B  (-0.1%)       -7 B  (-0.1%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[ddc22]

@daledupreez @southp Would like to gather your thoughts on this approach so that we grant granular control of the flow tracking to flows.

wp-calypso/client/landing/stepper/declarative-flow/internals/types.ts

Lines 112 to 130 in 6add167

	trackingConfig?: {
	/**
	* Should signup start be tracked at the start of the flow
	*/
	isRecordSignupStart: boolean;
	/**
	* Should signup complete be tracked at the end of the flow
	*/
	isRecordSignupComplete: boolean;
	/**
	* Supply additional event props to the `calypso_signup_start` event
	*/
	signupStartProps?: Record< string, string | number >;
	/**
	* Supply additional event props to the `calypso_signup_complete` event
	*/
	signupCompleteProps?: Record< string, string | number >;
	};
	};

---

Re thinking this but the idea remains mostly similar but with hooks.

[southp]

Thanks for looping us in @ddc22 :)

Although I think eventually this will work, my only concern is that it's lots of manual chores for the developers to follow, hence not a strong enough guarantee. Since Stepper is a general flow framework, the overall coherence of whether a flow is a signup flow seems to rely too much on the manual configuration from the developer. Roughly speaking, there are now:

1. Setup a back-and-forth redirection to /start/account if the user isn't logged-in, and skip it if the user is logged-in.
2. Put in the processing step somewhere since it's where the site creation code happens and where the signup completion event is fired. It might be questionable whether this should belong to the flow level or the step level.
3. Set the relevant tracking configuration props. There used to be isSignupFlow configuration flag, and now it'd become finer.

Since a "flow" in Stepper is a general concept, I'm wondering whether such a flag should be a pervasive prop existing in all flow instances, causing all flow to have to configure it whether it's a signup flow or not.

I'm seeing that Stepper already uses class extension in several places; I'm wondering if we can do similar thing to hide all these configuration away from the developers. e.g. a signup flow has to implement a SignupFlow interface that extends from the general Flow:

interface SignupFlow extends Flow {
 ...
}

and a signup flow on Stepper would only need to implement this interface and have all the signup-related configuration in-place. Currently it'd be mainly about the data tracking. In the future we might also need to port the new site managing functionality(i.e. when users navigate back-and-forth in the flow, they are actually editing the same site). If it's possible, it might be a good way to abstract all the manual chores away and make the signup-related code more reusable.

Also, last but not least, if we can move the user step onto Stepper, the whole finer configuration thing might not be needed, and a major pain of implementing a signup flow on Stepper will be removed. 🙃