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
* The redirect is being issued right after the on track event is fired.
Is this is known issue? What would be helpful to debug this further since it appears to be causing data loss? Thanks!
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?
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
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