Mixpanel Community Icon

Optimizing Mixpanel Events for User Tracking: Best Practices

·
·

First-timer Mixpanel user here. We're in beginning steps with the Data Tracking plan. We first created several events per page - as we were seeing things from the perspective of needing to see every step through a multi-page enrollment process, field-by-field (yes, we need that level of detail). But after completion, it seems like it might be easier to create more 'generic' events, like "Input_blurred" to capture any event where a field is entered and de-focused, or "button_triggered" – like given in a Mixpanel page's example. Then we'd attach properties of page_name, page_url, form_name, etcetera so we can still see the user's path through pages, and where they might have dropped, or hit an error. My question is a two-parter: Is this feasible, or over-simplifying events. And will we have any problems stitching together a user's experience? Does Mixpanel have built-in tools that present that with a few filters - like if I wanted to quickly see a user flow through pages, with drop-off? Or, is there a heavy lift in finding and presenting that information? 🎫

  • Avatar of Andrew S.
    Andrew S.
    ·
    ·

    This is the age-old question. Detailed events with the need to do custom events that combine events to look sat a higher level, or more generalized events with properties for breaking things down. I personally went the latter. I have specific events that are very transactional (questionnaire_submitted, rating_submitted, etc.) where the properties are very particular and make no sense to combine into a singular "submit" event with a property for submission_type (i.e., "questionnaire" vs "rating"). But for other things like "rating_submitted", I did not create separate events for "wine_rating_submitted" vs "beer_rating_submitted". It makes more sense to look at all rating submissions with the ability to then break it down by "product_type" (ie wine vs rating).

  • Avatar of Charles S.
    Charles S.
    ·
    ·

    Yeah, as I rework this, that seems to be the direction I'm leaning as well. General events overall, but I have a few specifics that I still want called out. I'm curious what others have found, and any gotchas they've run into

  • Avatar of Andrew S.
    Andrew S.
    ·
    ·

    Biggest thing I’ve found is deciding at a later time that I would like X property that I didn’t start with. So I need to modify along the way and then adjust with “custom properties” to make nice looking properties when “not set” on old events (e.g. “Pre-Oct2024” instead of “(not set)” in a breakdown)