Ad block shouldn't break your checkout | Hacker News Reader

Ad block shouldn't break your checkout

ilakovac.com

193 pointsinfomiho201 comments

Your checkout shouldn't trigger ad block. Stop slavishly bowing to GA everywhere. I'm about to give you money. That's the only 'analytic' you should care about.

I'm tired of being treated as little more than a data cow, always ready for milking.

Just. Stop.

To the person who ignores people who complain because their 'non-standard' browsers fail on their site, why do you have a site if you don't care about your users accessing it? Ego much?

> I'm about to give you money. That's the only 'analytic' you should care about

Yeah, but who are you? Are you an impulse buyer? Returning? Did you spend an hour on the product page? Did you jump between 20 different product pages?

You can't deny that this kind of analytics can be very useful for user conversion and website design. And the site in question tries to do the proper thing, checking if GA works before trying to do stuff with it, so it wouldn't just fail if GA was blocked by the user.

That's great, but all of that tracking is pointless if I can't actually complete the sale

That's not on TeeSpring, that's on Ublock Origin, which replaces the GA object with a dummy. The user is running code on their local machine that breaks his/her own ability to complete the sale.

And practically speaking, the back-stop is that if uBlock Origin causes too many high-profile websites to break, it'll get a reputation for degrading user experience and fewer users will install it.

When two independently-owned systems on the web break each other, "who needs to fix their stuff" is a question more of social networks and business politics than technology. TeeSpring's "fix" could be to pop a banner that says "WARNING: uBlock Origin breaks this site and we can't test for that."

That's not how it ends up working, though. People just share screenshots or tell friends of the broken website and people stop using the website not uBO.

And there are sites that will throw up a banner that says 'Adblockers might break this, if you have problems disable your Adblocker and try again' which is pretty effective. Funny enough, in my experience, sites with that banner tend to work with uBO enabled (probably because they're testing it).

> TeeSpring's "fix" could be to pop a banner that says "WARNING: uBlock Origin breaks this site and we can't test for that."

That'd be great. Then I, as a user of uBlock Origin, can nope-out of the site before wasting too much of my time and the site's resources.

> that's on Ublock Origin, which replaces the GA object with a dummy

There's absolutely nothing wrong with this. The blocker does it because just deleting the object would let obnoxious websites to detect its presence and punish users for it.

The better question is why their checkout completely breaks because of this. Their reliance on Google spyware is 100% on them and they are losing sales because of it.

It's not a very good dummy then as it's trivial to detect. PoC already exists in TFA.

Modifying client code (especially with an addon you do not control) and then complaining to the original code owner when functionality stop working is wrong.

Analytics and ads are annoying, I get it. However if you use an automated script to clear them out, be aware that some things might brake.

If Ublock Origin devs think they need to replace GA with a dummy to stop tracking they should've put a copy of the original interface with empty functions into it so the flow doesn't throw exceptions when the app tries to use it thinking everything's fine. Those scripts are publicly available and aren't a secret.

If your site put a selfish arrogant tracker in the way of completing the order... then you lost the sale. And the customer, who won't be coming back. I don't give a good god-damn about how it's "part of the site". It's not part of the transaction, and you put it there, and it broke things.

That's on the site for requiring tracking to be successful in order to take my money.

They shouldn't require tracking to succeed in order for me to buy the product. If they want tracking, sure. But be resistant to it erroring out. Don't let errors in 3rd party tools prevent your user from getting their core goals completed.

The same goes for client apps. Don't crash the app if it fails to log to a file. Don't crash the app if it can't sync your cache. Etc, etc. Don't let these unnecessary conveniences get in the users way.

The checkout shouldn't rely on GA.

Tracking should rely on the tracking service, not the checkout process

> Yeah, but who are you?

I am none of your business.

If you're trying to buy from me, who you are is literally my business.

And I'll happily fill out a form to tell you any information I feel is relevant to my purchase. If you want to covertly fingerprint and track me, I'll gladly take my business elsewhere.

No it's not. My shipping and payment details might be, if I decide to buy anything. Those are not the same as "who I am."

What I buy from you is your business. The information I give you to complete my transaction is your business.

Who I am is not.

You don't need to know if I have kids, have a disease, my age, my race, my gender. You don't need to know anything. Sure that information would help you make a better experience for me, I get that. But that's up to me. If I want a better experience, allow me to provide that information in exchange for the benefits that information gains me. But peeking over my shoulder as I walk through your store so that you can overanalyze everything I do isn't okay.

You, personally, are not. You, one of a cohort, kind of are.

If i run an e-commerce site, and see the vast majority of my users, but the minority of those that buy stuff, are on mobile and from India, maybe i need to optimise my site for mobile and lower-speed connections? Maybe something is wrong with my payment for specific currencies?

If i run a blog, ans the majority of my viewers come from France, maybe it's time i start writing localised content in French?

You get the gist.

You can see those things with just server logs.

No, you can't. There's no way to get viewport from server logs, and presenting them a form digestible by marketing people isn't easy.

I get the gist, you believe you’re so bad at running a shop and/or writing you can’t survive without creeping on people.

Also, look at both of your examples. They’re bad. They’re both best replied to with that diagram of holes on a WW2 airplane.

And for all of that, you need GA because...?

Because it's easy and marketing people can work with it. Access logs don't have all the information ( e.g. viewport) and are cumbersome to parse.

> this kind of analytics can be very useful for user conversion and website design

Excuse my ignorance on web development, but why? How?

It provides work for your marketing and sales people.

Well done analytics can give the tracker a lot of information about if the user got there from marketting or other outreach, what they did on the site, and if they took some action that's important to the site operator (buying something, creating an account, posting, logging in, whatever), and what page was the last thing they did before they left.

If you're selling stuff, and you notice a lot of people going partway through your checkout process and leaving, it might be a sign that something in the process isn't user friendly and improvement could benefit you. Especially if the behavior has changed recently.

You might see that people come in from a marketting link where you thought they'd like to buy A, but they rarely buy A, and if they do buy something, they buy B; maybe it would make sense to use that link to go to the sales page for B instead, etc.

You could even notice that people who don't run your javascript analytics still add things to the cart, and start the checkout, but never finish, and take that as something to investigate.

This isn't a defense of Google Analytics in specific, or javascript analytics in general, this could be done serverside with just a cookie to corellate across multiple visits, or a session cookie within the same visit, or instrumenting all the links and correlating that way. Javascript could be used to remove tracking tags for copying links, but have it when clicked; great if it works, not the end of the world if it doesn't.

I always try to just these things based on physical analogies. The clear analog for visiting an ecommerce store is walking into a physical store with a shopping cart. Maybe the physical store has cameras or some other way they track people. In any case they probably aren't watching every single customer to determine which aisles they walk down, if they pick up an item without putting it in their cart, etc. Let's say they are doing that though, for the sake of analogy. It's strange to me that people are ok with that, but let's move on..

Now, since an adblocker doesn't change anything anywhere except on the end user's computer, the analog should be something on the customer's person, or some part of their behavior. So let's say the customer tries to avoid identification by wearing a hat, and they purposely grab every item and put it back on the shelf to mess with the data about their shopping habits.

Do you think it makes sense for the cashier to refuse to checkout anyone who is wearing a hat? Or if they spotted someone who picked a few things up without putting them in their cart?

Because I sure don't.

Unless you're a big or medium sized org, fixing an issue that is seen by less than 0.01% of visitors is probably waaay down the priority list on the backlog

I beg to differ, we've run into issues with ad-blocking before and our target audience is definitely NOT on the tech-savvy side.

I worked for an e-commerce outfit for several years. Let me tell you they don't have massive budgets to use for R&D. Every last one of them uses off-the-shelf solutions, they have to, because they can't afford to pay a programmer to customize one for them. Their marketing teams work around the limitations of the software.

And they'd be absolutely blind without GA. There's no magic window into customer behavior. If you were actually in a physical store then they could look at you through the cameras. This way they can know if there are basic problems with the store.

With a website, they would have absolutely zero way to know what your experience of shopping there is like without a tool like GA. The only data they would have at all is sales numbers. The experience of shopping online would be immeasurably worse without it.

> And they'd be absolutely blind without GA.

Good.

> If you were actually in a physical store then they could look at you through the cameras.

That's a gross idea to have.

You must think a store is just a place managed by genies or something.

I'm pretty sure it's managed by people, and doesn't need to constantly surveil people to function.

No store owners I know manage their store through camera feed.

Don't try and talk sense into the commenters here. Their use case is the only one that matters, and they lack the imagination to think that other people have different budgets, time, or expertise than them.

There are people here who believe Google Analytics is the absolute devil, the reality is much more benign.

OP saying that "I am not a data cow" is just missing the point. GA is logging when you visit the website, some interactions like clicking a link, and generally not much more than that. It is not indexing your hard drive or downloading your photos.

Go somewhere in person and there's probably orders of magnitude more data being collected on your activities.

No excuse for breaking the website with the tracking though. NULL is a valid field in databases for good reason.

It checks null. It doesn't check for some nonsense thing inserted by a third party.

There might be other solutions besides Google, though. I'm not knowledgeable in the field but Matomo [0] (used to be Piwik) might be interesting, and there's likely other options which might be better in some ways.

[0] https://matomo.org/

I agree with you on the importance of GA for the e-Commerce. But you shouldn't actively prevent users from buying things because GA is not not working (in that case, because of uBlock).

Because of the pandemic, I go to stores wearing a mask. That might prevent me being identified by the cameras (IDK), but the cashiers still sell to me.

No.

The standard web analytics tools of the late 90s basically parsed the http log. Even those will give you info equivalent to "looking through cameras".

You might want GA, you might even need it, but you're absolutely not blind without it unless you choose to be so.

Good luck training your fresh-out-of-college marketing team on your homespun http log analytics tool. Even if you succeed, your CFO will convince your CEO to move to GA eventually. Ask me how I know.

What if I told you that the majority of people on a checkout page, don't actually check out, but abandon the cart instead?

"How would you even know that?" I hear you ask. Well, that's an interesting story....

Plenty of ways to get that data without invasive tracking like GA.

Is the invasive part that the data is going to GA or that the failure-to-close-sale is explicitly being logged at all?

abandoned carts are pretty commonly stored in a database so a followup email can be fired off later in the way. You don't need GA for this.

I hate when they do that. Obviously if I've abandoned the cart I had a reason for it, most likely the shipping fee is too high. If you haven't changed it don't spam me.

Sure, you don't need GA for that. In the same way that you don't need AWS, you could just deploy to on-premises servers.

But people pick AWS because it offers a lot more than just a storage bucket. Same with Google Analytics. It offers a ton of ecommerce analytics including custom tags that can be set by the shop owner. TeeSpring is probably not a full-service Ecomm platform like Magento. It's likely that they are piggybacking on GA's built in Ecomm tracking and reporting capabilities, instead of reinventing the wheel by doing it themselves.

FYI, Ublock Origin also blocks links to "sponsored results" shown on Amazon search.

I hate to be the one to break this to you but GA usually isn't as invasive as you seem to think. It's mainly tracking things like time on a page, links clicked, bounce rates, etc.

It's not deep scanning your hard drive to try and figure out your SSN or medical history like some people think.

I’ve seen adblocks take out anti-fraud libraries, localization libraries, accessibility libraries. They target things they shouldn’t.

Load these things on the main website too, so it can be fixed on the first page, not on the checkout page. Some of us train the adblockers (at least locally) by whitelisting exceptions to the default BLOCK EVERYTHING rule / the current rules provided by the shared lists.

“Anti-fraud” is just another word for spyware. If my bank supports 3D-Secure then your exposure to fraud is zero and you have no reason to stalk me for “anti-fraud” purposes.

No one uses 3D secure in the US. As a consumer I don’t use 3D secure because it shifts the liability on to me. Why would I expose myself to that risk when using the card number puts all the risk on the merchant?

There is also more than just unauthorized purchased. There is also card testers that test to see if the card is still valid.

My point is that if there's zero exposure to fraud then the purchase should go ahead regardless of whether the anti-fraud libraries load or provide a negative result.

So this means that users who expose the site to fraud must allow the anti-fraud libraries to track them, or switch to a bank that offers 3D-Secure so that liability is shifted to the bank and they no longer need to be tracked. Seems like a win-win situation.

> There is also card testers that test to see if the card is still valid.

Same scenario applies? If it's protected by 3D-Secure, who cares? The bank will end up paying the cost of it, not the merchant. If anything, this is a problem I'd love to have, as it means if I can identify those reliably I can keep pocketing money without even having to send out any actual goods.

GA? Some carts have 20 other sites they contact.

I have a backup browser for this. My main browser is locked down so tight it would take me ages to disable all the protections.

I remember trying to order from a pizza place that talked to a third party delivery site, I hit "Order" and the browser didn't do anything. DevTools told me it tried to talk to the 3rd party using HTTP although the page was in HTTPS, and the browser blocked it (this was years ago when browsers started blocking HTTP content on HTTPS sites). Modifying the submit URL to https solved the problem.

I found it pretty funny that I had to understand web development and troubleshoot the problem just to order pizza...

Same thing happened to me with Domino's Canada. The call to place the order was returning a well-structured JSON error message (it didn't recognize the city I had entered, which was my suburb rather than my "post town") but the front-end wasn't telling me anything!

This is why I always call to order for takeout or delivery. I'd say that 75% of the time I experience some kind of technical issues with online ordering. Just talk to the human at the store.

I can't help but think of the article on posted on here about a week ago with the old woman who refused to order milk online after her service canceled phone ordering.

More and more businesses are adding prerecorded responses and menus to their regular line. It’s a matter of time until we completely automate delivery calls too, I guess.

Then I'll either go there less and just order in person, or not at all.

The whole reason I call is E.G. Round Table Pizza had a perfectly good "Web 1.0" website. Instead of updating some CSS rules to make it render better on mobile they seem to have outsourced to a third party and now everything performs worse and has it's own clunky hell. So instead of using a shit re-design on a website I just call on the phone.

I find calling is not just for take out unreasonably effective.

Somehow (well, we know the reasons) many websites and platforms require you to have a full inner model of its workings if you want to get things done. If you call, more often then not the person calling you does that work for you.

I've found that half the time whatever site I'm trying to order with doesn't work, either due to Safari, adblock, or whatever. Sometimes doing it in Chrome helps, but not always. Even if it works, I need to create an account and set up another email aliases for the site (since every site gets it's own alias).

I've learned to just call orders in these days.

The value add of Skip/UberEats/GrubHub is more obvious now. At some point it's just nice to have an app that worksz even if you pay a premium for it.

The killer for me is Indian places that only offer their mildest spiciness when you order online, but ask you for a spiciness level when you order on the phone. Absolutely brutal.

Similar story with Dominoes UK, where signin doesn't (or didn't a couple of weeks back) work with uBlock.

> Hi, is this pizza abc?

> Yes, can I take your other?

> No, you don't get it, I'd like to file a bug report, but your website clearly has no feature to create issues so, when the field city has the value...

> Sir, I cannot fix the website. If you do not wish to make an order please hang up.

> Uhoh ok, sure, I'd like an anchovies pizza but instead of anchovies I'd like you to make sure that when the field city is set to Boston...

> Sir, I really cannot fix the website

> Couldn't you just make a note and leave it in the front door? So that if other customers have the same problem they can upvote the most common issues and then you can prioritize fixes and get a reasonable budget for each one?

> I obviously can't do that, do you want your anch...

> Of course you can't! That would be reinventing the wheel! Let me point you to the github...

I tried to move non-software related committee meetings to github because I liked the collaborative process

thats pretty funny to me now

Reminds me of pizzatool. Today, probably nobody under 40 would have ever used it. https://instructabest.blogspot.com/2019/07/the-story-of-sun-...

I tried to order something from an online store, the “place order” button did nothing. The json response was nice enough to tell me to contact their bank responsible for the payment integration. A part of me wonder how things would turn out if I followed their instructions.

I've gotten a little more paranoid in recent years and started blocking outgoing requests, just as a defense in depth. So I would prevent clients from connecting to anything but 22, 80 and 443 (to start; I added more for things like WebRTC and Amazon Streaming which uses AWS). I found a checkout that was connecting over some random port and wouldn't work until that was unblocked. Fucking annoying and I'm just left wondering how long until they have a security breach through their non-standard proprietary bullshit.

Hang on: The Tee Spring code checks if GA is there and works without it, the website breaks because Ad block replaces GA with a fake object that doesn't have the same API.

Perhaps some companies have the resources to check if their websites run with different ad blockers, but expecting websites to work when plugins are replacing and breaking running code is a big ask.

Don't put GA there, then.

I think the point is that Google Analytics shouldn't be an essential part of your site, so it totally breaking for any reason should be unnoticeable to the end user.

If it had broken, the code in the post would have worked. How exactly is code supposed to handle a dependency existing, but not being the API shape that it should be because a browser extension added an incomplete stub? Should every line of code get wrapped in try/catch?

There's a big difference between "resilient against a missing dependency" and "being resilient in the face of getting literally any object instead of the dependency you expected to get."

> Should every line of code get wrapped in try/catch?

Everything Google Analytics does is expendable, so the block of code that deals with it should be wrapped in try/catch.

> There's a big difference between "resilient against a missing dependency" and "being resilient in the face of getting literally any object instead of the dependency you expected to get."

If Google pushes a breaking change to the Google Analytics API tomorrow, that shouldn't break checkout either.

> Should every line of code get wrapped in try/catch?

For third party dependencies that might not get loaded for whatever reason? Yes, sure. There are better ways to do it, but that's the idea.

The code listed does check if it's been loaded. The stub that gets loaded is wrong. How do you guard against that?

It's not. It can work without it. The issue is something is pretending to be Google Analytics just enough to cause problems.

> Perhaps some companies have the resources to check if their websites run with different ad blockers,

Checking the top 3 adblockers that command the majority of market share would be a much smaller ask - maybe smaller than a check-mobile-browser sized ask.

Yeah this is very clearly on the ad-blocker.

I think TeeSpring has the right idea - they're checking that GA is loaded, if it is, then do stuff with it, if it's not, then don't.

I don't understand how a website can and should be expected to adapt to a browser plugin changing the APIs they depend on out from underneath them.

> I think TeeSpring has the right idea - they're checking that GA is loaded, if it is, then do stuff with it, if it's not, then don't.

I think they could go one step further and may be try...catch (sandbox) all access to third-party services that aren't critical.

User-agents, which browsers are, expectedly do put a lot of control in the hands of the end-users. Such breakages should be factored in and worked around (provided there are enough engineering resources to throw at the problem, of course).

Exactly. A browser's job as the user's agent is to do what the user wants it to do. It's not an ABI. If an end-user's browser is configured to do something you, as a developer, don't want or expect, and that breakage causes the loss of a sale, it's kind of on you: Either take a principled stand about "what browsers should be doing" and accept the lost sale, or try/catch around non-critical code to make your site more robust to the user's configuration choices.

The ad blocker is probably trying to do the right thing for their users, to. Too many websites check that GA is loaded, if it is, then do stuff with it, if it's not, then redirect to a "Please disable your ad-blocker" page.

I think the key point is that the only way to do this right is to have a quirks list and both implementations, and pick the implementation based on that list.

Why does checkout depend on Google APIs?

I believe that Firefox is replacing some Facebook JavaScript with a stub, to avoid that sites break because some tracking bits are missing.

So the reason why the GA object is replaced, rather than removed, is because removing it would break other sites. Tee Spring is trying to do the right thing, but fail because other sites don’t do the same.

Both uBlock Origin and TeeSpring are trying to do the right thing, but in incompatible ways. I would say in this case the onus is on uBlock Origin to provide a stub that is as transparent as possible.

But you don't even need to check, you just don't blow up and still check out if it doesn't work?

Put it this way, forget adblock, if the GA call fails, it should still check out. (Assuming the problem doesn't affect other stuff too, like internet down or whatever.)

I think the problem is that with the code-as-written, if the GA call fails, the relevant `window` field won't be populated, which the code is detecting.

Given the hyper-malleable nature of JavaScript in an HTML page in a user-agent owned by the end user, at some point the developer has to draw a line in the sand and say "This category of failure modes is not checked," because it's mathematically impossible to check all possible failure modes in that configuration. "An extension is intentionally faking an object in the `window` context" just happens to be on the other side of the "don't check" line for this application, because it's extremely unlikely (and, one could argue, user-self-inflicted).

Just stop using Google spyware. Takes zero amount of resources.

Chrome store says 10 million+ users (I expect it's vastly higher than that) 24,000 reviews. Firefox says 5 million users and 12,000 reviews.

Ignore it at your peril. If you want to make sales, you need to test the ways your prospective customers want to buy.

I’ve been running into this sort of thing more and more and more. It’s crazy how many page rely on some kind of google tag manager event before they’ll load the real content or perform the main function of the page.

Don’t all developers have ad blockers (clearly not)? I understand managers not testing for this, but for my own work it’d never load for me as a Dev, even.

I have this problem too. Every time I want to order something from a new place I have to work out what out of 50 domains actually needs to load in uMatrix. The funniest one is the garage. When I book a time for service I get a confirmation but when I show up at the garage on the date/time booked, they can't find a thing in the system. Or sometimes they just find an empty booking that doesn't even have my cars registration number. I bet it's connected to uMatrix blocking some part of the transaction.

I don’t have an ad blocker on my work machine. The light web browsing I do on that machine mainly involves docs, internal resources, and sites like SO — which don’t have any ads or have very inobtrusive banners.

I really think we're approaching the point where this argument is the same as "I don't wear a seat belt when I drive to the corner store. It's right around the block and I never go above 10mph anyway."

IMO, this points out the inherent and unresolveable contradiction between browsers being a user-agent, and browsers being a precisely-specified execution environment for arbitrary applications. A browser that is built to operate in the interests of its user will not run code that is harmful to them, whether that's code to track them, code to mine bitcoin, or code to display advertisements. On the other hand, a browser that is compliant with the (largely advertising-company-defined) web platform standard will do all these things, and can't permit any user-agent features or extension mechanisms that would interfere with them. The web platform standard as we know it essentially specifies that the browser belongs to the website operator (within some sandboxing guarantees), not to the browser user. On the whole, I prefer that software I run on my computer belong to me; this makes using the web a necessary evil at best.

The answer to the contradiction is to test with uBlock.

The existence of Firefox as a counterweight to Chrome means that the web standards are not going to win. Ads will be blocked. Cope and deal.

> The web platform standard as we know it essentially specifies that the browser belongs to the website operator (within some sandboxing guarantees), not to the browser user.

And that is precisely the problem. Once website operators get it through their thick heads that the browser is user property, not theirs, things might start to improve.

TBH I don't see this as a TeeSpring problem - the code on their page guards against a realistic scenario (the GA script fails to load), but the "break" is caused by uBlock's changes.

The article's title is correct: ad block shouldn't break checkout. Injecting a bogus value into a global breaks checkout, so ad block shouldn't do that.

I agree with that, though if I'm TeeSpring, I'd fix it anyway. It's silly to throw out incoming business. I assume the same thing would happen if there were a brief GA outage.

If GA is unreachable then window.ga wouldn't be defined.

The author is running an extension that specifically injects code to make window.ga into something unexpected, and then complaining about it.

Yes, though again, throwing out a checkout session for anyone running that extension isn't wise.

"If GA is unreachable then window.ga wouldn't be defined."

The legacy code you insert for GA does: var ga = document.createElement('script'); first, then loads GA. Wouldn't that have the same issue if GA is unreachable?

Doesn't matter. Anything that is not the main goal (in that case, the checkout process) should be isolated and not break it.

That may be true from a technical perspective, but it ultimately is TeeSprings problem. The problem they face is lost revenue from people who already clicked the purchase button.

I do see it as a TeeSpring problem. This particular bug got in my way 2 weeks ago when I was attempting to buy some merch to support a youtube channel I frequent. I almost abandoned the purchase.

A shopping site breaking checkout when there's a google analytics problem is madness, IMO. uBlock Origin is hugely popular. With 10M (claimed) active users, you should probably be testing against uBlock Origin for your e-commerce site.

As an aside, buying from TeeSpring was a little... interesting. You add the items to your cart and pay like at any other site. Instead of being charged for the total, I got invoiced separately for each (including separate confirmation emails), along with 5 or 6 duplicate shipping notices for one of the items. My credit card was also charged separately for each item. I get that there are probably reasons for this purchase flow, but it's not implemented well.

I got my stuff and all is good, but the whole buying experience was janky.

Coupling your checkout to Google Analytics is not good though.

If a purchase occurred on the internet and Google didn't know, did it really happen?

Funny. But why do I feel sad?

Personally I think the path should guard against any change to unnecessary third party library function. Because third party script can be bugged and break your site in a funny way. Just like the story broken facebook login broke many site and apps. The api behaves funny, so everything broke all together because you explicitly rely on it without care.

It's both.

as mention other places though, missing window.ga at all on other sites can cause worse problems. I'm not sure mimicing the whole api is useful, but maybe not adding the stub on teespring will be.

On teesprings side, it's not their fault, but adding '&& window.ga.getAll' will fix the issue

How does analytics factor into the functionality of the checkout? That's the only question that matters here. The answer is it doesn't, so regardless of if it loads, is buggy, or has weird data, it shouldn't stop the checkout process.

I've used adblock for so long that I completely forget it's even there. Consequently, I also forget how shitty most the internet is without it.

I never even thought about or realized that adblock may be why I have had issues with many different online retailers. I just assume "something is fukt with the site, or my browser, Vivaldi, is at fault" and then just buy the product elsewhere or buy a different/similar product instead.

My local energy company has a website where you can register an account to pay remotely with them. I have uMatrix on and it was blocking some third party scripts. It managed to get my account into some sort of "half-created" state. It is impossible to log in, impossible to reset the password, and impossible to create a new account with my (physical!) address because "an account already exists for that address". I ultimately found another solution, but that's the worst breakage I've ever seen... not just that my payment didn't go through, but my browser config permanently scrambled the entire possibility of ever getting an account set up!

(I did not bother trying to explain this to a human on the phone, because of the aforementioned alternate solution. That just sounds a supersized order of pain.)

That's a bad bug on their end. It implies that if a user's user-agent crashes (or they kick the power plug out of the wall at the wrong time), they can get into this state.

As a general principle, it should be impossible for a client to "half-configure" an account; the Internet isn't designed to be reliable enough to support guarantees that all the relevant messages get sent and received.

I am an author of a photo editor https://www.Photopea.com .

Whenever someone reports a bug to me, I ask them if they use any site-modifying extensions. If they do, I ignore them completely, even if they wrote a long, detailed report.

Web authors make websites for standard web browsers. I do not consider a browser with site-modifying extensions to be a standard web browser, and it is not my job to test my website with all 1,000,000 extensions that exist on earth.

It all started six years ago, when my website contained <div id="ad" ... and somebody reported, that their adblock removes that element, but it is not the ad. What kind of a mental process should a brain perform to conclude, that it is a bug in a website, and not in their extension, which is supposed to remove ads.

>I do not consider a browser with site-modifying extensions to be a standard web browser

What do you consider a standard web browser?

If someone ships a browser with Tracking Protection (like Firefox), or with NoScript preinstalled (like Tor Browser), or with another adblocker preinstalled, is that a standard browser because the user didn't modify it?

Or is it based on the number of user. Is your standard browser really just Google Chrome, because Google has a lot of marketshare?

I ask, because I looked up the statistics, and they say between 25-45% of users have an ad blocker, depending on the country.

It seems pretty unfair to ignore your users completely, even if they wrote a long, detailed report. No?

Maybe he chooses to ignore non-paying users, which is fair. Hell, ignoring any kind of user is fair. Might not be a great business strategy, but it's his site.

I think most of Photopea's users would be using the free services. I don't see why a developer would want to bend over backwards to support users who aren't paying them, aren't viewing ads to support their usage/bandwidth costs, and are having an issue due to another piece of software they have installed.

It's like emailing an email provider asking why your desktop email client is displaying emails weird.

A standard web browser is a browser, which runs a website according to web standards. If an extension e.g. replaces every image in a webpage with the image of Bill Gates, it is not a standard browser in my opinion, and users should not report it to me as a bug in my website.

The web standards leave quite a bit up to the implementation. Support for scripting is completely optional, for example; a compliant browser is not obligated to load or run your JavaScript. Or to render images, for that matter—the standards do not exclude screen readers. If your site is unusable when scripts are disabled it's your site which is non-compliant, not the user agent. On general robustness grounds you would do well to ensure that your site continues to operate properly even when third-party resources are unavailable, including Google Analytics. After all, the script could fail to load because the server is down and not because it's being blocked by an extension.

Certainly it's not a bug (on your part) that the user agent rendered the page as the user directed, but that isn't the actual complaint. The issue is that the page is over-complicated and fragile, proving unfit for purpose when faced with the slightest deviation from the default behavior of the top two or three most popular web browsers.

We're talking about a checkout. We're at the end of the sales funnel, where the monetary exchange is finalized, the deal is sealed, the value delivered.

Breaking this based on an ad blocker just loses you money.

> Breaking this based on an ad blocker just loses you money.

That's false. Similar thinking to how the MPAA said that downloading a MP3 is a lost sale. There was never a sale to begin with, the user is not interested in a purchase regardless of whether the pirated content is available.

Here, the user will just go through the checkout again in a browser without ab-block or disable it. Why would they suddenly not need a power washer because they're running ad-block?

In fact, if anything, it'll train the user to disable ad-block when they're ready to checkout--from _ANY_ site since most of them are broken under ad-block.

This is assuming that they know the ad blocker is causing the problem. I'm just going to buy the power washer from amazon because your site's checkout is not working!

of course you are.. but when you're not, the value of using the alternative site out weights having to go through the checkout process again or a 4 second page load as someone else suggested is a deal breaker.

Considering it has been reported that over half of potential customers will abandon a purchase if a page takes over 3 seconds to load, failing to load at all suggests you'll likely get similar - if not higher - losses

https://www.vouchercloud.com/resources/consumer-psychology-t...

No, if I visit a site that is broken by my adblocker, or that uses recaptcha, I just never visit it again.

The sales people are always on about how easily people "abandon carts" due to small friction. Lots of things people buy they a) don't need that urgently or b) can buy somewhere else. Some fan shirt off TeeSpring is very strongly in the "not urgently needed" category, your powerwasher example might very well be too and can be bought from tons of places.

This is probably true. I guess my buying impulses are tapered compared to others.

This is so horrendously wrong. I've experienced this on many different online retailers. I don't suddenly not want/need the product, I just go elsewhere. If a physical store I go to has their checkout system go down, I'll go elsewhere. Online isn't an exception to me, prior to this article, I NEVER realized that it was a possibility that my adblock was the cause. I just went to a retailer that didn't have a broken checkout. Going elsewhere is a more simple and easy fix than troubleshooting "WTF is wrong with this site?".

> I ask them if they use any site-modifying extensions. If they do, I ignore them completely, even if they wrote a long, detailed report.

Note to self, don't use Photopea due to poor customer support.

You would think the customer support would at least tell them to remove/disable the add-ons instead of ignoring them.

yeah, I also noted not to use photopea, their whole argument just comes across as arrogance/laziness. If you rely on GA loading before the rest of a page can actually work, then your site is bullshit. Enforcing a users data is given to GA is bullshit.

I expect they'll get over the loss of your business

In any case, it doesn't make much sense to advertise that you purposely ignore user complaints. If you do that, then that's bad, but why wear it as a badge of honor?

Maybe he's just so sick of hearing about errors or bugs from thousands of users, he's sabotaging his own product in hopes it will just die and he can move on.

Yes, don't let them write a long message if you are not going to read it. At least tell people that they need to try the website without any extension before reporting any issue.

Anyway, ad blockers are standard now and they usually share the blocking lists. Supporting them is just a matter of installing uBlock Origin in the browser you use to develop.

AFAIK Ivan is customer support, photopea is a one-man website, and one of the best out there.

> What kind of a mental process should a brain perform to conclude, that it is a bug in a website, and not in their extension, which is supposed to remove ads.

For website owners who are losing revenue, the mental process is simple: "If I change this webpage I will get more sales."

I think that's a fair point of view. I use ad blockers, and if you site breaks with them, I won't use your site. If you're OK with that, I am as well.

div id="ad" but not containing an actual ad, seems like a pretty obvious unintentional overlap, and one that's not going to go away.

How difficult would it be for you to change the div name to not coincide with the characters most closely involved with one of the most contentious technologies around? And never have to deal with that potential conflict again?

> What kind of a mental process should a brain perform to conclude, that it is a bug in a website, and not in their extension, which is supposed to remove ads.

Well, if the extension looks for obvious ad-related layout, and your site just happened to use that name, then yes, you have a bug related to common usage patterns.

Even if you used the name before anything ad related, when the world changes around you, you can choose to adapt, or you can get offended and obstinate and fall further and further into a niche of your own creation.

I've run into similar things with the word ad, banner etc but they don't have to be standalone to triggers some filters, adblock is fairly dumb in that sense.

An update: almost nobody pays for Photopea, and all my reports are from users who use it for free. I fixed over 3000 issues so far, some took minutes, others took weeks: https://github.com/photopea/photopea/issues?q=is%3Aissue+is%...

A "popular" issue is, that people use an extension, which renames files saved by Photopea to .TXT. It is reported several times a week and every time, I tell people to disable an extension. They often argue, that it can not be caused by an extension, or even lie, that they disabled it and it did not help.

https://github.com/photopea/photopea/issues/3246 https://github.com/photopea/photopea/issues/3227 https://github.com/photopea/photopea/issues/3194 https://github.com/photopea/photopea/issues/3187 https://github.com/photopea/photopea/issues/3116 https://github.com/photopea/photopea/issues/3110 https://github.com/photopea/photopea/issues/3049 and so on.

> the extension "Google docs offline" was renaming files form Photopea to .TXT. You are using the same extension.

https://github.com/photopea/photopea/issues/2294#issuecommen...

"Google docs offline" is an official extension from google which you get prompted to install when you go to Google Drive in Chrome without the extension installed. I don't think that caused anything and it looks like there was an actual bug you had:

> There really was a bug in Photopea. If you opened a file, whose name started with a dot . , like .myfile.psd, It was always exported as .TXT_ > I have fixed this bug. You can open files with any names now, and they should be saved under the right extension.

https://github.com/photopea/photopea/issues/3116#issuecommen...

It did seem like the issue was on your end and not the extensions though.

How does having GA integrated into your sales flow prevent these situations from happening?

What is GA? I do not have any sales.

Google Analytics

> What kind of a mental process should a brain perform to conclude, that it is a bug in a website, and not in their extension, which is supposed to remove ads.

On the other hand you know how ad blocking works and if it’s not too much effort just change the class name?

If your website behaves like malware is it really the fault of antimalware software that blocks it? If there was a better way to detect malware, sure, but heuristics is the best we’ve got and they do sometimes break - if it’s not too much effort to make your website not behave like malware why not do it?

I fully agree with you about other, more intrusive site-modifying extensions, but ad-blockers are fairly lightweight and only target behavior that looks malicious, and it’s fairly easy not to trigger them.

While we're at it, potential customers shouldn't need to identify pictures of traffic lights and buses to shop your store. If you're a web store, then you're in the business of selling things and advertising that you're selling them far and wide. The only place you might need a CAPTCHA is the account login page, and only then after there are multiple failed attempts from the same IP address. Other than that, get the fuck out of your customers' way.

Depends on if you have a bot/scraping problem or not. Though admittedly sitting behind something like Cloudflare and leveraging their reputation system rather than blithely embedding recaptcha into your page might be the way to go, but then you're married to Cloudflare. Pick your poison.

Apart from the caveat I gave regarding logins, there is simply no such thing as a bot or scraping "problem" for a web store. Your goal is to advertise what you are selling far and wide - bots are your friends. If you have problems with site load, the first thing to do is make your site more efficient. If you're a small operation and that still isn't enough, add generic server side throttling.

Why is it checking for GA at all? A critical function like accepting payment should be bullet proof. It's critical code and should be treated that way.

Adblock doesn't break sites. If your site doesn't work with adblock, that means your site is broken.

27% of American internet users use adblock in some form. Better go check right now that you're not losing 27% of sales to it.

I’ve reported this to Teespring and all they reply with is to try another browser and clear my cookies. They won’t listen. They’re basically making Teespring unusable for the technical crowd.

The *adblocker crowd. I think I'm in the "technical crowd" but I've never used an adblocker.

Running non-compliant extensions is your right, but the results don't need to be supported. I've run into this situation a number of times, although not with adblock. My advice has been to disable the extensions, or use a different browser without them.

I agree. Ideally an extension never breaks a site. But if I were to make a store. The most robust thing in the store would be the checkout system. They’re leaving money on the table considering how little work it is to test the site with the few popular extensions. It’s basically like supporting a special payment method or exotic browser.

> My advice has been to disable the extensions, or use a different browser without them

You're leaving out the option of "not using the website."

Let's face it, nothing for sale on TeeSpring is essential. Just thank them for putting a roadblock on your silly impulse buy.

When I'm providing support, it's for my company's application, and it really is essential in those cases.

> non-compliant extensions

Compliant to who/what exactly ? Extensions are executed in a user agent, ie a software acting on behalf of a user based on the settings they prefer. If anything it's the website that's non-compliant with the user's choice.

HTTP, HTML, CSS, ECMAscript all have formal specifications.

It's your choice to use things that don't conform, such as IE11, but I wouldn't assume it's the server's problem.

Browsing the web without an adblocker is like running unpatched Windows XP on a machine exposed to the internet.

You've hit tier 1 tech support, that's likely their first answer to EVERY issue

I think you need to consider changing the title of your article. If I understood correctly, you're saying: TeeSpring needs to fix their stupid checkout. I think your title should be: Your checkout should not break because of ad-block. You have it the other way around. It's important because most people understood it like how I initially did and I was prepared to write a lengthy comment on how wrong this argument is.

It's your job to fix your site so it doesn't break because of ad-block. If you're determined on refusing service for people who don't want to be tracked by breaking checkout, that's fine as well. But then you don't get to complain.

Side note: my pet peeve these days is emojis. People need to stop it with shoving emojis everywhere, just like TeeSpring needs to stop shoving evil analytics everywhere. Not everything needs to have 4x emotional emphasis ffs.

Some critical sites I need to pay through are so fundamentally broken by uBlock Origin and uMatrix that I've been forced to use the embedded browser in the LastPass app.

Since they're utility bills, credit cards, insurance portals, etc, I don't really have a choice not to use their services.

You can just disable your ad blocker for the website.

There are some sites where I've tried fully whitelisting them on uMatrix, and that's enough--so I give them a dedicated Container Tab and use it that way. But there are others where even with uB0 and uM completely disabled, the site still refuses to let me sign in. I'm not sure if it's some combination of Firefox's built-in tracking protection, or the fact that I'm coming in through a VPN, or what: but at some point, rather than spending a half hour fighting with it, just signing in on my phone was easier.

Why not just use the default browser?

FF is my main browser, so for anything behaving in a finicky way, I use Chrome, which doesn't have any extensions or Google IDs attached to it.

Also ad block should not break log-in process. I recently discovered that I could not log in to a web site unless I disable ad block. All core web site functionality should be tested to work with ad blocking. Unless you really hate your users.

Adblockers block Google Analytics, which is a different script from the ones that are served as part of displaying banner ads.

GA has an enormous set of capabilities for measuring user activity and e-commerce, especially because Tag Manager lets you assign trackable events anywhere you need to on the site.

It may be interesting to see if that site works if 'analytics.js' and 'gtm.js' are greenlit. Those are the main GA scripts. Everything else would likely be ad-related.

I never ceased to be amazed at how much core site functionality is implemented with Google Tag Manager.

I block it with uBlock Origin and many standard ecommerce sites just don't function in a most basic way.

This is the most infuriating thing ever. Plus checkouts that rely on constant popups for authentication and confirmation which usually get blocked too.

I basically have to switch to another browser to actually checkout on anything because there's so many things I'd need to disable to get them to work.

Fairly regular support conversation on the community website I run:

"I can't see the images on the 'Adverts' page."

"Do you have an ad-blocker installed?"

"Yes."

"What do you think an ad-blocker does..."

Is the issue that the store built a checkout dependency on google analytics to force people to disable uBlock or attempt to force uBlock to allow google analytics for this domain?

I believe that it was an unintentional mistake on TeeSpring's end.

Searching for the dummy function uBlock Origin uses for window.ga https://github.com/gorhill/uBlock/blob/master/src/web_access...

This reveals that this has been in uBlock Origin since 2019.

It makes no sense. All these ads and tracking and all that is to make people buy stuff.

If people are ready to give you money, don't try to stop them!

I also hate when sites use ever-changing 3rd party urls (e.g. $randomchars.cloudfront.net)

Use uMatrix on a site for more than a week and annoyances will show themselves. Twitch is the biggest site I've found that loves ever changing 3rd party urls.

Let me add that blocking outgoing requests to non-standard ports should also not break payment systems, yet I've encountered exactly that.

If your checkout system connects over anything but port 443, you done fucked up.

My fave example of this - I am using NextDNS for ad-blocking on my stock Pixel 4a, the Wells Fargo app won't allow me to sign in with fingerprint or username/pass while using DNS over TLS.

Did you ever get this working? I had a similar problem with nextdns and the amazon app but I was able to resolve via whitelisting a couple domains.

https://torguard.net/blog/only-one-out-of-five-top-us-banks-...

https://community.spiceworks.com/topic/2238885-wells-fargo-w...

British Airways does this. It's been broken for years.

Yes. And British Airways is renowned for fractally bad IT.

e.g.

outage, 2017

https://www.theguardian.com/business/2017/may/31/ba-it-shutd...

https://www.cloudpro.co.uk/it-infrastructure/7800/british-ai...

outage, 2019

https://www.itpro.co.uk/disaster-recovery-dr/34162/british-a...

Supply chain hack, 2018:

https://www.bbc.co.uk/news/technology-45446529

Low quality JavaScript shouldn't break your checkout. This is the type of issue that could have been caught by aggressive type checking.

That would not help, as the externs for that type don't match the faked runtime object.

uBlock Origin commit mentioning this:

https://github.com/gorhill/uBlock/commit/8cd2a1d263a96421487...

I run ad block (unlock origin) on Firefox. I noticed I couldn’t order on restaurants that used “Toast” for they’re ordering. Try chrome, works. But the reason wasn’t the browser but just I wasn’t ad blocking on chrome..

What OKR does a purchase move if there is no analytics tracker there to see it?

total sales?

Mediamarkt.be doesn't work at all on firefox mobile.

123-reg, can't use any of their support without disabling ad blockers, and built in blocking in vivaldi. Totally useless.

it shouldn't break lots of stuff but it does, e.g. access to bank & other financial sites.

Practically the whole Web doesn't function if client blocks add, disables JavaScript (which became quite annoying lately) or uses Tor.

I'd like to find a solution which would restore the ability to use sites. I'm thinking about website cleanup offering (startup anyone?), I wonder if something similar already exists.

I use Tor by default, and while many sites don't work (TFA is behind a Cloudflare captcha, ironically enough), I wouldn't say it's a majority.

LOL, article is hidden when uBlock is active. Way to go!

Hey, not sure what you mean :) I use uBlock Origin in Chrome and the article renders okay for me?

The site doesn't really use any JS other then some privacy friendly analytics.

Ah well, I blocked all JS for your domain, that worked.

The article was collapsing when I had uBlock on FFx, I only saw your bottom (C)opyright.

Displays fine for me - gotta be your filter lists subscriptions

So it's basically proving the site owner's point that they can't account for whatever randomness the user decides to put in their browser.

I use NoScript and uBlock Origin in Chrome, and the article appears with all the images.

One of the largest pharmacy chains in my area has a covid-vaccine-booking page that's impossible to complete if ad-blockers are enabled. (Even Safari content blockers on iOS break it.)

Developers failing to test sites with adblockers could literally result in people dying.

As a web developer, ad blockers are maddening. The problem is that they're part of an arms race that even if you don't use ads, you have to be aware of.

Early in my career, I worked on a site that displayed images, each of which was given a GUID and loaded from a server in thumbnail form. Fortunately, one of our developers used an ad blocker, because she realized two (of a couple hundered) thumbnails didn't show up. Turns out her ad blocker was running a heuristic based on both dimensions of the thumbnail and the URL the thumbnail was served from, and if it saw the sequence 'ad' in the URL (plus some additional pieces of the URL we never identified; attempts to reproduce it with a simpler URL didn't pan out), the browser extension would block the image from loading and our users got a broken image.

The best solution we could come up with was tweak the server logic to substitude 'a' with 'g' when vending the URLs, and then reverse the substitution when fetching them. Huge pain in the ass on our end, but necessary to ensure our customers' user experience didn't break from their own ad blockers.

"Ad block shouldn't break your checkout..." but it's third-party code you don't own or control splicing behavior atop the code you do own and control, so of course it breaks things occasionally. It's like the old era of the MacOS Desk Accessory API. It is provably mathematically impossible for the developer to guarantee successful execution of a Turing-complete program if the program can be arbitrarily modified by third-party injection, so the odds that browser extension in general (and ad blockers in particular, as they are designed to modify the intended site behavior) don't break any website are vanishingly close to zero.

Reply on news.ycombinator.com