Embedded analytics for exhibitors inside the portal they already log into

The post-show report for exhibitors went out as a PDF for eleven years. Six hundred and forty of them, one per exhibiting company, generated from a template and emailed on the Thursday after the show closed. The open rate was respectable. The number of exhibitors who could tell you anything that was in it, four months later at the rebooking conversation, was close to zero.

The team's first attempt at fixing this was a reporting portal with its own login. Two hundred and thirty accounts were created and forty seven people ever signed in twice. Embedded analytics for exhibitors is the version that works, and the reason it works has nothing to do with the report being better. It is in the portal they already use.

The second login nobody uses

An exhibitor's contact with your systems is concentrated and short. They log in to book the stand, order the badge allocation, upload the insurance certificate and download the exhibitor manual. That portal is already bookmarked, already has their password saved, and already has a reason to be opened in the fortnight before the show.

A separate analytics login competes with that for attention and loses. It arrives in a different email, has a different password, and offers something the exhibitor was not looking for at the moment it appeared.

Putting the report inside the existing portal changes the question from "will they adopt a reporting tool" to "will they click a tab". Same content, and a completely different adoption curve, because the surrounding session has already done the work of getting them there.

Two embedding models and which one exhibitors need

The tooling offers two shapes, and picking the wrong one produces a project that works in testing and collapses at rollout.

Microsoft's embedded analytics documentation (Microsoft Learn, 2026) describes the first as embed for your organization, also known as user owns data: "The embed for your organization solution allows you to build an app that requires signing in using Power BI credentials." Each app user needs a licence, and users authenticate against the corporate directory. That is the right model for internal staff and the wrong model for exhibitors.

The second is embed for your customers, also known as app owns data: a solution that "allows you to build an app that uses non-interactive authentication against Power BI. Your customers are likely to be external users, and they don't need to sign in using Power BI credentials to view the embedded content." The comparison table in the same documentation is explicit that app users need no licence and that your application authenticates using a service principal or a master user.

For 640 exhibitors the second model is the only one that survives contact with procurement, and the cost shape moves from per-user licences to capacity. The documentation notes that production embedding requires a purchased capacity, and that free trial tokens are limited to development testing, with a trial banner displayed above the report until a capacity is in place. Plan that purchase before the pilot, since the banner appearing in front of an exhibitor is a bad first impression that is entirely avoidable.

One functional difference is worth checking against your report before you commit. Under the customer-facing model, R and Python visuals are not supported. If your exhibitor page includes a custom-rendered chart built that way, it needs rebuilding with a native visual.

What identity does the report see?

Here is the trap that catches teams who have already built internal row filtering and expect it to carry over.

When the embedding application authenticates with a service principal, the identity functions inside the model no longer return an end user. The Power BI documentation (Microsoft Learn, 2026) states that in that situation the functions "return the service principal's application ID or an empty string, not an end user's identity", and draws the conclusion directly: filters written against those functions "won't filter data per user in embedded scenarios".

So a portfolio model whose row filtering works perfectly for internal staff, using the pattern described in row level security for event portfolios, will hand every exhibitor either everything or nothing the moment it is embedded behind a service principal. Nothing errors. The filter expression is unchanged and correct.

The mechanism that replaces it is an effective identity passed when the embed token is generated, carrying the user name and roles the report should resolve to. That is where the security of the whole arrangement actually lives, and it deserves its own treatment, so how the token is minted and why the identity in it must never come from the browser belongs to embedded report authentication tokens.

One report definition for 640 exhibitors

The arithmetic is what makes the case internally, and it is worth doing in front of whoever owns the exhibitor experience.

Producing a per-exhibitor PDF at four minutes each, including the check that it went to the right company, is 2,560 minutes for one show of 640 exhibitors. That is 42.7 hours, better part of a working week, repeated every edition. Across a portfolio of nine shows with roughly 3,900 exhibiting companies in total, the same process costs 260 hours a year.

The embedded version has one report definition. The report resolves against whichever exhibitor identity the portal session supplies, so the marginal cost of the 641st exhibitor is a row in a mapping table. The work moves from producing 640 artefacts to maintaining one, and the exhibitor gets something they can filter and re-open in March rather than a snapshot they saved somewhere in October.

The saving is not the strongest part of the argument. The strongest part is that the report stays live. An exhibitor deciding whether to rebook in February can open the page and see their own scan counts, lead volume and stand traffic from a show four months ago, which is the moment where the number changes a decision.

What belongs on the exhibitor page

A report an exhibitor opens once and never returns to has failed regardless of how it was delivered, so the content decision matters as much as the plumbing.

Anchor it on things the exhibitor can act on. Scan counts by day and by hour, so they can staff the stand differently next time. Lead volume against their own prior editions, which is the comparison they trust because they were there for both. Badge type or job function breakdown of who stopped, which tells them whether the audience matched the pitch. Stand traffic expressed against their own history rather than against a hall average.

Two things are worth leaving off deliberately. Anything that reveals another exhibitor, including a rank position in a small category, since a rank in a group of four is an identification. And any comparison against a peer group without first settling how large that group has to be before a percentile can be published, which is a question with a real answer and its own considerations.

The other content decision is a definitions panel on the page itself. An exhibitor asking why the scan count differs from the leads their team recorded is asking a definition question, and a short panel saying what a scan is, when the window opens and closes, and what gets excluded will remove most of those questions before they become emails.

Does the classification survive the embed?

Partly, and the gap has a shape worth planning around.

Microsoft's sensitivity label documentation (Microsoft Learn, 2026) covers embedded views and lists the supported scenarios: embedding for your organisation, Microsoft 365 applications such as Teams and SharePoint, and secure URL embedding from the service. In those, the label is visible in the embedded view and persists when data is exported to Excel.

The customer-facing model does not appear in that list, and the same documentation states that information protection in this tool "doesn't support B2B and multi-tenant scenarios". For an exhibitor portal, that means the file-level classification described in sensitivity labels on event reports is not the control you are relying on. The controls that matter for an external audience are the ones applied before the data leaves the backend, which is the subject of multi-tenant analytics isolation.

Where this stops

Embedding solves delivery. It creates two problems that the delivery mechanism cannot solve for you.

The first is support. Six hundred and forty exhibitors with a live report will ask questions, and the questions will be about the numbers rather than the interface. Why is my scan count lower than the badges I collected. Why does the lead total differ from what my sales team recorded. Somebody has to own those answers, and an embedded report without a named owner and a definitions page generates a support load that arrives entirely in the two weeks after the show, which is the two weeks your team has least capacity.

The second is that the report is now a commercial document. An exhibitor who can see their own performance can compare it with what a salesperson told them in the renewal conversation, and any gap between the two becomes a negotiation. That is a good outcome for a business that measures honestly and an uncomfortable one for a business that has been generous with its verbal estimates. Deciding to embed is partly a decision to stop rounding upwards in conversation.

Start by counting rather than building. Take the last edition of one show, count the exhibitors, and multiply by the minutes your team currently spends producing and checking a per-exhibitor report. Then open the portal those exhibitors already log into and find out whether it has a page you could put a report in. Those two facts settle whether this belongs on the reporting roadmap this year, and they take an afternoon between them.