/
Wallpaper [Engl.]

Wallpaper [Engl.]

Owned by Vanessa Quitzau (Unlicensed)
Last updated: Dec 01, 2023 by selin.sentuerk

Visualisation

Live-Demo

Format concept 

The Wallpaper is a large, very prominent advertising format which guarantees full attention for you and your message. It is a combination of an (oversized) Superbanner and a Skyscraper. 

Visibility:

The Skyscraper docks to the Superbanner from the right as standard. The standard delivery is with a Sticky Skyscraper.



General technical specifications

Wallpaper - Maximum sizes of individual publishers

Dimensions & file size

Standard dimensions:

  • Super Banner: 728 x 90 pixel 
  • Skyscraper: 160 x 600 pixel
  • may vary depending on publisher (see "Special features of Publisher" below)

File size:

  • .gif / .jpg / .png: 40 - 80 KB
  • HTML5: 150 KB initial + 300 KB download

Special features of Publisher

Please note:

Maximum sizres of individual publishers:

There are some publishers who can realize not only the standard size but also their own maximum sizes - you can find a list of corresponding publishers and sizes here.

The standard size also applies to network and theme channel rotations (see point above "Dimensions & File size").  

Delivery

  • physical creative delivery:
    • image file formats: .gif, .jpeg, .png
    • HTML5 - one HTML5-file set each for Superbanner and Skyscraper

or

  • delivery as a redirect: Iframe-Redirect - one Iframe each for Superbanner and Skyscraper 

Background colour:
We also require the hexadecimal colour code for the optional colouring of the background (example: #ff3B1A). The color may not be transparent or white.

 HTML5

Trackings

Please note the following when delivering physical HTML5:

It is not allowed to integrate any 3rd party tracking and clickcommands into the HTML file; these must be delivered separately and contain the necessary GDPR macros for the vendors used (see Ströer Tracking Guidelines for more information)


 HTML5-Specs ....expand here

The Ströer specifications have moved to stroeer.de.

Please find the most actual information and specifications for HTML5 advertising media there.

Click here: https://www.stroeer.de/en/planning-booking/specifications/online-ads/technical-specifications-for-physical-html5-ad/

Delivery format

Single HTML file + additional images/videos

3rd-Party-Tracking

allowed

Videoformats

H264/mp4 und VP8/WebM

Video filesize

max. 5 MB

Videostart & Audiostart

Only after explicit useraction

Leadtime

5 days or 10 days for mobile HTML5 formats

General guidelines

  • Deliver the HTML5 media ad as index.html, with full HTML syntax (Doctype definitions, <head>, <body>, etc.)

  • As much content (scripts, CSS, etc.) as possible should be included directly in the index.html instead of being outsourced to separate files.

  • When reloading external resources, make sure that they are enabled for cross-domain access on the server side (CORS).

  • Use an alternative graphic to replace the ad media for browsers that do not fully support HTML5.

  • The orientation of the displaying device should be taken into account and the advertising medium should be optimized for "Landscape" and "Portrait" displays.

  • The tracking/counting of user actions (except clicks) by a separate server must be done by the ad creator.

JavaScript guidelines

  • Use small, compact JS frameworks. Larger libraries like jQuery are usually unnecessary and increase the data load of the ad media exponentially.

  • Reduce your final JS code as much as possible. Use minifiers or similar tools so that your ad can be transferred to the viewer as quickly as possible.

  • Avoid logs (e.g. console.log or etc.) and possible errors to optimize the performance of your ad and not overload the browser console.

Click measurement

You have the possibility to have clicks on links to external sites measured by the Ströer Digital AdServer. For this purpose, dynamic assignment of the link URLs must be enabled in the HTML5 advertising medium.
When the ad medium is played out, the complete URLs of Ströer are inserted into the ad medium and measured when the user clicks.
During development of the media ad, the link URL-encoded (encodeURIComponent() ) can be transferred to the ad media using GET parameters.

yourAdvertisingMaterial.html?clicktag1=http%3A%2F%2Fwww.youreUrl.de&clicktag2=http%3A%2F%2Fwww.yourOtherUrl.de

  • Fill all links to be measured with the name "#clicktag" as placeholder and an ID attribute of the same name. If you want to use different links with different targets, you have to number the placeholders sequentially ("#clicktag", "#clicktag2", etc.)

<a href="#clicktag" id="clicktag" target="_blank">Linktext 1</a>
<a href="#clicktag2" id="clicktag2" target="_blank">Linktext 2</a>

  • Insert the following script in the <head> of your ad media:

<script type="text/javascript">
var getUriParams = function ()
{
    var query_string = {};
    var query = window.location.search.substring(1);
    var parmsArray = query.split('&');
    if (parmsArray.length <= 0) return query_string;
    for (var i = 0; i < parmsArray.length; i++)
    {
        var pair = parmsArray[i].split('=');
        var val = decodeURIComponent(pair[1]);
        if (val != '' && pair[0] != '') query_string[pair[0]] = val;
    }
    return query_string;
}();
</script>

  • Either at the end of the HTML file or when initiating the ad media, the dynamic assignment of the URLs must be triggered with the following code

<script type="text/javascript">
    document.getElementById('clicktag').setAttribute('href', getUriParams.clicktag);
    document.getElementById('clicktag2').setAttribute('href', getUriParams.clicktag2);
</script>

Pre-test click measurement

  • The advertising material should be tested by the creative agency for functioning clicktag transfer so that unnecessary feedback loops can be excluded.

  • Test: html5mediaad.html?clicktag=%LANDINGPAGE%

*%LANDINGPAGE% is to be replaced with a test target page and must be passed URL - encoded (either via the encodeURIComponent function or e.g. with the help of this page: https://meyerweb.com/eric/tools/dencoder/)

Guidelines for animations

  • Animations should be created as resource-saving as possible. Avoid the excessive use of transparency effects (opacity) or the triggering of browser "repaints". You can find more information about paint/repaint here.

  • Remove unneeded GIFs (e.g. a loading animation) completely from the HTML tree instead of just hiding the image. Hidden GIF animations continue to burden the browser.

  • Use the animation possibilities of CSS3 (Animation, Keyframe, Translate, etc.)

⚠ Never use animations with JavaScript's setInterval() or setTimeout().
JavaScript animations should always use the requestAnimationFrame API of the browser. Further information about requestAnimationFrame() can be found here.

Guidelines for pictures & videos

  • For an optimal image display on all devices, all images should be adapted for HDPI, if reasonable.

  • In order to keep the data load of the advertising medium low despite HDPI, the formats Progressive JPEG / Progressive PNG, SVG or WebP (limited browser support) are suitable. However, the choice of format is not restricted and is at the developer's discretion.

  • To deliver individual image versions to the correct device or pixel density, it is recommended to use CSS3 image-set() or <img>'s srcset element (note browser support).

  • Use server requests for smaller images sparingly. If you want to use many smaller image files (icons, logos), they should be loaded either as CSS sprites or directly in HTML as DataURI.

  • Videos must be provided as H264/mp4, as well as VP8/WebM and must not exceed 5 MB. When integrating videos, use the Browser Video API.

  • For videos in the advertising material, the sound may only be started after explicit action by the user (click on a "Sound on" button, etc.).

HTML5 on mobile devices

  • For in-app advertising formats we support the standardized API MRAID (Mobile Rich Media Ad Interface Definitions) of the Interactive Advertising Bureau (IAB). In order to access device functions, such as the creation of a calendar entry, the ad media must be MRAID-compatible.

  • Data from motion and alignment sensors of the mobile device may be read and used for the interaction of the advertising medium, but may not be used in a blocking manner. Functions such as closing or reducing the size of advertising media may not depend exclusively on the movement of the device.


 General technical specifications and Tracking Guidelines

notes: 

  • all trackings or redirects must be 100% SSL-compliant.

  • all ad tags/trackings to be used by us must contain the GDPR macros according to TCF v2.0 and all vendors used must be registered in the TCF v2.0 (Transparency and Consent Framework) of the IAB


Heavy Ad Interventions in Google Chrome

With Chrome 86, Google starts blocking ads that are resource-heavy and use an egregious amount of CPU or network bandwidth.
This happens as an reaction to consumers are increasingly frustrated with ads that disrupt their experience, interrupt content and slow browsing.

In order to avoid such a blockage of the creative we recommend to consider the restrictions/guidelines from Google:

https://developers.google.com/web/updates/2020/05/heavy-ad-interventions


 Ströer Tracking Guidelines... expand here


The Ströer specifications have moved to stroeer.de.

Please find the most actual information and specifications regarding the Ströer Tracking Guidelines.


Click here: https://www.stroeer.de/en/planning-booking/specifications/online-ads/stroeer-tracking-guidelines/

Ströer Tracking Guidelines for advertisers and agencies on the use of trackings

1. Tracking in general

Up to five tracking pixels per creative have proven themselves as standard. This usually includes:

  • two tracking pixels for impression tracking (media agency and technical service provider)
  • a clickcommand
  • a viewability measurement (e.g. meetrics)
  • a market research pixel (e.g. GfK)

Ströer randomly checks the validity and amount of trackings. After prior consultation, a higher number of trackings can also be used.

All file sizes include all trackings.


2. personal data

Cookies and similar technologies which store and/or read out personal data on the user's device as well as further data processing must comply with the guidelines of the German Telemediengesetz, the EU General Data Protection Regulation (GDPR) and be listed on our vendor whitelist.

If there are any questions regarding the Ströer vendor list, please contact: vendorlist@stroeer.de


In particular (but not conclusively) the following types belong to it:

External tracking pixels, which analyze and record user behavior and, if desired, compare it with a downstream database on the customer side, must be explicitly released by Ströer before the start of a campaign. This includes any of the following pixel types:

  • Ad Verification (reading the environment)
  • Targeting quality (testing the effectiveness of the used targeting)
  • User profiling (collecting profile data)
  • Third party retargeting (re-targeting of users outside our network via external pixels)

3. tracking service providers (vendors)

All technical service providers (vendors) which will be used by agencies and advertisers must be registered in the TCF v2.0 (Transparency and Consent Framework) of the IAB and listed on our vendor whitelist.

If there are any questions regarding the Ströer vendor list, please contact: vendorlist@stroeer.de


4. Consent-Signaling for direct campaigns

For all cookies and similar technologies that are used in the context of the direct campaign on our portfolio, the necessary GDPR macros for the vendors used must be transmitted to us.

In order for us to be able to recognize/find these GDPR macros, we need to know at least 5 working days before start of a campaign how and where these GDPR macros will be implemented in the redirects, scripts, iframes and/or any other tracking.

All adtags/redirects/trackings to be used on our portfolio must contain these GDPR macros.


 Note:  Without this information we cannot ensure that direct campaigns can go live.


5. Counting differences

Counting differences in delivered ad impressions, caused by the selective filtering of an external tracking pixel (e.g. ad verification pixel), will not be acknowledged by Ströer or billed in Ströer's favor without prior consultation, unless they can be proven by a validated data basis.


6. Bundesdatenschutzgesetz BDSG

the Bundesdatenschutzgesetz BDSG must be observed in any case

https://www.gesetze-im-internet.de/bdsg_2018/


7.  Further use of collected tracking data

The use of the collected tracking data is exclusively for the booked campaign and limited to the booked period in our network.

Any further use or sale of the data to third parties is prohibited.






general technical specifications




© 2025 - Ströer Media Solutions - https://www.stroeer.de

Related content

Datenschutz
Impressum