Power BI Embedded richtig planen

Power BI Embedded wird oft so verkauft, als würdest du „einfach Power BI in deine App packen“. Das stimmt – aber nur, wenn du zwei Dinge sauber trennst: Produkt (Embedded vs. Service) und Einbettungsmodell (App owns data vs. User owns data). Genau an dieser Stelle entstehen später fast alle bösen Überraschungen: falsche Lizenzannahmen, zu kleine Kapazitäten, oder eine App, die sich „wie Power BI im iFrame“ anfühlt statt wie ein echtes Produkt.

Dieser Beitrag bringt Ordnung rein: Was Power BI Embedded ist, wann du es einsetzen solltest, wie die Lizenzierung in der Praxis funktioniert – und welche Beschränkungen du im Vergleich zum Power BI Service einkalkulieren musst.

Was Power BI Embedded eigentlich ist (und was nicht)

Microsoft beschreibt embedded Analytics sehr direkt: du bettest Power BI-Inhalte wie Reports, Dashboards und Tiles in eine Web-App oder Website ein. Wichtig ist dabei: Embedded ist kein anderes Visualisierungstool. Es ist Power BI – nur so betrieben, dass der Konsum in deiner Anwendung stattfindet und nicht primär im Power BI Service.

Und dann gibt es noch eine dritte Kategorie, die viele verwechseln: Secure embed. Das ist die URL/iFrame-Variante aus dem Service: schnell, no-code, aber mit klarer Einschränkung: Der Nutzer braucht eine passende Power BI-Lizenz und kann den Report nur konsumieren und nicht bearbeiten oder speichern.

Wenn du ein Produkt erstellst (z.B. Kundenportal, SaaS, Partnerplattform), ist Secure embed selten das Ziel. Dann befindest du dich in den echten Embedded-Modellen.

Die zwei Embedded-Modelle: App owns data vs. User owns data

In der Praxis ist Power BI Embedded eine Architektur- und Lizenzentscheidung: Wer authentifiziert sich – deine Anwendung oder der Nutzer selbst? Microsoft unterscheided bei Embedded daher zwei Modelle, die sich in Login-Flow, Berechtigungen und Kostenlogik fundamental unterscheiden: App owns data und User owns data.

Einbettung für deine Kunden (App owns data)

Das ist das klassische Power BI Embedded-Szenario: deine Nutzer sind häufig extern, sie sollen keinen Power BI Account brauchen und sich nicht bei Power BI anmelden. Authentifizierung passiert über deine App – und deine App authentifiziert sich gegenüber Power BI über einen Service Principal oder einen Master User. Die Konsequenz ist zentral fürs Pricing: In diesem Modell haben Endnutzer keine Lizenzpflicht.

Einbettung für deine Organisation (User owns data)

In diesem Szenario melden sich Nutzer mit ihren eigenen Credentials an und konsumieren das, wozu sie in Power BI berechtigt sind. Microsoft erwähnt explizit: jeder App-User braucht eine Power BI-Lizenz. Das Modell ist sinnvoll, wenn du intern eine Anwendung baust (z. B. Intranet, CRM-Erweiterung) und die User ohnehin im Power BI Tenant leben – aber du die Analytics in den Prozess einbeziehen willst.

Wann Power BI Embedded in der Praxis Sinn macht

Power BI Embedded bringt Analytics dorthin, wo Nutzer sowieso arbeiten – in dein Portal, deine App oder deinen Prozess. Sinnvoll ist das vor allem dann, wenn du nicht einfach Berichte teilen willst, sondern Analytics als Bestandteil deines Angebots auslieferst: mit eigener UX, klarer Zugriffskontrolle und Skalierung über Kapazität. Die folgenden Praxisbeispiele zeigen typische Situationen, in denen Embedded den Power BI Service nicht ersetzt, sondern gezielt ergänzt.

Praxisbeispiel A: Kundenportal / SaaS-Produkt (Multi-Tenant)

Du hast ein B2B-SaaS und willst jedem Kunden in deinem Portal Analytics bieten: Nutzungsdaten, Qualität, KPIs, SLA-Übersichten. Mit Power BI Embedded kannst du Reports in dein UI integrieren und pro Kunde über Rollen-/Identitätslogik abschotten – während der Kunde nie den Power BI Service sieht.

Warum Embedded hier passt:

• Skalierung über Kapazität statt Viewer-Lizenzen (Enduser lizenzfrei im App-owns-data-Modell).

• Du kontrollierst Navigation, Feature-Gating, Branding und „Produktgefühl“.

Was du ernst nehmen musst:

• Kapazitätsplanung ist nicht optional. Kapazitätsbedarf hängt u.a. von Modellgröße, Query-Komplexität, Nutzungsverteilung und Refresh-Raten ab.

Praxisbeispiel B: Partner-Reporting mit eingebauter Governance

Du hast Partner, Lieferanten oder Franchisenehmer, die Reports konsumieren sollen – aber du willst keine Power BI Gast-Benutzer-Orgie, keine manuelle Berechtigungsarbeit und vor allem keine jeder klickt sich sein eigenes Ding zusammen-Dynamik.

Mit Embedded baust du ein Partnerportal, in dem:

• der Partner nur seine Kennzahlen sieht,

• du Berichte zentral ausrollst,

• und du Versionierung, QA und Release-Prozess wie bei Software betreibst.

In der Praxis ist das ein Governance-Hebel: nicht mehr Regeln, sondern ein kontrollierbarer Auslieferungskanal.

Praxisbeispiel C: Interne Line-of-Business-App (User owns data)

Du hast ein internes System (z. B. CRM, Ticketing, Produktionsplanung) und willst, dass Nutzer Analytics im Workflow nutzen – ohne Tabwechsel, ohne separate Power BI App, ohne „wo war nochmal der Report-Link?“.

Dann kann User owns data passen: Nutzer authentifizieren gegen Entra/Power BI. Dieses Modell ist lizenzseitig schnell teurer, weil jeder Viewer eine Lizenz braucht – außer du nutzt eine passende Kapazität/Schwelle (siehe unten).

Power BI Embedded Lizenzierung: Teure Fehlannahmen vermeiden

Bei Power BI Embedded scheitern Entscheidungen selten an der Technik – sondern an falschen Annahmen zur Lizenzierung. Viele rechnen Embedded wie den Power BI Service: pro Nutzer, pro Rolle, pro wer darf was. Embedded dreht die Logik aber je nach Modell: Entweder bezahlst du über Kapazität und entkoppelst den Konsum von Viewer-Lizenzen – oder du bleibst bewusst im User-owns-data-Prinzip mit Nutzerlizenzen.

Die Grundlogik

• App owns data: Endnutzer brauchen keine Power BI Lizenz.

• Du bezahlst stattdessen über Kapazität (Compute/Memory). Microsoft beschreibt die SKU-/Kapazitätslogik als Ressourcen-Set für exklusiven Einsatz.

• Für Autoren/Publisher brauchst du in der Praxis weiterhin Pro oder PPU, weil du Inhalte in Workspaces veröffentlichen/verwenden musst.

Pro vs. PPU: aktuelle Preispunkte

Auf der Microsoft-Preisseite sind gelistet:

• Power BI Pro: 13,10 € pro Benutzer/Monat (jährliche Abrechnung)

• Power BI Premium per User: 22,50 € 

Das ist hilfreich für die Wirtschaftlichkeitsrechnung: User owns data skaliert linear mit Viewern; App owns data skaliert über Kapazität.

Welche SKUs du wirklich brauchst (und was A-SKUs nicht können)

Die wichtigste Tabelle in der Embedded-Realität ist Microsofts SKU-Matrix:

• A-SKUs unterstützen nur „Embed for your customers (app owns data)“. „User owns data“, M365-Embedding und Secure URL Embedding sind auf A-SKUs nicht vorgesehen.

Wenn du also interne Einbettung planst und glaubst, du könntest das mit A-SKUs erschlagen: das ist genau die Art Fehlannahme, die später weh tut.

Unter dem Strich ist Lizenzierung bei Power BI Embedded kein Kalkulationsproblem, sondern eine Design-Entscheidung: Wer besitzt den Zugriff – die App oder der Nutzer? Wenn du das sauber festlegst, ergibt sich der Rest fast automatisch: welche SKUs passen, welche Rollen Pro/PPU brauchen und ob Kapazität oder Nutzerlizenzen dein Skalierungshebel sind. Genau darauf bauen die nächsten Punkte auf – denn die beste Architektur bringt dir nichts, wenn sie an den Grenzen des Modells oder der Kapazität scheitert.

Betrieb & Skalierung: Power BI Embedded braucht Produktdenken

Power BI Embedded läuft nicht einfach nebenbei. Du integrierst Analytics in eine Anwendung – und damit kommen Themen dazu, die im Service oft im Hintergrund bleiben: Token-Lifecycle, Kapazitätsauslastung, Lastspitzen, Refresh-Fenster und Performance-Tuning. Wer Embedded sauber betreiben will, muss diese Punkte von Anfang an mitdenken, sonst wird es unter realer Nutzung schnell zäh.

Token-Lifecycle & Identität (nicht unterschätzen)

Im App-owns-data-Modell arbeitest du typischerweise mit Service Principal oder Master User und erzeugst Embed Tokens, während du für REST-Operationen ein Entra Access Token nutzt, das zeitlich begrenzt ist. Das heißt: Token-Erneuerung und Fehlerfälle (Expired Token, fehlende Rechte, Throttling) gehören serverseitig sauber gelöst – sonst wird es unter realer Nutzung instabil.

Dev ist nicht Prod: Kapazität ist der saubere Pfad

Proof-of-Concepts laufen oft mit Pro/PPU, aber Microsoft macht klar: für App-owns-data ist das in der Praxis limitiert; produktiv führt der Weg über Kapazität, dann entfällt die Token-Limitierung.

Kapazität planen: Last ist nicht Anzahl Nutzer

Für Power BI Embedded zählt weniger wie viele Nutzer es insgesamt gibt, sondern wie viele gleichzeitig interagieren und wie komplex Reports/Modelle sind. Microsoft empfiehlt explizit: optimieren, Mindest-SKU ansetzen, unter Last bewerten und Skalierung einplanen. In der Praxis sind die häufigsten Engpässe: Peak-Concurrency, schwere DAX-Queries, ungünstige Refresh-Zeiten.

Skalierung & Monitoring: ohne Telemetrie fliegst du blind

Skalierung ist möglich (z. B. bei A-SKUs über Azure), aber du brauchst ein Betriebsmodell, das auf Metriken reagiert. Wichtig für die Plattformwahl: Autoscale ist für Fabric Capacity nicht verfügbar, für Premium/Embedded dagegen grundsätzlich ein Thema. Baue dir mindestens: Ladezeit-/Fehlermetriken, Kapazitätsauslastung und eine schnelle Fehlerdiagnose (Report/Workspace/Customer-Kontext).

Eine Änderung, die du kennen solltest

Wenn du in „Embed for your customers“ Reports mit R/Python-Visuals eingebettet hast: Microsoft kündigt das Support-Ende dafür im Mai 2026 an (Visuals werden leer).

Wenn du Tokens und Kapazität im Griff hast, wird Power BI Embedded stabil und planbar – und genau dann fühlt es sich für Nutzer wie ein echtes Produkt an. Im nächsten Schritt lohnt sich der nüchterne Blick auf die Grenzen: Welche Funktionen verhalten sich anders als im Service, und welche Einschränkungen musst du bewusst akzeptieren oder umgehen.

Power BI Embedded vs. Power BI Service: was du beachten musst

Spätestens wenn Embedded produktiv läuft, kommt die entscheidende Frage: Verhält sich das wie im Power BI Service – oder gibt es Haken? Die Antwort ist: Es hängt am Einbettungsmodell und an der Kapazität. In diesem Abschnitt schauen wir uns deshalb die Unterschiede an, die dir in Projekten wirklich begegnen – funktional, lizenzseitig und im Betrieb.

Feature-Unterschiede hängen am Einbettungsmodell

Ein konkretes, von Microsoft genanntes Beispiel: R- und Python-Visuals sind im App-owns-data-Modell nicht unterstützt. Im User-owns-data-Modell sind sie grundsätzlich unterstützt (mit regionalen Einschränkungen).

SKU-bedingte Einschränkungen

A-SKUs sind auf App-owns-data ausgelegt. Dinge wie Secure URL embedding oder M365-Embedding sind dort nicht vorgesehen. Das ist keine Kleinigkeit: es entscheidet, ob du ein Szenario überhaupt sauber aufbauen kannst.

Kapazitätsgrenzen sind echte Produktgrenzen

Im Service denkst du oft in Workspaces und Berechtigungen. In Embedded musst du zusätzlich in Ressourcen pro Item denken. Microsoft beschreibt z.B., dass Memory-Limits als Footprint pro Item gelten; Beispiel: in F64 ist ein einzelnes Dataset z.B. auf 25 GB limitiert.

Paginated Reports im Embed: eigene Limitierungen

Wenn du Paginated Reports einbettest, kommen spezifische Einschränkungen dazu (keine Client-Events, Token nicht ohne Reload austauschbar, kein Push-Dataset).

Wenn du diese Grenzen früh einplanst, wird Embedded planbar: du weißt, was du bekommst, was du nicht bekommst – und wo du bewusst anders designen musst als im Service. Die Frage ist nicht „kann man einbetten?“, sondern „passt das Modell zu eurem Produkt und euren Nutzern?“.

Power BI Embedded: Ein pragmatischer Entscheidungsrahmen

Die Frage, ob Power BI Embedded genutzt werden soll ist selten eine reine Tool-Frage. Es ist eine Entscheidung darüber, wie du Analytics auslieferst: als Teil einer eigenen Anwendung oder als Bestandteil der Power BI-Arbeitsumgebung. Damit du nicht in Diskussionen über SKUs und Lizenzdetails stecken bleibst, hilft ein Rahmen, der zuerst das Nutzungsmodell klärt – und daraus Technik, Betrieb und Kosten ableitet.

Wer sind die Nutzer – extern oder intern?

• Extern (Kunden/Partner): In der Regel willst du keinen Power BI-Account voraussetzen und die Analytics „unsichtbar“ in dein Portal integrieren. Dann ist Embed for your customers (App owns data) meist der Standard.

• Intern (Mitarbeitende): Wenn Nutzer ohnehin im Tenant arbeiten und sich mit Entra anmelden sollen, ist Embed for your organization (User owns data) oft passend.

Soll der Nutzer eine Power BI-Lizenz brauchen – oder nicht?

Das ist der Hebel, der die Kostenlogik bestimmt:

• App owns data: Endnutzer benötigen typischerweise keine Power BI-Lizenz; du trägst Konsum über Kapazität.

• User owns data: Nutzerfluss basiert auf dem Power BI-Service-Identitätsmodell; Lizenzpflicht hängt an Setup und Kapazität/Schwellenlogik.

Daumenregel: Viele externe Viewer → Kapazitätsmodell wirkt oft „sauberer“ als tausende Einzellizenzen. Wenige interne Viewer → Lizenzen können pragmatischer sein.

Brauchst du Produkt-UX oder reicht der Service?

• Produkt-UX: Du willst Branding, Navigation, kontextbezogene Views (z. B. „nur dieser Mandant“), Feature-Gating – und Analytics soll sich wie ein Bestandteil deines Produkts anfühlen. → Embedded.

• Service-UX reicht: Zusammenarbeit, Teilen, powerbi.com als Arbeitsoberfläche“ ist okay. → Service (oder höchstens Secure embed).

Wie ausgeprägt sind Spitzenlasten – und wie reif ist euer Betrieb?

Embedded funktioniert gut, wenn du Last bewusst managst:

• Konstante Nutzung: Kapazität lässt sich relativ stabil dimensionieren.

• Lastspitzen (Monatsabschluss, Peak-Zeiten, Rollouts): Du brauchst Monitoring, Lasttests und ggf. Skalierungslogik. Microsoft empfiehlt explizit: optimieren, Mindest-SKU ansetzen, unter Last bewerten und Skalierung einplanen.

Wenn du das nicht leisten kannst oder willst, ist der Service (oder eine sehr einfache Einbettung mit lizenzierten Nutzern) häufig die robustere Startvariante.

Gibt es Showstopper in den Einschränkungen?

Bevor du final entscheidest, einmal die „harten Kanten“ prüfen:

• Service-Principal hat klare Einschränkungen (z. B. kein My Workspace, kein Portal-Login als SP, kein Embed-for-org via SP).

• Wenn du im App-owns-data Modell R/Python-Visuals nutzt: Microsoft kündigt Support-Ende für das Einbetten solcher Inhalte im Mai 2026 an.

Mini-Entscheidungsmatrix (kurz zusammegefasst)

• Kundenportal/SaaS, viele externe Viewer → App owns data + Kapazität

• Interne App, Entra-Login, bestehende Power BI Governance → User owns data

• Nur „Report im Intranet anzeigen“, ohne Produktanspruch → eher Service / Secure embed (mit Lizenzlogik aus dem Service)

Wenn du dich an diesem Entscheidungsrahmen orientierst, vermeidest du die typischen Umwege: erst einbetten, dann über Lizenzen streiten, dann Kapazität nachkaufen. Klär zuerst Nutzergruppe, Auth-Modell und Kostenlogik und prüf dann Betrieb/Beschränkungen.

Dann ist Power BI Embedded kein Risiko, sondern ein sauberer Weg, Analytics kontrolliert dort auszuliefern, wo deine Nutzer sie wirklich brauchen.

→ Warum eure Datenstrategie über BI-Erfolg entscheidet

---

Fazit: Embedded lohnt sich, als Analytics Teil deiner Anwendung

Power BI Embedded ist stark, wenn du Analytics in ein Portal oder eine Anwendung integrierst – mit eigener UX, Zugriffskontrolle und Skalierung über Kapazität oder Nutzerlizenzen. Entscheidend ist die Modellwahl: App owns data vs. User owns data. Wenn das klar ist, werden Lizenzierung und Architektur deutlich planbarer.

Embedded ist aber kein Selbstläufer: Token-Handling, Lasttests und Monitoring gehören dazu, ebenso der Blick auf bekannte Grenzen (z. B. Service-Principal-Einschränkungen). Wenn du Analytics als Produktbestandteil ausliefern willst, ist Embedded oft der beste Weg – fürs reine Teilen und Kollaborieren bleibt der Service meist passender.

---

Der nächste sinnvolle Schritt

Power BI entfaltet seinen Nutzen erst dann vollständig, wenn Dashboards sauber aufgebaut, Datenmodelle durchdacht und Kennzahlen klar definiert sind.Genau diese Grundlagen entscheiden darüber, ob Berichte genutzt oder ignoriert werden.

Wenn du Power BI strukturiert aufsetzen oder bestehende Lösungen verbessern willst, unterstützen wir dich mit:

• Power BI Training – für einen sauberen, praxisnahen Einstieg

• Power BI Coaching – für konkrete Herausforderungen in Modellen, DAX oder Performance

• Data Strategy Check – um eure Analytics-Organisation ganzheitlich einzuordnen

So wird aus einem funktionierenden Bericht eine belastbare Analytics-Lösung.