4 ms·

Speaking as someone who uses a ton of mixpanel in production (http://www.twitch.tv/ http://www.twitch.tv/) the way you handle this is to make all your calls asy

by emmett 14y ago

Speaking as someone who uses a ton of mixpanel in production (http://www.twitch.tv/ http://www.twitch.tv/) the way you handle this is to make all your calls asynchronous. I am bummed that we are going to have missing data though :-(

latchkey 14y ago
This works fine for code where you are just firing a /track 'ping' back to the server on a page load. But, if you are trying to do things like track login's where you send a http redirect right after /track, then you need to use the optional callback parameter to /track and do the redirect in the callback. The problem with this is that if their JS doesn't load at all (which is the problem right now), then /track is never called and thus the callback is never fired. So because you can't depend on MP to reliably serve up a simple .js file, you have to write your own wrapper around all of that code to do a timeout incase the callback never fires. What a mess.
- Skywing 14y ago
  I don't use Mixpanel frequently, but could you not just put the Javascript file somewhere more reliable? Why not pull their code down and put it on your own CDN? I've done this with Mixpanel in the past, I believe. This wouldn't solve their API endpoints not responding obviously, but it's an easy way to take the issue into your own hands for the time being. Also, I don't think I would ever make your core logic depend on events from something as dispensable as a third party analytics service. It just sounds like a poor design choice to have some core site functionality occur after receiving a response from something you do not control. I'd try to make those Mixpanel requests more "fire and forget", if you will. Edit in response to you response below: I think you're missing the point here. The scope of their documentation probably does not include best Javascript practices. You made some poor implementation decisions and now you're getting burned. At least now you have experience using third party services and probably won't be so trusting of them, again. Trivializing service stability and other things does not make your point any more credible, though. Personally, I think it makes people overlook your point because it makes it sound as if you have no idea what you're talking about.
  - latchkey 14y ago
    Yup, lesson learned. I definitely won't ever depend on Mixpanel again to do something as simple a reliably serve up a single .js file. I don't want to include their JS file because what happens if they make a change that I need? That said, their documentation should account for this better imho. There should be sample code which clearly illustrates that if you are going to rely on callbacks being fired, that you better also setup a timer to make sure that they actually get fired. Edit in response to your response above: Mixpanel sells themselves on being simple to use, from their homepage: "It takes less than 10 minutes and is incredibly simple." The reality is far from that. Yes, I made a mistake of assuming that their JS would always get loaded and their callback would always get fired. I fully own up to that and I've learned my lesson. That said, their documentation should also reflect that the callback may not fire and you should be prepared for that by doing XYZ. It is two lines in bold red text and I would have thought harder about depending on that callback to fire. It honestly didn't cross my mind that their js wouldn't load and it hasn't been an issue until now. I'm also not trivializing service stability, yes, things go down and that is a fact of life. That said, when you've got $10+ million in the bank, you can prioritize a bit of the money towards setting up reliably serving of a single file, that doesn't go down for hours on end. There are services, such as CloudFlare and CloudFront which are pretty damn reliable for exactly this purpose and yes, are trivial to implement.

by emmett 14y ago

latchkey 14y ago

This works fine for code where you are just firing a /track 'ping' back to the server on a page load. But, if you are trying to do things like track login's where you send a http redirect right after /track, then you need to use the optional callback parameter to /track and do the redirect in the callback. The problem with this is that if their JS doesn't load at all (which is the problem right now), then /track is never called and thus the callback is never fired. So because you can't depend on MP to reliably serve up a simple .js file, you have to write your own wrapper around all of that code to do a timeout incase the callback never fires. What a mess.

Skywing 14y ago
I don't use Mixpanel frequently, but could you not just put the Javascript file somewhere more reliable? Why not pull their code down and put it on your own CDN? I've done this with Mixpanel in the past, I believe. This wouldn't solve their API endpoints not responding obviously, but it's an easy way to take the issue into your own hands for the time being. Also, I don't think I would ever make your core logic depend on events from something as dispensable as a third party analytics service. It just sounds like a poor design choice to have some core site functionality occur after receiving a response from something you do not control. I'd try to make those Mixpanel requests more "fire and forget", if you will. Edit in response to you response below: I think you're missing the point here. The scope of their documentation probably does not include best Javascript practices. You made some poor implementation decisions and now you're getting burned. At least now you have experience using third party services and probably won't be so trusting of them, again. Trivializing service stability and other things does not make your point any more credible, though. Personally, I think it makes people overlook your point because it makes it sound as if you have no idea what you're talking about.
- latchkey 14y ago
  Yup, lesson learned. I definitely won't ever depend on Mixpanel again to do something as simple a reliably serve up a single .js file. I don't want to include their JS file because what happens if they make a change that I need? That said, their documentation should account for this better imho. There should be sample code which clearly illustrates that if you are going to rely on callbacks being fired, that you better also setup a timer to make sure that they actually get fired. Edit in response to your response above: Mixpanel sells themselves on being simple to use, from their homepage: "It takes less than 10 minutes and is incredibly simple." The reality is far from that. Yes, I made a mistake of assuming that their JS would always get loaded and their callback would always get fired. I fully own up to that and I've learned my lesson. That said, their documentation should also reflect that the callback may not fire and you should be prepared for that by doing XYZ. It is two lines in bold red text and I would have thought harder about depending on that callback to fire. It honestly didn't cross my mind that their js wouldn't load and it hasn't been an issue until now. I'm also not trivializing service stability, yes, things go down and that is a fact of life. That said, when you've got $10+ million in the bank, you can prioritize a bit of the money towards setting up reliably serving of a single file, that doesn't go down for hours on end. There are services, such as CloudFlare and CloudFront which are pretty damn reliable for exactly this purpose and yes, are trivial to implement.