Every silver lining has a cloud
Thanks to the proliferation of cookies, pixels, cursor-tracking, and all manner of other surreptitious activity in your browser, companies today who want to use your browsing data to better sell you something (whether a product or a politician) have more power than ever before. Yet at the same time, consumers are growing more and more savvy about the ways they're tracked and profiled online, and have a growing number of tools to stop websites from doing it.
The problem is, most "bad" data-gathering piggybacks on "good" browser technologies with legitimate uses in making functional websites. So when people start trying to block the most egregious tracking activity, they often end up breaking the sites they actually want to visit.
The dreaded Spektrix_bounce=true
This is exactly what happened when Apple released version 12 of their Safari browser, which boasts "enhanced intelligent tracking prevention." All of a sudden, websites integrated with Spektrix for ticket sales just stopped working for many Safari users. Worse, they stopped working in a very specific way that didn't give users any information about what the problem was — or even any error message.
Instead, when a user clicked on a link to book tickets while "cross-site tracking" was switched on, they were kicked back to the website homepage with no explanation at all. The only thing you might have spotted, if you were a particularly eagle-eyed user, was the telltale addition to the page URL, showing there had been an issue: "?Spektrix_bounce=true"
Getting to the bottom of the problem
Safari has a relatively low share of global browser usage, so many websites seemed content to leave the issue without a hotfix while Spektrix worked on a permanent solution. However, one of our clients running Spektrix receives a large number of visitors via Safari, and wanted to ensure they weren't losing sales. The obvious solution was to add a message to the booking journey telling customers how to change their browser settings. Unfortunately, as with most sites experiencing the issue, our client's customers were getting bounced out of the booking journey before they had a chance to see any message, so this solution wouldn't work.
Moreover, we couldn't put any kind of message on the page where customers were ending up, because this was the client's main homepage — not the sort of place where you want to advertise that some people simply won't be able to use the site! We also couldn't display conditional messaging just to Safari 12 users; for one thing, this would also capture users whose Safari 12 was already working, but in any case doing that kind of browser-conditional content is not considered great practice in modern web design.
Instead, we got in touch with Spektrix to better understand what was triggering the "bounce=true" message, and the rather tricky answer turned out to be: everything. Indeed, this was actually the root of the problem, because part of the Spektrix booking process involves temporarily redirecting users to Spektrix itself. When they're bounced back they're supposed to be returned to the page they left from, but Safari seemed to be withholding this information — hence the default return to the homepage.
Putting a fix in place
Now that we better understood where the "bounce_true" string was coming from, we realised we could use it to our advantage. We audited all the current routes in and out of the booking process and determined that there was no situation where a user would intentionally end up on the homepage with the Spektrix_bounce message.
This meant we could write a piece of code to look for users arriving at that specific URL, and instead of displaying the normal homepage show them a message explaining there was a problem and how to fix it. Though practically this would only show up for Safari 12 users, it didn't rely on any messy browser conditionals and wouldn't capture users whose Safari already had cross-site tracking switched off. And when Spektrix eventually put in place a permanent fix for the issue, the error message naturally "disappeared" without us having to reset or further tweak the code. (Or, more importantly, without having to bill any further hours.)
A happy(ish) ending
We were glad we could put in place such a relatively simple fix for our client. Obviously it was only a stopgap until Spektrix fixed the issue more permanently, and it was still far from ideal because ultimately Safari 12 users still couldn't purchase tickets without changing settings or changing browsers — a significant barrier.
In the meantime, though, at least users were getting useful information about how they could solve the issue themselves. This was a much better outcome than simply dropping them back on the homepage with no explanation, and there was clear evidence that the solution worked: in the week after we put in place our fix, the percentage of sessions that resulted in a sale increased by nearly 15%, and overall sales via the website increased by 4%. A good result any way you look at it!