posthog
posthog copied to clipboard
PostHog
Leftover tasks for "Simplifying actions" Data Management sprint
Leftover pre-requisites before we release the new "simplified actions" experience to customers hidden behind the simplify-actions FF.
In scope:
- [ ] Docs updates - remove all posthog.com references to actions @pjhul
- [x] Rename actions to events in toolbar - https://github.com/PostHog/posthog/pull/10989
- [x] Different icons for raw events and events (verified/unverified) - https://github.com/PostHog/posthog/pull/10959
- [x] https://github.com/PostHog/posthog/pull/10492
- [x] Add event type filter to list view - https://github.com/PostHog/posthog/pull/10961
Out of scope:
- [ ] Deprecate actions api and consolidate functionality into event definitions api
- [ ] https://github.com/PostHog/posthog/issues/10774
- [ ] Sorting bug
- [ ] Next page bug
- [ ] Verified bug
- [x] Actions randomly not appearing in event picker after creation bug
- Event Wildcard (see last point in https://github.com/PostHog/posthog/issues/10774)
Deprecate actions api and consolidate functionality into event definitions api
Did we ever sort out a communication plan to announce the deprecation to users before flipping the switch?
Different icons for raw events and events (verified/unverified) @clarkus do you know if there are icons in Figma for this?
I am still working on these... I came up with a new icon while working on recordings that I am going to try to fit in everywhere.
Did we ever sort out a communication plan to announce the deprecation to users before flipping the switch?
Yup, I've been talking with @joethreepwood who has an email ready to go once the deprecation is ready.
Yep: example of the email and info on targeting on https://github.com/PostHog/posthog/pull/10492
It's now scheduled for a 12 noon GMT send on 22 July.
Just an update from the documentation side, I've gone through and have almost finished updating the documentation to remove all references to 'Actions'. However, the more I think about this change, the more this new naming scheme feels as though it's only going to muddy the waters more. I totally agree that the name 'Actions' does not do a good job of alluding to what these things actually are, but I'm worried this new scheme will cause more confusion.
Some concerns I have
- Events are an incredibly core part of the platform, and I'm still not clear on what we gain from changing 'Events -> Raw Events'. I also worry about completely changing the name of something so core to the product.
- It seems as though the real issue was with the name 'Actions' (which I totally agree isn't a great name), not with events
- The name 'Events' doesn't like it tells me about what these things are better than 'Actions' did
- The term 'Events' is already used by nearly every analytics product (including us currently) to mean something very specific, and by changing 'Events' to refer to 'Actions' this would be breaking from that standard meaning
- There are thousands of references to 'events' within the website and product, and it'll be infeasible to go through and update every single one
It seems to me that Actions, at their most basic, are a way of grouping multiple events together. IMO this is exactly why the name 'Actions' is bad: it doesn't allude to this at all. Here's my proposal for a slightly different naming scheme that I think will make things much more clear:
Proposal
- We keep the name of 'Events' the same (Don't rename to raw events)
- Rename 'Actions' to 'Custom events' (This is the name that both Amplitude and Mixpanel use)
- Note: Heap uses the term Combo events, which could be an option as well
- Whether or not we combine these two into the same tab within the dashboard, I think either is fine. I like the way the most recent version looks with one tab and then a drop-down selector.
Overall, I think that changing the name of 'Actions' alone will help solve the confusion at the source, and will mean we don't cause more confusion by changing what 'events' mean.
Let me know what you think! :)
cc: @jamesefhawkins @joethreepwood to get your input on this as well
On the marketing side, we've sent out comms about this change already. Thankfully it was to a small cohort of only 300 highly engaged users. If we're to revert this change I suggest we validate a final decision with users in the beta test group and then position the messaging as us being reactive to user feedback. This would be the most positive spin on the message and would follow the intent of the previous email.
Personally, I do agree that having raw events and events will probably be less clear (I can easily see the conversations users will have: "I'll make an event for that." "Do you mean a raw event or a regular event?" "What's the difference?" "One is like an action.") but it's something I don't have a blocking opinion on because I haven't seen the user feedback which motivated this change. Is there somewhere I can see the feedback, @alexkim205?
Thanks for the writeup @pjhul! The more I'm seeing references to raw events in the UI, I'm also realizing this might be more confusing. In addition to feedback here, we've also gotten some internal feedback that custom/calculated/synthetic events might be a better name for actions. We've also gotten feedback from one customer who've said that raw events could be misleading for their use case, so I'm also inclined to revert "raw events" back to "events" and rename actions to something else.
@rcmarron brought up a good point in standup today that "custom events" is already used throughout the app (see paths) to describe all events that aren't posthog events (pageview, pageleave, etc.), and that "events" can already be considered "custom". I think "calculated events" would be a good alternative since matching events for actions are calculated at an interval while events are raw. Thoughts?
@joethreepwood Given that we already have some internal and external feedback on this name change, let's go ahead with the name change! How do you think we should time this? Do you think this rename should be cherry-picked before the 1.38.0 release or should be communicated as a patch in 1.38.1?
Calculated events is fine with me! We do use the term Custom Events elsewhere in the docs as well, and I agree that it still doesn't do a great job of telling you what they actually do. I definitely agree with Joe here that before we move forward we should get some feedback from users on what they think of Calculated Events just to be very sure before we pivot.
Another term I've seen used elsewhere is the term Virtual Event, which I like in the sense that it implies that it's not an event that you directly "send" to PostHog. For now though let's get feedback on Calculated events!
Sounds like a plan 👍 — I have the rename PR good to go whenever we're ready
https://github.com/PostHog/posthog/pull/11018
@joethreepwood Given that we already have some internal and external feedback on this name change, let's go ahead with the name change! How do you think we should time this? Do you think this rename should be cherry-picked before the 1.38.0 release or should be communicated as a patch in 1.38.1?
Unless there's reason to wait on your side, I'd say cherry pick it and put it in Array. Avoids having to do dedicated communication and patch notes.
Flyby feedback. I think 'Combined Events' would be much better than 'Calculated Events'.
'Calculate' implies some kind of formula is being applied, which isn't what is happening afaik. 'Combined Events' is the most literal, straightforward description.
But, for the record, I think 'Actions' is fine and we should probably focus our energies on explaining the concept better.
I was really looking forward to this change (actions -> events, events -> raw events) and agree with @andyvan-ph that:
I feel like this is becoming no clearer
Strongly agree with the "synthetic events" terminology since it's already sort of an industry standard and we don't have to re-educate people with new naming conventions, which was sort of the original point of killing off "actions".
custom events" is already used throughout the app (see paths) to describe all events that aren't posthog events (pageview, pageleave, etc.), and that "events" can already be considered "custom". I think "calculated events" would be a good alternative since matching events for actions are calculated at an interval while events are raw.
Sometimes we lean a bit far on the side of being very literal (instead of just picking something that makes sense to most people), and I think this is one of those cases. While technically accurate that ~actions~ are calculated and different than raw events, I don't see a strong use case for users to need to know this – at least while using the app. (The actual definition is, of course, useful in documentation.)
The term "calculated" could show up as part of the description when defining an ~action~ but I think we're overcomplicating this - even in an effort to make this more accurate.
Strongly hoping we can stick with some widely-adopted industry terms than introducing a new term that brings no more clarity to the problem we were originally trying to solve.
For the sake of clarity, what are the options we're considering now?
- Events + Actions (status quo)
- Raw Events + Events (which we've kind of ruled out now?)
- Events + Synthetic Events
- Events + Calculated Events
- Events + Combined Events
- Events + Virtual Events
This is all really good input! I think it's worth getting any change out to users first and change the name based on the feedback that we get. It sounds like regardless of what terminology we choose, we should have better documentation to differentiate the two concepts.
Any concern that "Synthetic" will be read as artificial or fake or less real than a raw event?
Any concern that "Synthetic" will be read as artificial or fake or less real than a raw event?
Let's lean into this. I vote for 'Genetically Modified' and 'Organic' events.
The more I look at the options, the more I side with sticking with 'Events + Actions'.
I think 'Raw Events + Events' would have been great two years ago when changing the names of things wouldn't matter to much, and all the alternatives just feel like another abstraction.
Consolidating Actions and Events would be the ideal solution, but I believe this was ruled out in the original RFC on techincal grounds.
Bottom line: if we change the name of 'Actions' we still need to explain the difference between Events and XYZ, so a name change resolves very little.
FYI I'm taking this out of Array until we have a clear decision on this, to avoid further miscomms.
https://posthog.slack.com/archives/CSPHFDZH8/p1659348128612089