Solved

Mixpanel tracking a lot of nameless visitors

  • 15 May 2020
  • 5 replies
  • 476 views
T

I’m new to Mixpanel and just deployed my first tracking attempt. Everything seems good but right now we have a lot of nameless visitors (not yet signed up and aliased).

My questions are:

  • Is this common for other Mixpanel trackers?
  • How do I hide them to focus on only signed up users who are aliased?
  • Would this kill my free Starter plan quickly? We tend to have a lot of visitors who are just checking out the site (or even drop off straightaway). It seems like we are sacrificing the tool for a lot of uninterested users.

Thanks in advance :)

icon

Best answer by ian 15 May 2020, 23:26

Hi there,

Happy to help!  To answer your first question regarding the missing field, the Name and Email fields are populated if you store a user property called $name and $email respectively, as these are reserved properties which you can read more about here.  For your remaining questions:

  • Typically you want to store the information via the people.set() call when that information becomes available.  This is common for other Mixpanel users if they 1) don’t intend to track it or 2) use a different property naming convention as the ones listed above.
  • When aliasing users, are you also storing the user ID that you’re aliasing by?  If so, in the query builder at the top of explore, you can set a filter for user ID’s being set.  Presumably, you’re only aliasing once which is at the point that a user signs up.
  • If you are on a legacy events and profiles plan, the profiles plan can be affected by these unneeded profiles in Explore.  If you’re on an MTU plan, you can store as many profiles as you please as MTU’s are just the unique count of distinct_id’s that fired at least one event in the month.

Hope the above helps!

Ian

View original

5 replies

ian
Rank
Userlevel 2
Badge +2

Hi there,

Happy to help!  To answer your first question regarding the missing field, the Name and Email fields are populated if you store a user property called $name and $email respectively, as these are reserved properties which you can read more about here.  For your remaining questions:

  • Typically you want to store the information via the people.set() call when that information becomes available.  This is common for other Mixpanel users if they 1) don’t intend to track it or 2) use a different property naming convention as the ones listed above.
  • When aliasing users, are you also storing the user ID that you’re aliasing by?  If so, in the query builder at the top of explore, you can set a filter for user ID’s being set.  Presumably, you’re only aliasing once which is at the point that a user signs up.
  • If you are on a legacy events and profiles plan, the profiles plan can be affected by these unneeded profiles in Explore.  If you’re on an MTU plan, you can store as many profiles as you please as MTU’s are just the unique count of distinct_id’s that fired at least one event in the month.

Hope the above helps!

Ian

ian
Rank
Userlevel 2
Badge +2

And to add on to the first part of the question, you would want to look at when your storing profiles / how your storing profiles.  You may just want to call people.set() or hit our /engage api when a user signs up.

T

Thanks Ian for the thorough explanation – it makes a lot of sensse! A few points to clarfiy below.

I’m on the starter plan with MTU limit is 1k. Since the plan’s MTU would count all the distinct_id’s of people who have fired at least one event, if I have a lot of first-time visitors just checking pages out and subsequently bounce off, if would affect the tracking for real “interactive” users who have signed up and aliased (I do alias with User ID so can totally filter out)

Can I please also confirm this with you: if I’m not calling people.set/set_once at all pre user signup, I would get around the issue of Mixpanel tracking all unwanted first-time visitors?

Lastly, I’m not too clear about the /engage api. Could you tell me a bit more about it and why/how it differs from calling people.set()?

T

Also, for existing users who signed up before Mixpanel tracking, when they login, they would have 2 profiles (1 for their distinct_id and 1 for their User ID). That is because the Login functionality doesn’t do aliasing. My plan to get around this is to have a DB column for each user to tell if they have been aliased by Mixpanel, if not, I’ll call the alias call at login for them.

Is this a proper way of doing this?

ian
Rank
Userlevel 2
Badge +2

All first-time visitors assuming they fire an event will still count as an MTU, even if you’re not storing a profile with people.set() or set_once().  As such, to stay under the 1K MTU’s, you may want to rethink what you track in the pre-signup / sign in flows.  The /engage api is just the endpoint that is hit when calling the people.set() call (I brought it up as I wasn’t sure if you were using our client-side SDKs).

The good news with existing users who log in is that we actually just released our new ID merge functionality, where all you need to do is identify at login, and that will merge pre and post auth events.  This shouldn’t affect the aliasing at signups, but it will facilitate the merging of id’s at logins and keep duplicates from being created.  You can read more about how it works and how to turn it on here.

 

 

Reply


Mixpanel