[msencenb]

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.

[0xferruccio]

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!

[Androider]

"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.