Page 1 of 2

[Added] winfuture.de content ads

PostPosted: Wed Jan 11, 2012 4:17 pm
by Wladimir Palant
Proposed filters to be added

Code: Select all
@@||winfuture.de^$elemhide
@@||o0.winfuture.de^$script,domain=winfuture.de
@@||googlesyndication.com/pagead/*$script,domain=winfuture.de
@@||googleads.g.doubleclick.net^$script,domain=winfuture.de


Link to a test page

http://winfuture.de/news,67557.html (a randomly picked article)

Advertising type

Text ads only

Additional technical information

Third-party ad service used, advertising types restricted by configuration

Concerns

We currently have as a rule: "only one script from one domain". This is clearly violated here, ad scripts are served by three different domains. The feedback we got: they have to rely on third-party ad services and cannot control the technical details of ad delivery (which is sadly true for most smaller web sites). The question is whether this requirement is reasonable: browsers do DNS prefetching and speculative parsing now, page load delays delays due to scripts (and particularly DNS resolution for scripts) might not be relevant any more. On the other hand, other advertising services manage to create significant delays with just one script. So maybe a better requirement can be found (it still has to be verifiable though).

The other concern is disabling element hiding on the entire winfuture.de domain which seems to be the only possibility here. It might have unintended side-effects, e.g. it makes plista ads appear. Plista ads cannot be blocked without disabling useful functionality (related articles), but then again - these are also text ads and there are no problems with our requirements.

Finally, the ad in the article body is problematic IMHO. If it is acceptable then it should be marked more clearly (different background color like the plista ads). As it is now, there isn't enough separation from the article text.

Re: Text ads on winfuture.de

PostPosted: Wed Jan 11, 2012 6:20 pm
by Marijo
Wladimir Palant wrote:Concerns

We currently have as a rule: "only one script from one domain". This is clearly violated here, ad scripts are served by three different domains. The feedback we got: they have to rely on third-party ad services and cannot control the technical details of ad delivery (which is sadly true for most smaller web sites). The question is whether this requirement is reasonable: browsers do DNS prefetching and speculative parsing now, page load delays delays due to scripts (and particularly DNS resolution for scripts) might not be relevant any more. On the other hand, other advertising services manage to create significant delays with just one script. So maybe a better requirement can be found (it still has to be verifiable though).

On my system (DSL 6MBit, DNS prefetching disabled), it looks like the ads are shown after the page fully loaded which is the right way to do it (asynchronously, I guess). The rule/requirement needs to be relaxed a bit, especially when the scripts are served from the first-party itself and Google with its huge CDN. WebPagetest shows solid numbers for the domains involved.

Wladimir Palant wrote:The other concern is disabling element hiding on the entire winfuture.de domain which seems to be the only possibility here. It might have unintended side-effects, e.g. it makes plista ads appear. Plista ads cannot be blocked without disabling useful functionality (related articles), but then again - these are also text ads and there are no problems with our requirements.

Why is it not possible to whitelist only the elements where the ads are actually shown?

Wladimir Palant wrote:Finally, the ad in the article body is problematic IMHO. If it is acceptable then it should be marked more clearly (different background color like the plista ads). As it is now, there isn't enough separation from the article text.

I totally agree. A slightly different background color would help differentiate the ad from the actual content. In its current form, it's too disrupting when reading an article.

Re: Text ads on winfuture.de

PostPosted: Wed Jan 11, 2012 6:44 pm
by Wladimir Palant
Marijo wrote:On my system (DSL 6MBit, DNS prefetching disabled), it looks like the ads are shown after the page fully loaded which is the right way to do it (asynchronously, I guess).

I tried figuring this out but so far it looks to me that the ads merely show up when the page loads - but they load earlier.

I need to modify Diagnostics to record load/DOMContentLoaded events, this will make the analysis simpler in cases like this one.

Re: Text ads on winfuture.de

PostPosted: Wed Jan 11, 2012 8:30 pm
by MonztA
At least they claim their site is designed to load the content first then ads.

Re: Text ads on winfuture.de

PostPosted: Thu Jan 12, 2012 1:41 am
by Till
Marijo wrote:Why is it not possible to whitelist only the elements where the ads are actually shown?

Element hiding rules can't be disabled seperately, only for the whole page.

Re: Text ads on winfuture.de

PostPosted: Thu Jan 12, 2012 8:29 am
by Wladimir Palant
Marijo wrote:Why is it not possible to whitelist only the elements where the ads are actually shown?

I tried to come up with some reliable way to disable element hiding rules only in specific areas rather than on the whole page (would be useful elsewhere as well, subscription list authors asked for that to deal with false positives) but couldn't find any.

@MonztA: That's what they claim in the communication as well.

Re: Text ads on winfuture.de

PostPosted: Sat Jan 14, 2012 9:30 am
by Ares2
I would generally say that ads that are positioned in the middle of a connected entity are not "non-intrusive", regardless of whether they are more clearly marked or not. For that reason I think the Plista ad is not the best example for "acceptable" either, although it's not as bad as the others.

This is what I get: https://arestwo.org/uploads/winfuture_aa1.png

And IMO it should look more like this (separated from the content in both color and positioning): https://arestwo.org/uploads/winfuture_aa2.png

I think non-disruptive positioning is not too much to ask for when it comes to "acceptable ads" and therefore I would suggest to add something along this line to the list of criteria.

Re: Text ads on winfuture.de

PostPosted: Sat Jan 14, 2012 12:07 pm
by Wladimir Palant
Yes, I think that this is a reasonable requirement. The formulation should probably be:

Ad placement:
  • Ads should not obscure main page content (e.g. require the user to click a button to close them before being able to read).
  • Ads should not be placed in the middle of the main page content where they interrupt the reading flow. They can be placed above the main content, below it or on the sides.
  • When placed above the main content the ads should not require the user to scroll down to see the main content. With the expected height of a maximized browser window currently being at least 768 pixels and the browser UI taking 60-70 pixels away a page can count on having 700 pixels vertically. Ads shouldn't occupy more than 1/3 of that height.
  • When placed on the side the ads should leave enough space for the main content. With the expected width of the browser window currently being at least 1024 pixels and browser UI (scrollbar and window borders) taking 20-30 pixels away a page can count on having 1000 pixels horizontally. Ads shouldn't occupy more than 1/3 of that width.

Also:

Advertising should be clearly marked as such with the word "Advertising" (or its local language equivalent), it should be distinguishable from the page content (via a border and/or different background color)

Which leaves out the scenarios where there is no (clearly defined) main content or the advertiser cannot control the ad placement (like most advertising networks).

Re: Text ads on winfuture.de

PostPosted: Sat Jan 14, 2012 3:53 pm
by Ares2
Wladimir Palant wrote:Advertising should be clearly marked as such with the word "Advertising" (or its local language equivalent)

Does it HAVE to be "advertising" (adv*, "ads") or can it also be similar stuff like "sponsor*", "paid promotion", etc. ?

Re: Text ads on winfuture.de

PostPosted: Sat Jan 14, 2012 4:09 pm
by Till
Ares2 wrote:Does it HAVE to be "advertising" (adv*, "ads") or can it also be similar stuff like "sponsor*", "paid promotion", etc. ?

I wouldn't worry too much about the wording, any indication like that is sufficient IMHO.

Re: Text ads on winfuture.de

PostPosted: Sat Jan 14, 2012 5:15 pm
by Ares2
Till wrote:I wouldn't worry too much about the wording, any indication like that is sufficient IMHO.

I would agree with that, I was just wondering because Wladimir said "with the word Advertising".

Re: Text ads on winfuture.de

PostPosted: Sat Jan 14, 2012 9:00 pm
by Silico
Wladimir Palant wrote:Advertising should be clearly marked as such with the word "Advertising" (or its local language equivalent), it should be distinguishable from the page content (via a border and/or different background color)


An ad with a bold-coloured background is more intrusive than an ad having the normal page background. Sure, it's good for paid inclusion to be easily identifiable, but the "Advertisement" labelling requirement should be sufficient, especially if it's embedded in a border around the ad.

Sites, ad-networks, and advertisers would be very happy with a distinctive-colour requirement. For example, Google uses an eye-catching yellow.

So I'd say there should either be no distinctive colour requirement, or the requirement should be that ads shouldn't blare above the content, even if it's via its background colour.

Here lies the dilemma: when there's better things to look at, an ad must be intrusive to be effective on any but the bored.

Re: Text ads on winfuture.de

PostPosted: Sat Jan 14, 2012 9:11 pm
by Silico
Marijo wrote:On my system (DSL 6MBit, DNS prefetching disabled), it looks like the ads are shown after the page fully loaded which is the right way to do it (asynchronously, I guess).


There is a trade-off here: Asynchronous ad display attracts the eye but can prevent page load delays.

There should be no problem with multiple scripts if all their script tags use the "defer" attribute, which on most browsers prevents a script from running until the rest of the page has loaded.

Re: Text ads on winfuture.de

PostPosted: Tue Jan 24, 2012 7:48 am
by Guest
Till wrote:
Ares2 wrote:Does it HAVE to be "advertising" (adv*, "ads") or can it also be similar stuff like "sponsor*", "paid promotion", etc. ?

I wouldn't worry too much about the wording, any indication like that is sufficient IMHO.


I would. Marketroids always try to get cute with their wording.

ADVERTISEMENT: can quickly become Special Holiday Promotion or Friend of XYZ.com or some other linguistic monstrosity which doesn't reflexively bring up the connotations and feelings of a simple, direct label.

Marketroids can always be counted on to find the line where advertising begins to masquerade as content, then take several large steps beyond it.

Re: Text ads on winfuture.de

PostPosted: Tue Feb 14, 2012 5:26 pm
by Wladimir Palant
This took quite a bit longer than intended, sorry about that. Reason is that my ad placement rules proposal triggered heavy discussion, it seems that Google (who happens to dominate the search ads market) dictates everything about search ads - including how many they are. And in some exceptional cases there will be a full page of paid search results before the "real" search results, something that the companies we deal with cannot change.

So it looks like we will have to make an exception for search ads (with the limitation that paid search results still cannot be placed between real results and that there cannot be more paid search results than real results).

As to "only one script" rule - we need to remove it, at least until we encounter a site where this is really a problem. And then we can hopefully reformulate to have it make sense in the real world.

So much to the results of this topic, I am closing it as "Rejected". The main feedback for winfuture.de is that ad placement needs to be improved.

Edit: The criteria have been updated: https://adblockplus.org/en/acceptable-ads#criteria