Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plans: Use 2year and 3year default interval type #96174

Merged
merged 8 commits into from
Nov 25, 2024

Conversation

chriskmnds
Copy link
Contributor

@chriskmnds chriskmnds commented Nov 8, 2024

Related to https://github.com/Automattic/martech/issues/3403
Branched from #96357 (term-savings logic)

Proposed Changes

  • Introduces pbxNRc-4tx-p2 that will show longer term plans by default in the plans grid.
  • Experiment variants:
    • Control: Current pricing page, defaulted to annual plans
    • Treatment 1: Savings emphasized, grid defaults to annual plans
    • Treatment 2: Savings emphasized, grid defaults to 2-year plans
    • Treatment 3: Savings emphasized, grid defaults to 3-year plans
  • Adds a new experiment hook use-longer-plan-term-default-experiment.ts
  • See Plans: Enable term savings price display - as a grid feature #96357 for the term-savings logic (this PR builds on top to hook the experiment and add the default term)

Media

Screenshot 2024-11-20 at 5 14 37 PM

Why are these changes being made?

Low-tier, Personal and Premium Plan customers represent, by volume, the majority of dotcom plan purchases. With the Personal Plan alone, 45-50% of all users purchase said plan at signup. When considering monthly, yearly, 2 year, and 3 year billing terms, 35% of all users purchase an annual Personal Plan at signup.

Our low-tier users, however, are extremely price sensitive.

One potential way to address price sensitivity is to make our 2 year and 3 year plan discounts more prominent. By showing longer term plans on page load ( Ex. 2 year billing ), the plans grid monthly costs will render with 20% lower prices than with annual billing.

See pau2Xa-6wD-p2 for more context

Testing Instructions

  • Switch to USD and go to /start/plans and /plans/:site. Confirm:
    • For treatment variations:
      • Treatment 1: plans grid defaults to annual plans (and term in toggle) with savings emphasized on term yearly+
      • Treatment 2: plans grid defaults to 2-year plans (and term in toggle) with savings emphasized on term yearly+
      • Treatment 3: plans grid defaults to 3-year plans (and term in toggle) with savings emphasized on term yearly+
    • For control variant:
      • plans grid defaults to annual plans (and term in toggle) with no savings emphasized

Pre-merge Checklist

  • Has the general commit checklist been followed? (PCYsg-hS-p2)
  • Have you written new tests 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)?

@matticbot
Copy link
Contributor

matticbot commented Nov 8, 2024

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

App Entrypoints (~134 bytes removed 📉 [gzipped])

name                   parsed_size           gzip_size
entry-stepper               -585 B  (-0.0%)     -134 B  (-0.0%)
entry-main                  -504 B  (-0.0%)     -110 B  (-0.0%)
entry-subscriptions         -126 B  (-0.0%)      -52 B  (-0.0%)
entry-login                 -126 B  (-0.0%)      -52 B  (-0.0%)
entry-domains-landing       -126 B  (-0.0%)      -52 B  (-0.0%)
entry-browsehappy           -126 B  (-0.1%)      -52 B  (-0.1%)

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

Sections (~17009 bytes added 📈 [gzipped])

name                                parsed_size           gzip_size
update-design-flow                      +7660 B  (+0.6%)    +2577 B  (+0.8%)
link-in-bio-tld-flow                    +7633 B  (+0.4%)    +2492 B  (+0.5%)
jetpack-app                             +7551 B  (+1.9%)    +2887 B  (+2.2%)
plugins                                 +7471 B  (+0.2%)    +2580 B  (+0.3%)
plans                                    +669 B  (+0.0%)     -239 B  (-0.1%)
jetpack-connect                          -196 B  (-0.0%)     -693 B  (-0.2%)
checkout                                 -196 B  (-0.0%)     -966 B  (-0.2%)
signup                                   +176 B  (+0.1%)       +2 B  (+0.0%)
jetpack-cloud-pricing                    -103 B  (-0.0%)     -256 B  (-0.1%)
gutenberg-editor                          -81 B  (-0.0%)      -25 B  (-0.0%)
with-theme-assembler-flow                 +27 B  (+0.0%)       -1 B  (-0.0%)
update-options-flow                       +27 B  (+0.0%)       -1 B  (-0.0%)
trial-wooexpress-flow                     +27 B  (+0.0%)       -1 B  (-0.0%)
tailored-ecommerce-flow                   +27 B  (+0.0%)       -1 B  (-0.0%)
start-writing-flow                        +27 B  (+0.1%)       +8 B  (+0.1%)
site-setup-wg                             +27 B  (+0.0%)       -1 B  (-0.0%)
site-setup-flow                           +27 B  (+0.0%)       -1 B  (-0.0%)
site-migration-flow                       +27 B  (+0.0%)       -2 B  (-0.0%)
reblogging-flow                           +27 B  (+0.4%)       +8 B  (+0.4%)
readymade-template-flow                   +27 B  (+0.0%)       -1 B  (-0.0%)
onboarding-flow                           +27 B  (+0.1%)       +8 B  (+0.1%)
newsletter-flow                           +27 B  (+0.1%)       +8 B  (+0.1%)
new-hosted-site-flow-user-included        +27 B  (+0.4%)       +8 B  (+0.4%)
new-hosted-site-flow                      +27 B  (+0.3%)       +7 B  (+0.3%)
migration-signup                          +27 B  (+0.0%)       -2 B  (-0.0%)
migration-flow                            +27 B  (+0.0%)       -2 B  (-0.0%)
import-flow                               +27 B  (+0.0%)       -1 B  (-0.0%)
hosted-site-migration-flow                +27 B  (+0.0%)       -2 B  (-0.0%)
free-post-setup-flow                      +27 B  (+0.0%)       +0 B
entrepreneur-flow                         +27 B  (+0.0%)       -1 B  (-0.0%)
design-first-flow                         +27 B  (+0.1%)      +11 B  (+0.2%)
connect-domain                            +27 B  (+0.1%)       +9 B  (+0.1%)
assembler-first-flow                      +27 B  (+0.0%)       +0 B
ai-assembler-flow                         +27 B  (+0.0%)       +0 B
hosting                                   +13 B  (+0.0%)      -18 B  (-0.0%)

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

Async-loaded Components (~4995 bytes added 📈 [gzipped])

name                                             parsed_size           gzip_size
async-load-signup-steps-plans-theme-preselected      +7799 B  (+2.0%)    +2973 B  (+2.3%)
async-load-signup-steps-plans                        +7799 B  (+2.0%)    +2973 B  (+2.4%)
async-load-calypso-my-sites-checkout-modal            -103 B  (-0.0%)     -544 B  (-0.2%)
async-load-calypso-blocks-editor-checkout-modal       -103 B  (-0.0%)     -571 B  (-0.2%)
async-load-signup-steps-design-picker                  -81 B  (-0.1%)      -25 B  (-0.1%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

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.

@jeyip
Copy link
Contributor

jeyip commented Nov 12, 2024

This PR is on pause until further discussion about technical implementation is resolved in p9Jlb4-e5j-p2#comment-14161

@chriskmnds chriskmnds force-pushed the update/plans-grid-longer-term-default branch from a0abfcc to 009f03e Compare November 19, 2024 08:39
@chriskmnds chriskmnds changed the base branch from trunk to update/plans-grid-term-savings-price-display November 19, 2024 08:40
const useLongerPlanTermDefaultExperiment = (): {
isLoadingExperiment: boolean;
term?: string | null;
// TODO: Consider removing this and always return concrete term values (where undefined/null would mean no term savings)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll study this a bit more. I want to make the "clean up" phase after the experiment as easy as possible, e.g., this hook remaining to define the default term/interval type.

@chriskmnds chriskmnds marked this pull request as ready for review November 20, 2024 15:19
@chriskmnds chriskmnds requested a review from jeyip November 20, 2024 15:24
@matticbot matticbot added the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Nov 20, 2024
@chriskmnds
Copy link
Contributor Author

@jeyip I think we are ready here to test. The experiment should be hooked to the logic. I still need to investigate something, but not blocking.

@jeyip
Copy link
Contributor

jeyip commented Nov 21, 2024

Wonderful! Thanks for your work here @chriskmnds. Will review this tomorrow morning.

@jeyip
Copy link
Contributor

jeyip commented Nov 22, 2024

Testing

Requirements

Used bookmarklets in 22092-explat-experiment to assign myself to different treatments and control

For each of the flows listed below:

  • ✅ Treatment 1: plans grid defaults to annual plans (and term in toggle) with savings emphasized on term yearly+
  • ✅ Treatment 2: plans grid defaults to 2-year plans (and term in toggle) with savings emphasized on term yearly+
  • ✅ Treatment 3: plans grid defaults to 3-year plans (and term in toggle) with savings emphasized on term yearly+
  • ❌ For control variant: plans grid defaults to annual plans (and term in toggle) with no savings emphasized
    • I'm still seeing the longer plan term savings emphasized in the header price. The bookmarklet was acting a little oddly though in that it wouldn't successfully assign at times, so it might be on my end. If you wouldn't mind trying the control variant assignment, we can confirm if it's a local issue for me.

Flows:

  • /start
  • /plans

Browsers

  • Chrome

Notes

I realized that the savings label is showing for the logged in spotlight plan. It can be handled in a separate PR. I believe that we can remove it in that case, but lemme know if you think otherwise.

Screenshot 2024-11-21 at 17 23 47

@chriskmnds
Copy link
Contributor Author

@jeyip control variation should be fixed now, if we can give it another round of testing. I guess we can also ship this if it tests out right?

concerning:

I realized that the savings label is showing for the logged in spotlight plan. It can be handled in a separate PR. I believe that we can remove it in that case, but lemme know if you think otherwise.

Shouldn't that be the case? i.e. show the savings if user is looking to upgrade from yearly to biennial (etc.)? 🤔

@matticbot
Copy link
Contributor

matticbot commented Nov 22, 2024

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

  • notifications

To test WordPress.com changes, run install-plugin.sh $pluginSlug update/plans-grid-longer-term-default on your sandbox.

@jeyip
Copy link
Contributor

jeyip commented Nov 22, 2024

@jeyip control variation should be fixed now, if we can give it another round of testing. I guess we can also ship this if it tests out right?

Yes will test again before I sign off today :)

@jeyip
Copy link
Contributor

jeyip commented Nov 22, 2024

Shouldn't that be the case? i.e. show the savings if user is looking to upgrade from yearly to biennial (etc.)? 🤔

Oh man that's silly of me 🤦 For some reason, I thought I was on the same term view as the current plan ( annual current plan in the annual view ) and missed the biennial upgrade CTA. Yes you're right we should show savings in that case.

@jeyip
Copy link
Contributor

jeyip commented Nov 25, 2024

For control variant: plans grid defaults to annual plans (and term in toggle) with no savings emphasized

I smoke tested the all treatments and the control again. Can confirm that everything works well now 🙂

isLoadingExperiment: isLoadingExperimentAssignment,
term: isLoadingExperimentAssignment ? undefined : term,
isEligibleForTermSavings: !! (
experimentAssignment?.variationName && experimentAssignment.variationName !== 'control'
Copy link
Contributor

@jeyip jeyip Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if I'm missing something, but if variationName returns null for the control, do we still check if experimentAssignment.variationName !== 'control' here?

Wouldn't just the experimentAssignment?.variationName check be enough?

Copy link
Contributor Author

@chriskmnds chriskmnds Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we still check if experimentAssignment.variationName !== 'control' here?

We don't (probably?). I kept it out of reaction for the most part. was a bit surprised how control is treated as a non-entity/null variation. Almost like a type-safe system is missing internally. I guess no harm in keeping the extra check?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kept it out of reaction for the most part. was a bit surprised how control is treated as a non-entity/null variation.

Sounds good 🙂

@chriskmnds chriskmnds force-pushed the update/plans-grid-term-savings-price-display branch from 021e5d8 to 67bd5de Compare November 25, 2024 09:14
@chriskmnds chriskmnds requested a review from a team as a code owner November 25, 2024 09:14
@chriskmnds chriskmnds requested a review from aneeshd16 November 25, 2024 09:14
Base automatically changed from update/plans-grid-term-savings-price-display to trunk November 25, 2024 09:38
@chriskmnds chriskmnds force-pushed the update/plans-grid-longer-term-default branch from 3090e5f to 32c9f83 Compare November 25, 2024 09:39
@chriskmnds chriskmnds merged commit 1f562c3 into trunk Nov 25, 2024
11 checks passed
@chriskmnds chriskmnds deleted the update/plans-grid-longer-term-default branch November 25, 2024 09:54
@github-actions github-actions bot removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants