Solved

How to best implement a voted event?

  • 26 June 2020
  • 4 replies
  • 154 views

I want to track votes and I’m wondering if you would have ideas as to best implementation of tracking.

 

Option 1:

vote_cast

    type: video or comment

    value: 1 or -1

 

Option 2:

upvote_cast

    type: video or comment

downvote_cast

    type: video or comment

 

Option 3:

video_upvoted

video_downvoted

comment_upvoted

comment_downvoted

 

I think this is a scenario where I would really benefit from some insight from your team as to which way would be the best in the longterm. I don’t want to make a mistake now.

icon

Best answer by enague 7 August 2020, 23:45

Hi ebrawer​,

Eric here from Mixpanel Support, thanks for writing in. I'd be happy to help.

I honestly love this question, and I think it is a really important one. Since your data can sent in any way you like, I have seen most customer’s follow a convention to make it either more detailed or concise, so you have to find that balance. I would avoid option 3 because it is too specific, and it creates a precedent for your other events to be very specific. This causes way too many events to be in your project, and it might not be the best when comparing data sets. Meaning it would be hard for you to filter or breakdown based on an event property: https://help.mixpanel.com/hc/en-us/articles/360001236083.

 

I would suggest having a mix of option 1 and 2. We want the most bast event like “vote_cast,” but we also want to make it understandable for the future. So, if you think a value of -1 for a “vote_cast” is completely understandable for your company, then that is great. For me, I would make the value event property as either “downcast” or “upcast.” Something like the following:

 

Option 4

Event: vote (or vote_cast)

Type: video or comment

Value: up_cast or down_cast (up or down)

 

I would play around with it and focus more on the event properties since you can always change the display name of the events as described here:https://help.mixpanel.com/hc/en-us/articles/360001307806#adding-or-changing-descriptions.

 

Lastly, you could even go with option 1 and just add a description on the event to make sure the values of 1 and -1 are clearly written out to avoid confusion. I think there are many ways to go here, but with the information I’ve said here, I believe you will have a gut feeling on what to choose.

**Also, we released some pretty cool data set demos, so you can play around and see if you life any methods used here: https://mixpanel.com/get-started/?explore=True.

 

I hope that helps. Please let me know if you have any more questions.

 

Best,

Eric =)

View original

4 replies

Badge

Hi ebrawer​,

Eric here from Mixpanel Support, thanks for writing in. I'd be happy to help.

I honestly love this question, and I think it is a really important one. Since your data can sent in any way you like, I have seen most customer’s follow a convention to make it either more detailed or concise, so you have to find that balance. I would avoid option 3 because it is too specific, and it creates a precedent for your other events to be very specific. This causes way too many events to be in your project, and it might not be the best when comparing data sets. Meaning it would be hard for you to filter or breakdown based on an event property: https://help.mixpanel.com/hc/en-us/articles/360001236083.

 

I would suggest having a mix of option 1 and 2. We want the most bast event like “vote_cast,” but we also want to make it understandable for the future. So, if you think a value of -1 for a “vote_cast” is completely understandable for your company, then that is great. For me, I would make the value event property as either “downcast” or “upcast.” Something like the following:

 

Option 4

Event: vote (or vote_cast)

Type: video or comment

Value: up_cast or down_cast (up or down)

 

I would play around with it and focus more on the event properties since you can always change the display name of the events as described here:https://help.mixpanel.com/hc/en-us/articles/360001307806#adding-or-changing-descriptions.

 

Lastly, you could even go with option 1 and just add a description on the event to make sure the values of 1 and -1 are clearly written out to avoid confusion. I think there are many ways to go here, but with the information I’ve said here, I believe you will have a gut feeling on what to choose.

**Also, we released some pretty cool data set demos, so you can play around and see if you life any methods used here: https://mixpanel.com/get-started/?explore=True.

 

I hope that helps. Please let me know if you have any more questions.

 

Best,

Eric =)

Thanks Eric! This is really helpful. For the demos, the Video Platform one is most interesting to me but I believe I saw a much more developed version of it (like 100x better) during a sales demo. I’d love to be able to see that one in more detail.

Userlevel 5
Badge +3

@arpitc — You seem to be an expert on tracking plans and advocate for taking the time to invest in a tracking plan to set your project up for success. Any additional pieces of advice here?

Badge

Thanks @cherise for the mention! 

From my point of view, it’s better to stick to 1 event here as it might be possible for someone to upvote a video/comment and for some reason change their mind later and downvote it. If you have 2 separate events, both events will be fired which is not ideal. 
 

Additionally, it is important to think about the data types of the properties. I would recommend using a boolean property instead of a numerical one (value = +1 or -1). The property could be called is_upvote which will either be true or false (in case of a downvote). 


As you can see, a nifty trick I use is to prepend all boolean properties with an is -- this makes it very easy to spot properties of the boolean data type. 

So I would go with option 1 as follows: 

Event: Vote Cast (or vote_cast if you use snake case for event names)

Properties:

  1. is_upvote (boolean)
  2. content_type (enum) -- With values video and comment. It’s very important to not use a string for this property to ensure data accuracy

Cheers!

Reply