Debugging Mixpanel track_forms

Question

Does anyone have experience debugging Mixpanel track_forms?

First of all, the Firebug Chrome console (when debug is enabled in Mixpanel config) shows an empty properties object for any track_forms event. Every other Mixpanel event has a populated properties object, with referrer, browser data, etc. Unclear if it's a console timing issue and the data is actually logged or whether the data is in fact missing from these events.

Second, I have a jquery-submitted form (submitted upon checkbox click) that is an event I'm trying to log to mixpanel. Regardless of whether I use track or track_forms, the event does not appear to log. If I add a breakpoint that delays form submission, the event does appear to log. So it appears to be a race condition and the Mixpanel timer is not working.

/* doesn't work */
var d={};
$('.ch').bind('change',function(){  /*checkbox click submits form*/
    d['checked']=$(this).is(':checked'); 
    d['value']=$(this).val();
    mixpanel.track("my event",d);
    $('#myform').submit();
});

/* also doesn't work */
mixpanel.track_forms("#myform",'my event',d);

Has anyone solved this before? This is a very basic use case of client side form submission.

score 7 · Accepted Answer · answered Jul 31 '13 at 00:18

It's not immediately obvious in the mixpanel docs but the mixpanel.track_forms() should be executed on page load. I suspect behind the scenes the mixpanel API inspects the DOM element looking for a child of type 'submit', then hooks on a 'click' listener in order to intercept the form submission so that the mixpanel tracking can be attempted before actually submitting the form.

I too wanted to have the form auto-submit when a form field changed, rather than having the user click a separate button. We still need the 'submit' input button, but it can be styled as hidden.

The following works for me:

    $('#lang_form_footer_form_select').bind('change',function(){
      $('#lang_form_footer_submit_btn').click();
    });
    mixpanel.track_forms("#lang_form_footer", "Language form - Footer");


    <form id="lang_form_footer" action="/i18n/setlang/" method="post">
    {% csrf_token %}
    {% get_current_language as LANGUAGE_CODE %}
    <input name="next" type="hidden" value="{{ redirect_to }}" />
      <select id="lang_form_footer_form_select" name="language">
        {% get_language_info_list for LANGUAGES as languages %}
        {% for language in languages %}
          <option value="{{ language.code }}" {% if language.code == LANGUAGE_CODE %}selected="selected"{% endif %}>{{ language.name_local }}</option>
        {% endfor %}
      </select>
    <input id="lang_form_footer_submit_btn" type="submit" value="{% trans "Go" %}" style="display:none" />
    </form>

Also one gotcha: make sure the input element doesn't have an id or name set to "submit" as this overrides the DOM selector.

you're right that `mixpanel.track_forms` intercepts the form submit and delays for 300ms to let its event fire before proceeding with the form submission. — Rob Sobers, Aug 28 '13 at 23:57
@dwightgunning Great catch. It does indeed work if I inject a type=submit element into the form AND trigger that element's click event rather than calling form.submit() event in my javascript. Also, there's a bug in the mixpanel js console logging where it does not log the properties submitted to the track_forms event in the console -- very misleading. However, I have verified that the properties do reach the MixPanel server successfully via their Live view feature. Not very straightforward to use & debug with all these gotchas, but mystery solved. — randalv, Sep 04 '13 at 21:26

score 1 · Answer 2 · answered Feb 19 '13 at 00:08

1

Calling track right before submitting the form won't work since the page change prevents the track from completing. That's why track_forms exists; unfortunately, it doesn't work for forms submitted this way.

The easiest way to do this is to track the data on the page that submitting lands on.

The best way to do this is to track the data on the server where the form data is being processed.

By the way, the properties paramter to track(_forms) is optional, so you can just do mixpanel.track('my event');

answered Feb 19 '13 at 00:08

raylu

2,630
3
17
23

Hi @raylu. I want to use the client-side library without having to depend on setting data into a subsequent request. Sounds like there's no way to do this. Too bad. – randalv Jul 30 '13 at 22:41
@randalv, when you submit a form, you already are sending data to the next request. That's why the best way is to track the data on the server. – raylu Jul 31 '13 at 00:03
wrong, track_forms was thought to do this. But the lib seems buggy – chesscov77 Aug 08 '13 at 22:35
In conclusion, the best way is to track the data on the server. – raylu Aug 08 '13 at 22:54
I found a way to do it. im using jquery: bind the form submission using $('form').submit(), then send your event to mixpanel, and create an interval using setInterval. then return false. Inside setInterval, submit the form directly using $('form').get(0).submit, and the handler wont be executed.. using 500 ms as interval is long enough.. – chesscov77 Aug 13 '13 at 22:31
@raylu, agreed the server-side code would work fine, just won't be visible for testing with the rest of the js console messages. At the time I posted the question I had only a client-side implementation, but I see they currently support a simple server-side module as well, with a track function that can be used in place of a client-side track_forms function. Juan, setInterval sounds like it would work fine to replicate the 300ms track_forms delay now documented in MixPanel docs. As dwightgunning noted, track_form requires a type=submit element. – randalv Sep 04 '13 at 00:16

Debugging Mixpanel track_forms

2 Answers2