Building Better Beacon
Published ....
Last modified ....
Share this post on BlueskySee discussion on Bluesky
Over the past year or so we've been rebuilding a core library that supports tracking business KPI and metrics across our various web and native app experiences.
This involved quite a bit of work from a variety of teams, I acted as one of the lead architects in designing the web integration for the new system, and worked with my team to build it out and get the first iteration in production.
It had been smooth sailing for several months across the first few experiences that adopted the new version of the core library, at least until the other week where we identified a show stopping bug.
Background
The library leverages
navigator.sendBeacon
to post event payloads to one of our internal processing gateways, we use this
data to get an overall sense of how users are browsing and interacting with our
sites, and it powers key business metrics like our visits, add to cart rate and
our overall conversion.
We chose sendBeacon because of it's slightly stronger guarantee that the browser won't drop the requests when a page is unloaded or navigated away from. This gave us confidence that we could send richer content (via JSON payloads) than our previous system, and also allow us to track key interactions before they resulted in the customer navigating to another page.
Our previous iteration of this system, which was about 6 years old or so, heavily relied upon cookies and sending data via image requests (which greatly inhibited the size and fidelity of the data we could collect).