Strange Mixpanel Behavior

Solar2D Android
#1

I am in the process of transitioning to Mixpanel now that Flurry is gone, and I’m noticing a weird behavior on Android. I’m in the beta test process with a new app, and I’ve got about 30 testers on Google Play.

Whenever I update the app on Play, all the test devices light up over the course of the next few minutes, initialize and trigger all the Mixpanel events, even events that require a button press to trigger.

It seems like it’s linked to the devices downloading the update because over the next day or so I’ll get a few more of these bursts from devices that I presume were off when the initial update was posted, but I don’t know why (or how) it’s triggering all the events. Does anyone know why this is happening? It doesn’t happen on iOS.

#2

One possibility is that these are events from Google Play’s automated stability tests. They seem to use some processes to guess where UI elements are on the screen and they run tests across multiple devices that include interacting with UI, closing/reopening the app etc. I typically see all these events within the span of a few minutes after pushing an update.

1 Like
#3

Thanks for the insight! That makes sense- because of my small install base, it looked like it was my beta testers and the idea that it was Google’s automated testing suite hadn’t occurred to me.

I suppose after the app is launched and I have thousands of daily active users and not just a handful, the weird automated testing blip won’t be so impactful on the statistics. I was worried that once I launched, every device installed on Play would exhibit this behavior and ruin my ability to track retention, etc.

#4

Yeah, it should not skew your metrics in the long term especially when you consider that this will only typically happen within 24h of pushing a new update.

Was also curious as to which plugin you’re using for mixpanel and if it’s any good. The one that we’ve been using since some years has some significant limitations so I’d really like to try any alternatives

#5

I’m using the Mixpanel plugin from Yoger. Frankly, I can’t get most of the features to work and I find the whole thing incredibly frustrating. However, I have gotten it to log new installs and new sessions, and that’s really all I need, so I’m just trying to be zen about the whole thing.

#6

I’m using the same plugin and I agree that it is quite limited. We could never get even coarse geo data for users with it so we ping a free service with users’ IP address to try and fetch their approximate location and then add that into the tags before sending events to mixpanel.

Would be happy to share the relevant section from our mixpanel code should you need that feature :slight_smile:

#7

Do you know how to set the City, Country and OS? I’m adding them manually using register_track_properties, but I can’t get them to show up in the main row, which means that the reporting of “Active Users by - [city, country, etc.]” just shows “Not Set”.

image
image1244×407 51.3 KB

#8

They should be automatic by the SDK as far as I know. I integrated their SDK a while back, and I don’t manually track any of those properties but they definitely all get populated.
It’s possible that by tracking them manually you are overriding the automatic collection, and causing Mixpanel to unset them.

#9

It seems likely that you did a better job writing your plugin than Yoder Games did. I started manually tracking the geo and platform data exactly because it wasn’t auto-populating. :man_shrugging:

#10

So I looked at our code and we’re just fetching the IP address for the device and adding that data to the tracking properties of mixpanel. This seems to allow mixpanel to populate some geo data though it still doesn’t work for 100% of devices but it’s better than nothing.

local mixpanel = require "plugin.mixpanel"

local pg = mixpanel.getInstance("xxxxx")

local function ipListener(event)     
    if ( event.isError ) then          
        debugStmt.print("analytics:Network error!")     
    else       
        local deviceIP = event.response   
        debugStmt.print("analytics:IP response: "..deviceIP) 
        pg:register_track_properties({ip=deviceIP})--set ip property of mixpanel  
    end
end
network.request( "http://myip.dnsomatic.com/", "GET", ipListener )
#11

That works! How did you know to do that?

In the example project, in register_track_properties, there are properties that are simply named, like Platform, which I took to be a “Mixpanel Property”, and there are the properties that are in brackets and quotes, like ["App name"], that show up on the dashboard as “Your Properties”.

You’ve got ip as simply a named property, but I haven’t been able to find a list anywhere of what the “Mixpanel Properties” are. I’m sure this is a case of LMGTFY, but I’ve been flailing for weeks.

– Side note, Platform doesn’t seem to do anything, since “Operating System” still shows as “(not set)”, even when I register it, per the example given: Platform = system.getInfo("platform"),

#12

Yeah the documentation was never fully clear to us either so from what I can recall, we were able to connect with the folks at Yoger Games and they helped us with the IP address thing. This was pre-covid at a time when we were publishing a game on Steam and the only analytics option that worked on PC was mixpanel so that’s how it started.

An updated plugin for this will be very helpful though if someone would be willing to put theirs on a subscription model for the community.

#13

This is potentially drifting off-topic, but I noticed that:

network.request( "http://myip.dnsomatic.com/", "GET", ipListener )

frequently returns “Too Many Requests” from myip.dnsomatic.com. I was looking in the docs and came across this:

local socket = require( "socket" )
local client = socket.connect( "www.apple.com", 80 )
local ip, port = client:getsockname()

The main difference seems to be that the ip address returned via the network.request method is IPv4 and socket.connect returns IPv6. I plugged the IPv6 address into Mixpanel and it resolved the location correctly.

Is there a reason not to use socket.connect for this? The warning about using the socket library in the docs is… vague.