Basic taxonomy on events & properties

[paolodamico]

Is your feature request related to a problem?

If I work in a larger team or have a ton of events/properties, it can be hard to keep track of what each event and property is. It's only natural I'd use PostHog as the source of truth for this.

Describe the solution you'd like

I'd like to be able to add descriptions (and potentially tag) events & properties to easily identify them. We need to figure out first if this is the best way to support taxonomy (from experiment with dashboards).

This is just a concept, we need to dive a little bit more before building this.

Additional context

• Related to Extend information on actions page #4265.
• Requested by a focus customer (cus_IViwMhqr5dnHPa).
• This would be a premium collaboration feature.
• This is just a basic step on taxonomy. We could later expand it to define expected properties and property types and recognize anomalies to help drive data quality (see Taxonomy #3228 for more details).

Thank you for your feature request – we love each and every one!

[paolodamico]

Worked on some mockups to work out the UX here. Looking for feedback. One point in particular that's still causing me some issues is on what to do about properties. The problem is that most of the time properties will only make sense to be defined in the scope of an event (i.e. just duplicating events behavior for properties wouldn't make much sense). This however requires implementing full taxonomy on events too. Any thoughts?

Events List

1. As this is a premium feature. For now we would hide the description & tagging options if the user doesn't have a valid license. We could consider some upselling here at a later stage.
2. If the instance has no support for event stats, we could simply hide the columns and just keep the relevant warning.
3. We would allow users to preemptively add an event before it's actually ingested.

Event Details

Event Picker

Action Picker

4. Unsure whether we should remove showing the match groups here. While I think having this information could be quite useful, I believe the way we show it today can be confusing.
5. Description and tagging is implemented for actions too.

@corywatilo @liyiy @jamesefhawkins @EDsCODE

[macobo]

Re taxonomy, one product which does this is https://www.amundsen.io/ - worth taking a look, perhaps there's worthwhile ideas to share from it. :)

Personally things like owner, frequent users, property schema per event with examples (!), date range all seem like worthwhile things.

[andrewm4894]

I love the events mockups.

We actually find that we have a lot of overlaps for properties across multiple events. So for us it would make sense to just have a flat hierarchy of event properties and then maybe even let the "link" between events and event properties be made by posthog itself based on what it sees on a sample of recent events.

For example i will probably just go in and add descriptions to the top N event properties that really need them. And then posthog could tell me what events these event properties are found in.

So i don't even have to maintain the relationships somewhere explicitly (which will be overhead for me) - posthog will just see what properties are in what events and surface that to me in some way if deemed useful.

[andrewm4894]

one last idea - being able to publish or share this publicly could be useful too. So some way to either publish some events or properties such that they could be shared with users or the public to say - "look this is all the events and what's in them that we capture about you when you use our system".

Might be a bit of a distraction for now but was thinking being able to use all this in some way as part of your own documentation and disclosure could be useful for some too.

[paolodamico]

Thanks for the thoughtful feedback @andrewm4894 & @macobo, I've incorporated your input and updated the mockups (latest version on Figma). CC @liyiy

Event Picker & Action Picker

1. Kept the same as above.

Events List

2. We add the concept of an owner to each event. This way a fellow teammate can have some guidance on who to contact about something.
3. Design now shows hover popover on properties. When clicking a property, we open the property drawer in the same page.

Event Details

4. Make drawer's space wider and change the layout to make better use of space.
5. We now show the top properties for this event, plus allow editing description and tags inline. Clicking a property opens the respective drawer (if possible, otherwise we may open the property in a separate tab).
6. We now also show the most recent 10-20 events so that you can get a quick look at event examples (ideally clicking an event would open the event drawer which we haven't introduced yet).
7. Each section can be collapsed for easy navigation.

Properties

8. We follow almost the same behavior for properties too.
9. We drop the owner concept from properties because the mental model is somewhat confusing for properties.
10. The details page won't have the properties section.
11. The recent section must include the event name column.

[andrewm4894]

looks great.

for the properties within the event it could be useful to be able to see for what % of sampled events each property was present on. just might help you quickly debug or spot if you see that say only 5% of the events have a specific property then that might be something i'd need to check on for example. not sure if this might be expensive to compute or not but think it could be handy to have in the popup table for the event properties.

[paolodamico]

Thanks @andrewm4894! Makes sense, that sounds indeed quite helpful. I'll leave this to @liyiy to see if it's feasible to be done in the first iteration of this, or if we need to consider it as an improvement.

[liyiy]

Did not mean to close this issue by linking it to that PR lol, reopening it

[clarkus]

@paolodamico I took a stab at exposing some of the taxonomy in an updated concept for picking actions and events. This doesn't capture the full detail you have, but I think it could be enough to make each option more identifiable, while still functioning within the context of other workflows (authoring funnel steps for example). It takes the current picker and organizes options into category tabs. This would enable a user to use a keyword search within a single category.

In this concept I am trying to balance describing options in sufficient detail for the current context, while allowing a user to view more event/action details in a secondary context. This all happens in the context of picking an option, so we still need to optimize for that task as well. Thoughts?

[samwinslow]

@clarkus I love this! It brings together the best aspects of the old/more compact dropdown and the new, SelectBox-based dropdown below:

I like that we might re-introduce the tabbed layout, because if a user has a lot of properties, the above design makes the user scroll to see all the categories.

[paolodamico]

❤️ it! Some thoughts:

1. While the description blurb can be enough most of the times, there will be cases where I'll want to see the entire description and details. How would this look? Fwiw, I think it needs to be super simple, if it makes me open a separate tab or even a separate view it would IMO introduce some mental strain.
2. Events can have descriptions and tags too. Of particular consideration is PostHog events (e.g. "Pageview" / "Autocapture") that have their own built-in description which we set.
3. Related to the last two points and your second screenshot, in some cases I'd like to jump into the specific action or event, how would this play out with the points above?
4. There's a version for users that doesn't include any taxonomy (either description or tags) as this is a paid feature, except for PostHog events. Worth considering how this would look.
5. In the context of this component, it's not clear what "Last 30 days" means.
6. Now that we are reworking this, it might be worth rethinking the icon we use to indicate PostHog events (Design request: Events & props icons #4266) if you want to take a stab at it.
7. Related to that, what icon would we show for a custom event in your current design?
8. I think it could be useful to be able to navigate the filter tabs with the keyboard to make a smoother experience, but I also don't want to interfere with the search box. I was thinking of maybe using the arrow keys? Wdyt?
9. With this new tab filtering experience I think I'd probably drop the "Suggested for you" filter, as it's just confusing in this context. We can keep suggesting properties in the main tab.

Not sure if you want me to comment on the UI just yet?

[clarkus]

@clarkus I love this! It brings together the best aspects of the old/more compact dropdown and the new, SelectBox-based dropdown below:

I like that we might re-introduce the tabbed layout, because if a user has a lot of properties, the above design makes the user scroll to see all the categories.

Yes! I was thinking about the work you mentioned on infinite scrolling property lists and such. This would lend well to that loading behavior while still letting a user quickly see that some sets are entirely empty.

[clarkus]

1. While the description blurb can be enough most of the times, there will be cases where I'll want to see the entire description and details. How would this look? Fwiw, I think it needs to be super simple, if it makes me open a separate tab or even a separate view it would IMO introduce some mental strain.

I think we can extend the summary cards shown on hover to include descriptions, tags, etc. I am tracking this today and should have more to share before my day ends.

2. Events can have descriptions and tags too. Of particular consideration is PostHog events (e.g. "Pageview" / "Autocapture") that have their own built-in description which we set.

Thank you for the context and clarification. I will correct this.

3. Related to the last two points and your second screenshot, in some cases I'd like to jump into the specific action or event, how would this play out with the points above?

I think this can be in the summary card shown on hover. I'm concerned that an action that leads to a separate summary will compete with the actual selection of the item for the current task. I think the designs above are right on target, but I'd like to update them a bit to be more consistent across composition areas.

4. There's a version for users that doesn't include any taxonomy (either description or tags) as this is a paid feature, except for PostHog events. Worth considering how this would look.

Thank you. I will add this today.

5. In the context of this component, it's not clear what "Last 30 days" means.

This is taken directly from the rolling metrics you have in the work above. I agree the labeling could be a bit clearer, but I'm also questioning placement. I will try a few more ideas on this.

6. Now that we are reworking this, it might be worth rethinking the icon we use to indicate PostHog events (#4266) if you want to take a stab at it.

+1

7. Related to that, what icon would we show for a custom event in your current design?

I am not sure. I think the use of our branding here is a bit problematic, but I don't have a better solution in mind yet. I will spend some time on icons today.

8. I think it could be useful to be able to navigate the filter tabs with the keyboard to make a smoother experience, but I also don't want to interfere with the search box. I was thinking of maybe using the arrow keys? Wdyt?

@mariusandra had similar feedback at #2760 (comment). This bears more research. I think arrow keys are generally a safe bet, but I want to educate myself a bit more and see if anyone else has figured this out. :)

9. With this new tab filtering experience I think I'd probably drop the "Suggested for you" filter, as it's just confusing in this context. We can keep suggesting properties in the main tab.

Yup I think that's a reasonable change to make. The label is also much longer so kind of out-competes the other tabs.

Not sure if you want me to comment on the UI just yet?

Everything is fair game for comments. Feel free to jump into figma and leave comments there if you want to annotate specific items.

[clarkus]

Here's a quick progress update. I've worked through a few icon iterations to help show type families in the combined list of options. I've also included a card shown on hover that will display the object details and provide a secondary action to view all those details directly. This is all hanging off of a filter mechanism, but the list functionality should be the same across instances.

with taxonomy details

without taxonomy details

alternate list states with icons

[paolodamico]

Really love this new UI! Will add some UI-related comments on Figma, but looking pretty solid 💪

[samwinslow]

Started building something similar here last week: #4844 (take a look at the video if you can).

I am a fan of keeping the textbox looking as much like a textbox as possible. Users with hundreds / thousands of property definitions should immediately recognize that they can type to search. 🔍

[paolodamico]

I believe this can now be closed with your work on taxonomy and Marius/Sam's on the event/property selector right @liyiy ?