Retningslinjer for displayannoncering

 

Bemærk: Du kan hente dokumentet som pdf

 

Introduktion

Danske Mediers retningslinjer for displayannoncering har til formål at lette kommunikation omkring digital annoncering mellem medier, bureauer og annoncører ved at formulere en række forslag til standarder og gode tips til de mest anvendte formater og produkter inden for display annoncering (bannere) med henblik på en god brugeroplevelse og effektivt kampagneafvikling. Det er frivilligt om medier eller andre vil følge retningslinjerne eller ej.

 

Retningslinjerne er udarbejdet af Danske Mediers arbejdsgruppe for Online & Advertising bestående af: Astrid Thusgaard-Madsen, Eniro; Anders Høgh Laursen, Berlingske Media; Dennis Vesti Brorsen, Jysk Fynske Medier; Jakob Nielsen, Ekstrabladet; Jesper Johansen, NORDJYSKE Medier; Mikkel Hansen, TV 2 samt Allan Sørensen, Danske Medier.

 

Levering og pakketering

1) Det anbefales, at der benyttes 3. parts tags eller eksternt hostede iframes.

 

2) Leveres der HTML-bannere, bør de være pakket i en .zip-fil med tydelig angivelse af en “main” html-fil, der er navngivet “index.html”, så der ikke opstår tvivl om, hvilken fil der skal hentes, og

 

3) Alle filer skal være indeholdt i én enkelt mappe, da nogle adservere (bl.a. ADTECH) kræver en én-folder struktur. Dvs: Ingen undermapper.

 

Hosting

4) Bannere hostes hos annoncøren med mindre andet er aftalt.

 

5) Ved lange svartider kan mediet vælge at suspendere kampagnen. Det anbefales derfor, at den ansvarlige for hosting af annoncer er omhyggelig med at sikre en serverkapacitet, der kan håndtere et stort antal kald på samme tid.

 

Clicks

6) Target på alle clicks skal sættes til “_blank” så annoncørens side åbnes i en ny fane.

 

7) Afleveres HTML-bannere, skal der angives en tydelig clickTAG-funktion direkte i index.html-filen.

 

8) Det er annoncørens/bureauets ansvar, at banneret indeholder de funktioner, der kan samle en clickTAG-parameter op, som mediet sender med ved afviklingen. Angives dette ikke, kan det ikke garanteres, at mediet kan tælle kliks på kampagnen.

 

9) clickTAGs skrives i de pågældende systemer således:

 

DFP: %%CLICK_URL_UNESC%%
ADTECH: _ADCLICK_
Emediate/Cxense: EASLink=

 


 

Tip: Eksempel på indsættelse af clickTAG i et HTML-banner

 

a) Indsæt dette script i <body> tagget af banneret, der fanger den parameter, som mediet sender med, når en annonce loades:

 

<script>
var parseQueryString=function(){var e=window.location.search;var t={};e.replace(new RegExp(“([^?=&]+)(=([^&]*))?”,”g”),function(e,n,r,i){t[n]=i});return t};var params=parseQueryString();clicker=params[“clickTAG”];
</script>

 

b) Find den funktion, der er bundet til brugerens click-event. Ofte kan du finde den ved at søge efter “window.open”.

 

c) Skift nu URL’en i denne klik-funktion (window.open-funktionen) ud med en, der kalder clickTAG’et. Det gøres således:

 

window.open(“http://landingpage.dk”,”_blank”);

 

Udskiftes med:

 

window.open(clicker+”http:// landingpage.dk”,”_blank”);

 

Banneret vil nu kalde den URL, som mediet sender med, når banneret loades – og mediet vil kunne tælle klik på banneret. Alternativt hvis et banner leveres som en iframe-url, så skal clickTAG og landingURL sættes som en query parameter: ADTECH eksempel:

 

<iframe src=”http://bannerhost.dk/?clickTAG=_ADCLICK_http://landingpage.dk”></iframe>

 


 

Vægt

10) Uanset format må banneret maksimalt hente 100 kB med følgende undtagelser:

 

11) Begrænsning gælder på det initiale load. Data hentet via polite load indgår ikke i opgørelsen af de 100 kB.

 

12) Load af biblioteker fra nedenstående ofte brugte CDN services tæller ikke med i grænsen på de 100 kB. Følgende biblioteker tillades:

 

GSAP fra Cloudflare:
<script src=”https://cdnjs.cloudflare.com/ajax/libs/gsap/latest/TweenMax.min.js”></script>

Jquery:
Seneste to versioner: https://code.jquery.com/jquery/

 

13) Det anbefales, at man loader CDN bibliotekerne via HTTPS også selv om websitet eller banneret kun er i HTTP.

 

14) Data der kaldes efter brugerinteraktion tæller ikke med i grænsen på de 100 kB.

 


 

Tip: Sådan kan du minimere vægten på HTML5-bannere

 

IAB har opstillet en god guideline for udvikling af HTML5-bannere:
http://www.iab.com/guidelines/html5-for-digital-advertising-1-0-guidance-for-ad-designers-creative-technologists

 

Google har ligeledes skrevet en glimrende artikel med gode råd til at holde vægten på HTML5-bannere nede:
https://support.google.com/richmedia/answer/6261897

 


 

Flash

15) Bannere i FLASH-format tillades ikke, da teknologien ikke længere understøttes af flere større browsere og ikke supporteres af Adobe.

 

HTML5

16) Det anbefales at bannere leveres i enten HTML5-format eller flade billede-formater.

 

Bemærk: Det er uhensigtsmæssigt at auto-konvertere flash til HTML5, da filerne ofte bliver unødigt store og hurtigt overstiger de anbefalede grænseværdier.

 

Polite load

17) Ønskes tungere vægt end 100 KB, skal dette være lavet med polite-load (Max 1 MB). Dvs. det må først loades ved browser-eventet window.onload. window.onload må KUN benyttes i iframe bannere. Første load bliver ofte omtalt initial load, mens polite-load også kan omtales subsequent load.

 

Dataindsamling

18) Vær opmærksom på om mediet har fastsat regler for dataindsamling i forbindelse med afvikling af annoncering.

 

19) Det anbefales at annoncør el. bureau inden kampagnestart oplyser mediet om alle tredjeparter, der kaldes i forbindelse med annonceafviklingen af hensyn til at kunne opfylde lovkrav om samtykke fra brugere inkl. oplysning om alle juridiske personer, der har adgang til data samt formålet hermed.

 


 

Tip: Danske Medier og Kreativitet & Kommunikations har udarbejdet en skabelon til en Dataindsamlingsaftale mellem medier og bureauer m.v., der kan findes her:

http://danskemedier.dk/wp-content/uploads/2016/01/Standardaftale-om-Dataindsamling.pdf

 


 

Serverkald

20) Antallet af serverkald fra et banner holdes til maksimalt 15 kald ved initialt load og højst yderligere 10 kald ved polite load af hensyn til ikke at sløve sitets performance unødigt.

 

21) Det anbefales at mest muligt indhold placeres direkte i bannerets kode og ikke i yderligere filer, der først skal hentes.

 

22) For at minimere antal serverkald bør al ekstern grafik sprites og optimeres.

 


 

Tip: Antallet af serverkald kan holdes nede ved at bruge tekst i stedet for grafik.

 


 

Custom fonte

23) Det anbefales, at man undlader at bruge custom fonte eller kun embedder de karakterer, der er anvendt i banneret. Bemærk: Hvis der kaldes et komplet font-bibliotek, når man hurtigt grænsen på 100 kB for et banner.

 

Billeder og grafik

24) Alt grafik skal så vidt muligt leveres i formatet .svg og alle billeder eller grafik leveret i andre formater skal være optimeret mest muligt.

 


 

Tip: Brug evt. en optimizer som: http://optimizilla.com

 


 

Video og audio

25) Streaming af lyd eller video i bannere må kun aktiveres ved enten mouse-over efter 1 sekund og skal så tilsvarende stoppe ved mouse-out. Alternativt kan streaming startes og stoppes ved klik.

 

26) Video-formater i bannere må ikke starte før en bruger selv har foretaget en aktiv handling som f.eks. klik eller mouse-over efter 1 sekund.

 

27) Mediet står for ikke for hosting af streaming med mindre andet eksplicit er aftalt på forhånd.

 

28) Streaming i bannere må max fylde 10 MB efter brugeren har foretaget en aktiv handling.

 

29) Indeholder banneret lyd skal der være en tydelig stop/mute-knap.

 

Scrolling og mobilbannere

30) Mobilbannere med swipe-funktioner eller andre interaktioner må ikke blokere for vertikal scrolling, da det ofte medfører fejlklik og er til irritation for brugerne.

 

31) Brug aldrig touchstart som et alias for click i mobilbannere, da touchstart vil blive skudt afsted når brugeren scroller.

 

Iframes

32) HTML-bannere skal være testet til at fungere i frames, da de ofte loades ofte ind i mediets adserver ved hjælp af en disse.

 

33) Bannere må ikke indeholde scripts, der interagerer med andre elementer på siden og risikerer at ødelægge eller på nogen måde ændre ved sidens indhold.

 

Animationer og loops

34) Annoncer må maksimalt loope 3 gange. Den maximale totale animationstid er 45 sekunder – uanset antallet af loops.

 

35) Animationer før brugerinteraktion i form af klik eller mouse-over efter 1 sekund skal skrives i CSS3 Transitions, Transforms eller Animation – eller med GSAP biblioteker hosted på Cloudflare CDN. der kaldes som:

 

<script src=” https://cdnjs.cloudflare.com/ajax/libs/gsap/latest/TweenLite.min.js”></script>

 

36) Framerate i animationer i bannere begrænses til max 18 fps

 

37) Der tillades ikke processor-tunge animationer før brugerinteraktion i form af klik eller mouse-over efter 1 sekund.

 


 

Tip: CPU-forbrug kan aflæses i ved at trykke CTRL-ALT-DEL og vælge Jobliste samt fanebladet Ydeevne. Åbn annoncen i en browser og kontroller diagrammet. En lille top på 20-30% er helt normalt. Men hvis ikke CPU-forbruget stabiliserer sig på et relativt lavt niveau (max. 5-10%) bør der ændres i filen. Bemærk: CPU-forbruget varierer mellem forskellige maskiner og på baggrund af hvilke processer, der kører. Derfor kan det være svært at anføre præcise grænser for CPU-forbrug. Medier forbeholder sig typisk ret til at fjerne annoncer uden varsel, hvis de bruger urimeligt meget CPU.

 


 

38) Bannere må ikke indeholde vedvarende, hurtige ”stroboskopiske” animationer af grafik, tekst, farver eller baggrundselementer.

 


 

Tip: Se http://csstriggers.com for referencer til hvilke css-properties der er bedst optimeret til animation.

 


 

SSL

39) Det anbefales, at der kun leveres HTTPS / SSL-kompatible bannere.

 

Bemærk: iOS 9 medfører, at man ikke kan blande HTTP- og HTTPS-kald i annoncer. Desuden loader mange adservere nu udelukkende annoncer via HTTPS, og bannere der kalder indhold via HTTP-protokollen risikerer derfor at blive blokeret helt eller kun fremstå delvist.

 


 

Tip: Sådan kontrollerer du om et banner er SSL-kompatibelt:

Sørg som udgangspunkt for at for, at alle billeder, scripts, filer, osv. der loades i dit banner, kaldes med HTTPS som protokol – og ikke med HTTP://

Herefter kontrolleres banneret således:

 

a) Tryk F12 i din browser, så du åbner udviklingsværktøjerne. Vælg fanen ”Konsol” (”Console” på engelsk)

b) Åben dit banner i vinduet. Sørg for at hente banneret via HTTPS (!)

c) Kig i konsollen efter advarsler om ”mixed content”. Hvis det er tilfældet, forsøger banneret at kalde en server via en http-forbindelse der bliver blokeret. Dette kan lede til store diskrepanser og at banneret aldrig bliver vist.

 


 

Standardformater til Desktop:

De enkelte medier fastsætter selv krav til dimensioner på de bannere, som de tillader, men som oftest tillades følgende standardformater:

 

  • 300*250 Medium rectangle (artikelbanner)
  • 160*600 Wide skyskraber
  • 728*90 Leaderboard
  • 930*180 Megaboard
  • 930*600 Monsterbanner

 

Standardformater til Mobil og tablet

Danske Medier og Kreativitet & Kommunikations har udarbejdet et særskilt sæt retningslinjer for kreativer til mobil-sites:
http://danskemedier.dk/wp-content/uploads/2014/08/Retningslinjer-for-kreativer-til-mobil_v2-1.pdf

 


 

LEAN formater

Det anbefales, at alle aktører i markedet søger af efterleve IABs L.E.A.N.-principper med henblik på at styrke brugernes positive opfattelse af displayannoncering:

 

L.E.A.N. står for:

  • Light
  • Encrypted
  • AdChoices supported
  • Non-invasive or disruptive

 

Principperne forskriver at man:

  • Minimerer filstørrelser og datakald for at reducere loadtider
  • Afstår fra formater som overlays og pop-up, der dækker for indhold.
  • Afstår fra formater der afbryder brugeroplevelsen
  • Afstår fra at bruge formater der starter lyd automatisk
  • Leverer annoncer via SSL/HTTPS
  • Anvender AdChoices til at give brugere kontrol med målrettet annoncering

 


 

Referencer: