[jroseattle]

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

Thanks for listening!

[0xferruccio]

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

[Terretta]

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

[0xferruccio]

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