SSL-Konformität

Das SSL-Protokoll (Secure Socket Layer) wird auf sicheren Websites verwendet, um die Kommunikation zwischen dem Server und dem Browser des Nutzers zu verschlüsseln. Damit eine Website SSL-konform ist, müssen alle Elemente, die auf die Website geladen werden, SSL verwenden.

Wird ein nicht sicheres Creative auf einer sicheren Website geschaltet, wird im Browser des Nutzers möglicherweise eine Warnung ausgegeben. Zudem kann es zu Problemen bei der Schaltung kommen oder die gesamte Seite wird blockiert. Daher ist es sehr wichtig, auf die SSL-Konformität zu achten.

Standardmäßige Rich Media-Creatives

Wenn Sie ein Creative mit nicht sicheren URLs in Studio über den Tab "Creatives" hochladen, erscheint auf dem Bildschirm mit den Details zum Creative im Schritt "Dateien verwalten" eine Warnung. Die Warnung neben den einzelnen Creatives zeigt die nicht-sichere URL, die korrigiert werden muss.

Creatives SSL-konform machen

Wenn Sie Ihre Creatives sicher und SSL-konform gestalten möchten, müssen Sie die in Studio aufgeführten nicht sicheren URLs durch sichere URLs ersetzen und die Creatives anschließend noch einmal hochladen. Informationen zur Vorgehensweise erhalten Sie im Rich Media-Hilfeartikel Dateien hochladen. Sichere URLs beginnen entweder mit „https“ oder weisen protokollrelative URLs wie //mysite.com auf.

Tipps

• Ersetzen Sie nicht einfach nur "http" durch "https". Mitunter haben Anbieter und Werbetreibende vollständig andere sichere URLs, insbesondere bei Tracking-URLs für Ereignis-Tags.
• Klick-URLs müssen nicht geändert werden. "http" kann in Links verwendet werden, die den Nutzer von einer sicheren Website auf eine andere weiterleiten.

Assets von einem nicht sicheren Host migrieren

Falls Assets über Ihre aktuelle Hostingplattform nicht sicher ausgeliefert werden können, haben Sie die Möglichkeit, zu einem sicheren Host zu migrieren oder die Asset-Bibliothek von Studio zu verwenden.

Die Basispfade eines Ordners sind für Videodateien überhaupt nicht und für Ordner nur dann verfügbar, wenn der Ordner nach dem 27. Mai 2015 erstellt wurde.

Asset-URLs in einem vorhandenen Creative mit der Asset-Bibliothek ersetzen

Um nicht sichere Asset-URLs in einem vorhandenen Creative zu ersetzen, müssen Sie in Studio Ihre Assets auf den Tab "Assets" hochladen und dann die unten genannten Schritte ausführen.

Assets aus einem Ordner in der Asset-Bibliothek mithilfe der Basispfade des Ordners laden:

1. Wählen Sie einen Ordner aus und kopieren Sie auf dem Tab "Assets" im Bereich Details den Pfad im Feld "Basispfad des Ordners". Der Basispfad des Ordners führt direkt zu diesem Ordner, sodass Sie auf jede Datei in ihm verweisen können.

   Ein Basispfad eines Ordners sieht etwa wie folgt aus: https://s0qa.2mdn.net/ads/richmedia/studio/21429303/.

2. Ersetzen Sie den nicht sicheren Pfad in Ihrem Creative durch den Basispfad des Ordners. Fügen Sie an das Ende des Pfads den Dateinamen an.

   Wenn Sie das oben genannte Pfadbeispiel verwenden würden, sähe die statische URL, die auf die Datei myimage.jpg verweist, so aus: https://s0qa.2mdn.net/ads/richmedia/studio/21429303/myimage.jpg.

Im Artikel Assets zuweisen, entfernen und ersetzen können Sie nachlesen, wie Sie Assets in neue Creatives laden. Die oben genannten Schritte beziehen sich nur auf das Aktualisieren von Creatives, die bereits auf statische Pfade verweisen.

Ein Creative wurde als nicht konform gekennzeichnet, ist aber SSL-konform

Wenn Sie das Creative in Studio auf den Tab "Creatives" hochladen, überprüft Studio unabhängig davon, ob eine bestimmte Methode aufgerufen wird, alle Funktionen im Creative-Code. Wenn Sie die Warnmeldung zur fehlenden SSL-Konformität in Studio beseitigen möchten, müssen die Methoden, die nicht ausgelöst werden, aus dem Creative-Code entfernt werden. Zudem sollten Sie sicherstellen, dass es sich bei allen URLs (Klick-URLs ausgenommen) um sichere URLs handelt. Anschließend können Sie das Creative erneut hochladen.

Dynamische Creatives

Falls Ihr Feed oder Feld nicht konform ist, erscheint neben dem entsprechenden Element in "Schritt 2: Daten verwalten" ein Warnsymbol. Sie können den Feed SSL-konform machen. Außerdem haben Sie die Möglichkeit, den Hinweis zu ignorieren, falls die zugehörigen dynamischen Creatives nie auf Websites getraffickt werden, auf denen SSL-Konformität verlangt wird. Für Profile, die vor dem 1. Juli 2014 erstellt wurden, wird ein entsprechendes Kästchen angezeigt. Wenn Sie es anklicken, bestätigen Sie, dass der Feed SSL-konform ist. 

Das Kästchen „Ich bestätige, dass dieser Feed SSL-konform ist.“

Für dynamische Profile, die vor dem 1. Juli erstellt wurden, können Sie die SSL-Konformität manuell bestätigen. Klicken Sie dazu das Kästchen „Ich bestätige, dass dieser Feed SSL-konform ist.“ an. Damit geben Sie an, dass Sie den Feed überprüft haben und bestätigen können, dass er SSL-konform ist. Die verknüpften Creatives können dann in Campaign Manager 360 getraffickt werden.

Ein Feed ist auch dann konform, wenn die Klick-URLs fälschlicherweise mit dem Label „Text“ gekennzeichnet wurden. Dadurch wird zwar in Studio eine Warnmeldung ausgelöst; prinzipiell ist ein solcher Feed jedoch konform.

1. Überprüfen Sie, ob Sie das Kontrollkästchen für den Feed aktivieren können: Suchen Sie die URL-Spalten im Feed, die mit http:// beginnen und den Feldtyp "Text" aufweisen. Werden diese Spalten für Klick-URLs genutzt?
2. Falls ja, bitten Sie Ihren Berater, die Funktion GPA_ALLOW_OVERRIDING_SSL_STATUS zu aktivieren. Klicken Sie nach der Aktivierung im Workflow für dynamische Creatives unter „Schritt 2: Daten verwalten“ das Bestätigungskästchen an.
3. Falls die Spalten nicht für Klick-URLs verwendet werden, ist der Feed nicht SSL-konform und kann nicht auf Websites getraffickt werden, auf denen SSL-Konformität verlangt wird.

Wenn Sie das Kontrollkästchen Ich bestätige… aktivieren, obwohl das Profil oder Creative n SSL-konform ist, kann dies zu Problemen bei der Schaltung führen.

Dynamische Creatives SSL-konform machen

Um sicherzustellen, dass Ihre dynamischen Creatives sicher und SSL-konform sind, darf für Daten-/Feldtypen, die "http://"-URLs enthalten, nicht "Text" festgelegt sein. Bei einer als "Text" angegebenen URL gelten der Feed und das Profil als nicht-SSL-konform. Verwenden Sie stattdessen eine der in der Tabelle unten aufgeführten Optionen.

Anwendungsfälle	Daten-/Feldtyp	Unterstützte URLs
Bilder	Bild-URL	"http://" oder "https://"
Pixel zum spontanen Erstellen von Videos, Videos*	Drittanbieter-URL	(nur Pixel) http:// oder https://, (andere) http://
Klicklinks	Exit-URL	"http://" oder "https://"
Exit-URLs für die Berichterstellung	Exit-URL	"http://" oder "https://"

* Für Videos sind immer URLs mit "https" erforderlich.

Hinweis: Die sicheren URLs können sich von den nicht sicheren URLs unterscheiden. Ersetzen Sie daher nicht einfach nur "http" durch "https". Mitunter haben Anbieter und Werbetreibende vollständig andere sichere URLs, insbesondere bei Tracking-URLs (für Ereignis-Tags).

Weitere Vorgehensweise für nicht SSL-konforme Profile

Wenn Sie die Warnmeldungen zur fehlenden SSL-Konformität aus dem Studio-Profil entfernen möchten, überprüfen Sie unter "Schritt 2: Daten verwalten", ob die Elemente mit "http://" beginnen und für die Felder die Option "Text" festgelegt ist. Falls ja, haben Sie mehrere Möglichkeiten:

• Ändern Sie den Daten-/Feldtyp zu „Asset-URL“, „Bild-URL“ oder „Drittanbieter-URL“. Vergessen Sie nicht, auch den Creative-Code zu aktualisieren.
• Für einige Profile wird das Kästchen „Ich bestätige, dass dieser Feed SSL-konform ist.“ angezeigt. Aktivieren Sie dieses Kontrollkästchen, falls Sie das Profil überprüft haben und sicher sind, dass es SSL-konform ist. Weitere Informationen erhalten Sie im Abschnitt "Informationen zum Kontrollkästchen 'Ich bestätige, dass dieser Feed SSL-konform ist'".
• Ändern Sie nichts und lassen Sie das Profil in seinem aktuellen Zustand. Falls für das Placement, auf dem das Creative geschaltet werden soll, keine SSL-Konformität erforderlich ist, spielt es keine Rolle, dass die Creatives nicht SSL-konform sind.

Funktionsweise protokollrelativer URLs

Eine protokollrelative URL enthält weder das Präfix HTTP noch das Präfix HTTPS, sondern sie beginnt mit //. Der Vorteil protokollrelativer URLs ist, dass das Protokoll automatisch an die Seite angepasst wird, auf der die URL verwendet wird. Sie können protokollrelative URLs nur von Hosts verwenden, die sowohl die HTTP- als auch HTTPS-Schaltung unterstützen.

Beispiel für eine verschlüsselte Website

Wenn eine protokollrelative URL in https://www.youtube.com aufgerufen wird, wird die URL automatisch über HTTPS geladen, da YouTube über HTTPS geladen wird. // wird zur Ladezeit in https:// geändert.

Wenn versucht wird, eine HTTP-URL auf einer HTTPS-Website zu laden, die Sie besuchen, erscheint in Ihrem Browser eine Warnung und der Content wird möglicherweise überhaupt nicht geladen.

Beispiel für eine nicht verschlüsselte Website

Wenn eine protokollrelative URL in http://www.theguardian.com aufgerufen wird, wird das Pixel automatisch über HTTP geladen, da die Guardian-Website über HTTP geladen wird. // wird zur Ladezeit in http:// geändert.

Eine HTTPS-URL kann ohne Probleme auf einer HTTP-Website geladen werden.

Auf protokollrelative URL umstellen

Wenn eine URL mit http:// beginnt und Sie die protokollrelative Version derselben URL verwenden möchten, sollten Sie zuerst die HTTPS-Version der URL in einem Browser testen. Nicht bei allen Websites ist HTTPS aktiviert. Wenn versucht wird, URLs zu laden, die nicht für das sichere Schalten eingerichtet sind, erscheint eine Fehlermeldung. Sie können einfach prüfen, ob eine URL über HTTPS funktioniert, indem Sie die URL mit dem Präfix https:// in einen Browser eingeben.

Beispiel

Wenn die URL http://www.google.com lautet, geben Sie https://www.google.com in die Adressleiste Ihres Browsers ein. Wenn die URL für das Laden mit dem Protokoll HTTPS eingerichtet ist, wird sie korrekt geladen und in der Adressleiste des Browsers wird ein Vorhängeschloss-Symbol () angezeigt.

 

Lokales Testen

Protokollrelative URLs haben einen Nachteil: Wenn Creative-Entwickler von ihrer Arbeitsstation aus an ihren Creatives arbeiten, versuchen Browser mitunter, sie über das Protokoll file:// zu öffnen. Das bedeutet, dass die protokollrelative URL nicht in einer lokalen Umgebung funktioniert. Da sich dies nur auf das lokale Testen eines Creatives auswirkt, können Sie sicherheitshalber die protokollrelative URL verwenden. Wenn der Entwickler das Pixel auch lokal testen möchte, muss das Protokoll speziell auf HTTPS festgelegt werden.