Best Practices for Tracking User Intent vs. Action Events in Analytics

·Dec 04, 2025 04:23 PM·

Share

Are there any guidelines/best practices for tracking "intention" events (when a user clicks something) vs. "result" events (when the action that they clicked actually happens? For example, we allow all users to click "save a copy" on shared projects, but that takes anonymous users to a sign-in page, and only after they sign in will the project get actually copied into their account. I want to track two events, one for the click and one for the actual copy, but I'm struggling to come up with good naming and other conventions that would generalize well across other similar situations (and be easy to understand and use by my team in Mixpanel)

3 comments

· Sorted by Oldest

Andrew S.
·
·
For what it’s worth, when I have situations like that, I treat them as the same event, but I have an additional property that records how it was completed. For example, you could use something about whether the click event they were signed in at that time with the Boolean true or false. I always prefer to have fewer events with properties that allow me to filter or break them down based on circumstances or conditions.
Vlad S.
·
·
that's not really what I'm trying to get at... here's another example: we have a "Subscribe" button, which takes users to a checkout which is managed by a totally separate piece of code I don't have access to. The user may do a whole bunch of things in there, one of which is simply drop out and never finish checkout. So it's important to measure both when a user started the checkout and when they completed it (first event is generally frontend and last event is generally backend, although that may vary). I'm trying to generalize this into a pattern I can apply more broadly where an action can be started but not finished
Andrew S.
·
·
I have something similar for people that go through a reservation process that has multiple screens. And in fact, some of those flows involve third-party systems. When somebody aborts the process along the way, the front end captures a reservation_aborted event which allows me to track flows that go from reservation started to reservation completed versus those which go from reservation started to reservation aborted

Andrew S.
·
·
For what it’s worth, when I have situations like that, I treat them as the same event, but I have an additional property that records how it was completed. For example, you could use something about whether the click event they were signed in at that time with the Boolean true or false. I always prefer to have fewer events with properties that allow me to filter or break them down based on circumstances or conditions.
Vlad S.
·
·
that's not really what I'm trying to get at... here's another example: we have a "Subscribe" button, which takes users to a checkout which is managed by a totally separate piece of code I don't have access to. The user may do a whole bunch of things in there, one of which is simply drop out and never finish checkout. So it's important to measure both when a user started the checkout and when they completed it (first event is generally frontend and last event is generally backend, although that may vary). I'm trying to generalize this into a pattern I can apply more broadly where an action can be started but not finished
Andrew S.
·
·
I have something similar for people that go through a reservation process that has multiple screens. And in fact, some of those flows involve third-party systems. When somebody aborts the process along the way, the front end captures a reservation_aborted event which allows me to track flows that go from reservation started to reservation completed versus those which go from reservation started to reservation aborted