logoalt Hacker News

63stackyesterday at 7:02 PM8 repliesview on HN

So what do you think, what's happening here?

My experience with IT in banks is that this entire "feature" of tracking who's opening/not opening emails must have went through about 50 people, and it must have taken at least a year from the idea forming in someone's head, going through all the administrative bureaucracy, getting approved, developed, tested, and rolled out.

Is it that HSBC has 0 competent people who could have mentioned that "tracking pixels are unreliable, especially in 2025/26"? Or is it that everybody who mentioned this was overruled by middle/upper management because they know better? What about the http:// part? I imagine there must have been a few developers saying we should not be serving anything under http://.


Replies

malfistyesterday at 7:38 PM

I ran a team at FAANG where I supported people creating content, including emails, and no matter how many times I explained open tracking was only useful as a trend and not an individual evaluation it just went over people's heads.

Senior leadership wouldn't believe me, kept harassing my team to explain why so and so who said they opened the email didn't have an open event, and why so and so who said they didn't open the email did have an open event.

Authors wouldn't believe me because email open was the highest scoring metric they had. Less than 3% of recipients would land on the page for the publication, but >50% would "open" the email that has a teaser and a call to action to open the webpage. If they had to go off of the click through metrics which are accurate it'd make it sound like they were bad at their job.

So everyone used open rates because it made them feel good. Either that they were writing engaging content, or made them feel like they actually had a handle on who was/was not reading their mail.

No metric would have been better than this metric.

show 3 replies
stackskiptonyesterday at 7:43 PM

They might have competent people but most tech people working at a bank like are out of fucks to give.

At these massive, unable to go bankrupt companies, you quickly lose all fucks to give. No one cares about opinion of ICs or even direct managers, Senior Management makes the calls and you either execute quietly or replaced with someone who is. When I worked for $MegaUSBank, there was two types of people. Those who realized their "spark" was draining out of them and got a new job after a few years and those who were just "Whatever, I push buttons and get paycheck." and had been there for 15 years.

show 1 reply
dwedgeyesterday at 7:13 PM

At least they email him and don't send the stupid "you have an important message, login to see it" email. No idea what those important messages are, I'm sure sometimes they were important

show 2 replies
m463yesterday at 8:14 PM

I think of the term "state of the practice"

Same thing happens with renting apartments. Slowly but surely, conveniences like apartment-phone-app (to open doors, to access mailboxes) get accepted by people and then they "throw the switch" and make the remaining 3% do it. Or maybe new renters must accept it to move in. And then they can deny access to apartments imeediately, track their residents, match with online activity and more...

brendoelfrendoyesterday at 10:37 PM

My take: someone wanted a technical solution for what is a people/process problem. A hypothetical version of events, just one of many possible scenarios of course: 1) Important communications required by law and/or regulation are sent by email. 2) Contacting customers via email is sometimes unreliable. It is unreliable enough that problems caused by missed emails caused enough pain in some exec's silo that they demanded a solution. 3) "Make sure people read their email" isn't really an actionable demand. The business knows this, so they turned to IT. 4) "Make sure people read their email" isn't really technically feasible either, but at this point it's not about making sure that the customer got the message: it's about making sure that the company is covered if a customer complains about missing communications. 5) To that end, a variety of technical solutions are proposed, and everyone knows that they're all bad or incomplete. The tracking pixel is chosen because it's at the intersection of "least bad" and "lowest effort to implement." 6) Around now, someone probably pointed out the issue with serving the content over http, but changing that requires buy-in from another team. It'll go to their product manager as an inject and maybe get prioritized for next PI (it won't, something more important will come up between now and then). 7) The tracking pixel ships. The team that implemented it stresses that this is an incomplete solution and the business really needs to re-evaluate their processes around customer communications. 8) The email tracking pixel solution gets a bullet point on a slide in a presentation given to managers 3-5 levels higher than the devs who made it. No one mentions that the solution is incomplete and requires additional work and investment. No one ever thinks of it again.

raverbashingyesterday at 7:05 PM

I think people are overthinking this, though the discussion about reliability is merited

For every HN technically inclined people you have dozens of other customers who will give any email (thinking it's just writing "[email protected]" or something) - or worse- and they have to find a way of identifying those customers

wat10000yesterday at 8:17 PM

I'd guess one of two things. One is a conversation that goes like:

"I want to send letters to everyone who doesn't open our emails."

"We can't really detect that. We could add a tracking pixel, but–"

"Yeah, do that, the tracking pickle thing."

The other is that the "did they open this?" feature was rolled out purely for metrics knowing that it's imprecise, and later on got repurposed for something unsuitable without looking at how the "did this email get opened?" facility actually worked.

show 1 reply
antonvsyesterday at 7:42 PM

> Is it that HSBC has 0 competent people who could have ...

In the chain of command for a feature like this, that's quite possible.

> Or is it that everybody who mentioned this was overruled by middle/upper management because they know better?

Or just learned helplessness, they don't bother because they know it's not worth trying.