UI/UX for paid features

[paolodamico]

As we start to introduce more paid features (see https://github.com/PostHog/company-internal/issues/417), we'll need to have a clear UX for how to show these, including clarification on whether a feature is paid, any upselling, etc. One tricky thing we should consider is when only partial functionality is paid (e.g. wildcarding in Paths). The goal of this issue is to define some base UI/UX.

[paolodamico]

Comment from @clarkus on linked issue,

Depending on the goals for each case, we can tackle this a couple different ways. Much like an empty or blank state, we can use pay gates to gate access to a feature while still promoting it in a non-intrusive way. Placement depends on scope - is an entire feature being gated, a portion of a feature, or some other special case (feature flag maybe?).

• Page level pay gates - something that blocks an entire page / feature with an empty content state targeted at promoting upgrades or free trials - this is very much targeted at pushing upgrades.
• Inline replacements - in places where we would usually display the paid feature, we can display a succinct version of the page level pay gate. Depending on how prominent the gate needs to be, we could even make them dismissible for users who don't plan on ever using the feature.
• Other workflows - depending on the volume of users affected, this is a case where other tools can fill gaps in product. Email is a powerful tool for communicating complex thing to a targeted audience, so that might be something that can inform people of something new without being too disruptive to the daily work that happens in the product.

Let me know if you want to discuss which features exactly to make paid, we need to be very careful not to have any "regressions".

If we can get a list of scenarios together, I can put together quick examples to help facilitate discussion. I have capacity for this anytime. 👍

[paolodamico]

Re @clarkus,

What we currently have:

• Paid gate modals (see below).

What's coming:

• Functionality-level restrictions (e.g. wildcarding in Paths, link between Funnels & Paths). FYI, particularly this would block us from including the new Paths functionality in the release.
• Feature-level restrictions (in page). For instance, correlation analysis which shows up in funnels, wouldn't show up for free users.

Other:

• We have other functionality (such as event/property taxonomy) that currently is just not shown if you're on a free plan.

I think we could have a custom icon to indicate something is paid/premium (e.g. ⚡️) and then some light copy explaining the benefits of the feature and then relevant links to docs for that feature and to upgrade.

[clarkus]

Being super tactical here - is the immediate goal to communicate a lack of access, or are we actively upselling to encourage users to try new features? The patterns we use will change based on intent. Is there a broader strategy around how we encourage upgrades? How and where are we demonstrating improved features so that users can make an informed decision about upgrades?

The structure I mentioned in my previous comment is a start towards a partial solution, but there are other areas where we could go into greater detail on what each tier supports, restrictions, etc. As an example, our billing page is currently super sparse and redirects to stripe for management. We could go into much greater detail there to clarify offerings and restrictions. We can indicate restrictions in the UI with iconography and such, but we'll get compounding value when we have a layered approach to communicating restrictions / promoting upgrades.

To be clear, I'm not blocked on this work, but I think the initial changes could be much more long-lived if we have some strategy to pursue here. I am also being a bit more cautious than usual because this is a huge area of trust with users - I don't want to jump into any solutions before we have a bit more of the problem set.

[timgl]

Functionality-level restrictions (e.g. wildcarding in Paths, link between Funnels & Paths). FYI, particularly this would block us from including the new Paths functionality in the release.

For these I think just greying out the element with a tooltip that explains that this is a paid feature and how to upgrade would probably do for now?

[corywatilo]

I think @clarkus's reservation is wanting to make sure we're showing enough value to non-upgraded accounts so the entire app doesn't start to feel like shareware - essentially a giant promo to upgrade to a paid plan, like many free mobile apps.

One idea: intent-based messages instead of disabled icons

Some fictional examples in this wireframe to spur other ideas, but demonstrating how a text-based message that is relevant to the account (based on volume). (If your volume is under "50k/mo" for example, certain features just won't be as useful, so we maybe shouldn't bombard with disabled buttons which are more likely to aggravate technical people instead of encourage them to upgrade, especially if they're not a good candidate for it.) On Cloud, we could even use Clearbit data to enrich our data about a customer.

Obviously this doesn't work for everything, as there will be plenty of features useful to free customers, but if we can expand our thinking from upselling a feature to upselling benefits in another package based on lifecycle, it could be more relevant and less visually annoying to users.

[clarkus]

I put together some rough ideas in figma at https://www.figma.com/file/gQBj9YnNgD8YW4nBwCVLZf/PostHog-App?node-id=4262%3A36980. I'm mostly looking to clarify the problem we have short term, but also get us thinking more about a long term strategy with payment gates and upselling features. These flows can become really complicated and very limiting depending on how we approach this. Feel free to add feedback in figma if you have any.

[paolodamico]

Made two quick proposals in Figma (from @clarkus's designs) that are quite aligned with @corywatilo's point and seem faster to implement as to not block the release. I also wanted to this a ton less "sales-y" to avoid alienating users, and in any case we can give this upsells more thought and experiment with them.

Option A

Option B

Particularly for Paths (which is the blocker today), I was thinking we could have something like Option A in the insight builder (talking about advanced options) that can be dismissed permanently and hide the other options for now (view funnel, paths to funnels, ....), we can reevaluate more calmly after the release if we want to do the disabled options thing or not.

@EDsCODE / @timgl I assume start, end points and excluding path items we want to keep free? They seem to overlap with existing functionality.

[clarkus]

I also wanted to this a ton less "sales-y" to avoid alienating users, and in any case we can give this upsells more thought and experiment with them.

I'd challenge this as an assumption that needs validation. I think matching too closely to functional UI will make some things harder to spot and understand that we're trying to sell features. This gets to my points about having more strategy and a planned approach for this stuff. Either option will probably work short term, but having a solid strategy and problem definition here will help us speed up shipping this kind of content in the future in a consistent way.

Editing to clarify my intent - I think any of these options will get us to shipping shorter term. Longer term, selling stuff is an area that is fundamentally alienating to some users - they're just never going to like disruption in this form. I mostly want us to strike the right balance of noticeable, motivational, and actionable. Let's present the best short-form content we can using an approachable style and aim to make the least disruptive as possible. If the scope of this issue is just short-term paths upsells, I think we can create a follow up issue to figure out the broader strategy for upsells. 🙌

[paolodamico]

100% agreed @clarkus! Basically I just want us to get to something that we're comfortable deciding right away and shipping in the release tomorrow, and we can discuss longer term strategy with the Growth Team as well (@kpthatsme) to indeed strike the right balance you suggest.

@EDsCODE any thoughts on taking any of the proposed approaches so we can ship tomorrow?

[corywatilo]

My only request would be: if we're adding banners/callouts, consider the option to make them dismissible on the user level. (Once I know they're there, I don't need to be bombarded with them every time I use the app.) We can remind them in other channels (emails, the key contact of the account, etc).

[clarkus]

My only request would be: if we're adding banners/callouts, consider the option to make them dismissible on the user level.

Agreed. I feel like making them always dismissible is a good default. I think the only exception is if we get to any page level gates that we might always expose for discoverability purposes.

[kpthatsme]

I think this is one of those topics that probably warrants a quick sync discussion around strategy before tactics...especially around cloud/enterprise/scale's groupings. In terms of making a quick decision for what we ship for a release tomorrow, @paolodamico I like your option B.

[posthog-bot]

This issue hasn't seen activity in two years! If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.

[posthog-bot]

This issue was closed due to lack of activity. Feel free to reopen if it's still relevant.