Häufig gestellte Fragen zu „at.js“

Antworten auf häufig gestellte Fragen über die Adobe Target zur at.js-JavaScript-Bibliothek.

Welche Vorteile hat die Verwendung von at.js gegenüber mbox.js?

Die at.js-Bibliothek ersetzt mbox.js. Die Bibliothek „mbox.js“ wird nicht mehr unterstützt. Für die meisten Benutzer bietet at.js jedoch Vorteile gegenüber mbox.js.

Neben anderen Vorteilen verbessert at.js die Seitenladezeiten für Web-Implementierungen, verbessert die Sicherheit und bietet bessere Implementierungsoptionen für Single-Page-Anwendungen.

Im folgenden Diagramm wird die Seitenladeleistung von mbox.js und at.js verglichen.

(Klicken Sie auf das Bild, um es auf die volle Breite zu erweitern.)

{modal="regular"}

Wie oben gezeigt, werden Seiteninhalte bei der Verwendung von mbox.js erst geladen, wenn der Aufruf von Target abgeschlossen wurde. Bei der Verwendung von at.js werden Seiteninhalte schon geladen, wenn der Aufruf von Target eingeleitet wird, nicht erst nach Abschluss des Vorgangs.

Wie wirkt sich at.js und mbox.js auf Seitenladezeiten aus?

Viele Kunden und Berater möchten wissen, wie sich at.js und mbox.js auf die Ladezeit von Seiten auswirken, insbesondere im Kontext von neuen oder wiederkehrenden Benutzenden. Leider ist es schwierig, zu messen und konkrete Zahlen darüber zu geben, wie at.js oder mbox.js die Seitenladezeit aufgrund der Implementierung jedes Kunden beeinflussen.

Wenn die Besucher-API jedoch auf der Seite vorhanden ist, können Target besser verstehen, wie at.js und mbox.js die Ladezeit der Seite beeinflussen.

In den folgenden Abschnitten wird die Aktionssequenz für neue und zurückkehrende Besucher beschrieben:

Neue Besucher

Zurückkehrende Besucher

Warum sind die Antwortzeiten nach einem Upgrade von einer vorherigen Version von at.js auf Version 1.0.0 scheinbar langsamer?

at.js ab Version 1.0.0 löst alle Anforderungen parallel aus. In den vorherigen Versionen werden die Anforderungen sequenziell ausgeführt, d. h. die Anforderungen werden in eine Warteschlange verschoben, und Target wartet auf den Abschluss der ersten Anforderung, bevor der Vorgang mit der nächsten Anforderung fortgesetzt wird.

Die Art und Weise, wie in früheren Versionen von at.js Anforderungen ausgeführt werden, unterliegt dem so genannten „Head of Line Blocking“. In at.js 1.0.0 und höher ist Target zur parallelen Anforderungsausführung gewechselt.

Wenn Sie sich beispielsweise das Wasserfallmodell der Netzwerkregisterkarte für at.js 0.9.1 ansehen, werden Sie feststellen, dass die nächste Target erst gestartet wird, nachdem die vorherige fertig gestellt wurde. Bei at.js 1.0.0 und höher ist dies nicht der Fall. Dort beginnen alle Anforderungen grundsätzlich zu derselben Zeit.

Auf die Antwortzeit bezogen kann dies mathematisch wie folgt betrachtet werden:

Die at.js-Bibliothek Version 1.0.0 führt die Anforderungen schneller aus. Zudem laufen at.js-Anforderungen asynchron, sodass Target das Rendern der Seite nicht blockiert. Selbst wenn der Abschluss von Anforderungen mehrere Sekunden dauert, wird die gerenderte Seite angezeigt. Lediglich einige Teile der Seite bleiben leer, bis Target eine Antwort vom Target-Edge erhält.

Kann ich die Target-Bibliothek asynchron laden?

In at.js 1.0.0 kann die Target-Bibliothek asynchron geladen werden.

So laden Sie at.js asynchron:

Das asynchrone Laden von at.js eignet sich hervorragend, um zu verhindern, dass das Rendern des Browsers blockiert wird. Bei dieser Technik kann es jedoch zu Flackereffekten auf der Webseite kommen.

Sie können ein Flackern vermeiden, indem Sie ein pre-hiding-Snippet verwenden, das die Seite (oder bestimmte Teile) ausblendet und diese dann nach at.js einblendet und die globale Anfrage geladen hat. Der Ausschnitt muss vor dem Laden von at.js hinzugefügt werden.

Wenn Sie at.js über eine asynchrone Adobe Experience Platform-Implementierung bereitstellen, stellen Sie sicher, dass Sie das pre-hiding-Snippet direkt auf Ihren Seiten einfügen, bevor Sie Target mit Adobe Experience Platform-Einbettungs-Code implementieren.

Wenn Sie at.js über eine synchrone DTM-Implementierung bereitstellen, kann das vor-ausgeblendete Snippet über eine Seitenladeregel hinzugefügt werden, die oben auf der Seite ausgelöst wird.

Weitere Informationen finden Sie unter Verwaltung von Flackern mit „at.js“.

Ist at.js mit der Adobe Experience Manager-Integration (Experience Manager) kompatibel?

Adobe Experience Manager 6.2 mit FP-11577 (oder höher) unterstützt jetzt at.js-Implementierungen mit ihrer Adobe Target Cloud Services.

Wie kann ich mit at.js ein Flackern beim Laden von Seiten verhindern ?

Target bietet mehrere Möglichkeiten, ein Flackern beim Laden von Seiten zu verhindern. Weitere Informationen finden Sie unter " mit at.js verhindern.

Wie groß ist at.js?

Die at.js-Datei hat beim Download eine Größe von etwa 109 KB. Da die meisten Server Dateien jedoch automatisch komprimieren, um die Dateigröße zu verringern, ist at.js bei Komprimierung (mit GZIP oder einer ähnlichen Anwendung) auf dem Server etwa 34 KB groß und wird in dieser Größe auch geladen, wenn Benutzer Ihre Webseite besuchen. Die Komprimierungseinstellungen des Servers, auf dem at.js installiert ist, bestimmen die tatsächliche Größe der Datei.

Warum ist at.js größer als mbox.js?

at.js-Implementierungen verwenden eine einzelne Bibliothek ( at.js), während mbox.js-Implementierungen tatsächlich zwei Bibliotheken ( mbox.js und target.js) verwenden. Es wäre also gerechter, at.js mit mbox.js und target.js zu vergleichen. Beim Vergleich der komprimierten Größen der beiden Versionen ist ersichtlich, dass die at.js-Version 1.2 34 KB groß ist und die mbox.js-Version 63 eine Größe von 26,2 KB hat. ``

at.js ist deshalb größer, weil im Vergleich zu mbox.js deutlich mehr DOM-Parsing durchgeführt wird. Dies ist erforderlich, da at.js „Rohdaten“ in der JSON-Antwort erhält und diese zunächst verarbeiten muss. mbox.js verwendet document.write(), das Parsing wird vom Browser übernommen.

Trotz der größeren Datei zeigen unsere Tests, dass Seiten mit at.js schneller geladen werden als Seiten mit mbox.js. Zudem bietet at.js eine höhere Sicherheit, da keine zusätzlichen dynamischen Dateien geladen werden und document.write nicht benötigt wird.

Enthält at.js jQuery? Kann ich diese Komponente von „at.js“ löschen, wenn ich jQuery bereits auf meiner Website verwende?

at.js nutzt derzeit Teile von jQuery, deshalb wird Ihnen oben in at.js der MIT-Lizenzhinweis angezeigt. jQuery wird nicht ausgelöst und die Bibliothek übt keinen Einfluss auf die bereits auf Ihrer Seite eingebettete jQuery-Bibliothek aus, bei der es sich möglicherweise um eine andere Version handelt. Der jQuery-Code in at.js lässt sich nicht löschen.

Unterstützt „at.js“ Safari und domänenübergreifende Einstellungen, die als „nur x“ eingestellt sind?

Nein, ist die domänenübergreifende Einstellung auf „nur x“ festgelegt und sind Drittanbieter-Cookies in Safari deaktiviert, setzen sowohl mbox.js als auch at.js ein deaktiviertes Cookie und es werden für diese Kundendomäne keine mbox-Anforderungen ausgeführt.

Um Safari-Besucher zu unterstützen, wäre eine bessere X-Domain „deaktiviert“ (setzt nur ein Erstanbieter-Cookie) oder „aktiviert“ (setzt in Safari nur ein Erstanbieter-Cookie, während in anderen Browsern Erst- und Drittanbieter-Cookies gesetzt werden).

Kann ich Target Visual Experience Composer (VEC) in meinen Einzelseitenanwendungen verwenden?

Ja. Sie können VEC für Ihre SPA benutzen, wenn Sie at.js 2.x verwenden. Weitere Informationen finden Sie unter Visual Experience Composer (VEC) für Einzelseiten-Programme.

Kann ich den Adobe Experience Cloud-Debugger für at.js-Implementierungen verwenden?

Ja. Sie können außerdem mboxTrace für das Debugging oder die Entwicklerwerkzeuge Ihres Browsers verwenden und zum Isolieren von Mbox-Aufrufen nach „mbox“ filtern, um die Netzwerkanforderungen zu analysieren.

Kann ich mit at.js Sonderzeichen in meinen Mbox-Namen verwenden ?

Ja, genau wie bei mbox.js.

Warum werden meine Mboxes nicht auf meinen Webseiten ausgelöst?

Target-Kunden verwenden mitunter Cloud-basierte Instanzen mit Target zum Testen oder für einfache Machbarkeitsprüfungen. Diese Domänen sind neben vielen anderen Teil der öffentlichen Suffix-Liste.

Moderne Browser speichern keine Cookies, wenn Sie diese Domänen verwenden - es sei denn, Sie passen die Einstellung cookieDomain mit targetGlobalSettings() an. Weitere Informationen finden Sie unter Verwenden Cloud-basierter Instanzen mit Target.

Können IP-Adressen bei der Verwendung von at.js als Cookie-Domäne dienen?

Ja, wenn Sie at.js, Version 1.2 oder neuer verwenden. Adobe empfiehlt jedoch dringend, immer die neueste Version zu verwenden.

Abhängig davon, wie Sie targetGlobalSettings verwenden, müssen Sie möglicherweise weitere Änderungen am Code vornehmen, nachdem Sie at.js heruntergeladen haben. Benötigen Sie beispielsweise etwas voneinander abweichende Einstellungen für Ihre Implementierungen von Target auf verschiedenen Websites und konnten Sie diese Einstellungen nicht dynamisch mit JavaScript festlegen, nehmen Sie diese Anpassungen manuell vor, nachdem Sie die Datei heruntergeladen haben und bevor Sie sie auf der entsprechenden Website hochladen.

In den folgenden Beispielen können Sie die at.js-Funktion targetGlobalSettings() zum Einfügen eines Code-Ausschnitts verwenden, um IP-Adressen zu unterstützen:

Dieses Beispiel betrifft eine einzelne IP-Adresse:

if (window.location.hostname === '123.456.78.9') {
    window.targetGlobalSettings = window.targetGlobalSettings || {};
    window.targetGlobalSettings.cookieDomain = window.location.hostname;
}

Dieses Beispiel betrifft einen IP-Adressbereich:

if (/^123\.456\.78\..*/g.test(window.location.hostname)) {
    window.targetGlobalSettings = window.targetGlobalSettings || {};
    window.targetGlobalSettings.cookieDomain = window.location.hostname;
}

Warum werden mir Warnhinweise wie zum Beispiel „Aktionen mit fehlenden Selektoren“ angezeigt?

Diese Nachrichten stehen in keiner Verbindung zur at.js-Funktionalität. Die at.js-Bibliothek versucht, alles zu melden, was nicht im DOM gefunden werden kann.

Nachfolgend finden Sie mögliche Grundursachen für diesen Warnhinweis:

Was ist die Domain tt.omtrdc.net, zu der die Aufrufe des Target-Servers gehen?

tt.omtrdc.net ist der Domänenname für das Adobe-EDGE-Netzwerk, mit dem alle Server-Aufrufe für Target empfangen werden.

Warum verwendet at.js nicht immer die Cookie-Flags „HttpOnly“und „Secure“?

„HttpOnly“ kann nur über Server-seitigen Code festgelegt werden. Target-Cookies, wie z. B. Mbox, werden über JavaScript-Code erstellt und gespeichert, also kann Target Cookieflag „HttpOnly“ nicht verwenden. Target verwendet set HttpOnly für Drittanbieter-Cookies, die Server-seitig gesetzt werden, wenn domänenübergreifend aktiviert.

„Secure“ kann nur über JavaScript festgelegt werden, wenn die Seite mit HTTPS geladen wurde. Wenn die Seite nur mit HTTP geladen wird, kann JavaScript dieses Flag nicht festlegen. Darüber hinaus ist das Cookie bei der Verwendung des Flags „Secure“ nur auf HTTPS-Seiten verfügbar. Für Seiten, die über HTTPS geladen werden, legt Target die Attribute Secure und SameSite=None fest.

Um sicherzustellen, dass Target Benutzer ordnungsgemäß verfolgen kann und die Cookies Client-seitig generiert werden, verwendet Target keine dieser Flags außer in den oben genannten Situationen.

Wie behandelt at.js Sicherheitsprobleme wie XSS- und MITM-Angriffe?

Die Kommunikation mit dem Adobe Edge-Netzwerk, das durch at.js aktiviert wird, erfolgt nur über HTTPS, solange die secureOnly Option in der Funktion targetGlobalSettings() auf „true“ (targetGlobalSettings) festgelegt ist. Andernfalls darf at.js basierend auf dem Seitenprotokoll zwischen HTTP und HTTPS wechseln.

Die folgenden Kopfzeilen werden standardmäßig erzwungen:

Alle Kopfzeilen, die bereits auf Client-Seiten verwendet werden, können erzwungen werden. Eine gängige Methode dazu ist die „HTTP-Anfrage-Header-Autorisierung“. Die Adobe-Kundenunterstützung kann Sie hinsichtlich Best Practices und Methoden weiter beraten.

Darüber hinaus sind Anfragen an das Adobe Edge-Netzwerk öffentlich (da sie von Besucherbrowsern aus gesendet werden sollen) und sie enthalten keine sichtbaren Besucherdetails (sie enthalten nur eine Besucher-ID). Diese Anfragen liefern Besuchern Erlebnisse und enthalten Details dazu, was ein Besucher auf der Seite sehen sollte.

Beachten Sie bei Antwort-Token und Sitzungs-IDs, die in diesen Anfragen übertragen werden:

Es wird erwartet, dass der Access-Control-Allow-Origin-Header mit dem Wert "*" in at.js-Anfragen angezeigt wird, da sie öffentlich sind, keine Authentifizierung erforderlich ist und der Zugriff auf das Adobe Edge-Netzwerk von jeder Domain über JavaScript-Aufrufe erfolgen muss.

Die Content Security Policy (CSP) muss jedoch auf der Seite erzwungen werden. Weitere Informationen zu CSP-Anforderungen für at.js finden Sie unter Content Security Policy und targetGlobalSettings.

Wie oft sendet at.js Netzwerkanfragen?

Die Target gesamte Entscheidungsfindung von findet Server-seitig statt. Das bedeutet, dass at.js jedes Mal, wenn die Seite neu geladen oder eine öffentliche at.js-API aufgerufen wird, eine Netzwerkanfrage gesendet wird.

Können wir im besten Fall davon ausgehen, dass Benutzer durch das Ausblenden, Ersetzen und Wiedereinblenden von Inhalten keine Beeinträchtigung der Seitenladezeit bemerken werden?

at.js vermeidet das Vorab-Ausblenden des HTML-Bodys oder anderer DOM-Elemente über einen längeren Zeitraum, dies ist jedoch von den Netzwerkbedingungen und der Aktivitätseinrichtung abhängig. at.js bietet Einstellungen, mit denen Sie den CSS-Style zum Ausblenden des Bodys anpassen können, um nicht den gesamten HTML-Body, sondern nur bestimmte Teile der Seite auszublenden. Hierbei wird erwartet, dass diese Teile DOM-Elemente enthalten, die „personalisiert“ werden müssen.

Wie lautet die Reihenfolge der Ereignisse in einem durchschnittlichen Szenario, in dem sich ein Benutzer für eine Aktivität qualifiziert?

Bei der at.js-Anfrage handelt es sich um eine asynchrone XMLHttpRequest, weshalb wir folgende Schritte ausführen:

Wie oft war der Seiteninhalt vollständig geladen und sichtbar, wenn at.js das Element, das durch die Aktivität geändert wird, zum letzten Mal einblendet?

Wie oft war der Seiteninhalt im oben aufgeführten Szenario vollständig geladen und sichtbar, wenn at.js das Element, das durch die Aktivität geändert wird, zum letzten Mal einblendet? Anders ausgedrückt: Die Seite ist vollständig sichtbar, ausgenommen der Aktivitätsinhalt, der kurz nach dem anderen Inhalt eingeblendet wird.

at.js blockiert nicht das Seiten-Rendering. Benutzer bemerken möglicherweise leere Bereiche auf der Seite, in denen sich die von Target angepassten Elemente befinden. Wenn der anzuwendende Inhalt nicht viele Remote-Assets, wie z. B. Skripte oder Bilder, enthält, wird alles schnell dargestellt.

Wie wirkt sich eine vollständig zwischengespeicherte Seite auf das oben aufgeführte Szenario aus? Ist es in diesem Fall wahrscheinlicher, dass der Aktivitätsinhalt merklich nach dem Rest des Seiteninhalts geladen wird?

Wenn eine Seite in einem CDN gespeichert ist, das sich nahe am Standort des Benutzers, aber nicht in der Nähe des Target-Edge befindet, erlebt dieser Benutzer möglicherweise Verzögerungen. Target-Edges sind jedoch über die ganze Welt verteilt, sodass dies in der Regel kein Problem darstellt.

Ist es möglich, ein Hero-Bild anzuzeigen, das nach kurzer Verzögerung ersetzt wird?

Stellen Sie sich folgendes Szenario vor:

Das Target-Timeout beträgt fünf Sekunden. Ein Benutzer lädt eine Seite, die eine Aktivität zum Anpassen des Hero-Bilds aufweist. at.js sendet die Anfrage, um zu bestimmen, ob eine Aktivität angewendet werden muss, die erste Antwort bleibt jedoch aus. Wir können also davon ausgehen, dass der Benutzer den regulären Inhalt des Hero-Bilds sieht, da keine Antwort von Target zu etwaigen anzuwendenden Aktivitäten eingegangen ist. Nach vier Sekunden gibt Target eine Antwort mit den Aktivitätsinhalten zurück.

Ist es zu diesem Zeitpunkt möglich, dass die alternative Version angezeigt wird? Nach vier Sekunden könnte das Hero-Bild also ausgetauscht werden. Würde der Benutzer diesen Austausch bemerken?

Das Hero-DOM-Element ist zu Beginn ausgeblendet. Nachdem eine Antwort von Target eingeht, wendet at.js die DOM-Änderungen an, wie z. B. die IMG-Änderung und die Anzeige des angepassten Hero-Bilds.

Welcher HTML-Doctype ist für at.js erforderlich?

at.js erfordert den Doctype HTML 5.

Diese Syntax lautet:

<!DOCTYPE html>

Der Doctype HTML 5 stellt sicher, dass die Seite im Standardmodus geladen wird. Beim Laden im Quirks-Modus sind einige JS-APIs, von denen at.js abhängig ist, deaktiviert. Target deaktiviert at.js im Quirks-Modus.

Funktioniert at.js in einer Ionic-App-Umgebung.

Diese Implementierung wurde nie getestet, da at.js nicht für die Verwendung in einer Nicht-Web-Umgebung vorgesehen war. Adobe empfiehlt seine SDKs für mobile Implementierungen.