Launch HN: June (YC W21) – Product Analytics for B2B SaaS Companies
After a year of building our product we tried to monetise and failed. Our free users weren’t willing to pay us money for individual reports.
Among the users we had, there were a handful of later stage B2B companies with few customers but a lot of revenue (one had 50 customers and $1m in annual revenue). These companies looked at their analytics in a different way. They cared a lot more about specific individual users than consumer apps do, and they spent a lot of time using our product.
After learning this we spent some time trying to understand the differences between product analytics for a B2C product versus a B2B one. We learned three main things that led us to pivot our company into building a product analytics tool for B2B SaaS companies:
(1) Most of the revenue in B2B products comes from a handful of customers. In Slack’s case, 500 customers out of 700,000 made up to 40% of revenue[1]! (2) Most of the revenue B2B products make comes from expansion. Contracts start small and grow over time, as a company wins more trust and delivers value. This means that growing product usage among existing users, over time, draws in more users and more revenue. (3) Product management in B2B is a lot less quantitative than in B2C. It is more a collaboration with Sales and Customer Success teams. The kind of insights you need from analytics are different. You need to know “Are our key customers adopting the new feature we launched?” and not “Does our new redesign improve activation by 2%?”
After learning these things we went back to the drawing board and rebuilt our product with them in mind. That is, we built a product analytics tool that (1) has automatically set up reports that allow you to track acquisition, activation, retention and feature usage; (2) supports measuring metrics both in terms of how many users or companies use your product; and (3) helps you answer common questions for your users like “Who used our product the most in the last 90 days?”, “Who tried our new feature once and never came back?”, “What’s our feature with the highest retention? How many people use it?”
This realization happened a year ago and we’ve now reached the point where more than a thousand B2B SaaS companies at seed and Series A use us every month.
We would love to get some feedback from the broader HN community! You can find our product at: https://june.so
[1] https://www.fool.com/investing/2019/04/29/slack-relies-heavi...
50 comments
[ 3.0 ms ] story [ 89.4 ms ] threadMy co-founder Enzo (the CEO) came up with the name because when starting out the feeling we had was that most analytics products felt cold and intimidating and our goal was to build something that feels warm and welcoming - like June
We already have https://july.so
Great product though! Will be following y’all’s progress!
You product feels very lightweight.
One of the problem we have in my current startup is that we have multi-tenant customers, different deployment methods - on-prem/managed etc. Platforms like amplitude, do not cater to these types of models. So, instead we built our own datawarehouse+metabase setup that gives us very granular control, reliability and assurance over the data, as well as we built lot of custom metrics.
Would love you hear your thoughts.
> When you have simple SaaS platform, a platform like amplitude or mixpanel is generally enough capture these metrics. You can create these funnels in that product. The level of customization in these tools is pretty good too.
It's true that you can create most of the features in June in Mixpanel or Amplitude. Setting up June as a small company though will take a lot less time and give you out of the box the most important things that you should be looking at.
As an example here's an email from one of our users: https://imgur.com/a/UO1ZPOZ
> You can start with a basic tool, but everyone eventually moves to an advance product like amplitude or mix-panel for SaaS.
Interestingly we see the opposite, most of our paying customers were Mixpanel or Amplitude users that weren't using those tools that much because of the effort involved to get some valuable information, preferring a simpler product for a shorter time to value
The way we see it is that in the long run - as we develop our product more and more, companies will have something like June for any use case that is not unique to their business (like launching a new feature, activating users, see how your biggest customer uses your product etc..) and a data warehouse with a BI tool for every analysis that is unique and only relevant to your specific business.
That being said right now we see that companies from the Series B stage onwards graduate out of using June and that's totally fine for us for now. You can read more about our approach to building our product here (https://www.june.so/blog/reaching-product-market-fit)
> One of the problem we have in my current startup is that we have multi-tenant customers, different deployment methods - on-prem/managed etc. Platforms like amplitude, do not cater to these types of models. So, instead we built our own datawarehouse+metabase setup that gives us very granular control, reliability and assurance over the data, as well as we built lot of custom metrics.
One of the things we're built for is that for every event you send you can specify what tenant performed that action and every report works both at a user level and at a company level. (see: https://help.june.so/en/articles/6789004-how-to-track-compan...) For other tools company tracking is an add-on to the core product, for us it's the core.
So not only you know how many users use your product, but you can look at the behaviour of individual tenants for every metric you're looking at. Additionally for every tenant we automatically generate reports for that specific company, so when your Customer Success or Sales people hop on a call with customers they have answers to questions like "how much are they using our product?", "who are their top users?" and "have they started using all of our core features?"
It's a long answer, but hope it addresses some of your doubts :)
Posthog's value prop is that it's all-in-one, it's open-source and it's built for engineers.
Additionally, in my experience when a company wants to self-host their analytics June, Amplitude or Mixpanel aren't even considered as an option and Posthog is the go-to tool.
As much as our products cover similar use cases, in the day to day we don't really see much overlap in terms of target customers
The thing that stopped me was that there was no way to track an event to only a company, it still had to be tied to a user with the identify call. Our most important metrics ($ processed per company) is not based on a user at all. I wish June let you do company only event tracking - I would have had to hack in a fake user to track against.
Lots of our other metrics are per user, so we did like that it was possible to tie it to users-just surprising that an analytics company focused on org level analytics required it.
Also on the wishlist - hubspot integration. I’ve been evaluating Hightouch to punch data from my app to hubspot and it’s probably going to work, but take more effort than I was hoping for.
Best of luck!
> The thing that stopped me was that there was no way to track an event to only a company, it still had to be tied to a user with the identify call.
I'm not sure why this is completely blocking you, we have plenty of customers that just create a user with user_id "system" to track actions that aren't tied into a specific user in a company.
There isn't really any drawback to that approach as you can filter out the system user from every analysis that doesn't want to include them! Happy to support you on the implementation or answer any further doubts in our Intercom conversation thread :)
> Also on the wishlist - hubspot integration. I’ve been evaluating Hightouch to punch data from my app to hubspot and it’s probably going to work, but take more effort than I was hoping for.
We do have a June to Hubspot integration, and will be building a deeper integration in the next months (that being said it's not part of our free plan)
Anyways thanks for the feedback and hope to see you come back in the future
I'll try to add some context around this for my use case: we need to track items at various levels within an organization. Company, division, team, user -- and that's flexibility I need by customer. These are contextual interactions with our customers, and we're not always interacting with actual users.
> There isn't really any drawback to that approach as you can filter out the system user from every analysis
There is a drawback for us. Forcing everything to a "system" user means we have to manipulate and skew how our customers interact with us to map into this product analytics product. This is important to us because we don't want everything to boil down to a user, even if it's just a "system" account.
This might not be so important with your other customers, so your mileage may vary.
Thanks for listening!
> There is a drawback for us. Forcing everything to a "system" user means we have to manipulate and skew how our customers interact with us to map into this product analytics product. This is important to us because we don't want everything to boil down to a user, even if it's just a "system" account.
I'm not sure I understand the end user impact between how your customers use your product and how you model the things you measure.
If you analyse your data only at a company level it doesn't really matter that the user in the company that you're assigning an action to is called "system". The only things that matter are the dimensions you use to analyse your data - and if in your event data there's a field you use like the "group_id" of the entity you're analysing and a field for a "user_id" called "system" that you ignore.
The only thing we force you to do is structure information as an event stream with timestamps!
That being said if you have a product with multiple levels of grouping like "Company, division, team" you wouldn't be able to attach one action to all three, you'd just be able to assign it one by one (and probably would have to send an event for each)
Again happy to support on a 1:1 basis if that helps
This feels like a case where you could be more open minded to users' "job to be done" and less reliant on the "you can just..." trope from engineers over-familiar with a pet tech.
While I appreciate you got to "let's jump on a call", the "I'm not sure I understand" plays like engineering speak for "you're doing it wrong".
I've found, in general, users never do it wrong, rather, product owners fail to accept their product is not being used for the job they think.
Users have a need, users try to make a need-adjacent product fit the need -- but it doesn't. Teaching the users a lesson in using the product doesn't actually resolve the need.
(This is similar to the rare insight that requiring user training before using the product is a sign of both a poor user experience and a need/feature mismatch. The more marketed and "required" the training, the less well-suited the product.)
The let's jump on the call is genuinely to understand what the job to be done is, whether it's something we should cover or not and see if the problem is an education gap in our documentation or a product gap in our offering.
If we're not the right product to serve those specific needs we'd point to the best alternative we know of
> I'm not sure why this is completely blocking you, we have plenty of customers that just create a user with user_id "system" to track actions that aren't tied into a specific user in a company.
It was never a technical problem, but a cognitive dissonance between the marketing and implementation details. I'll do my best to narrate my internal dialogue as a potential buyer.
I come to the homepage and am intrigued by the words "focused on companies"—because that is absolutely what I want! I want company level metrics (sports teams in my case) to be the first class citizen. I actually do not care about user identification at all. There are a ton of products that already do that I can pick if I want. I assumed you might be able to drill down into user level metrics eventually, but I thought our v1 would not identify users at all.
Jumping over to the docs, I head to the tracking behavior section for companies. The user_id param being required does not fit with my idea of what June is at this point. Why would I need to identify a user, if this analytics is focused on companies?
To me, this data model suggests that this is a traditional analytics product that treats user + user events as first class, then rolls that up to do clever things at the analysis level for companies. I had expected company events to be the first class citizen and for the events to flow top down from there. Now I'm concerned that when I stick in a 'team' user_id the data is going to be muddied, because the product won't know that this hacked in ID is just a generic company thing. Does that mean my user based analytics are going to be off? What does that imply for the data/reports downstream?
> There isn't really any drawback to that approach as you can filter out the system user from every analysis that doesn't want to include them! Happy to support you on the implementation or answer any further doubts in our Intercom conversation thread :)
This comment highlights what I mean. If you are an analytics company focused on tracking companies, I expected it to just work that way out of the box. If I need to remember to filter out this user from a bunch of metrics or analyses, I am bound to forget at some point or bring on a teammate who doesn't know.
Anyways, thanks again for the reply and hope the feedback is helpful.
I appreciate the feedback here on the user/company focus. That being said I think that as our focus is to help you understand how companies use your product it's actually essential to also track users.
A lot of our customers use June to understand who are the internal champions within a company - at what stage of activation each user within a company is etc...
In the end companies are groups of people and most of the time you really want to make sure that multiple users within the companies that use your product are active. And without tracking users you can't really do that!
If you're "focused on companies", just add a company level event/metric API even if it's all sugar and you internally model it with user IDs or whatever. I don't think anyone is saying tracking user events isn't important, it obviously is, just that in addition you should introduce company events to truly differentiate yourself from the "ordinary" analytics providers.
* B2B SaaS is a lot more qual. than B2C (We also sell to B2B SaaS[1] and this squares with what we've seen). You don't need to cater to all the scenarios that Amplitude or Mixpanel or Heap cater to which narrows the scope of what to ask of users (and what you need to build!)
* Honing in on SaaS means you can offer canned AARRR reports and key feature usage reports out of the box which massively accelerates that.
* Pulling metrics from where they already live and transforming them into immediately useful data for PMs. CDPs like Segment enable that but you could even de-risk customer migration to June by pulling data from Mix or Amplitude
Congrats on hitting 1k customers. Looking forward to seeing where you go next.
1 - https://www.savio.io
I’m also a heavy user of Amplitude and I see how June solves many of my common use cases in a more usable way.
Probably for me it doesn’t make a huge difference, and I still do deep analysis at my dwh or amplitude. But for the rest of the org, that is less data oriented, I found that June increases their data driven mindset just by making it easier to understand and use.
That’s what good UX is for.
We have a retention report which works for both users and companies and allows you to quickly spin up retention cohorts
Would you consider adopting the STARS framework[1] ? It was designed to solve the questions you mentioned like “Are our key customers adopting the new feature we launched?” but at the same time it also incorporates qualitative feedback.
[1] http://starsframework.org/
Full disclosure: I helped design it.
The main thing I'd look for is whether:
- Do you know if your customers or businesses use the new features you build? - Do your teammates understand what's happening inside of your product? - Is it easy for you to know who your best users are? - Can your customer success quickly get a sense of the health of an account?
If there are problems in your company that could be solved by an easier to use analytics tool that more people could use more often it might be worth it!
It'd be great to catch up sometime.
It'd be nice to meet, we really admire what you've been able to do at Amplitude helping establish the product analytics category
[1]: https://www.june.so/blog/june-vs-pendo
The two products are quite different, one a web-based and more of an aid, where retention and such metrics make sense. Here we've experienced companies replacing the sole person using our application, the new hire doesn't get taught about our tool or forgets, and suddenly they're wondering about these bills they're getting. We've got multiple companies where we've successfully sold our product to several times.
The other is a more traditional CRUD application, which users have to use to get their job done. As such retention and similar isn't a very relevant metric. However it has a large number of modules, and a lot of new functionality in each release, so feature tracking is more interesting. Perhaps failure/error tracking too, like how many manage to trigger certain errors and warnings, indicating a potential weak UI.
I mean the main screenshot shows a "Features" panel, but we have several hundred features we'd like to track, maybe thousands depending on how we can filter on event properties. We have quite a lot of core modules, almost all of which are per-country, so we need to be able to look at module usage per country for example. In addition a large portion of our customers have one or more custom integrations (some have over a dozen, again per-country in relevant countries). I wasn't able to see if we'd get the insight we need for this use-case.
In either case we're quite worried about PII, and while it's nice you got GDPR covered, I think we don't want any PII connected to our users. It's interesting to know how many users use a feature at a given company, but we don't really want to know who that is. From what I can gather that should be OK, just use some UUID for each user and leave it at that?
Perhaps these are dumb questions, product analytics isn't my forte and as mentioned we're just exploring the options at the moment, so don't have any direct experience yet.
That said, June does look really interesting. Especially since we don't have anyone who can dedicate a lot of time to this task.
You can use June without sending us PII some of our users do it. That being said most of our customers send PII to June as it really helps in the day to day to be able to look up a customer and get a quick glance of their usage
For features you can indeed create hundreds of them - we have pretty good filtering for the features, so you'd be able to rank them by usage, retention or even launch date.
Let me know if you do sign up, I'd love to make sure you get the most out of our product
1. The first thing I check is the Pricing page — and the pricing is reasonable. Ok there.
2. The second thing I need to know is where the data goes and do I need to load external JavaScript libraries from somewhere. I probably do, but I can't be sure, because your quick start guide doesn't say much if I'm not registered logged in, which I can't be bothered to do.
I am guessing the answer to (2) is that I need to load a third-party JavaScript library and send the data somewhere. If that's true, I won't use your product, even though otherwise it's something I really need.
I would use a product that would let me instrument my code, gather data on my servers, and analyze it without sharing it.
That being said I don't think using 3rd party vendors is a problem for most companies as it's far better to let someone else manage security updates, availability etc..
As long as you make sure there are good security measures in place. We undergo yearly external pen tests by a CREST accredited firm, and have an active SOC2 Type II program. For GDPR requirements we also sign Data Processing Agreements with most of our customers.
I think for most companies we guarantee better safeguard of your customer data then self hosting something in a docker container.
That is where I will respectfully disagree, having seen many companies do a lot of hand-waving (and acronym-throwing) and have abysmal practices underneath. There is no way for me to verify that. And I really do not want to have to explain to my customers that I'm sending data about their activities to an external business.
I'll stick to my own data gathering solution for now, I guess.
Really appreciate your feedback
Both Amplitude / Mixpanel have pretty easy interfaces for building custom reports. If you are a profitable scaled SaaS the integrations available and the customizability + add-on product portfolios like schema management as you grow make it real hard to compete.
I would love to understand if you are building for a different segment of users here or tackling some use-cases and have a different POV which is not captured yet by these tools.
The main difference at this stage is our complete focus on B2B SaaS and the user experience.
We write and keep up to date some comparisons with alternatives on our site: https://www.june.so/blog/june-vs-mixpanel
Just signed up for June -- looking to see how the platform reacts as my events flow to June from Segment.