Over the past few months, one of the sites I work on has had it’s fair share of, what I would classify as, an absolutely destruction-filled botting attempt. The unfortunate part is that it worked very well and ruined plenty of data that otherwise would have been great to have, including user eventing and abandoned carts. We were able to recover and clean this data, but the damage in time it took to figure this all out had been done. Here is how we solved a pretty massive, yet simple, bot problem on a Shopify store.
Let’s start with the basics… We saw a massive surge in user events, mainly “product added” events. Now these particular ones come through as a backend event (in other words, not fired by any frontend code, purely by backend action, this should have been our first clue). At first we thought this was perfectly fine, then we noticed these were turning into abandoned carts. Here we start digging…
We initially thought we were firing off multiple “product added” events. After spending some time on this we found that wasn’t the case. Then we started to think maybe it was the solution used to receive these backend events, nope that wasn’t it either. We stumbled upon the idea that maybe this was a botting attempt, possibly to mess up our analytics or generate fake accounts to then turn around and sell off. After looking at the IP addresses and location of these requests we found that most were coming from Ashburn and 1 other city, both with AWS locations, and all IP addresses listed as AWS being the owner.
Cool… so we are getting botted. Now how do we defend?
There are a few ways, but nothing 100%. Honeypot and captcha were the main solutions. We started implementing these along with one other 3rd party solution. After testing a honeypot, we noticed there still wasn’t many of these being caught. Ok so maybe they are a little more advanced, here comes the captcha.
Whilst adding the captcha one of the team members mentioned how the eventing history looked super strange. It did, how does a user add a product without loading a page? It should go “page loaded” -> “product added”, where was the page loaded event?
We started looking into possibilities and one this that peaked my interest was the potential for “direct to checkout add to cart links” where a user could add a product directly to checkout, and may or may not be redirect to checkout. Bingo, this has to be it.
We searched for where this link could exist, unfortunately it didn’t show on the eventing history because there was no page loaded event so we had to fly blind (as they say).
Eventually we found the problem. Recharge. Recharge is a subscription solution for Shopify stores and one thing they offer on their product page is a link that would directly add a product to cart and go to checkout. After testing, we realized this would also be the reason we didn’t see page loaded events since the page that loads is a part of the Recharge app codebase, and wouldn’t be connected to our analytics at all.
The solution: We took the product that was being affect, changed the subscription time, saved it, changed it back, saved again, and now when we look at the generated link it is different. Meaning we just generated a brand new link and the old one should be gone. Sure enough, within 5 minutes we saw a stop to all product added events with that pattern, and abandoned cart rate started dwindling.
