Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ad block shouldn't break your checkout

ilakovac.com

Post reply on HN
Print view View original

111–120 of 204 posts

Re: Ad block shouldn't break your checkout

#111

Post by vmception »

savant_penguin wrote: post #37
bellyfullofbac wrote: post #13

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…

> 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…

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

thats pretty funny to me now

Re: Ad block shouldn't break your checkout

#112

Post by Grimm665 »

Kwpolska wrote: post #99
sparker72678 wrote: post #10

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 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."

Re: Ad block shouldn't break your checkout

#113

Post by beshrkayali »

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.

Re: Ad block shouldn't break your checkout

#114

Post by ratww »

bastawhiz wrote: post #60
josephcsible wrote: post #54

Earlier quoted context omitted.

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 o…

> 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.

Re: Ad block shouldn't break your checkout

#115

Post by admax88q »

throwawayboise wrote: post #50
lainga wrote: post #18

Earlier quoted context omitted.

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.

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.

Re: Ad block shouldn't break your checkout

#116

Post by matheusmoreira »

helsinkiandrew wrote: post #44

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.

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

Re: Ad block shouldn't break your checkout

#117

Post by randompwd »

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.

Re: Ad block shouldn't break your checkout

#118

Post by ehutch79 »

vinceguidry wrote: post #87
wai1234 wrote: post #30

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…

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 yo…

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.

Re: Ad block shouldn't break your checkout

#119

Post by matheusmoreira »

Navarr wrote: post #61
helsinkiandrew wrote: post #44

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.

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.

Why does checkout depend on Google APIs?

Re: Ad block shouldn't break your checkout

#120

Post by waynesonfire »

priyanmuthu wrote: post #77
waynesonfire wrote: post #69

Earlier quoted context omitted.

> 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…

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.
Post reply on HN