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