Sök
Rensa sökning
Stäng sökrutan
Googles appar
Huvudmeny

Välja GPT-läge och taggtyp

Det första du måste välja när du taggar dina sidor med Google Publisher-taggen är om du ska använda asynkron eller synkron rendering. Du måste också bestämma om du vill hämta alla annonser med en enda begäran och vilka annonsenheter och inriktningskriterier som ska användas.

I allmänhet rekommenderar vi att du använder asynkron rendering med läget för en enda begäran aktiverat. Kombinationen ger bästa sidinläsningsupplevelse och garanterade spärrar.

Kodformatalternativ för annonstaggar

  • Asynkron: Den här taggtypen kan minska tiden det tar att läsa in sidor på din webbplats, i och med att annonsen och övrigt innehåll läses in parallellt i stället för att övrigt innehåll läses in först när annonsen är inläst. Det fungerar på så sätt att annonserna renderas i ramar som reserveras på sidan tills annonsen är klar att visa. Det här är det mest användarvänliga taggalternativet.
  • Synkron: Den här taggtypen är avsedd för annonser som inte renderas korrekt i ramar, till exempel expanderbara annonser och mellansidesannonser. Synkrona taggar läser in annonser samtidigt som innehållet på sidan. Annonsutrymmet reserveras inte i synkront läge till skillnad från med asynkrona taggar.*
  • Läge för en begäran: Det här alternativet kan ge bättre inläsningsprestanda för sidan i vissa fall. Med den här typen av tagg anropas alla annonser på sidan samtidigt från sidans huvud i stället för att en begäran skickas för varje annons.

Läs mer om skillnaderna nedan.

Teckenbegränsningar för GPT-annonsbegäranden

I Google Publisher-taggar används HTTP-metoden GET för att begära annonser. Med den blir antalet byte som kan skickas per begäran begränsat. Annonstaggar med synkron rendering kan högst ha 4 096 tecken per begäran. Om taggtypen är asynkron och överskrider 4 096 tecken använder GPT automatiskt metoden POST, vilket höjer gränsen till 8 192 tecken.*

* Den höjda teckengränsen med metoden POST gäller inte för annonser som renderas i IE version 9 och tidigare.

Asynkron och synkron rendering

Asynchronous and synchronous rendering (4:21)
Vad är asynkron rendering och varför rekommenderas det?

En asynkron hämtning innebär att GPT-koden på sidan inte förhindrar att efterföljande HTML läses in. Om du till exempel har en leaderboard med multimedia som tar tid att rendera, gör asynkrona taggar att resten av sidan läses in i stället för att vänta på att det ska bli klart, vilket ger en bättre användarupplevelse och mindre upplevd latens.

En annan anledning till att använda asynkron rendering är om du vill använda dynamisk tilldelning av kompletterande annonser intill video, vilket inte fungerar med synkron rendering (mer information finns i Skapa taggar för kompletterande annonser). En annan är om du vill uppdatera annonsplatser med pubService.refresh(platser), som bara fungerar i asynkront läge (mer information finns i referensguiden för API för Google Publisher-taggar).

Det finns två nivåer av asynkron inläsning med GPT:

  • Asynkron inläsning av GPT:s JavaScript-bibliotek. När du använder det asynkrona läget (som anropas i <head>-taggen) innebär det att <body>-avsnittet på sidan inte väntar på att GPT:s JavaScript-bibliotek ska läsas in före renderingen.
  • Asynkron rendering av annonsmaterialen i <body>-avsnittet i dokumentet. Detta gör att HTML-element kan läsas in utan att vänta på att annonsmaterialen före dem ska renderas.

Vi rekommenderar att både biblioteket och annonsmaterialen läses in asynkront för att ge bästa möjliga prestanda. Det går dock att läsa in biblioteket synkront och rendera annonsmaterialen asynkront.

Visa annonser i asynkrona, lokala iframes i GPT

I GPT används lokala iframes för att visa annonser, vilket är nödvändigt för asynkron användning. Vissa annonser kanske inte renderas korrekt i ramar. Det kan till exempel gälla expanderbara annonser som ska skrivas direkt på huvudsidan eller annonser som försöker få tillgång till DOM-elementen (och JavaScript-miljön) direkt på sidan. Om du använder ett annonsmaterial från tredje part och detta inte har samma storlek som annonsplatsen kan iframen dessutom göra så att annonsen blir beskuren eller att det blir för mycket luft runt den. Det finns några saker du kan göra för att försäkra dig om att annonserna renderas korrekt i GPT:s asynkrona läge:

  • Konvertera egna mallar för lokala iframes och samarbeta med multimedieleverantören för att ta fram korrekta annonstaggar som är klara för iframe.
  • Läs IAB:s lista med metodtips och skapa multimedieannonser som är klara för iframe. Om dessa metoder används ska de flesta multimedieannonser renderas korrekt även i asynkront läge.
  • Använd en av följande två vanliga metoder som gör att expanderbara och flytande annonsmaterial fungerar korrekt med iframes: lokala iframes (rekommenderas) eller filer som blockerar iframes. Båda metoderna beskrivs nedan.

Lokala iframes

Fördelar Nackdelar
Fil som blockerar iframes behövs inte Stöds av ett begränsat antal multimedieleverantörer.
IAB har publicerat rekommendationer för lokala iframes.
Stöds av asynkron GPT.

I asynkront GPT-läge används iframes som finns i samma domän som huvudsidan. När huvudsidan och iframen finns i samma domän är iframen en lokal iframe. Vissa multimedieleverantörer, som DoubleClick Studio, kan blockera lokala iframes direkt utan en fil som blockerar iframes.

I en lokal iframe används en JavaScript-tagg för att visa annonsen så att annonsen visas i iframen. För att hela annonsmaterialet ska kunna visas måste det fortfarande flyttas utanför iframen. Annonskoden identifierar att en lokal iframe används och placerar annonsmaterialet på huvudsidan. Slutresultatet blir att annonsmaterialet visas på sidan, utanför den iframe som användes för att leverera annonskoden, och det behövs ingen fil som blockerar iframes.

Innan du implementerar asynkrona GPT-taggar bör du kontrollera med multimedieleverantören att de har stöd för att undvika lokala iframes direkt. Om leverantören inte har stöd för den här varianten går det fortfarande att använda en fil som blockerar iframes enligt beskrivningen nedan.

Fil som blockerar iframes

Fördelar Nackdelar
Stöds av de flesta multimedieleverantörer. Utgivaren måste ha en fil som blockerar iframes för varje multimedieleverantör.
Stöds av asynkron GPT.

En vanlig lösning du kan använda om multimedieleverantören (till exempel Eyeblaster, Pointroll eller DoubleClick Studio) inte har stöd för lokala iframes är att låta varje leverantör tillhandahålla en HTML-fil som blockerar iframes. HTML-filen måste placeras på din server, oftast på samma server som visar din webb När du väl har filen på servern kan du i allmänhet använda den för alla annonser från den multimedieleverantören.

Den här metoden innebär att annonsmaterialet placeras på huvudsidan och har åtkomst till sidinnehållet. Detta kan vara ett säkerhets- eller integritetsproblem för vissa utgivare.

När annonsen visas inne i en iframe skapas det ytterligare en iframe. Denna iframe anropar filen som blockerar iframes. Annonsen använder sedan filen som blockerar iframes för att placera annonsmaterialet på huvudsidan. Slutresultatet blir att annonsmaterialet visas på sidan, utanför den iframe som användes för att leverera annonskoden.

De flesta multimedieleverantörer har stöd för den här lösningen. Fråga dina leverantörer om de har det.

Kan jag använda både asynkrona och synkrona taggar på min webbplats eller på samma sida?

Du kan använda asynkrona taggar på vissa sidor på din webbplats och synkrona taggar på andra. Det kan vara bra om du till exempel brukar använda asynkrona taggar, men kör en kampanj med multimedieannonser som inte fungerar så bra med lokala iframes. I så fall kan du använda synkrona taggar enbart på sidor där just den kampanjen ska visas och asynkrona taggar på alla andra sidor.

Du kan inte blanda asynkrona och synkrona taggar på samma sida (men du kan läsa in JavaScript synkront och rendera annonsmaterialen asynkront).

Här finns några exempel på synkrona och asynkrona taggar.

Arkitektur med en begäran (SRA)

Single request architecture (5:54)
Vad är läge för en begäran och varför rekommenderas det?

I läget för en begäran läses alla annonser som definierats i sidhuvudet in när den första display()-funktionen anropas i stället för att varje annons anropas separat i annonsplatsen. Vi rekommenderar läget för en begäran eftersom du genom att samla alla annonsanrop i en begäran kan garantera spärrar (att allt annonsmaterial från en rad visas tillsammans på samma sida). Dessutom kan sidan läsas in snabbare med ett mindre antal begäranden.

Om du har aktiverat läget för en begäran kan du också aktivera garanterade spärrar för nätverket. Funktionen förbättrar inställningen Display creatives (Visa annonsmaterial) i raderna genom att erbjuda alternativet att visa Alla. När du väljer Alla visas bara raden om en annonsbegäran innehåller tillräckligt många annonsplatser för att visa alla radens annonsmaterial. Du kan aktivera Garanterade spärrar genom att klicka på fliken Admin och välja Funktioner i kolumnen till vänster.

Du kan också ställa in spärrar för huvudannonser och kompletterande annonser som garanterar att alla annonsmaterial visas tillsammans eller att minst en kompletterande annons alltid visas tillsammans med huvudannonsen.

Dessa funktioner fungerar bara på sidor som har taggats med GPT med läge för en begäran aktiverat.

Visa våra exempeltaggar om du vill veta mer om hur du aktiverar läge för en begäran.

Fall där det kanske inte är bäst att använda läge för en begäran

Alla annonstyper och radtyper i DFP stöds av läge för en begäran. DoubleClicks dynamiska multimedieannonser är däremot inte kompatibla.

*Med synkrona taggar renderas annonser i en div på sidan. Beroende på annonsmaterialet kan de också komma att renderas i en iframe i en div.

Var den här artikeln till hjälp?
Hur kan vi förbättra den?