Das SPIEGEL-Radar — Wie wir mit Kennzahlen arbeiten (und mit welchen)

13 min readOct 18, 2021

Welche Kennzahlen sind relevant für die redaktionelle Arbeit? Wie wichtig ist Reichweite? Was sind eigentlich die „richtigen“ Zahlen, wie interpretieren wir sie, und was lernen wir daraus? Vor diesen Fragen stehen Digitaljournalist:innen seit vielen Jahren — und die Antworten wandeln sich stetig. Der Markt verändert sich, die Bedürfnisse der Leser:innen und die der Redaktionen, die Unternehmensziele und auch die Kultur des jeweiligen Medienhauses. Eine Lösung, die für alle Redaktionen passt, gibt es nicht. Zuallererst steht also die Erkenntnis: Dies ist kein Projekt mit einem fest definierten Ziel und einem zeitlichen Ende. Dies ist ein Prozess, in dem alle Einzelteile immer wieder nachjustiert werden.

Im Zuge des umfassenden Relaunch-Projekts NextGen Anfang 2020 haben wir damit begonnen, ein maßgeschneidertes System für redaktionelle Kennzahlen zu entwickeln: das SPIEGEL-Radar.

Es zeigt die wichtigsten Kennzahlen, die im Alltag relevant sind.
Es nimmt keine Entscheidungen ab, sondern hilft Redakteurinnen und Redakteuren, besser zu verstehen, wie ihre Inhalte ankommen, und informierte Entscheidungen zu treffen.
Es ist auf verschiedene Gruppen innerhalb der Redaktion ausgerichtet und zeigt in Dashboards Kennzahlen für das Geschehen auf der Homepage und die Performance-Daten von Artikeln mit verschiedenen Filtermöglichkeiten an.
Es vereint unterschiedliche Datenquellen und kombiniert diese so, wie es einzelne Tools von der Stange nicht können.
Es ist auf die individuellen Unternehmensziele des SPIEGEL angepasst.

Klingt aufwendig? Ist es auch. Aber es hat sich gelohnt.

Der Weg zur „richtigen“ Kennzahl

Welche Kennzahlen sind die richtigen? Zunächst sind zwei Grundfragen zu klären:

Vor welcher Fragestellung steht die jeweilige Abteilung?„Was möchtet Ihr denn wissen?“ — diese Frage steht meist am Anfang, wenn aus der Redaktion der Wunsch nach einer Auswertung ihrer Inhalte kommt. Die Frage klingt einfach, ist aber alles andere als trivial zu beantworten. Oftmals ist es etwas Allgemeines wie: „Ich möchte wissen, ob die Homepage funktioniert.“ Oder der Artikel. Oder ein Social-Post. Die Kriterien, was „funktioniert“ bedeutet, können sehr unterschiedlich sein. Beispiel Homepage: „Läuft“ sie besonders gut, wenn sie möglichst viele Menschen erreicht? Wenn diese Menschen möglichst lange bleiben? Wenn sie möglichst viele Artikel lesen, Videos schauen, Kommentare schreiben? Wenn sie möglichst häufig wiederkommen? Wenn sie sich zu einem Probeabonnement entscheiden? Am liebsten alles gleichzeitig? Es lohnt sich, auf die Ausgangsfrage eine möglichst genaue Antwort zu finden.
Welche Möglichkeiten hat die Abteilung, auf die Kennzahl zu reagieren? Es gibt im Grunde zwei Sorten von Kennzahlen: Jene, die bei der Ad-hoc-Steuerung helfen (wenn ich also durch konkrete und sofortige Eingriffe in den Status quo etwas an der Kennzahl in meinem Sinn verändern kann) — und jene, die rückwirkende Analysen ermöglichen, die mir Hinweise darauf geben, ob meine strategischen Überlegungen und Schwerpunkte so beim Publikum ankommen, wie ich mir das vorgestellt habe. Beide sind wichtig, sie ergänzen und bedingen sich sogar. Kommen nur wenige Menschen von der Homepage aus in einen Artikel, kann das mehrere Gründe haben. Vielleicht ist die Headline langweilig, zu laut oder unpräzise, vielleicht schreckt die optische Aufmachung ab, vielleicht ist der Text zu weit unten eingebaut, der Vorspann unattraktiv oder auch das Thema. Ad hoc lässt sich an den meisten möglichen Ursachen etwas verändern, an der Headline, dem Vorspann oder der Aufmachung. Nur der womöglich schwierige Themenbereich — der bleibt. Und wäre wiederum ein Fall für die Analyse: Warum nehmen unsere Leser:innen das Thema nicht so an, wie wir uns das vorstellen, wenn wir es doch für relevant halten? Ist das bei diesem Thema immer so? Liegt es am Format? Um Rückschlüsse ziehen zu können, ist ein systematischer Blick auf größere Datenmengen nötig, die nicht in Echtzeit-Dashboards abbildbar sind.

Sind die beiden Grundfragen erst einmal geklärt, geht es an Konzeption und Testing. Beim SPIEGEL leistet die Kernarbeit ein interdisziplinäres Team aus Daten- und Research-Expert:innen, IT und Redaktion. Auf dem Weg werden immer wieder Feedback-Runden mit Produktentwicklung und den jeweiligen Nutzer:innengruppen gedreht.

Das Projekt SPIEGEL-Radar

Woher wir kommen

Vor dem Relaunch 2020 haben wir fünf verschiedene Tools parallel benutzt. Eines zur Unterstützung der Homepage-Steuerung (Meetrics), eines für den redaktionellen Hausgebrauch (Parse.ly), eines für tiefere Analysen (Google Analytics) und eines zur Erfassung unserer Probeabos (Plenigo via Tableau-Visualisierung) und eines, das schon seit 2009 auf SPIEGEL ONLINE lief (Reports/Netmind). Wir haben im Laufe der Jahre etliche weitere Anbieter getestet, unter anderem Outbrain, Chartbeat und Linkpulse.

Viele dieser Tools sind aufwendig programmiert, haben beeindruckende interaktive Visualisierungen und Live-Dashboards. Sie sind schnell und performant, und wenn es mal nicht läuft, gibt es meist einen 24/7-Support. Nachteil: Sie sind teuer.

Zudem bieten die meisten Lösungen in der Regel Standardkennzahlen wie unter anderem “Page Views”, “Visitors” (neu und wiederkehrend), “Engaged Time” und Zuführungskanäle, manche auch diverse Formate von Interaktionen, sogar explizit “Conversions”. Allerdings muss man sich für einen Anbieter mit all seinen Stärken und auch Schwächen entscheiden, eine Individualisierung auf Basis der Bedürfnisse der eigenen Arbeitsabläufe und Geschäftsinteressen ist in aller Regel nicht möglich.

Wir hatten also zu viele (oder nicht ganz passende) Kennzahlen — und zu viele Tools. Diese beiden Punkte waren die Hauptmotivation, ein eigenes Tool zu entwickeln:

1. Single Source of Truth: Wir wollten nur noch eine Quelle für unsere Kennzahlen, nicht mehrere nebeneinander, die technisch unterschiedlich funktionieren und daher zu oft widersprüchlich wirken.

2. Individualisierung: Wir wollten nur noch die Kennzahlen sehen, die für uns wirklich nötig und hilfreich sind. Niemand braucht ein Tool, das auf dem Startscreen ruft „It’s a great day“ — dabei sind nur gerade einige tausend Menschen in einem sehr klickintensiven Spiel unterwegs.

Und so fiel mit dem Umstieg auf ein neues Redaktionssystem auch die Entscheidung, ein neues Analytics-Tool anzuschaffen, das für alle Abteilungen im Verlag nutzbar ist: Adobe Analytics, das die Nutzungsdaten liefert. Um diese Nutzungsdaten von spiegel.de mit Metadaten der Artikel und Vertriebsinformationen verknüpfen zu können, kam eine weitere Komponente ins Spiel: PowerBI, ein Microsoft-Tool, das die Visualisierung komplexer Daten aus verschiedenen Quellen ermöglicht.

Ein interdisziplinäres Team aus IT-Expert:innen, Produktentwicklung und Redaktion hat Ende 2019 begonnen, das SPIEGEL-Radar zu entwickeln, anfangs unter hohem Zeitdruck, weil das Tool synchron mit dem Umstieg auf unsere neuen Systeme fertig sein musste. Seither arbeitet das Team daran, das Radar stetig zu verbessern und immer wieder an die Bedürfnisse der Redaktion anzupassen.

Wo wir stehen — Der Weg vom ersten Entwurf bis zum aktuellen Stand

Der Entwurf — Herbst 2019

So sah die erste Idee für ein Homepage-Dashboard aus. Oben die allgemeinen Kennzahlen in der Übersicht, darunter eine Liste mit den Artikeln, die im oberen Bereich der Homepage zu sehen sind, und einem Bereich darunter, der die „Hidden Gems“, die verborgenen Schätze, anzeigt, die gerade besonders gut laufen, aber womöglich mehr Sichtbarkeit vertragen könnten.

Die erste Live-Version — Januar 2020

Diese Version des Homepage-Dashboards entspricht der ersten Umsetzung, die im Januar 2020 mit der Umstellung der Systeme live ging. Zu Beginn hatten wir mit technischen Problemen zu kämpfen, die im Testbetrieb mit dem alten System nicht aufgetreten waren. Die Real-Time-Schnittstelle funktionierte nicht wie zuvor und lieferte häufiger Daten verzögert, das neue Redaktionssystem verhielt sich im Zusammenspiel anders als in der Testphase, die Datenbanken waren überlastet, und wir waren streckenweise im Daten-„Blindflug“ unterwegs, so dass unsere Redaktion sich immer wieder auf ihr über Jahre trainiertes Bauchgefühl verlassen musste. Und, auch das sei gesagt: Es funktionierte. Der redaktionelle Alltag lässt sich, mindestens vorübergehend, auch ohne Echtzeitdaten bewältigen. Die Menschen sind uns nicht in Scharen davongelaufen.

Unsere wichtigsten Kennzahlen auf dem Homepage-Dashboard und welche Alltagsfragen sie beantworten:

1. Wie attraktiv ist dieser Inhalt generell? „Live“ (Klicks in den Artikel in den letzten 5 Minuten, minütlich aktualisiert, bezieht sich auf interne (spiegel.de) wie externe Quellen wie SEO, Social, Aggregatoren etc.; der grüne Pfeil weist auf steigenden Traffic hin, der gelbe auf Stagnation, rot wäre Sinkflug)

2. Wie attraktiv ist dieser Inhalt für Menschen, die bereits auf der Homepage sind, also unser loyales Publikum? „CTR“ (steht für Click-through rate, das Verhältnis der Klicks zur Anzahl der Impressions auf der Homepage, die auf diesen Text entfallen, ebenfalls binnen fünf Minuten)

Zusätzlich sind Metadaten zum Artikel zu finden, unter dem Detail-Link gibt es weitere Informationen wie Unique Visitors, Lesetiefe, Traffic-Entwicklung, Devices und Referrer.

Die erste Iteration — Februar 2021

Mit der Einführung der „Pay first“-Strategie im Herbst 2020 haben wir die Spalte „CON“ (steht für Conversions, also den Abschluss eines Probeabos) hinzugefügt. Sie bezieht sich auf einen Zeitraum von zwei Stunden und wird ebenfalls minütlich aktualisiert. Die bunten Pfeile haben sich als nicht hilfreich erwiesen und werden entfernt. Als neues Merkmal kommt „HPseit“ hinzu, die Standzeit eines Artikels auf der Homepage, also das Zeitfenster, in dem wir einem Inhalt die größtmögliche für uns direkt steuerbare Sichtbarkeit geben.

Die zweite Iteration — Juni 2021

Teil unserer „Pay first“-Strategie ist, dass wir jede Woche 4000 neue Probeabonnentinnen und -abonnenten gewinnen wollen. Um dieses Wochenziel sichtbar zu machen, haben wir einen Tacho eingebaut, der uns den Fortschritt anzeigt. Der aktuelle Tag ist ebenfalls mit seinem Beitrag zu sehen. Mediane geben einen Hinweis auf die Ergebnisse der Vorwochen. Wichtig für uns ist ebenfalls zu wissen, wie sich unsere Abonnent:innen auf der Seite verhalten, daher kommt eine Spalte mit einer Kennzahl hinzu, die den Anteil der zahlenden Kundschaft in den Artikeln wiedergibt.

Und so funktioniert das Radar

Umsetzende Abteilung ist die SPIEGEL-IT. Die Kolleg:innen standen zunächst vor der Frage, mit welchen Software-Komponenten ein maßgeschneidertes System realisiert werden kann. Das Ziel: Wir wollten eine moderne Cloud-Anwendung für redaktionelle Kennzahlen zur Verfügung stellen, die sicher aus dem Internet erreichbar und auf allen Devices (Mobile, Tablet und stationäre Rechner) aufrufbar ist. Es gab zwei mögliche Wege: eine vollständig individuell entwickelte Anwendung — oder eine Lösung auf Basis der Microsoft-Azure-BI-Plattform und PowerBI.

Es gab viele Aspekte abzuwägen: Wie hoch würden Projekt- und Betriebskosten ausfallen? Wie ist es um die IT-Sicherheit bestellt? Welche Software-Komponenten benutzen wir bereits im Haus? Schließlich fiel die Entscheidung: Wir probieren es mit der bereits im Haus eingesetzten Microsoft-Azure-Infrastruktur und PowerBI.

Für uns von Vorteil: Die Azure-BI-Infrastruktur bringt alle nötigen Komponenten mit, um eine sichere, moderne, datengetriebene Anwendung umzusetzen.

Fürs SPIEGEL-Radar sind unsere Hauptdatenquellen:

redaktionelle Daten aus dem Redaktionssystem Statamic (Titel, Text, Publish Date etc.),
Hompepage-Strukturdaten (Artikel-ID, Position des Artikels auf der Homepage, Homepage-Blöcke etc.)
Metriken aus Adobe Analytics (Visits, Views etc.)
Ergänzend dient das redaktionelle Bildsystem als Quelle für die Vorschaubilder.

Und so funktioniert das Ganze: Die Adobe-Daten werden per Pull-Webservice abgefragt und zusammen mit den Daten aus dem Redaktionssystem, die automatisch per Push-Webservice bei jeder Änderung im Redaktionssystem zur Verfügung gestellt werden, im Data Lake abgelegt. Alle Daten liegen im JSON-Format vor. Der Data Lake dient als zentraler Speicher und verteilt die Daten neben dem Radar auch an andere Systeme, die redaktionelle Daten konsumieren.

Aus dem Data Lake werden die Daten per ETL-Mechanismen (ETL steht für „Extract, Transform, Load“) in eine Stage-Datenbank übertragen. Dort werden sowohl Artikel-JSON-Daten, die Homepagestruktur-JSON-Daten als auch die Adobe-JSON-Daten in Tabellenstrukturen transformiert und geladen. Beispielsweise werden die unterschiedlichen Homepageblöcke identifiziert, extrahiert und in eine entsprechende Tabellenstruktur geschrieben.

Herzstück des Radars ist der sogenannte Core-Layer. Hier werden die Rohdaten aus den Stage-Tabellen in ein logisches Datenmodell überführt und miteinander verknüpft. Außerdem findet im Core-Layer die Berechnung eines Großteils der Kennzahlen statt. Ein Beispiel: die Berechnung der Conversions eines Artikels (also der Probebaos, die wir diesem Inhalt zuschreiben) in einer Minute. Zudem hat eine abstrakte Homepage-Position mit Artikel-ID nach dem Durchlaufen der Prozesse im Core-Layer einen sprechenden Titel, eine lesbare Position, ein Publish Date und ein Vorschaubild.

Nachdem ein Großteil der Kennzahlen vor- oder komplett berechnet ist, werden die Daten in einem letzten Schritt in einen In-Memory-Layer (Analysis-Service) geschrieben. Dieser Layer dient als Cache, der es ermöglicht, ohne Performance-Einbußen mit einer großen Anzahl an Usern auf die Kennzahlen in PowerBI zuzugreifen. Außerdem führt Layer finale Berechnungen durch und reicht sie an PowerBI weiter. So wird beispielsweise der Zwölf-Wochen Median der Conversions auf Basis der vorberechneten Conversions im Core-Layer berechnet.

Herausforderungen

Redaktionell

Die Skepsis gegenüber Kennzahlen im redaktionellen Kontext hat in den letzten Jahren deutlich abgenommen. Dennoch gibt es immer wieder Fragen. Die häufigsten drei sind:

Können mir als Redakteur:in Zahlen nicht egal sein? Die Zeiten, in denen die Redaktion sich um die Buchstaben und „der Verlag“ sich um die Zahlen gekümmert haben, sind lange vorbei. Um die grundlegenden Veränderungen, die der Medienwandel mit sich bringt, und vor allem die Bedürfnisse der Nutzer:innen besser zu verstehen, müssen sich Redaktionen damit beschäftigen, ob und wie ihre Inhalte funktionieren. Diese Erkenntnisse sind essenziell für das Geschäftsmodell und das Gedeihen der Marke. Daher ist die Beschäftigung mit den wichtigsten Kennzahlen kein Hobby, sondern integraler Bestandteil redaktioneller Arbeit.
Sollen wir jetzt nur noch schreiben, was die Leute lesen wollen? Natürlich nicht. Die Entscheidung, ob ein Thema relevant ist, bleibt eine zutiefst redaktionelle. Wenn ein Text, Video oder sonstiges Format trotzdem nicht so performt, wie erhofft, kann das die unterschiedlichsten Gründe haben. Es bleibt aber der Kernpunkt: Die Redaktion mag das Thema für relevant halten, aber offensichtlich ist es nicht gelungen, diese Relevanz auch den Nutzer:innen zu vermitteln. Die Redaktion hat also etwas gesendet, aber kaum jemand hat das Gesendete empfangen. Da reicht es nicht aus, zu entgegnen, man habe dieses Thema aus „publizistischen Gründen“ gebracht. Denn was ist das für eine Publizistik, im Wortsinn, wenn sie niemanden erreicht? Wir müssen uns also damit auseinandersetzen, warum dieser Inhalt nicht „funktioniert“ hat. Die Analyse der Zahlen hilft dabei.

3. Ich hätte gern Kennzahl X zurück, mit der konnte ich besser arbeiten — wieso nutzen wir die nicht mehr? Kennzahlen sind kein Selbstzweck, sie orientieren sich an den strategischen Unternehmenszielen, nicht an einzelnen Nutzer:innen. Man mag also jahrelange Erfahrung mit „Klicks“ gesammelt haben, kennt die historische Entwicklung, man weiß aus dem Stand, ob die Zahl im Vergleich eher gut oder nicht so toll ist — und dann kommt plötzlich jemand her und ersetzt diese bekannte, gelernte Kennzahl. Plötzlich Fahrenheit statt Grad Celsius, man muss umdenken, umrechnen, neu lernen. Führt man neue Kennzahlen ein, ist Transparenz sehr wichtig. Was kann die neue Kennzahl, was die alte nicht konnte? Welchen Einfluss hat die neue Größe auf ein gemeinsames Ziel? Welche Schwächen hat sie vielleicht? Ist sie womöglich nur ein Zwischenschritt, bis etwas Besseres erdacht ist? Ein gemeinsames Herantasten an das „Was ist eigentlich ‚gut‘ in dieser neuen Metrik? Was erwarten wir?“ hilft allen Beteiligten.

Technisch

Wir haben uns, wie bereits erwähnt, gegen eine Out-of-the-box-Lösung wie Parsely oder Chartbeat entschieden, um unsere individuellen Bedürfnisse besser abzudecken. Dabei haben wir jedoch zwei Dinge vorausgesetzt:

Adobe liefert bereits aggregierte Echtzeit-Daten, das spart Verarbeitungsschritte.
Bei Microsoft PowerBI bekommen wir eine fertige Visualisierungsebene.

Es stellte sich dann heraus, dass wir auf vermeintlich einfache Lösungen gesetzt hatten, denn es war alles andere als einfach, die Daten von A nach B zu bekommen.

So muss die gewählte Schnittstelle bei Adobe zum richtigen Zeitpunkt abgefragt werden, da uns diese die Daten nicht in Form eines Echtzeit-Streams liefert. Abhängig von der Performance der Echtzeitdatenverarbeitung des erhebenden Tools sind die Daten aber nicht immer zum selben Zeitpunkt verfügbar. Somit erfolgt die Abfrage nach dem Motto „so früh wie möglich, so spät wie nötig“, um in mindestens 99 Prozent der minütlichen Requests auch Daten zu erhalten. Das führte dazu, dass wir die Daten — eigentlich „Echtzeit“ — im Dashboard selbst nur verzögert darstellen konnten. Auf der anderen Seite sparen wir uns die Verarbeitung von Millionen einzelner Requests in Rohdatenform, was technisch und mit Blick auf den Datenschutz weitere Herausforderungen bedeutet hätte.

In PowerBI haben wir ein fertiges Produkt, bei dem wir uns um Hosting und Frontend wenig Gedanken machen müssen. Zudem können wir auf Expertise aufbauen, die uns auch in weiteren Reportings zugutekommt. Nur benötigt PowerBI wiederum bestimmte Datenstrukturen, um seine Stärken auszuspielen. Diese Stärken liegen eher im Bereich “statischer” Reports, die ad hoc angefragt werden oder festen, längeren Berichtsintervallen folgen. Was wir wollten: einen sich selbst aktualisierenden Echtzeitbericht, für den laufend Information von zwei Datenquellen (Redaktionssystem und Datenerhebung) mit individuellem Fehleraufkommen und -handling in des benötigte Zielformat überführt werden müssen. Dafür mussten wir am Ende doch mehr alternative Wege finden als anfangs gedacht.

Wohin wir wollen

Neue technische Infrastruktur

Unsere internen Entwickler arbeiten daran, die technische Infrastruktur grundlegend neu aufzusetzen. Hauptziele sind eine Reduzierung der Kosten und ein performanteres Produkt. Die bisherige Infrastruktur ist unter Zeitdruck entstanden und musste möglich rasch in Zusammenspiel mit den neuen technischen Komponenten funktionieren. Die Neufassung, das Radar 2, ist zudem schlanker aufgebaut und somit einfacher zu warten. Wichtiger Aspekt für die Redaktion: Neue Features können schneller umgesetzt werden.

So sieht der Entwicklungsstand derzeit aus:

Die Artikel-Indizes

Die reine Reichweite, sei sie in Page Views, Visits oder auch in Visitors gemessen, kann eines nicht leisten: Aufschluss über den Erfolg eines Artikels bei der Nutzerschaft geben. Journalist:innen möchten möglichst viele Menschen mit ihren Inhalten erreichen — aber sie möchten auch, dass ihre Texte wirklich gelesen werden. Deswegen hat der SPIEGEL eine Kennzahl entwickelt, die Reichweite und Lesetiefe miteinander vereint. Der Erfolg eines Artikels, abgebildet durch einen Indexwert, gliedert sich in zwei Komponenten:

Quantitative Nutzung: Wie wurde ein Artikel in der Breite gelesen
Qualitative Nutzung: Wie wurde ein Artikel in der Tiefe gelesen?

Für beide Teile wird ein entsprechender Score von 0 bis 100 errechnet, der zu gleichen Teilen in den Gesamtindex (ebenfalls 0 bis 100) einfließt. Gemessen werden die einzelnen Artikel an der Gesamtheit aller Artikel. Das heißt, die Indizes setzen alle Artikel ins Verhältnis zueinander. Ein Wert von 80 bedeutet: Der entsprechende Artikel wurde in der Breite bzw. Tiefe mindestens genauso gut gelesen wie 80 Prozent aller Artikel. Wir haben im Mai 2020 begonnen, die Indizes für beinahe alle Texte zu berechnen. Formate wie Liveticker sind ausgenommen oder aktuell noch sehr lange Texte, da eine gewisse Sample-Größe erreicht sein muss, um statistisch valide Werte berechnen zu können. Analysieren können wir anhand der Index-Werte sowohl die Nutzung aller Artikel durch Abonnent:innen, als auch die Nutzung freier Texte durch Nicht-Abonnent:innen.

In einem ersten Analyseprozess mit den Ressorts hat das Team bereits viele wertvolle Anhaltspunkte gefunden, wie sich bestimmte Themenbereiche in ihrer quantitativen und qualitativen Nutzung voneinander unterscheiden, welche Artikel von vielen Menschen besonders tief gelesen werden oder welche durch eine hohe Reichweite und eine eher geringe Lesetiefe auffallen. Der Blick auf die Texte, die von wenigen Menschen und von diesen auch eher oberflächlich gelesen werden, ist ebenso hilfreich wie auf jene Artikel, die ein kleineres, aber sehr engagiertes Publikum schätzt.

Diese Grafik zeigt beispielhaft die Verteilung von Artikeln anhand ihres Indexwertes in einer Quadrantenlogik.

Bisher mussten die Analysen dieser komplexen Datenmengen händisch vom Data-Team aufbereitet werden. In den kommenden Monaten werden die Indizes ins Radar implementiert sowie in einem weiteren Schritt in Adobe zur Analyse verfügbar gemacht. So sind sie künftig für alle im Haus zugänglich, die damit arbeiten möchten.