Qlik-KPIs und PII: Welche Daten die Kennzahl wirklich braucht

Versions- und Quellenstand: Qlik Cloud (SaaS), 23.10.2026. Kein festes Qlik-Sense-Client-Managed-Release. Cloudoberfläche und Funktionsumfang können sich auch bei kleineren Updates ändern; regionale Rollouts, Subscription und Tenantkonfiguration vor Umsetzung prüfen. Installierte Gateway-/Connectorversionen separat protokollieren. Redaktionell gegen Herstellerhilfe geprüft, nicht im Kundentenant ausgeführt.

Durchgängiges Beispiel: Monatsumsatz und Wachstum nachvollziehbar auswerten

Die Vertriebsleitung möchte zwei KPIs vergleichen: Monatsumsatz in EUR und Umsatzwachstum gegenüber dem Vormonat. Bei einer Abweichung sollen berechtigte Analysten die zugrunde liegenden Beträge prüfen können. Der fachliche Gegenstand bleibt dieselbe Kennzahl; eine Kundenkontakt- oder Serviceanwendung wird dafür nicht benötigt.

Wir verwenden unverändert die vier synthetischen Monatswerte aus der Grundlagenserie. Revenue steht im Labor für den bereits abgestimmten Umsatzbetrag in EUR, eine Zeile für Monat und Region. Die Zahlen sind ein Rechenbeispiel, keine echten Kundendaten.

Zuerst die Kennzahl erklären

Der Monatsumsatz ist die Summe von Revenue für den ausgewählten Monat und den vereinbarten Regionsumfang. Im Labor wird er mit Sum(Revenue) bei passender Auswahl dargestellt. Für das Wachstum werden zwei vergleichbare Monate gegenübergestellt:

Wachstum = (Umsatz aktueller Monat - Umsatz Vormonat) / Umsatz Vormonat
September = 1200 + 800 = 2000 EUR
Oktober   = 1500 + 1100 = 2600 EUR
Wachstum  = (2600 - 2000) / 2000 = 30 %

Die Summe 4600 EUR ist die Kontrollsumme beider Monate zusammen. Sie ist nicht der Oktoberumsatz. Bei einem Vormonatswert von null oder einem fehlenden Vergleichsmonat wird keine normale Wachstumsquote behauptet; die Anzeige muss diesen Fall erklären.

Für einen realen KPI werden zusätzlich Buchungsbezug, Stornos, Währung, Periodenabschluss und Datenstand fachlich festgelegt. Eine Qlik-Formel beantwortet diese Fragen nicht von selbst. Die Metrik-Governance für Master Items vertieft die gemeinsame Definition und Wiederverwendung.

Welche Felder braucht genau dieser KPI?

Eine andere Kennzahl kann andere Daten benötigen. Für eine Wiederkaufsquote kann beispielsweise eine verknüpfbare Kundenreferenz erforderlich sein. Die vier Monatszeilen enthalten diese Information nicht; daraus lässt sich keine belastbare Kundenkennzahl ableiten. Der Datenbedarf folgt daher der konkreten Definition.

KPI-App und Detailanalyse aus derselben Bedeutung ableiten

Die breite KPI-App lädt für diesen Vergleich nur den vereinbarten Monats-/Regionsbestand und den Datenstand. Wenn die Ursache einer Abweichung auf Belegebene geprüft werden muss, erhält die zuständige Analysegruppe einen begrenzten Detailzugriff mit Belegreferenz, Betrag und den tatsächlich benötigten Merkmalen.

Die Detailanalyse darf nicht allein deshalb eine vollständige Kundenliste enthalten. Für dieselbe Periode, Region, Währung und Definition muss ihre Summe zum KPI passen. Falls die vorliegenden Monatsaggregate keine Belegzeilen enthalten, wird dafür eine zusätzliche passende Quelle benötigt; sie lässt sich nicht durch Drilldown aus vier Aggregatzeilen erzeugen.

Eine eigene Detail-App ist sinnvoll, wenn Empfängerkreis, Granularität, Schutzbedarf oder Aufbewahrung abweichen. Entscheidend sind passende Daten- und Rechtewege. Eine zusätzliche App-Kopie allein stellt noch keine Trennung her.

Eine Regionsberechtigung verändert den sichtbaren KPI

Ein NORTH-Consumer kann im selben Beispiel für Oktober 1500 EUR sehen. Ein für beide Regionen berechtigter Consumer sieht 2600 EUR. Für NORTH beträgt das Wachstum von 1200 auf 1500 25 %, für beide Regionen zusammen 30 %. Beide Ergebnisse können korrekt sein, wenn der jeweilige Umfang deutlich ausgewiesen ist.

Section Access reduziert den verfügbaren Datenbestand. Eine gewöhnliche Kennzahl rechnet auf dieser zugänglichen Basis. Ein im Ausdruck verwendetes TOTAL macht ausgeschlossene Regionen nicht wieder zugänglich. Vergleichbarkeit verlangt daher denselben fachlichen und berechtigten Umfang; die Beschriftung „Umsatz“ allein reicht nicht.

Soll eine freigegebene Gesamtsumme für eine größere Zielgruppe sichtbar sein, wird dafür eine passende Aggregatbereitstellung geprüft. Eine regionale Berechtigung darf nicht einfach umgangen werden, um eine optisch gleiche Zahl zu erzwingen.

PII-Schutz an der Kennzahl ausrichten

Für die beiden beschriebenen KPIs müssen Kontaktfelder die breite App gar nicht erreichen. Ein im Datenmodell vorhandenes E-Mail-Feld bleibt geladen, auch wenn es kein Arbeitsblatt anzeigt. Maskierung in einem Diagramm und Begrenzung des geladenen Datenbestands sind unterschiedliche Maßnahmen.

Personenbezug umfasst auch rückführbare Kennungen und Kombinationen. Pseudonymisierung ist keine automatische Anonymisierung. Zweck, Rechtsgrundlage, Erforderlichkeit, Empfänger und Aufbewahrung werden vor dem Laden geklärt. Besondere Kategorien und Beschäftigtendaten brauchen die jeweils erforderliche Spezialprüfung; die interne Owner-Freigabe ersetzt diese nicht.

Für eine Kennzahl mit begründetem Personenbezug wird konkret festgelegt, welche Felder und Population verarbeitet werden dürfen, wer die Freigabe verantwortet und wie lange die Daten benötigt werden. Das vorhandene BI-Sicherheitswerkzeug kann diese Entscheidung optional festhalten. Ein zusätzliches Pflichtformular gehört nicht zur KPI-Berechnung.

Schritt für Schritt: Berechnung, Berechtigung und Veröffentlichung prüfen

1. Definition: Monat, Währung, Regionsumfang und Aktualität bestätigen. Eine Master-Kennzahl kann den Ausdruck wiederverwenden; die Qlik-Hilfe erklärt diese Funktion. Die fachliche Bedeutung wird separat abgestimmt.
2. Werte: September 2000, Oktober 2600 und Wachstum 30 % für beide Regionen prüfen. Für NORTH Oktober 1500 und Wachstum 25 % als eigenen Umfang prüfen.
3. Datenmodell: Kontrollieren, dass die breite App keine für diesen KPI unnötigen Kontaktfelder enthält. Für Detaildaten ihre Summe gegen denselben KPI-Umfang abstimmen.
4. Zugriff: Mit normalen erlaubten und ausgeschlossenen Testidentitäten prüfen. Ein manuell gesetzter Regionsfilter im Admin-Konto simuliert keine echte Berechtigungsreduktion.
5. Veröffentlichung: Nach dem dokumentierten NORTH-Änderungsrelease auf 1600 gelten Oktober 2700 und Wachstum 35 % für beide Regionen. Erst die bestätigte neue Fassung darf diese Werte anzeigen; vorher bleibt der freigegebene alte Stand maßgeblich.
6. Weitere Datenwege: Tatsächlich verwendete Exporte, Reporting-, API- und AI-Pfade gesondert prüfen. Datenumfang und berechtigter Kontext müssen dort weiterhin zur vorgesehenen Verwendung passen.

Damit erklärt die App eine benannte Kennzahl für einen erkennbaren Umfang. Eine Detailfreigabe erlaubt noch keine beliebige andere Verwendung der dort sichtbaren Daten.

Die technischen Schutzschritte vertiefen

Weiter mit Section Access, geladenen Feldern und QVD-Ausgaben sowie Veröffentlichungs- und Zugriffstests. Deren kleines 120/250-Labor prüft technische Zugriffswirkung; diese Beträge sind nicht die Monats-KPIs des vierzeiligen Beispiels.

Quellen, Hilfe und Lernmaterial

• DSGVO / GDPR
• EDPB: Controller and processor
• Qlik: Section Access
• Qlik: Data connections in spaces
• Qlik: What is new / staged rollouts

Bei Videos hat die aktuelle schriftliche Hilfe Vorrang. Externe Medien werden vom jeweiligen Anbieter bereitgestellt.