Hacker News Reader

Comment by soared | Hacker News Reader

Except that the content is directly related to user behavior. If they see no one reads the style section, they'll cut it and move resources to financial news. If they didn't have tracking they'd never know that, be wasting resources and having a comparatively inferior product.

They can't do UX anaylsis, nothing.

View on HN

For the first, it's sufficient enough to just look at the number of page requests.

For the second, I never got explained to me how UX analysis really works for news sites. Isn't it enough to put 2 or 3 people in a room and show them a few variations of the UI? There isn't really much to publishing text, images, and a few graphs. Graphs are a very well explored field, I don't think you can learn more about them by just watching hot maps and click through rates.

I suspect there's lot of bullshitting happening around "UX analysis", with third-party "experts" offering analyses which may, or may not, show something significant. As long as everyone in the chain can convince their customer/superior that their work is useful, the money will flow, whether or not the work is actually useful.

That's one of the fundamental problems in tech today, namely:

"It is difficult to get a man to understand something, when his salary depends on his not understanding it.”

Server logs just aren't sufficient, no matter how many times hn says so. You don't get enough data to make data-driven decisions. Thats like giving a data scientist 1/3rd of the available data, and saying "thats good enough".

You'd expect ux to be a small unit, but that includes everyone who works on revenue-generating ads. Moving one tiny thing has a direct impact on revenue, which affects every person employed by nyt.

>Thats like giving a data scientist 1/3rd of the available data, and saying "thats good enough".

And it could easily be enough. Having 1/3 of a quantity of something doesn't mean you barely had enough before.

It's pretty simple, try a few different designs with A/B testing and you will see which one has the most revenues.

However the result will usually be a lot of dark patterns. For instance, that's why you get popup to ask you to register.

It absolutely isn't sufficient to look at the number of page requests. How do you discern like-reads vs hate-reads? How do you determine whether someone clicked on an article, read the first line, and then bailed vs read the whole thing? There are a heap of metrics used to determine engagement which factor into the material decisions referred to in the grandparent.

Why do you need to track user behavior across unrelated domains to achieve any of that?

They could certainly track what you mention here (which pages are being accessed) via logging requests - without any use of additional front-end assets.

You can do all of those analytics server side, there's no reason to deliver it via JS and have the client do the computation. You're already sending all the required info to track that sort of thing via the request itself.

It's amazing to me that no one out there seems to do server-local handling of ads, either... If you put ads directly into your page instead of relying on burdensome external systems, suddenly blocking isn't a thing anymore. ALL of the functionality supposedly needed for analytics and an ad-driven business model can happen server side, without the page becoming sentient and loading a billion scripts and scattered resources, with the one exception being filtering out headless browsers. If external systems need to be communicated with, most of that can happen before or after the fact of that page load. Advertising and analytics is implemented in the most lazy, user hostile way possible on the majority of sites.

It's because they use systems that identify the client via js to deliver the most "expensive" ad possible. It's complete garbage of course, Google/Facebook should be held liable for what they advertise, not run massive automated systems full of fraud. If Google delivers malware they shouldn't be able to throw their hands up and go "well, section 230!".

The way it's implemented has several "benefits":

- It externalizes resource usage - the waste happens on users' machines. Who cares that it adds up to meaningful electricity consumption anyway?

- It makes it easier for marketing people and developers to independently work on the site. Developers can optimize, marketers can waste all that effort by including yet another third-party JS.

- It supports ad auctions and other services in the whole adtech economy.

- You don't have to do much analytics yourself, as the third party provides cute graphs ideal for presenting to management.

There used to be an open source self-hosted (php) ad application called openx. It worked well for quite a while. In its later years, it suffered a number of high-profile security vulnerabilities, and the open source version was poorly maintained since OpenX [the company] was focused more on their hosted solution which probably had migrated to a different codebase or at least was a major version past the open source codebase.

The open source version has been renamed "Revive Adserver", and it looks maintained, but I don't think it's used nearly as much as the openx [open source version] of old.

If you use Revive Adserver or you design a server-local ad system in-house, it won't be as sophisticated as gigantic ad-providers who can do all sorts of segmentation and analysis (producing pretty reports which execs and stakeholders love even if that knowledge adds no value to the business).

Funny that you mention that --in a former life I had to develop around and maintain an openx system.

I don't think it's very surprising. Advertisers won't let publishers serve ads directly because that requires trust in publishers to not misrepresent stats like impressions and real views. I don't know how you'd solve that trust problem when publishers are actually incentivized to cheat advertisers.

I think you may have identified the biggest issue, and it's a shame the pragmatic solution is an unpleasant technical solution.

Couldn’t they eg have some trusted proxy server that routes some requests to the real-content NYTimes server and some to the ad server?

That sounds like a viable solution to the trust issue. They don't need to respond to the requests, just see copies they can be sure are real requests.

For advertisers to trust this proxy server, the NYT cannot control this proxy server to preserve its integrity. So now you're asking the NYT to base their business on an advertiser-controlled server?

What happens when the proxy goes down? What happens when there are bugs? Do you think publishers can really trust advertisers to be good stewards of the publisher's business? Think for a moment about publishers that are not as big as the NYT.

Okay, maybe they do trust an advertiser-controlled proxy server. This means that both tracking scripts and NYT scripts are served from the same domain, meaning they no longer have cross origin security tampering protection. What's stopping the NYT from serving a script that tampers with an advertiser's tracking script?

Those are issues, but not insurmountable, especially when the benefit is "obviate any adblocker".

They can use a trusted third party to run the proxy and use industry standards/SLAs for site reliability/uptime. And they can still use different subdomains with no obvious pattern (web1.nytimes.com vs web2.nytimes.com -- which is the ad server?) or audit the scripts sent through the proxy for malice.

> They can't do UX anaylsis, nothing

They could, but that would require paying people and firms like Nielsen to gather data. Instead they engage in the same freeloading that the industry derides users for.

Reply on news.ycombinator.com