Woocommerce-admin: Store Profiler - Business details step: install free extensions in 1 click

[pmcpinto]

Description: we're going to experiment with a new approach to install free extensions in the Store Profiler flow, including WCPay. We should start with a small subset of new users - it seems that the easiest way can be filtering the segment by the store location and industry. Eg: stores with the location in the US and Electronics & Computers as industry.

Final segmentation: Stores that selected the US as country and Fashion, Apparel, Accessories or Health & Beauty as Industry. It gives ~2.5% of the total number of new users and ~30% of the total number of new users from US

Acceptance Criteria:

• [ ] display the changes in the flow just to a specific segment (segmentation tbd)
• [ ] display just one checkbox to install all the free extensions. The checkbox should be toggled on by default
• [ ] show a popover with more info about the extensions when the user hovers the info icon
• [ ] install the following extensions if the user clicked "continue" with the checkbox togged on: Jetpack, WooCommerce Services, Facebook, Mailchimp, Google Ads, WCPay
• [ ] remove the JP/WCS step for this segment, as they're going to be installed in the Business details step
• [ ] the redirect to the Jetpack account creation flow should only happen after the theme step

Event tracking:
It will be better to add a new event for this step's alternative version:

Event name: wcadmin_storeprofiler_store_business_details_continue_alternative
Event prop: extensions_installed (value: Yes/No)
Event description: When the user clicks on "Continue" on the alternative version of the Business step

Event name: wcadmin_storeprofiler_store_business_details_popover_alternative
Event prop: NA
Event description: When the user clicks on the popover

It will be necessary to update wcadmin_storeprofiler_step_view to include this alternative step as the value of the step prop. It can be named business-details-alternative

Additional links:
Design mockup

[joshuatf]

Estimate: 5. I see two items that stand out in this issue:

1. Since we're introducing split-testing in WCA, it might be nice to have some generic functions around this so we don't recreate the wheel each time we do this.
2. If I recall correctly, the plugins that determine if the benefits screen is shown may be cached on first load in the profiler component, so making sure that's updated will resolve removing the benefits screen.

The redirect to Jetpack at theme step could introduce more code debt, so it would be nice to have a promise in place to get the Jetpack URL instead of using a component to handle this. See https://github.com/woocommerce/woocommerce-admin/pull/4473 for how this was handled for plugins. (The above estimate does not include time for this refactor).

[timmyc]

If we are touching this step, I feel we should also take the plunge and make the list of extensions installed in the step extensible... so a few different options there, from easier to more difficult. But I think all of these could align for a way to accomplish the above based upon vertical

• wc-admin only: new endpoint that delivers a list of recommended extensions based upon current profile data. The REST endpoint response should be filterable to allow for over-riding by other plugins ( think wc-calypso-bridge / ecomm plan ). This endpoint could also maybe return the desired "layout" to use in the step too. Estimate: 8
• woocommerce.com: similar to the above, but have the logic setup to call out to a new REST endpoint on wc.com. Perhaps this could be considered with Alpha building the new catalog feature. Estimate 13

Given the catalog feature is sounding like it will happen from Alpha, I'm personally leaning towards not tackling this issue in this sprint cycle myself, and instead working with Alpha with this design in mind and revisiting once the REST API for that is ready.

[pmcpinto]

Given the catalog feature is sounding like it will happen from Alpha, I'm personally leaning towards not tackling this issue in this sprint cycle myself, and instead working with Alpha with this design in mind and revisiting once the REST API for that is ready.

We're only allowed to automatically install extensions available on .org, so in this step it won't be possible to use any API coming from wccom

[mattsherman]

Design comment: That seems like a very large amount of info to put into a popover (it looks/feels off that the popover has greater info/density than the screen it is on).

[jeffstieler]

We're only allowed to automatically install extensions available on .org, so in this step it won't be possible to use any API coming from wccom

The WCCOM endpoint could only return plugins that are on .org - so the install would still come from .org. Or are we unable to even make that initial query to WCCOM at this step?

Estimate: 5

I agree with @joshuatf 's estimate of 5 assuming that we aren't adding endpoints to power this.

Design comment: That seems like a very large amount of info to put into a popover (it looks/feels off that the popover has greater info/density than the screen it is on).

+1 from me on this.. the popover is larger than the entire step card.

we're going to experiment with a new approach to install free extensions
...
display just one checkbox to install all the free extensions

I'm concerned about the way this test might not allow for any interpretations other than this "one click" version performs better than the "many clicks" version that exists now. (unless I guess the large popover overwhelms people?)

How are we going to measure the performance of this relative to the "many clicks" version we have now?

Are we perhaps introducing a bit of a dark pattern here where we are just hiding more information in hopes that it leads to our desired outcome?

[mattsherman]

1. Since we're introducing split-testing in WCA, it might be nice to have some generic functions around this so we don't recreate the wheel each time we do this.

Are you saying we currently don't have any split/A-B testing support in WCA?

2. If I recall correctly, the plugins that determine if the benefits screen is shown may be cached on first load in the profiler component, so making sure that's updated will resolve removing the benefits screen.

Can you help me understand what this means?

The redirect to Jetpack at theme step could introduce more code debt, so it would be nice to have a promise in place to get the Jetpack URL instead of using a component to handle this. See #4473 for how this was handled for plugins. (The above estimate does not include time for this refactor).

I think we definitely should include this refactoring into our estimate so we don't knowingly introduce code debt. Or, at least know how much extra effort we would be talking about to do the refactoring.

[joshuatf]

Are you saying we currently don't have any split/A-B testing support in WCA?

AFAIK we do not. We have the ability to turn on/off features and in core we introduced a random selection for updating an individual feature.

There may be an opportunity to create a reusable split method, but it may also lead to some over-engineering and better done on a case-by-case basis.

Can you help me understand what this means?

Sure! In the profiler we cache the active plugins when the profiler is first loaded so that the benefits screen does not get removed mid-way while we're still installing/connecting.

https://github.com/woocommerce/woocommerce-admin/blob/1b2632cf820d291d6938801d145e5210045f9b4d/client/profile-wizard/index.js#L165

This will need to be modified so that we can remove it during the profiler, but not while we're on the benefits step.

I think we definitely should include this refactoring into our estimate so we don't knowingly introduce code debt.

High on my list of things to do. Will have an issue outlined first thing in the morning.

[psealock]

Estimate: 5

This seems reasonable. If we take this suggestion from Pedro:

it seems that the easiest way can be filtering the segment by the store location and industry

Then we don't really need to create A/B test plumbing, which is wise unless we see ourselves really leveraging the technique in the future.

[joshuatf]

Jetpack connection URL refactor outlined in https://github.com/woocommerce/woocommerce-admin/issues/4639

This might be something we want to include in the sprint as well.

[pmcpinto]

Are you saying we currently don't have any split/A-B testing support in WCA?

Correct. That's why I was thinking about just displaying it for a specific segment based on geo and some additional criteria from the profiler.

Design comment: That seems like a very large amount of info to put into a popover (it looks/feels off that the popover has greater info/density than the screen it is on).

+1 from me on this.. the popover is larger than the entire step card.

That's a good point. I'm wondering if it would be better to display the content below the checkbox with a toggle, instead of the popover. @jameskoster what do you think?

[jameskoster]

I'll work on an iteration next week to streamline the popover content. We probably don't need the title, and the disclaimer can be shorter. That will save a lot of space.

[jameskoster]

I exercised some subtraction and came up with:

I acknowledge the popover is still quite "heavy", but that's kind of the point here. We're working on the assumption that most people will simply opt-in or out of "installing" the stuff we recommend without much thought (or viewing the popover at all). Of course we'll monitor performance and adjust accordingly.

[pmcpinto]

I acknowledge the popover is still quite "heavy", but that's kind of the point here. We're working on the assumption that most people will simply opt-in or out of "installing" the stuff we recommend without much thought (or viewing the popover at all). Of course we'll monitor performance and adjust accordingly.

@jameskoster we're required to specify the extensions that will be installed. An alternative can be displaying that text below the continue button.

[jameskoster]

I think it's ok to include the plugin names in the small text.

I'd prefer to keep all the jargon together for this initial iteration. Starting from there will help paint the best picture of how important these details are to people.

That said, we should probably add a track to the popover click :)

[mattsherman]

That said, we should probably add a track to the popover click :)

💯

[pmcpinto]

Updated the event tracking section and final segmentation of the issue description.

Something that I mentioned in the P2 discussion: I’m good with placing the “legalese” below the continue button for transparency. Curiously in the current implementation we don’t mention the accounts’ requirement, so we could consider removing that content.

[jameskoster]

I’m good with placing the “legalese” below the continue button for transparency.

Design for this here: