Hi team,

a question about the js api call regarding to user identity.

So we are using mixpanel.alias when user signup and mixpanel.identify for user login.

For some reason we have some incorrect unique id set to some user, (seeing from mixpanel live view dashbroad)

so we try to have fix the issue by adding the below code when our app starts.

const id = mixpanel.get_distinct_id();
if (INCORRECT_FORMAT) {
   mixpanel.people.set({
      '$email': `${CORRECT_EMAIL}`,
      '$name': ${CORRECT_NAME}`
  });
  mixpanel.identify(`${CORRECT_ID}`);
}

However, it doesnt seems to showing correct beacon on the live view (checking from browser console also mixpanel debug plugin that we are sending correct distinct_id.

Any suggestion?

We've been seeing an issue over the last week where the loaded callback for the Mixpanel javascript is not called when it finally loads. This seems to be a race condition where mixpanel-2.2.js has loaded quickly and has not called our callback.

We believe the problem to be in the mixpanel['init'] method in mixpanel-2.2.js. If we apply a name, _loaded() is always called and our client code can initialise correctly. We are using this as a workaround for now but would love to get some help solving this.

From: https://mixpanel.com/docs/integration-libraries/using-mixpanel-alias

In fact, this behavior is so undesirable that if you call alias with an existing alias as the argument, Mixpanel will just silently ignore the alias request.

However the JS client will still set the alias in props even if the request was ignored:

mixpanel.alias("existing_alias")
mixpanel.get_property("__alias")
// "existing_alias"

I think the code actually already wanted to solve this problem correctly here:

            return this.track("$create_alias", { "alias": alias, "distinct_id": original }, function(response) {
                // Flush the people queue
                _this.identify(alias);
            });

If I understand correctly, then even if the alias already existed, it would identify as that alias anyway. The problem is that _this.identify(alias); will not do anything because of:

if (unique_id != this.get_distinct_id() && unique_id != this.get_property(ALIAS_ID_KEY)) {

Since alias is already set at this point, it will not change the distinct_id.

I think the correct solution would be actually to identify as the alias if the alias already existed. However the alias function would need a callback parameter so we can wait until this information is known. Otherwise it should change distinct_id to alias immediately, but then I don't know what the value of the alias property (in JS) is.

Basically what I want to do is, if alias already exists, identify as that alias, otherwise create alias for the current Person. I hack around it right now like this:

      mixpanel.alias("myalias");
      mixpanel.unregister("__alias");
      mixpanel.identify("myalias");

I've seen searching online some people use mixpanel.cookie.clear() to clear the mixpanel cookie. However, that also makes distinct_id undefined.

Is there something we should do when a user logs out or should we do nothing? I'm trying to understand the "right" behavior.

If we don't clear the cookie and the user signs up again, then two account creation events are created and both accounts associated to a single account (after aliasing). If we do clear the cookie, then there's no distinct_id (it becomes undefined) which causes issues when trying to create a new people property after a second sign up.

If mixpanel.init() is executed after the loading of mixpanel-core, window.mixpanel cannot be accessed at all, even after mixpanel.init() is called.

Hi team,

a quick question for the beta auto tracking feature,
I saw in the core code that we are sending page view only on init (correct me if I am wrong),
do we have the method to auto send page view on client side navigation as well? (perhaps listens to history change?)

Thanks

would be dope

Android version of Mixpanel library supports event queuing that makes it possible for offline apps to track user events. Is this feature on the roadmap of JavaScript lib?

In iOS 9, if a user has a content-blocker installed (in my testing it was 1Blocker installed) MixPanel events will not be sent. The content-blocker will see it as a different domain and it gets blocked.

Unsure of how to get around this issue but this is obviously effecting a significant number of users, especially for our mobile web app.

mixpanel.reset() is called when users logout in order to prevent profile hijacking and polluting the alias table since we've found situations where more than one user could sign in from the same computer/browser.

however, when testing the reset() method in firefox, instead of resetting the distinct_id, a new cookie is created with an additional distinct_id.

This issue only seems to be happening with firefox. Works as intended in safari/chrome. Have not tested in ie.

Helps isolate browser version specific behavior / issues.

Hey Mixpanel,

Just curious why it's not possible to access super-properties before mixpanel is loaded. As far as I understand those are stored in a cookie or localStorage, so can be fetched immediately by the browser. Is there a technical limitation that makes those properties inaccessible before it's loaded? (e.g. using get_property() or mixpanel.persistence.properties())

I'm implementing a C3.js chart component in my website which is based on SVG rendering. Whenever I click this chart a MixPanel event fires, but this results in an error Mixpanel error: Implementation error. Please contact [email protected]..

The underlying problem is that this line:

Would it be feasible to check if elem.className is a string or an object, and if it's an object to return the elem.className.baseVal?

If you have a placeholder link that does not have a href (<a>Example</a>), then the behaviour of track_links is broken.

Without track_links, clicking that link in most browsers does nothing.

If you call track_links on a placeholder link, then clicking the link refreshes the page.

Interestingly this only happens in IE9, but not 10 or any other browser. Adding mixpanel to the window object solves it, but that seems like a rather dirty workaround. Any advice here? The issue seems to be a response from the mixpanel api which includes a piece of code like mixpanel._jsx[123123]....

https://github.com/mixpanel/mixpanel-js/blob/master/src/mixpanel-core.js#L1070

First, perhaps a more unique, less clash-y name for this internal property? No one can track a property of "token" currently.

Second, and far more important, this method mutates given data, impacting other code in my app. I am happy to put a PR in to fix this issue, but I haven't had the time to see how pervasive this pattern is around the library. Is this just a one-off that slipped through?

Thanks!

It tries to fetch the library using chrome:// on chrome extension pages.
Why not fetch the library always using https? That way you wouldn't need to handle all these special cases. Wouldn't that be more secure as well? Is there anything to be gained by sometimes fetching the lib using http?

Related to #48

We have a security requirement to mark the Mixpanel cookie as both secure and HttpOnly.
We can set secure_cookie in mixpanel.set_config to add secure to the cookie, but there is no option to add HttpOnly to the cookie. An option for this would be appreciated. Thanks.

Information on HttpOnly cookies: https://www.owasp.org/index.php/HttpOnly

I'd like to be able to have any errors thrown within mixpanel-js surfaced to the error handling/logging code running on my origin. Due to cross-origin security policies, errors are currently reported simply as Script error. with no stack trace or line number.

To accomplish this, we need

• the crossorigin attribute set on the script tag injected into the DOM by the mixpanel loader. Note the property name is actually crossOrigin even though the attribute is crossorigin
• Mixpanel CDN configuration (cdn.mxpnl.com) set to serve Access-Control-Allow-Origin permissively (preferably *, which is common on other public script serving CDNs).

For example CDNjs serving jquery:

$ curl -D - -o /dev/null -sS "https://cdnjs.cloudflare.com/ajax/libs/jquery/3.0.0-beta1/jquery.min.js" | grep Access
Access-Control-Allow-Origin: *

Mixpanel CDN serving mixpanel:

$ curl -D- -o /dev/null -sS  "https://cdn.mxpnl.com/libs/mixpanel-2-latest.min.js" | grep Access
$

See also: https://errorception.com/docs/cors

I would like to include mixpanel along with other 3rd party libraries in a bundle (using webpack) that is requested when my app loads. The end result will be one bundle for my app code and one bundle for my vendor code. My app will only need to load 2 JS bundles to load all the code for my app.

I am not able to run the mixpanel code with mixpanel.js alone. I need the snippet as well. The snippet attempts to inject an additional script on my page. Is there a supported means of bundling the mixpanel library with the bootstrapping functionality of the snippet into a single .js file that my app can request - even as part of a bundle with other libraries?

To better understand my particular situation, I am building a Chrome App. Unlike a Chrome Extension, a Chrome app cannot include external scripts, so I need to supply everything locally. My build process already bundles all my frontend JS together so I have no need for a bower_components or libs directory in my final production code. I'd like to use mixpanel without having to modify the build process to include additional stand-alone scripts.

Additionally, because this is an app that's already installed on the user's machine, I'm not concerned about network latency of downloading a large JS bundle.

The iOS and Android Mixpanel clients support buffer and send events as batch.

I hate to see dozens of events that occur at the same second flood the network....

It would be very useful to support the $unset operation in the js lib (https://mixpanel.com/help/reference/http)

We're seeing cookie names such as mp_:192.0.<snip>_mixpanel. The : is not a valid character in a Cookie name, and while Chrome and nginx both forward this alright, our backend Python library (Tornado) chokes on it, and drops the entire Cookie header. (Which contains other cookies as well.)

Can this character be removed from whatever generates the name for the Mixpanel cookie?

(note: we're using version 2.2, I think, from the CDN)

Background

We're loading MixPanel via Segment, so we're unable configure it upon init, but Segment provides an analytics.ready function to change pulled in libraries once they're loaded.

MixPanel has a set_config function and we're trying to use it to set persistence to localStorage instead of cookies. In this documentation, it says:

  // type of persistent store for super properties (cookie/
  // localStorage) if set to "localStorage", any existing
  // mixpanel cookie value with the same persistence_name
  // will be transferred to localStorage and deleted
  persistence:                "cookie"

The problem

Here's our code:

      window.analytics.ready(function(){
        window.mixpanel.set_config({ persistence: "localStorage", persistence_name: window.mixpanel.persistence.name || "" });
      });

The behavior I'm seeing is:

• The mixpanel.config object is updating as you would expect with our code.
• The existing MixPanel cookie is staying in a cookie.
• No MixPanel LocalStorage data is being added.

I'm not sure if we're doing something wrong or if the library is not working as described?

Hi Mixpanel,

This might relate to #35, but seems slightly different. I'd like to retrieve all the super properties that we have set for a user. I can use mixpanel.get_property, but then I need to know the name of the super property. I couldn't find a public method exposing it.

I saw that I could access mixpanel.persistence.props - but feels like reaching too deep into the internals(??). Would appreciate some pointers for the recommended way of doing this.

Cheers
Yoav

Earlier today we had an issue with parts of our application not working properly in IE 8. After some initial investigation the error we were seeing was 'r.body' is null or not an object. According to the JS, it was on line 43 of mixpanel-2.2.min.js

We think it had something to do with this commit:

a91d113

And, as I look at that again there are some new comments on that commit verifying our assumption. Our fix to get our users back going again was to pull the 2.2 release and host on our own CDN that we have setup. Is there a reason that 2.2 on your CDN was replaced with these fixes instead of rolling out a new versions on the CDN (e.g. 2.2.1, 2.2.2) and notifying customers of an upgrade? This caused about a 2 hour outage for out customers this morning until we figured out what the issue was and resolved it.

Also, is there somewhere I need to be following in order to get release notification in the future?

Hey folks,

So unless I'm mistaken, both alias and identify don't allow for a callback function - this seems suboptimal especially for identify, since that's supposed to be called on login. In our application in particular, we're doing something like this:

params =
    username: 'a-username'
    password: 'a-well-encrypted-password'
Session.save params, ->
    User.get id:'me', (user) ->
        mixpanel.identify(user.id)
        redirect_to_next_url()

The problem here is that it's plausible our redirect will fire before the identify call completes - I realize it's a bit of a race condition, but it'd be much cleaner if I could do:

mixpanel.identify(user.id, ->
    redirect_to_next_url()
)

The same goes for alias and signing up a new user. Any reason these functions don't provide callbacks?

If a user starts on an unsecure site, we put a record in local storage to this URL. As an example, the record will be written to http://www.gooogle.com and all Mixpanel information will be stored under this name.

Later on the site, if the user moves from unsecure to secure browsing, the library goes and looks for the information in local storage under https://www.google.com. Since the prior record was saved with http and not https, the library sees no Mixpanel information and instead creates an entirely new record.

Is it possible to save the Mixpanel information into one local storage record, regardless of the http versus https status of the webpage? Currently reporting will be broken if you use this model and switch protocols mid session.

See example here:

http://codepen.io/anon/pen/vOMPVM

As you can see here: https://github.com/mixpanel/mixpanel-js/blob/master/mixpanel.js#L4718 The instance is not set on the window until after the loaded event. Reported this already but posting it here, seems kinda serious.

Hi team

https://mixpanel.com/help/reference/tracking-an-event

currently the js blob will assign an array to the global mixpanel variable if the javascript cannot be fetch, wondering why we are assigning array instead of object (or even better, we can leave unassigned)

the reason is we are having defensive code against mixpanel when execute any commend using just check if (mixpanel), but as it is currently assigned an array, we are getting javascript error.

Thanks

I have a case where I'd like to generate some events server-side, but include as much info as possible from the user's current browser session. Ideally I'd call mixpanel._.info.properites, pass that stuff to the server, who would then add that info to the events it later generates. Unfortunately, that properties function's name is obfuscated by the minification.

I see that info.browser and info.device are already explicitly exempted from this obfuscation. Why not add properties to the list, for someone who wants -all- the props?

Thanks for considering it.

If one includes mixpanel.js in their Cordova application, messages won't get logged. The problem comes with the script tag that is generated and inserted into the DOM:

//cdn.mxpnl.com/libs/mixpanel-2-latest.min.js

By default it matches the same protocol the document is loaded under, which in Cordova on Android, is file://. The filesystem lookup for file://cdn.mxpnl.com/libs/mixpanel-2-latest.min.js of course ends up failing.

One possible solution would be to always use https://. If there's a clean way to merge the mixpanel.js and mixpanel-2-latest.min.js files into one (or even do it as a build step and provide the file in the mixpanel-js repo) and ship that, it would be preferred.

If I do a people.set before I have called identify I understand that it queues up the call and eventually sends the update when I identify the user, but when you eventually call identify the user is sent with the distinct_id before I called identify, a scenario might be:

1. New user visits site, distinct_id is set to random.
2. people.set is called (call is queued)
3. identify is called (distinct_id is set to 1), person details are sent with the original random distinct_id

To me would it not make sense that we send the person details with the distinct_id that we have set to at the time we call identify, I also notice that if it is a shared computer and you do not clear on logout, I saw it override users data with the previous persons as the distinct_id was in the cookie and the update would get attached to that earlier user.

Most of my issues are now resolved with the implemented reset() on logout, and ensuring I call identify before I set the persons details, but wanted to bring it up and see if anyone had any thoughts.

Hello,

We have a form with multiple buttons, and each one should send to a different Rails action.

<input name="free_subscribe" type="submit" value="Subscribe for free">

#routes.rb
# Routes the request to 2 different actions depending on which button was clicked.
patch :confirm, constraints: lambda {|req| req.params.has_key?(:free_subscribe)}, action: :free_subscribe
patch :confirm

Before using mixpanel.track_form, when I click a button of the form, the POST data includes its value: free_subscribe:Subscribe for free, and the right controller action is fired.

When we try to track the form using mixpanel.track_form, the button's value is not sent with the POST data anymore, and it makes it impossible, server-side, to know which button was clicked.

Here is a simple Javascript snippet that you can use to reproduce Mixpanel's problem in simpler conditions:

// Without this, clicked button's data is added to the form's POST data.
// With it, it is gone.
$('form').submit(function(evt) {
  evt.preventDefault();
  form = this;
  console.log('In submit callback');
  console.log(form);
  setTimeout(function() {
    console.log('In setTimeout callback');
    console.log(form);
    form.submit();
  }, 0);
})

Similar code can be found in Mixpanel JS library, in mixpanel.js#L1544-L1553.

Any suggestion on how to fix, or work around this?

Thanks,

David

Given a link of the form:

<a href="//somelink.com" data-download-link title="title here" target="_blank">
 some text here
</a>

I cannot successfully get mixpanel.track_links to work, via this:

mixpanel.track_links( "[data-download-link]", "Download Link Clicked" );

"[data-download-link]" is a valid DOM query string, however.

Don't have a PR at this time but it would be nice not to have to know the selector.

Do you have plans regarding cordova support?

There are two main concerns when it comes to cordova support using mixpanel-js:

1. The current implementation is cookie based
2. Offline support

There is a simple workaround for the first one which consists of replacing the current cookie implementation by a localstorage based implementation. Currently this is dirty but I can work on a pull request if you are interested.

I don't have worked yet on the second issue but I think we can build a local storage solution too. I think this would be awesome for cordova but this would help people who build websites with offline support too.

Recently when we run our feature specs I've noticed this error in the logs. Any idea on how to suppress the warning or prevent it thanks.

Mixpanel use underscore in method names (track_links, track_forms) and this naming conversion fails on most js coding standard validation (https://github.com/jscs-dev/node-jscs)

It is not possible to send an engage update that does not modify the $last_seen property of a People record. This is probably a rare use case, but it is annoying not to have this flexibility.

See http spec: https://mixpanel.com/help/reference/http#people-analytics-updates

Hi there,

It's possible that I am using this incorrectly but I am seeing this error: Cannot read property 'disable_all_events' of undefined

It looks like it is happening because I am tracking an event before init has been called. Is this allowed?

I've enabled mixpanel.track_links on some links on my site - however, when a user uses Ctrl+click to click on these links, they expect the link to open in a new tab - however, the link opens on the same page.

track_links works as expected when the user middle clicks, or uses command-click on OS X.

The snippet below from people.set includes the default people properties:

        // make sure that the referrer info has been updated and saved
        if (this._get_config('save_referrer')) {
            this._mixpanel.cookie.update_referrer_info(document.referrer);
        }

        // update $set object with default people properties
        $set = _.extend({}
            , _.info.people_properties()
            , this._mixpanel.cookie.get_referrer_info()
            , $set
        );

It seems like this should also be done with set_once to populate the initial referrer, device, IP address, etc... on a profile if they don't already exist.

Hi,

Question. I'm hitting 414 uri too long errors. I was reading the docs and noticed the recommendation to POST to mixpanel's endpoints (batch documentation). As far as I can tell it's not possible to configure mixpanel to use POST as opposed to GET, is that correct?

Ideally this would be an option, if not I would like to be able to use (import/require) this lib's encoding. Is either of these options something you would consider?
Out of interest, what's the reason for preferring GET over POST - (legacy) browser support?

Kind regards

Mixpanel events are not sent on Firefox 48.0.2 (MAC OS version). No errors are shown and the Network to api.mixpanel.com?data=... does not event appear in the console.

The exact same code works on Chrome and Safari. To note as well, i'm not able to see any calls to api.mixpanel.com (i know the identify method throws them as well, but nothing. I tmight as well be an issue with the identify method).

The track_pageview setting is true by default, but should be defaulted to false now that it's ignored in projects and pseudo-deprecated.This will suppress a lot of unnecessary mp_page_view events.

can you publish this on npm so it can be used with browserify?