Best Practices für Back-up-Streams bei der dynamischen Anzeigenbereitstellung

Anders als bei clientseitigen Videoimplementierungen, bei denen der Videostream und Anzeigen unabhängig voneinander angefordert werden, wird bei der serverseitigen Implementierung – die mit der dynamischen Anzeigenbereitstellung verwendet wird – nur ein Stream angefordert, bei dem Anzeigen dynamisch in den Videocontent eingefügt werden. Falls ein Serverfehler auftritt, wird möglicherweise der Stream blockiert. Dies führt nicht nur zu einer schlechten Nutzererfahrung, sondern auch zu Umsatzeinbußen.

In der dynamischen Anzeigenbereitstellung von Ad Manager werden Ihnen HTTP-Fehler angezeigt, wenn Sie einen Stream erstellen und wenn der Stream aktiv ist. Außerdem können Sie einen Back-up-Stream angeben, falls Sie keine gültige Antwort vom Server erhalten.

Der Back-up-Stream wird verwendet, wenn während der Erstellung des Streams ein Fehler auftritt. Falls ein Fehler auftritt, wenn der Stream aktiv ist, wird in Ad Manager automatisch versucht, das Problem durch Verwenden einer Ihrer Varianten zu beheben. Wenn keine Ihrer Varianten wiedergegeben werden kann, wird der Stream beendet. Wir empfehlen Ihnen in einem solchen Fall, einen anderen Stream zu erstellen und noch einmal zu versuchen, den Stream zu aktivieren.

Bei der Erstellung eines Streams erkannte HTTP-Fehler beheben

Fehlertyp	Empfehlung
Fehler vom Typ 4XX (außer 429)	Wenn HTTP-Fehler vom Typ 4XX auftreten, sollten Sie nicht auf die Rohstreams zurückgreifen, da die Fehler am Client vermutlich an diesen Instanzen liegen. Die Anfrage, die Sie an den Server senden, muss richtig sein und alle erforderlichen Parameter enthalten.
Fehler vom Typ 429 oder 5XX	Wenn HTTP-Fehler vom Typ 429 oder 5XX auftreten, sollten Sie auf den Roh-Reservestream ohne Monetarisierung zurückgreifen. Im IMA SDK können diese Fehler mit einem Fehler-Handler erfasst werden und der Standardstream kann auf den Back-up-Stream umgeschaltet werden.

 

Beispiel für die Verarbeitung eines Fehlers mit dem IMA SDK

tvOS

static NSString *const kBackupContentPath =
@"http://googleimadev‑vh.akamaihd.net/i/big_buck_bunny/bbb‑,480p,720p,1080p,.mov.csmil/"
@"master.m3u8";

- (void)streamManager:(IMAStreamManager *)streamManager
didReceiveError:(NSError *)error {
NSLog(@"Error: %@", error);
[self playBackupStream];
}

- (void)playBackupStream {
NSURL *contentURL = [NSURL URLWithString:kBackupContentPath];
self.playerViewController.player = [[AVPlayer alloc] initWithURL:contentURL];
[self.playerViewController.player play];
}

URL des Back-up-Streams für einen Video-on-Demand-Stream (VOD) oder einen Livestream abrufen

Ihre App sollte einen Mechanismus umfassen, um die Back-up-URL für VOD-Streams und lineare Livestreams abzurufen. Bei einem VOD-Stream sollte der Back-up-Stream dem Element ingestURL entsprechen, das im MRSS-Feed angegeben ist. Bei linearen Livestreams sollte der Back-up-Stream mit dem auf der Ad Manager-Benutzeroberfläche angegebenen Contentstream identisch sein.

HTTP-Fehler bei einem aktiven Stream beheben

Falls ein Fehler auftritt, wenn der Stream aktiv ist, sollten Sie nicht auf den Rohstream zurückgreifen. In Ad Manager werden die meisten auftretenden Fehler automatisch behoben, sofern dies möglich ist. In Fällen, in denen ein Fehler nicht am Server behoben werden kann, wird die Wiedergabe des Streams beendet. Falls der Stream angehalten wurde, sollte die App einen neuen Stream starten. Tritt der Fehler weiterhin auf, greifen Sie auf den Rohstream zurück.

Fallback-Implementierung prüfen

Sie können Ihre Fallback-Implementierung mit den folgenden Beispielstreams prüfen:

Streamformat	Asset-Schlüssel
HLS	MSQJlB9VSgqJkGNv1mB0FA
DASH	TrhaCde0R_uKzG_psucTww

Diese Streams dienen ausschließlich zu Testzwecken und lösen immer den HTTP-Fehler 429 aus.

 

Automatischer Failover bei linearen Streams für die dynamische Anzeigenbereitstellung

Für den seltenen Fall, dass unser System ein unerwartet hohes Besucheraufkommen erreicht, verwenden wir möglicherweise einen Stream als Fallback, der bei manchen Nutzern keine Anzeigen enthält. Der Besucher sieht dann den zugrunde liegenden Content.

Falls ein Fallback-Stream nicht ausgeliefert werden kann – etwa weil die Authentifizierung oder der Weiterleitungstyp „Origin" eingerichtet ist oder Varianten für den Stream ausgeschlossen wurden – wird ein HTTP-Antwortcode vom Typ 429 gesendet und die Anwendung greift auf den lokalen Rohstream zurück.

Wenden Sie sich bei Problemen oder Ausfällen bei der dynamischen Anzeigenbereitstellung an den Publisher-Support.