I heavily considered June recently for my b2b saas (they even offered my tiny bootstrapped startup a small discount for the first year, which I appreciate very much).
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.
> 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
> 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
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.
If you're up for it I'm happy to hop on a call to understand a bit more your use case as I'm not sure I understand correctly. (email met at my first name @june.so)
> 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
Reading through this conversation worries me about adopting the product -- will it meet B2B needs, or will it do what it was conceived to?
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.)
Didn't want to sound dismissive here, English isn't my first language so maybe I didn't express myself in the right way.
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
Thanks for the reply. We do plan on taking another pass at analytics in July or August. I'll give the system user_id a try, it's entirely possible that will work for us and I have simply not gotten to an aha moment yet with the product (we are starting from scratch, so no segment data to import).
> 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.
Hey Matt thanks for the follow up explaining here!
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!
"Just remember to filter out special user IDs x, y, z, they're actually companies" is exactly the type of problems that when you solve will make the customer go "oh, this maps _exactly_ how I think about company events/metrics".
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.
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!