User-Agent eingefroren: Was Geräteberichte noch belegen können

Drei Angaben, die der User-Agent nicht mehr verrät

Der User-Agent war lange Zeit eine Zeichenkette, aus der Auswertungen Browser, Version, Betriebssystem und oft sogar das Gerätemodell herauslasen. Die User-Agent-Reduktion streicht daraus drei Angaben: die genaue Plattform- beziehungsweise Betriebssystemversion, das Gerätemodell und die Nebenversion des Browsers (MDN Web Docs). An ihre Stelle treten keine Lücken, sondern feste Werte. Plattformversion und Gerätemodell werden durch Konstanten dargestellt (MDN Web Docs), und genau darin liegt das Problem für Berichte: Eine Konstante sieht aus wie ein Messwert. Sie hat das richtige Format, sie lässt sich zählen, sortieren und in Diagramme übernehmen. Nur sagt sie nichts mehr über das Gerät, das den Seitenaufruf ausgelöst hat.

Chromium wendet die Reduktion auf Windows, macOS, Linux, Chrome OS und Chrome auf Android an (Chromium). Die Projektdokumentation hält ausdrücklich fest, dass es sich um wörtliche Werte handelt, die sich auch dann nicht ändern, wenn ein Nutzer ein aktualisiertes Betriebssystem oder ein neueres Gerät verwendet (Chromium). Ein aktuelles Oberklassegerät, ein Tablet eines anderen Herstellers und ein älteres Einsteigergerät senden damit denselben Plattformteil. Die folgende Übersicht stellt gegenüber, was im reduzierten User-Agent steht, was ein Bericht daraus typischerweise macht und was tatsächlich belegt ist.

Die Werte in der Tabelle stammen aus der MDN-Dokumentation zur User-Agent-Reduktion, die für Android Android 10; K, für macOS Macintosh; Intel Mac OS X 10_15_7 und für Windows Windows NT 10.0; Win64; x64 als feste Werte nennt (MDN Web Docs). Die Nebenversion erscheint in jedem Fall als 0.0.0, nur die Hauptversion wird korrekt angezeigt (MDN Web Docs). Den Unterschied an einem einzelnen Gerät zeigt das Beispiel aus derselben Quelle:

# vor der Reduktion (Beispiel aus MDN Web Docs)
Mozilla/5.0 (Linux; Android 16; Pixel 9) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.12.45 Mobile Safari/537.36

# nach der Reduktion
Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Mobile Safari/537.36

Vor der Reduktion stand dort Android 16 mit dem Modell Pixel 9 und die volle Versionsnummer 143.0.12.45, danach Android 10, Modell K und 143.0.0.0 (MDN Web Docs). Browserfamilie und Hauptversion haben die Reduktion überstanden, alles andere ist Platzhalter. Ein Bericht, der die zweite Zeile auswertet, zählt also keine Android-10-Geräte, sondern Chrome-Aufrufe von Android-Geräten beliebiger Version. Das Modell K ist kein Gerät, das irgendjemand in eine Testmatrix aufnehmen sollte.

Die Stufen der Reduktion: von Chrome 101 bis Chrome 113

Die Reduktion kam nicht an einem Stichtag, sondern in Stufen. Die Chromium-Projektseite beschreibt sie als Phasen; für Berichte sind vier davon entscheidend (Chromium). Wer eine Zeitreihe über diese Versionen hinweg betrachtet, sieht Brüche, die kein Nutzerverhalten erklärt. Die Reihe sieht stetig aus, aber die Grundlage hat sich unter ihr verändert.

1. Chrome 101: Die Nebenversionen MINOR.BUILD.PATCH werden reduziert und als 0.0.0 ausgeliefert (Chromium).
2. Chrome 107: Beginn der Einführung des reduzierten User-Agents auf dem Desktop, samt navigator.userAgent, navigator.appVersion und navigator.platform (Chromium).
3. Chrome 110: Beginn der Einführung auf Android, für Mobiltelefone und Tablets (Chromium).
4. Chrome 113: Der umgekehrte Origin Trial endet, alle Seitenaufrufe erhalten den reduzierten User-Agent und die zugehörigen JavaScript-Schnittstellen (Chromium).

Für macOS gilt eine Besonderheit: Die Plattformversion war schon in Chrome 90 aus Gründen der Website-Kompatibilität auf 10_15_7 gedeckelt (Chromium). Der Anlass war also nicht Datenschutz, sondern Kompatibilität, das Ergebnis im Bericht ist dasselbe. Eine Auswertung, die macOS-Versionen aus Chrome-Aufrufen sortiert, zeigt deshalb schon seit Chrome 90 einen einzigen Wert, lange bevor die übrigen Plattformen folgten.

Nicht jeder Browser auf jeder Plattform ist betroffen. Für iOS und Android WebView gibt es laut Chromium derzeit keine Pläne zur Reduktion (Chromium). Aufrufe aus eingebetteten Browsern in Apps können also weiterhin detailliertere Angaben tragen als Aufrufe aus dem Chrome-Browser selbst. In einem Bericht vermischen sich damit echte Versionsangaben aus WebViews und eingefrorene Angaben aus Chrome. Ein Anteil mit aktueller Android-Version kann dann aus einer einzelnen App stammen, während die Konstante Android 10 für alle übrigen Chrome-Aufrufe steht.

Solche Brüche kennt jeder, der Vorjahreszahlen über verschobene Aktionstage vergleicht: Die Kurve läuft weiter, obwohl sich die Messgrundlage geändert hat. Bei Gerätedaten ist es der Browser, der die Grundlage verschiebt, nicht der Kalender. Wer Betriebssystemversionen über mehrere Jahre vergleicht, sollte die Versionssprünge von Chrome im Diagramm markieren und Aussagen davor und danach getrennt lesen.

Das iPad, das sich als Mac ausgibt

Unabhängig von Chromium hat Apple den User-Agent des iPad schon früher umgestellt. Mit Safari 13 sendet Safari auf dem iPad, mit Ausnahme des iPad mini, eine User-Agent-Zeichenkette, die mit der von Safari auf macOS identisch ist (WebKit). Hinter der Umstellung stand das Ziel, auf einem Touchgerät die Desktopfassung von Websites auszuliefern (WebKit). Der WebKit-Blog beschreibt, dass Safari auf dem iPad meistens eine macOS-Kennung übermittelt, wenn es eine Seite lädt (WebKit). Für Berichte heißt das: Ein erheblicher Teil des iPad-Verkehrs erscheint unter macOS und damit in der Regel unter Desktop.

Es gibt eine Ausnahme von der Ausnahme: Wird eine Seite geladen oder neu geladen, während Safari im Multitasking auf ein Drittel der Bildschirmbreite verkleinert ist, sendet Safari eine iOS-Kennung, weil das mobile Layout dort besser passt (WebKit). Dasselbe Gerät kann damit an einem Tag als Mac und als iPad im Bericht auftauchen. Wer Geräteanteile über die Zeit vergleicht, sieht Schwankungen, die mit der Fensteraufteilung zusammenhängen und nicht mit dem Publikum.

Die praktischen Folgen: Der Tabletanteil wird unterschätzt, der Mac-Anteil überschätzt, und Tests für die Touchbedienung bekommen zu wenig Gewicht. Das kann bei Angeboten ins Gewicht fallen, die häufig auf dem Tablet genutzt werden, etwa Kataloge, Rezeptseiten oder Buchungsstrecken. WebKit selbst empfiehlt Entwicklern, die Desktopfassung ihrer Website auf einem iPad zu testen (WebKit). Die Felddaten-Blindstelle bei iOS Safari verstärkt den Effekt: Wo Ladezeitdaten nur aus Chrome stammen, fehlt der iPad-Anteil auch dort.

Windows 10 oder 11: eine Frage ohne Antwort im User-Agent

Bei Windows ist die Lage noch eindeutiger. Microsoft schreibt, dass User-Agent-Zeichenketten nicht aktualisiert werden, um zwischen Windows 11 und Windows 10 oder zwischen Prozessorarchitekturen zu unterscheiden (Microsoft Learn). Der Plattformteil Windows NT 10.0; Win64; x64 steht also auf Windows 10 wie auf Windows 11, unabhängig von der Prozessorarchitektur. Browser, die keine User-Agent Client Hints unterstützen, können die beiden Versionen gar nicht unterscheiden (Microsoft Learn). Laut der Übersicht von Microsoft gilt das für Firefox, während Edge, Chrome und Opera die Unterscheidung über Client Hints ermöglichen (Microsoft Learn).

Ein Bericht, der „Windows 10“ ausweist, zählt damit in Wahrheit Windows 10 und Windows 11 zusammen. Wer daraus einen hohen Anteil veralteter Systeme ableitet und etwa Testaufwand für ältere Windows-Versionen einplant oder eine Kampagne zum Systemwechsel an diesem Anteil ausrichtet, arbeitet mit einer Summe, die sich nicht zerlegen lässt. Die ehrliche Beschriftung lautet „Windows 10/11“. Die Unterscheidung gelingt nur über einen High-Entropy-Hint, den der Server ausdrücklich anfordern muss: Webserver müssen den Antwort-Header Accept-CH senden, um Felder mit höherer Entropie anzufordern, die nicht standardmäßig im Sec-CH-UA-Header stehen (Microsoft Learn).

Was im Gerätebericht weiterhin trägt

Nach der Reduktion bleibt weniger übrig, aber was übrig bleibt, ist belastbarer als vorher. Der Standardsatz der Client Hints umfasst den Browsernamen mit Hauptversion, die Plattform und das Mobil-Kennzeichen (Chromium). MDN nennt als Low-Entropy-Hints Save-Data, Sec-CH-UA, Sec-CH-UA-Mobile und Sec-CH-UA-Platform (MDN Web Docs). Low-Entropy-Hints sind solche, die wenig Information preisgeben, die sich zum Fingerprinting eines Nutzers verwenden ließe (MDN Web Docs). Sec-CH-UA wird, sofern keine Berechtigungsrichtlinie es sperrt, standardmäßig gesendet, ohne dass der Server per Accept-CH zustimmen muss (MDN Web Docs). Zusammen mit Viewport und Bildschirmklasse ergeben sich sechs Angaben, auf die sich ein Gerätebericht stützen kann:

Auch bei diesen Angaben lohnt der zweite Blick. Sec-CH-UA kann an beliebiger Stelle und unter beliebigem Namen erfundene Marken enthalten (MDN Web Docs). Das ist Absicht: Auswertungen sollen nicht auf exakte Markenlisten bauen, die jeden neuen Browser ausschließen. Und die Version im Header ist die signifikante Version: Ein Chromium-Build mit der vollen Nummer 96.0.4664.45 meldet dort 96 (MDN Web Docs). Eine Auswertung muss also Platzhaltermarken herausfiltern und darf aus dem Header keine Patchstände erwarten.

Die Bildschirmklasse ergänzt, was der User-Agent nicht mehr sagt. Sie beantwortet die Frage, die hinter den meisten Gerätefragen steht: Wie sieht die Seite auf den Bildschirmen aus, die das Publikum tatsächlich nutzt? Wer das prüfen will, kann die Seite in der responsiven Vorschau über mehrere Breiten ansehen, statt auf Gerätemodelle zu optimieren, die im Bericht ohnehin nur als Konstante stehen.

High-Entropy-Hints: nur auf ausdrückliche Nachfrage

Die Informationen sind nicht verschwunden. Alles, was vor der Reduktion im User-Agent stand, ist über die High-Entropy-Client-Hints verfügbar, auf Anfrage über die Request-Header der User-Agent Client Hints oder über die JavaScript-Schnittstelle navigator.userAgentData.getHighEntropyValues (Chromium). High-Entropy-Hints sind solche, die mehr Information für ein Fingerprinting preisgeben können, und sie sind deshalb so abgesichert, dass der Browser entscheiden kann, ob er sie liefert (MDN Web Docs). Alle Client Hints, die keine Low-Entropy-Hints sind, gelten als High-Entropy-Hints (MDN Web Docs). So sieht eine solche Nachfrage aus:

# Antwort-Header: der Server fordert Details an
Accept-CH: Sec-CH-UA-Platform-Version, Sec-CH-UA-Model, Sec-CH-UA-Full-Version-List

# JavaScript: Nachfrage beim Endgerät
navigator.userAgentData.getHighEntropyValues(['platformVersion', 'model', 'fullVersionList'])

Der Mechanismus dahinter ist in RFC 8942 beschrieben. Das Dokument definiert den Antwort-Header Accept-CH, mit dem ein Server ausdrücklich darum bittet, dass der Browser diese Header in Anfragen mitsendet (RFC 8942). Weil Client Hints ein ausdrücklicher Opt-in-Mechanismus sind, müssen Server, die Informationen über die Umgebung des Nutzers wollen, aktiv danach fragen; Browser und Datenschutzforscher können so nachvollziehen, welche Ursprünge diese Daten sammeln, und darauf reagieren (RFC 8942). Ist der Browser einverstanden, sendet er die angeforderten Header bei allen folgenden Anfragen, bis Browser oder Tab geschlossen werden (MDN Web Docs).

Mit dem Prüfwerkzeug für HTTP-Header lässt sich feststellen, ob die eigene Website bereits Accept-CH setzt. Das kann passieren, ohne dass es dem Betreiber bewusst ist, etwa weil ein Plugin, ein vorgeschalteter Zwischenspeicher oder ein eingebundenes Skript den Header konfiguriert hat. Wer eine Messung ohne Einwilligung betreiben will, sollte wissen, welche Details die eigene Website beim Endgerät anfordert.

Warum eine cookielose Messung bewusst verzichtet

RFC 8942 benennt den Grund, warum die Reduktion überhaupt kam: Die Erkennung über den User-Agent kann nicht alle statischen Merkmale zuverlässig bestimmen, braucht eine externe Gerätedatenbank, ist nicht cachefreundlich und stützt sich auf eine passive Fingerprinting-Fläche (RFC 8942). Unter dem Stichwort Entropie hält das Dokument fest, dass sehr fein aufgelöste Daten helfen können, Nutzer über mehrere Anfragen an verschiedene Ursprünge hinweg zu identifizieren (RFC 8942). Genau diese Daten liefern High-Entropy-Hints: exakte Betriebssystemversion, Gerätemodell, vollständige Versionsnummern.

Für eine Messung ohne Einwilligung ist das zuerst eine rechtliche Frage. Nach § 25 Abs. 1 TDDDG ist die Speicherung von Informationen in der Endeinrichtung des Endnutzers oder der Zugriff auf dort bereits gespeicherte Informationen nur zulässig, wenn der Endnutzer auf Grundlage klarer und umfassender Informationen eingewilligt hat (TDDDG). Ob die aktive Nachfrage nach High-Entropy-Werten als ein solcher Zugriff gilt, ist nicht abschließend geklärt und hängt vom Einzelfall ab; dieser Beitrag ersetzt keine Rechtsberatung. Wer eine Messung ohne Einwilligungsbanner betreiben will, ist aber gut beraten, diese Frage gar nicht erst aufzuwerfen.

Die technische Seite ist ebenso klar. Eine Messung, die bewusst auf Cookies und Wiedererkennung verzichtet, würde ihr eigenes Konzept unterlaufen, wenn sie gleichzeitig die Merkmale einsammelt, die sich am besten zur Wiedererkennung eignen. Der Verzicht hat einen Preis: kein getrennter Ausweis für Windows 11 und Windows 10, keine Gerätemodelle, keine Patchstände. Der Gewinn ist ein Bericht, der nichts behauptet, was er nicht gemessen hat. Warum das Grundprinzip trägt, beschreibt der Beitrag über cookieloses Tracking ohne Consent-Banner ausführlicher; die datenschutzrechtliche Einordnung der Messung bündelt die Seite zur DSGVO-Compliance von XICTRAQ.

Den eigenen Gerätebericht prüfen

Ob ein Bericht Konstanten als Messwerte ausweist, lässt sich mit wenigen Handgriffen feststellen. Die folgenden Schritte funktionieren mit jedem Werkzeug, das Aufschlüsselungen nach Betriebssystemversion, Gerätemodell oder Browserversion anbietet, und ebenso mit den Zugriffsprotokollen des eigenen Servers.

1. Android-Versionen nach Browser aufschlüsseln: Dominiert bei Chrome-Aufrufen ein einziger Wert Android 10, ist das die Konstante Android 10; K und keine Gerätegeneration (MDN Web Docs).
2. Gerätemodelle ansehen: Taucht das Modell K auf, stammt es aus dem reduzierten User-Agent. Es gehört weder in eine Testmatrix noch in eine Zielgruppenbeschreibung.
3. macOS-Versionen ansehen: Eine Häufung bei 10.15.7 zeigt den gedeckelten Wert, nicht den Softwarestand der Mac-Nutzer (Chromium).
4. Windows-Beschriftung ansehen: Steht dort „Windows 10“, ist in Wahrheit die Summe aus Windows 10 und Windows 11 gemeint (Microsoft Learn).
5. Nebenversionen ansehen: Enden Browserversionen auf .0.0.0, ist nur die Hauptversion belastbar (MDN Web Docs).
6. iPad-Anteil gegen Bildschirmklassen halten: Ein auffällig kleiner Tabletanteil bei gleichzeitig vielen Mac-Aufrufen mit Tablet-Auflösungen spricht für iPads hinter der Mac-Kennung (WebKit).
7. Zeitreihen an den Versionssprüngen lesen: Brüche rund um Chrome 101, 107, 110 und 113 sind eher Folgen der Reduktion als Verhaltensänderungen (Chromium).

Wer Zugriffsprotokolle des eigenen Servers hat, kann die Konstanten direkt suchen. Das folgende Beispiel zeigt drei Abfragen und die Werte, auf die sie treffen; die Ausgabe ist auf den ersten Treffer gekürzt.

Jede Zeile, die auf eines dieser Muster trifft, trägt an dieser Stelle keine Geräteinformation. Wer die Treffer ins Verhältnis zu allen Aufrufen der jeweiligen Plattform setzt, sieht, wie groß der Anteil der Konstanten im eigenen Bericht ist, und damit, wie wenig die Versionsspalte noch aussagt. Automatisierte Aufrufe verzerren das Bild zusätzlich, weil viele Crawler veraltete oder erfundene Kennungen senden; wie man sie aussortiert, beschreibt der Beitrag zum Filtern von Bot-Traffic in der Webanalyse.

So geht XICTRAQ Analytics mit eingefrorenen Werten um

XICTRAQ Analytics ist für genau diese Lage gebaut. Von den Client Hints wertet XICTRAQ ausschließlich die drei Low-Entropy-Hints Sec-CH-UA, Sec-CH-UA-Mobile und Sec-CH-UA-Platform aus, die der Browser mit der Messanfrage ohnehin standardmäßig mitschickt. Die Website sendet dafür kein Accept-CH, und der Tracker ruft getHighEntropyValues nicht auf. Die Geräteklasse stützt sich neben dem User-Agent auf das Mobil-Kennzeichen, die Viewport-Breite und die Bildschirmgröße. Wie diese Werte in den Auswertungen erscheinen, beschreibt die Dokumentation zu den Analytics-Berichten.

• Android 10; K: wird als Android ohne Versionsangabe geführt, weil die Versionsangabe eine Konstante ist.
• macOS 10.15.7: wird als macOS ohne Versionsangabe geführt, aus demselben Grund.
• Windows NT 10.0: erscheint als Windows 10/11, weil der User-Agent die beiden Versionen nicht trennt.
• iPad hinter der Mac-Kennung: wird über die Bildschirmauflösung und das Hochformat als Tablet erkannt, statt als Mac gezählt zu werden.
• Bildschirme: lassen sich über fertige Klassen wie Full HD, WQHD, UHD/4K und Ultrawide auswerten, statt einzelne Pixelwerte zu vergleichen.

Welche Signale der Tracker erfasst, listen die Einstellungen des Trackers auf; die technische Einbindung beschreibt die Anleitung zum JavaScript-Tracker. Im Bericht lassen sich Gerät, Browser und Betriebssystem aufschlüsseln und nach Auflösung oder Bildschirmklasse filtern. Eingefrorene Versionsfelder bleiben dabei leer, statt mit einer Konstante gefüllt zu werden.

Welche Entscheidungen sich noch auf Geräteberichte stützen lassen

Für die Browserunterstützung bleiben Browserfamilie und Hauptversion belastbar. Wer festlegen will, ab welcher Version ein Feature ohne Ausweichlösung ausgeliefert wird, findet diese Angabe weiterhin im Bericht. Für Layout und Tests tragen Mobil-Kennzeichen, Viewport und Bildschirmklasse, Gerätemodelle nicht. Für Fragen zum Betriebssystem trägt die Plattform, die Version in der Regel nicht.

Nicht mehr belastbar sind Aussagen über Android-Altgeräte, über den Anteil von Windows 10 und über die Verbreitung bestimmter Mac-Softwarestände, soweit sie aus Chrome-Aufrufen stammen. Wer solche Fragen beantworten muss, braucht eine andere Datenquelle mit Einwilligung, etwa eine freiwillige Umfrage oder Supportdaten mit Zustimmung, nicht die Webanalyse. Ähnlich verhält es sich mit KI-Browsern, deren Aufrufe sich ebenfalls nur über Client Hints und Verhalten einordnen lassen; der Beitrag zu KI-Browsern in der Webanalyse zeigt, wie Sec-CH-UA dort zur Unterscheidung beiträgt.

Für die Planung heißt das: Testbudgets nach Bildschirmklassen und Browserfamilien verteilen, nicht nach Gerätemodellen. Supportzusagen an Hauptversionen knüpfen, nicht an Patchstände. Und jede Kennzahl, die auf einer Betriebssystemversion beruht, mit dem Hinweis versehen, ob sie aus einer Konstante stammt. Welcher Tarif welche Auswertungstiefe enthält, steht in der Preisübersicht von XICTRAQ.