Tracking events that are triggered server side but sent client side when doing xhr requests

[msaspence]

I have an app, that in addition to using pjax is doing lots of ajax, all of this gracefully degrades without javascript. What is the best way to handle the mixpanel events triggered in both these xhr requests and their normal http alternatives, given that both share the same application logic. The options as I see it:

1. Leave them in the session queue until the user makes a proper request: This isn't really an option. There is no guarantee the user will visit another page, and if you're using pjax they're unlikely to do a full request until their next session.
2. Only send events server side (with #track rather than #append_track): This seems like the best solution, but to do async means setting up redis which I'd like to avoid for the sake of keeping our stack simple. Can I do it with delayed_job maybe?
3. Trigger the same events on the javascript callbacks with the mixpanel javascript library - this isn't very dry and I know at some point I will leave two event triggers out of sync.
4. Patch the mixpanel middle ware to insert the event tracking script at the end of the xhr response (since it has no head or body tags): This would add to the response time (when the whole point is to make the app feel really snappy, more than negligible though?), and feels like it would be very brittle (oh stick it on the end of the response somewhere, there's a good chance 3rd party javascript libraries wont be able to handle it, and suspect it would require a lot of config of xhr to opt in or out). Would also need to be wrapped in <script></script> when the xhr is returning html but when returning json then the request would need to be jsonp and the mixpanel code would need to be outside the callback.
5. Patch the mixpanel gem to provide an http end point to retrieve the current mixpanel tracking script so that it can be retrieved after each ajax and pjax complete call back: This some how feels a bit messy making another request for the data, but then its data the user isn't waiting for so it make sense to separate it and would ensure it doesn't interfere with the javascript handling the response. This is how I'm currently doing it (but in my application rather than in a forked gem)

Essentially what I'm asking is, is there another better way that I've missed? And if you are interested in 3. or 4. as a pull request? I think having thought over my options as I've written this issue option 2. is best or me but I still wonder if there is a use case for 3. or 4.?

[zevarito]

Hi @msaspence,

Sorry, I hadn't time to answer you before.

If I understand your problem correctly, I am seeing as only option to track events with a queue or even a simple cron job can make it work.

To avoid repetition you can wrap the lib with your own class that will use Javascript if it is available on the client or his http counter part if it is not.

Please let me know if you understood your problem correctly.

[zevarito]

By other hand, I was thinking a little bit about the Gem design, and thinking loud it might be interesting to stop using a middleware to inject scripts. Just call a method from the layout that adds Mixpanel js snippet and a small piece of code to handle XHR responses globally, that way tracking metadata can be passed through response headers.

[msaspence]

Yeah I'm using delayed job to queue events so not so much a problem for me now

However your suggestion makes sense to me as a better implementation for append_track as it removes the requirement for a html doc in the response body

[zevarito]

Well actually you should include it in your layout once. Then use just headers, I hope to get time to do it.

On Sunday, February 24, 2013, msaspence wrote:

Yeah I'm using delayed job to queue events so not so much a problem for me now

However your suggestion makes sense to me as a better implementation for append_track as it removes the requirement for a html doc in the response body

— Reply to this email directly or view it on GitHubhttps://github.com/zevarito/mixpanel/issues/77#issuecomment-14018855.

Alvaro