Add site lifecycle status guess to My Jetpack

[robertsreberski]

Proposed changes:

• Add all stats needed to perform user/site lifecycle status check
• Add selector combining all available information and doing best guess

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

Does this pull request change what data or activity we track or use?

Testing instructions:

• Go to /wp-admin/admin.php?page=my-jetpack
• Check that window.myJetpackInitialState.userStats includes correct information
• Do a static code analysis of selector getGuessedSiteLifecycleStatus() whether it matches the following conditions:

"Brand New Sites"
Have no paid products
Have no active Jetpack modules (aside from modules that are active by default)
Have only one Jetpack plugin installed
Have no site or user connection
May or may not come from a known host (we can do our best to guess)

"New Sites"
Have no paid products
Have 3 or fewer Jetpack modules activated

"Settling-in Sites"
Have one paid product (this does not include bundles - which contain multiple products)
Have fewer than 10 active Jetpack features (paid or free)

"Established Sites"
Have more than one paid product (could be individual products or a bundle) OR
Have 10+ Jetpack features enabled

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• 🔴 Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Once your PR is ready for review, check one last time that all required checks appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team Review" label and ask someone from your team review the code. Once reviewed, it can then be merged.
If you need an extra review from someone familiar with the codebase, you can update the labels from "[Status] Needs Team Review" to "[Status] Needs Review", and in that case Jetpack Approvers will do a final review of your PR.

---

Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

• WordPress.com Simple releases happen daily.
• WoA releases happen weekly.
• Releases to self-hosted sites happen monthly. The next release is scheduled for March 5, 2024 (scheduled code freeze on March 4, 2024).

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Backup plugin:

• Next scheduled release: March 5, 2024.
• Scheduled code freeze: February 26, 2024.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Boost plugin:

• Next scheduled release: March 5, 2024.
• Scheduled code freeze: February 26, 2024.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Search plugin:

• Next scheduled release: March 5, 2024.
• Scheduled code freeze: February 26, 2024.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Social plugin:

• Next scheduled release: March 5, 2024.
• Scheduled code freeze: February 26, 2024.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Starter Plugin plugin:

• Next scheduled release: March 5, 2024.
• Scheduled code freeze: February 26, 2024.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Protect plugin:

• Next scheduled release: March 5, 2024.
• Scheduled code freeze: February 26, 2024.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Videopress plugin:

• Next scheduled release: March 5, 2024.
• Scheduled code freeze: February 26, 2024.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Migration plugin:

• Next scheduled release: March 5, 2024.
• Scheduled code freeze: February 26, 2024.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WordPress.com Simple site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin, and enable the add/my-jetpack-user-type-check branch.

• To test on Simple, run the following command on your sandbox:

  bin/jetpack-downloader test jetpack add/my-jetpack-user-type-check
  

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[CodeyGuyDylan]

@robertsreberski i am guessing (based on the code) I should be looking at window.myJetpackInitialState.lifecycleStats instead of window.myJetpackInitialState.userStats? userStats always shows up as undefined for me

[CodeyGuyDylan]

"Brand New Sites"
May or may not come from a known host (we can do our best to guess)

I don't see any check for this yet

"New Sites"
Have 3 or fewer Jetpack modules activated

I think we still need to check this, the way it is right now they would be labelled as "New" if there are no purchases regardless of the amount of modules

[robertsreberski]

"Brand New Sites"
May or may not come from a known host (we can do our best to guess)

I don't see any check for this yet

When I'm thinking about it, it's not really a check I suppose, I don't see how it can distinguish "Brand New Sites" 🤔 We just have that information in the state, but don't include it in lifecycle status.

[CodeyGuyDylan]

"Brand New Sites"
May or may not come from a known host (we can do our best to guess)
I don't see any check for this yet

When I'm thinking about it, it's not really a check I suppose, I don't see how it can distinguish "Brand New Sites" 🤔 We just have that information in the state, but don't include it in lifecycle status.

I was referencing "may or may not come from a known host" since there doesn't seem to be any best guess type code as it pertains to that. I am not sure if that exists though

[CodeyGuyDylan]

Thank you for the changes! I had a few questions about the condition for "new" and "brand new" users. It seems, at least with my testing, we could be mislabelling some users with these conditions

[CodeyGuyDylan]

One note about the features being checked here. I created a new jurassic ninja site without anything pre-downloaded (other than whatever comes with the Jetpack plugin normally) and as soon as I connected my user account, I had 17 features in my features array

I am not 100% sure this is the behavior for all jetpack sites, but if it is, that would mean that as soon as a user connects their site, they'd automatically be labelled as "established" since they don't have a purchase yet and wouldn't get stopped with the "settling-in" condition

[robertsreberski]

Thanks for catching that; indeed, some features are enabled by default. I'll omit them in the features array!

[robertsreberski]

I've updated the code to add hardcoded array of default features. Unfortunately, I don't see any easy access to them; they are essentially features from the WPCOM_Features that include the JETPACK_ALL_SITES slug.

Not sure if that solution is good enough or if we should update the get_available_features_for_blog_uncached() method (fbhepr%2Skers%2Sjcpbz%2Sjc%2Qpbagrag%2Snqzva%2Qcyhtvaf%2Sjcpbz%2Qovyyvat%2Sfgber%2Qcebqhpg%2Qyvfg.cuc%3Se%3Q1prs6727%232141-og) to, e.g., include default_features array in the response. It might be an overkill, though, unnecessarily increasing the size of every payload. And the array of default features isn't likely to change often or in the near future 🤔

What do you think?

[CodeyGuyDylan]

Hmmmm, even with that added defaults array, I still had 4 features active as soon as I connected my site

(Ignore scan, that is because I purchased Protect)

I think those social features may be active by default? And I am also wondering if there are other default features added depending on the host?

Do you think it might be better to just leave the features out of these calculations? The modules and purchases may be enough if we can't confidently know what and how many features are active by default

[jboland88]

I think I contributed to this 😬 In the task description I used the word "features" to mean "Jetpack modules", not thinking about the wpcom_features array.

I agree with @CodeyGuyDylan - let's simplify this by dropping the features check and just use purchases and Jetpack modules.

So sorry for the mislead there @robertsreberski 🤦

[robertsreberski]

Yeah, that simplifies things 😅 sounds good, thanks for your feedback here 👍

[robertsreberski]

I was referencing "may or may not come from a known host" since there doesn't seem to be any best guess type code as it pertains to that. I am not sure if that exists though

I've been working on such code last month (#34864), and it's already accessible as window.myJetpackInitialState.isUserFromKnownHost.

[CodeyGuyDylan]

I was referencing "may or may not come from a known host" since there doesn't seem to be any best guess type code
as it pertains to that. I am not sure if that exists though

I've been working on such code last month (#34864), and it's already accessible > as window.myJetpackInitialState.isUserFromKnownHost.

Oh ok I misunderstood, I thought there was going to be some sort of host check when determining how new users are. This makes sense, thank you

[jboland88]

I think I created some trouble in the initial description - my apologies!

I think this will be a quick cleanup to remove "features" from the data gathered and checks. Then this should be good to go.

[jboland88]

I think I contributed to this 😬 In the task description I used the word "features" to mean "Jetpack modules", not thinking about the wpcom_features array.

I agree with @CodeyGuyDylan - let's simplify this by dropping the features check and just use purchases and Jetpack modules.

So sorry for the mislead there @robertsreberski 🤦

[jboland88]

Related to the comment above, I think this can be a modules check instead of a features check

[CodeyGuyDylan]

I think this looks good now, thanks for all the back and forth about the conditions 😅 . I left one non-blocking comment about a comment, everything else looks good

[CodeyGuyDylan]

I think this is inaccurate, the user will be marked as 'established' if they have 2 or more purchases OR 10 or more modules

[jboland88]

Thanks for the updates - LGTM!