Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Impossible to identify events and people separately #67

Open
idpaterson opened this Issue · 8 comments

5 participants

@idpaterson

While I agree that it was confusing to have to identify events and people separately (#43), the fix (6194f18) seems to eliminate the ability to give a separate identifier for events and people. A simple use case for a separate identifier is:

  1. User installs the app
    • event identifier is tied to the device
    • people identifier is nil because they are not logged in
  2. User logs in
    • event identifier is still tied to the device
    • people identifier corresponds to a different user id

In Mixpanel, we have to be able to make a funnel to track conversion from installation to log in to activity within an app. Requiring the event identifier to change when the user logs in is unacceptable because it will make this type of funnel impossible. Furthermore, the Mixpanel People interface shows events based on an identifier that can be distinct from the people identifier. While that unfortunately does not support multiple devices per user it at least allows us to see the activity of the user from their most recent device, with combined people statistics from all their devices.

It does not seem to be possible to set $distinct_id as a property on People because it will be overwritten by the value of the distinctId property. I apologize if I did not notice a way that the current approach accounts for this.

@kopertop

Any updates on this? We were just told to upgrade before iOS 7 is release or our data wont be accurate, but we can't without this being fixed.

@neilrahilly
Owner

Does this cover what you guys need?

f2c83fa

If so, I'll push Monday

@idpaterson

Neil, that looks like it will work for us in most cases. One thing that has been an issue in the past is removing the People identifier when the user logs out inside the app. In the past that was done by sending @"" as the identifier (because that is what the backend needed to unassign the identifier).

Is it in line with past versions to handle a nil identifier by mapping it to an empty string rather than discarding the value and logging an error? If I remember correctly, that approach was chosen in the past because a developer would probably just send nil to unregister the identifier and at the time doing so caused the app to crash. I think your current logic is good for the event identifier since setting that to nil is probably a mistake.

@neilrahilly
Owner

I've set up a separate branch for this:

https://github.com/mixpanel/mixpanel-iphone/tree/people-identify

On it, I re-added mixpanel.people identify:. I left the distinct ID validation, cause it's helpful to catch integration mistakes, but also added a -reset method to mixpanel.people so you can log users out.

I don't want to make these changes part of the mainline lib because we are strongly encouraging new users to use the same distinct ID for both events and people. Some new products, like Activity Feed, even assume the IDs are the same. On the other hand, I understand the dilemma for you guys.

Please let me know if this is sufficient for you to upgrade.

@catdawg

Hey guys,
What about if I want to opt-out of logging people? Right now I'm not really interested in having a different identifier for people, I just want to only use people for a specific set of users. If I use that branch and not call people identify will it work out as before?

@idpaterson

Thanks Neil, we'll give that a try.

@catdawg from what I've seen, setting an identifier for People does not do anything unless you also make an update to a Person attribute. In our apps we manage People data on the backend but wanted to get their most recent IP address (used by Mixpanel to show location info) by identifying the user in the app. As it turned out, we had to send along a property in order to get the SDK to upload any people data (including the identifier). If that is still the case, you should be okay as long as you don't set any properties on People. Can you confirm that behavior, Neil?

For anyone else that is struggling with the inability to track users with multiple devices in Mixpanel:
Keep a close eye on the alias feature that is in the works. It attempts to solve the problem of tracking across a login/registration funnel by mapping all activity on the original device ID to the new user-based identifier (an email address, User ID, etc). It's not ready for this use case yet since each user account can only have one alias mapping to it. Currently you can't map a funnel across login on the user's second device, you would just have to call identify: on the second device upon login. Unfortunately for us it is critical to understand what a user did prior to authenticating so aliasing a single device is not a viable solution – yet.

The Activity Feed feature on People cannot map to multiple devices but it can map to a different identifier than the person. There is an $events_distinct_id attribute on People which forms that association - we just map it to their most recently used device. The Activity Feed section would show a more complete picture for the user if you use a user id as the unified event/people identifier.

If anyone else is following the same path as we are (identifying events by Device ID and people by User ID), please contact me here or on twitter @ip1t. Perhaps collectively we can help Mixpanel better support users with multiple devices. I'd love to hear any other solutions you've found or how you've fared in converting to a unified people/device identifier!

@neilrahilly
Owner

That description is correct @idpaterson. Thanks for the thorough reply.

Also, in case it makes your life easier, you can get the geolocation we provide server-side by providing a $ip record attribute in an people API call, e.g.:

{
    "$token": "YOUR_PROJECT_TOKEN",
    "$distinct_id": "userid123",
    "$ip": "1.2.3.4",
    "$set": {
        "plan": "premium"
    }
}

We'll geolocate 1.2.3.4 and use the results to set the user's $city, $region and $country properties.

If you collect the user's IP anyway, or sending it to the server is easier than having a partial Mixpanel people implementation in your app, then you could include $ip in one of your server-side Mixpanel API calls.

@idpaterson

Thanks, that $ip tip should work for most people using the API. We actually tried it until we realized a bit of an issue in our infrastructure. We're connecting to our backend through a load balancer that ends up masking the user's IP. Since we're not using a standard HTTP protocol for networking there's nowhere to pass along that original IP. Hopefully we'll expand usage of People in the app since features like incrementing properties would be very useful for interaction metrics that we don't capture on our backend.

@malectro malectro added the enhancement label
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.