Improve Blocked Lesson CTA

[laurosilvacom]

This is our current Blocked Lesson CTA:

Goal

The objective is to increase New Paid Subscribers. We can do this in two ways.

1. Decrease the free lesson threshold to 2 lessons. Currently, it is set to 7 lessons. The objective is to increase the number of users that are presented with the Blocked Lesson CTA.

2. Once on the Lesson CTA. The learner should be presented with a compelling offering. We can do this by presenting a custom Checkout Widget on the Lesson Overlay as the CTA. Adding a custom Checkout Widget removes one additional step from the funnel and benefits from the high traffic on the lesson level.

UI Implementation

• All design assets are available in Figma.

• If the user is watching a course, we can assume that they are probably not a manager but an individual and would likely only need one subscription. Monthly subscriptions are our most popular pricing tier, so presenting them with this single option makes sense.

• We'll be able to upsell them on the yearly plan in the Stripe Checkout session. This still needs to be enabled.

• We can also give them the option to explore further pricing options by redirecting them to the pricing page.

• PPP will soon be available on egghead, so we should consider how that fits into the overall design.

Overlay view:

Mobile view:

Technical Implementation

• We can re-use the checkout button and the Hook that pulls the pricing data from the original Checkout Widget.

• It is important to note that an email step in the checkout is needed to see if they have an account already for a given address. Currently, it’s full-page, but I don’t think that is necessary, meaning it could just be a “wizard,” which is true for /pricing.

• Josh recently implemented “pay and play” and that’d be interesting here where the stripe return URL is to the specific lesson, so the “verify purchase” step would be in the video frame as well and give them near “instant” access. Note: “pay and play” gives you an access token for 30 days based on your stripe checkout session ID and successful payment.

• Besides the Checkout Button, the Hook the pulls pricing data, and the email validation widget, the rest is static data.

Non-Goals

• Tracking course progress for anon users and syncing it when they login/buy.
• Refactoring the Checkout Widget that’s used on the pricing page.
• Presenting multiple pricing options on the Lesson CTA overlay.

Potential Blockers

• PPP on egghead is still not implemented. Can this present a potential blocker? Is this something that can be worked on after PPP on egghead is implemented?
• The step that validates email in the checkout session needs to be a Widget. How can we present the email validation widget once the user clicks on the checkout button?

Research

• This document outlines further research that's driving this pitch.

[joelhooks]

https://postmarkapp.com/rebound

[jbranchaud]

Technical Implementation

• We can re-use the checkout button and the Hook that pulls the pricing data from the original Checkout Widget.

The commerce XState machine I've been working on for the PPP implementation may be an even better fit here, for pulling in the pricing data. That will also make it pretty seamless to include the PPP checkbox.

• It is important to note that an email step in the checkout is needed to see if they have an account already for a given address. Currently, it’s full-page, but I don’t think that is necessary, meaning it could just be a “wizard,” which is true for /pricing.

This is implemented as a full page transition right now (on /pricing). A wizard for capturing the email makes a lot of sense. I think we could incorporate that into this new commerce machine.

• Josh recently implemented “pay and play” and that’d be interesting here where the stripe return URL is to the specific lesson, so the “verify purchase” step would be in the video frame as well and give them near “instant” access. Note: “pay and play” gives you an access token for 30 days based on your stripe checkout session ID and successful payment.

We should be able to drop them on whatever page when Stripe checkout is complete. I don't remember exactly how that works, but I remember there is some mechanism already in place for that.

Re: 30 day expiration on those tokens. I thought it was 24-hours. I just double checked and there isn't an expiration being attached to them. I'll go in and add an expiration. I like 24-hours because it is enough to get started while still making them sign in / verify their email within a day of signing up. Versus pushing that out to a month. Thoughts?

• Besides the Checkout Button, the Hook the pulls pricing data, and the email validation widget, the rest is static data.

👍