posthog.com
posthog.com copied to clipboard
PostHog
Updating pricing page to match new a la carte pricing model
To match our updated billing system, our pricing is moving toward charging for bucket features (or groups of features). This wire splits our products into three:
- Product analytics + data stack
- Session recording
- Feature flags + experiments
Notable things:
- Headline/subtitle angles our billing as, "You get access to everything, but you don't have to use a paid feature (if you don't want to) by setting a billing limit"
- Proposing we remove the ability to directly sign up for Self-Host (Self-Serve) and Self-Host Enterprise. Get started would link to PostHog Cloud signup page, and from there, we'd offer a link to switch to self-host.
- Experiments has a callout that you just need to add a payment method to get access (until when/if we decide to allow a "free trial" of it
- Pricing calculator adds a # recordings slider, based off this pricing
Related: product-internal#355
cc @benjackwhite @jamesefhawkins @timgl @kappa90 @smallbrownbike @camerondeleone @simfish85
Looks slick to me!
- Agree with the billing limit angle although we need to make sure we actually have that up and running around the time we release this
- Definitely agree with removing linking to the License billing page for self host but it could make sense to have a separate button / notice for self-hosted ("Once deployed you can configure billing from within the app" or something to that effect).
- Regarding slider - tempted not to have it in the App as it introduces a lot of technical complexity when paired with the billing limit and other elements. But on the website I think it makes sense.
This doesn't work for me right now.
-
There's is so much information to digest here. Volume discounts + addons, different products, "*adding a card unlocks experimentation" etc. I don't feel like this communicates effectively what I'm getting.
-
The language contributes to this confusion. We have the Product OS, which is an all-in-one product, product analytics, but then session recording, feature flags etc. are also products in their own right.
-
The single CTA feels so divorced from the rest of the page. Also, I get we want to encourage Cloud vs self-host, but this feels like an extreme too far. If we can't put a CTA for self-host on the most important page on our website, why are we even supporting it anymore?
On the whole I'm 👍 - I like the sliders for calculating volume.
- Minor point - Enterprise should be 25% extra
- To @andyvan-ph's point maybe we need a callout of what extra you get for free just by entering your card rather than having it spread across a few different places?
Proposing we remove the ability to directly sign up for Self-Host (Self-Serve) and Self-Host Enterprise. Get started would link to PostHog Cloud signup page, and from there, we'd offer a link to switch to self-host.
The only issue I have with this is that we should make the signup flow leaner (it's already overcrowded and I want to remove stuff from there and move it post-signup, e.g. name, organization name, where did you hear about us).
I like that right now self-hosted is just a tiny footer option, doesn't divert you too much from the main choice (signup for cloud)
There's is so much information to digest here. Volume discounts + addons, different products, "*adding a card unlocks experimentation" etc. I don't feel like this communicates effectively what I'm getting.
I think we should just default assume people will put their cards in, this means we can remove the asterixes and this disclaimer, which would simplify things.
@kappa90 - this was a winning variant in a previous experiment we ran (I believe?) so I presume we'll have an onboarding flow that gets card details early.
On the "skip" card entry detail, in the signup flow, we should then say "you'll lose out on x, y, z features and only get x events"
We have the Product OS, which is an all-in-one product, product analytics, but then session recording, feature flags etc. are also products in their own right.
No - Product OS is a platform (the operating system), the products are as you say - analytics/session recording/feature flags (that you install into the operating system).
I think the above is worded appropriately. I can't tell if you are referring to positioning on this page specifically, or the overall concept on the homepage? (we are in a slightly fiddly period of trying to split out pricing etc like this, but it's not across every product, which I think makes this somewhat harder to articulate well on the website... that said we did test the homepage positioning change and it was neutral compared to the more product-analytics focussed messaging from before.
The single CTA feels so divorced from the rest of the page.
Valid concern, I think this approach is rational to test. Adding a bunch of extra CTAs will add to clutter but may improve conversion.
If we can't put a CTA for self-host on the most important page on our website, why are we even supporting it anymore?
There's extra context here...
The concept is we want people to choose "how" they use PostHog, once they've signed up. So this will become part of the flow into the product instead of adding it to the pricing page. Again, to reduce the complexity of the decision. All users need to do now is click that button. (ie you could make the same argument for cloud...)
Perhaps we should add small text under that button "Pricing is the same no matter how it is hosted", which would remove the "where is self hosted gone" concern though.
While I shouldn't be a blocker, I feel strongly that this is a step backwards.
- In terms of colours, my eye is drawn immediately to the large, dark block of sliders -- away from the desired CTA and straight to the most complex part of the page. In previous designs we've seen these sliders negatively impact conversion because people begin fiddling with them and don't progress further. Having two sliders will, I believe, have a similar impact at best.
- We know many users do not know how many events they will need to ingest and that removing this consideration from the pricing page helps conversion. Instead, we drive them to enter the product ASAP. Now we're asking people to know not only how many events they will ingest, but also how many sessions and what the difference/correlation between them may be.
- While I understand the OS/Products distinction @jamesefhawkins makes at a high-level, the use of the word 'Products' is confusing. Labelling features as products and foregrounding pricing makes me see Sessions/Analytics as distinct, discrete things I can buy separate from each other. I'd immediately ask: What if I only want analytics? Or sessions? If I only want sessions, can I use experiments as well? Do sessions include events and vice versa? How do I sign up for just one thing? None of these questions are answered and it leads away from the actual reality which is that you get everything in the OS, but pay based on usage only, and only above a threshold. They are not fully distinct products.
If I was a buyer, I'd really struggle with this pricing page. It would immediately raise concerns about how many events/sessions I'd need to use, how pricing for each compares to multiple tools in different verticals, which products I'd want, if I want to argue for discounts across different products, whether I need to add 20% for those Enterprise features, etc.
My feeling is that we need to flip the pricing process entirely. The first decision users should make is where/how they will host and our first priority should be getting them into the product as fast as possible.
No - Product OS is a platform (the operating system), the products are as you say - analytics/session recording/feature flags (that you install into the operating system).
My point is less about the homepage positioning than the fact the line between "the platform" and "the products" feels ill-defined. This wireframe doesn't communicate to me these are individual products in a platform, but features. Consequently the phrase "The Product OS suite ships with all products" just feels a bit jarring / confusing.
Although it's an earlier concept, I think the design from #355 communicates the distinction better because the Product OS is presented as its own entity that's required for all the other products to work.
The concept is we want people to choose "how" they use PostHog, once they've signed up. So this will become part of the flow into the product instead of adding it to the pricing page.
This makes sense, but the proposal was to send people to the Cloud signup page and then add a link for people who want to self host, which feels is a weird journey to send people on. If we're moving that decision into the onboarding flow, I think we should look at how that works / what it looks like at the same time as revising the pricing page.
@kappa90 - this was a winning variant in a previous experiment we ran (I believe?) so I presume we'll have an onboarding flow that gets card details early.
Yes, about 10-12% of people who go through the onboarding insert their card now
My point is less about the homepage positioning than the fact the line between "the platform" and "the products" feels ill-defined. This wireframe doesn't communicate to me these are individual products in a platform, but features. Consequently the phrase "The Product OS suite ships with all products" just feels a bit jarring / confusing.
What if we positioned our products similar to the AWS or Adobe ones? People understand that when entering AWS, they enter their card once, to get access to a bunch of different products, which are independent, but also can interact with each other (e.g. Cloudfront works on its own, or you can attach it to Route 53 and S3).
This would require a bit of change in how we communicate vs. now, but it fits the direction of PostHog as a OS, where you "install" different products (analytics, recordings, FF, apps), on top of the OS data stack. Rather than having one pricing page with all the different tiers at once, a change could be to isolate these as single products, with their own pricing. This also fits the idea of PostHog teams being small startups, each working on a separate product on top of the core stack.
What if we positioned our products similar to the AWS or Adobe ones? People understand that when entering AWS, they enter their card once, to get access to a bunch of different products, which are independent, but also can interact with each other (e.g. Cloudfront works on its own, or you can attach it to Route 53 and S3).
This resonates with me and the AWS example specifically – I vaguely recall @jamesefhawkins using AWS as an example to me before. As James pointed out, the fact we're in a transition period makes it harder.
I think the earlier design conveys that positioning better, but maybe there's something to Joe's point that this is actually something you deal with AFTER you've created an account? I don't have a strong view on that yet.
Yeah, my feeling is that they can try all of this stuff for free -- and we, as a product-led company, trust that the product is strong enough to make them want to pay. So, put complex pricing questions at the start is the wrong thing to do, especially when the product is free to get started with to a generous level.
The only thing we should ask users to consider before they start making an account are the things they actually need to consider before they make an account because they will make tangible differences - e.g., hosting.
One nit (there are enough people giving feedback otherwise!) - I thought the icon for Feature flags + experiments was an actual toggle and was trying to figure out what that would mean, so maybe something else there (flags? test tubes??)
