Segment events canceled by browser


When testing Segment integration on Chrome I was able to create a scenario where Chrome would cancel the XHR request sending data from the browser to the Segment server. Scenario:

* Using the standard Segment snippet

* Making a track() call

* Issuing a redirect using JavaScript in the browser

* The redirect is being issued right after the on track event is fired.


The Segment JavaScript will be downloaded to the browser. The "real" implementation of the track() function will run, accept the payload, add it to the send queue (I believe using localStorage). Then the redirect command is issued. During the page unloading phase of the browser (I believe during beforeunload) the Segment JS will start the XHR request. Then Chrome will cancel the request (as seen in the Network tab in the Dev Console). Then the target page will load. I do not see the XHR request being reissued on the target page despite the Segment documentation indicating that it will detect delivery failures and retry. I suspect that that browser is performing a preflight request and canceling the request before the real XHR request is made. I then suspect that the Segment JS code that detects XHR failures is not implemented in a way to catch these specific types of cancelations. 

Is this is known issue? What would be helpful to debug this further since it appears to be causing data loss? Thanks!

3replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • hi there  Brian,


    Thanks for posting! I'm fairly confident this is expected behavior from your analytics.js library.

    I believe that for this use-case, we created a .trackLink() method, documented here.  Can you let me know if this helps?

    thanks again!

    Reply Upvote
  • My understanding is that trackLink() is specific to tracking clicks on an individual element in the DOM. In my use case the track() is NOT triggered by a user clicking an element in the DOM. The track() call is triggered by a separate, user-independent event. So I don't believe trackLink() will work for my use case.

    Additionally, I'm aware that the track() call itself also has a callback parameter that will wait for a period of time (defaults to 300ms, but is configurable via the timeout() call) before making the callback. My understanding is that the purpose of this timeout is to allow the Segment JS time to send the track event payload to the Segment server. However, the problem with this solution is that the 300ms is arbitrary. It is implemented with setTimeout and needs to be tuned. Tuning the timeout value forces a tradeoff between waiting long enough to hope that Segment delivers the data vs waiting too long that negatively effects the user experience while they wait for the page to redirect.

    I thought that the Segment retry technique should solve this problem so that we don't need to worry about the page redirecting because any failure will be retried on the subsequent page. However, this does not seem to work in the case where the browser cancels the request.

    Reply Upvote
  • hi  Brian, thanks for your reply and for clarifying the use-case a bit more. My apologies - .trackLink() is not the right approach in your case.


    The Segment retry behavior we've just added to analytics.js was not intended to address redirect behavior nuances. 

    In your use-case, if you absolutely need assurance that our API has ingested your event before you redirect your page, you might have to engineer a custom solution to maybe listen to 200 responses from our server before issuing the redirect. That way, at least, the delay (similar to that introduced by the timeout and callback) is not arbitrary but rather justified by your absolute need for confirmation of delivery.

    Additionally - perhaps moving some tracking to the server side could help - but it would really depend on your use case details and the various destinations you wish to send data to.

    Reply Upvote