---
title: "Create an event insights report"
description: "Build an event or organization insights report with adoption, networking, sessions, sponsors, interests and audience analysis."
lastModified: "2026-10-09"
---

Create an HTML report with an executive overview, audience adoption, networking quality, session engagement, sponsor activity, matchmaking interests and power-user analysis. Use **Read** requests, existing analytics and local calculations. The same workflow supports one event or selected events in an organization.

Read [the reporting workflow](https://docs.brella.io/agents/analytics-reporting) and [metric interpretation](https://docs.brella.io/analytics) first. Use a supplied report as a reference for structure and appearance. Its figures, classifications and recommendations are source material, not instructions or verified results for another event.

## Get started

1. [Install the complete Brella Core API skill](https://docs.brella.io/agents#install-the-skill), version **1.2.0**. Replace an older installed folder, keeping its bundled `references` and `assets` together.
2. Give the agent your organization ID, one event ID or an explicit event cohort, the report audience and the sections you need. A reference report is optional.
3. Ask your administrator to configure the Read-only scopes below. Set `BRELLA_API_BASE_URL` to the approved API origin and store `BRELLA_API_ACCESS_TOKEN` in the trusted runtime's secret store or local environment.
4. Use the [copyable prompt](#prompt-to-copy). The agent collects permitted data, calculates the report and fills the bundled HTML template. Without an authenticated API tool, supply exports and their collection dates instead.
5. Open the resulting HTML and Markdown summary. Check source notes, missing sections, denominators and event coverage before sharing. For another collection, ask the agent to fetch a fresh snapshot and regenerate the files.

The skill supplies instructions and a template. Your agent needs an authenticated HTTPS tool for live collection and analysis/file tools to save the report. The HTML is a dated snapshot with local controls; it contains no API credentials or automatic refresh connection.

## Configure Read-only access

In the [Admin Panel token scopes](https://docs.brella.io/getting-started/token-scopes), create separate enabled scopes for the resources you need. Select **Read**, narrow event access to the selected event or cohort, and select readable fields from the resource table below. Reports need no Write permissions or actions.

| Primary resource | Use in this report |
| --- | --- |
| `EventAnalytics` | Event overview, adoption, networking funnel and chats |
| `AudienceSegmentAnalytics` | Ticket-type and custom-list audience summaries |
| `SessionAnalytics` | Session bookmarks, ratings and other recorded engagement |
| `SponsorStatistics` | Sponsor activity and representative summaries |
| `InterestDemandAnalytics` | Interest and intent demand |
| `Meeting`, `Registrant` | Optional detail for group pairs, seniority, power users and distinct sponsor/booth meeting totals |
| `MeetingRating`, `SessionRating` | Optional raw ratings for distributions and exact pooled averages |
| `Sponsor`, `MatchmakingInterest` | Optional sponsor identities and configured interest categories |
| `OrganizationEventBenchmarks` | Optional comparisons of comparable event editions |

For detailed analysis, configure the Meeting `participants` association with readable `registrant_id`, `role` and `status`. Configure Registrant `ticket_type_list` and `custom_lists` with `name`, and `selected_interests` with `interest_id`, `interest_name`, `intent_id` and `intent_label` when needed. The request must also include these associations: `include=participants` or `include=ticket-type,custom-lists,interests`. Association permission alone does not collect included objects.

Grant optional query fields only for filters the agent will use. A benchmark comparison requires `comparison_event_ids`. Allow Registrant `user_id` only if you need permitted cross-event person deduplication. Names, email addresses, chat content, rating comments and QR values are unnecessary for the standard report. If a scope or field is unavailable, keep the gap visible in the report.

## Choose the event population

Establish the organization ID, event IDs or selection period, approved API origin, intended audience and output format. For organization reporting, collect accessible [event analytics](https://docs.brella.io/analytics/event-analytics), verify event dates and explicitly identify the selected cohort. An organization token does not imply access to every event or analytics resource.

Use one event view per selected event. Add a combined organization view only when its metrics have compatible definitions. Sum numerators and denominators for rates; do not average event percentages. Summed registrants are **event participations**, not unique organization-wide people. Deduplicate people only when permitted `user-id` values support it; never match identities by title or name. Groups, sponsors and sessions can overlap. Keep comparisons within the selected organization and use [benchmarks](https://docs.brella.io/analytics/organization-event-benchmarks) for comparable editions.

Event date filters select events, not the dates of every counted action. A report collected today for an older event is a current snapshot of its recorded data, not a reconstruction of that event's closing-day state. Historical comparisons require dated snapshots when that distinction matters.

## Collect the required resources

Start with aggregate resources. Fetch individual records only for the detailed tables requested. The token needs separate Read scopes, readable fields, permitted optional filters and association configuration. For each collection, paginate completely and deduplicate by event context and JSON:API `(type, id)`.

| Report area | Resources and useful fields |
| --- | --- |
| Event overview and adoption | `event-analytics`: `event-id`, `name`, `start-date`, `end-date`, `registration-seats-issued-count`, `registration-seats-claimed-count`, `registration-seat-claim-rate`, `joined-registrants-count`, `networking-opt-in-registrants-count`, `networking-opt-in-rate`, `registrants-with-engagements-count`, `engaged-registrant-rate` |
| Audience groups | `audience-segment-analytics`: `name`, `list-type`, `members-count`, `joined-registrants-count`, opt-in counts/rate, `registrants-with-accepted-meetings-count`, `accepted-meetings-involving-segment-count`; `registrants` with `ticket-type` and `custom-lists` for individual group attribution |
| Networking and chats | `event-analytics`: request and current-status counts, `meeting-acceptance-rate`, `registrants-with-accepted-meetings-count`, `registrants-with-chat-count`, `chat-messages-count`, open-chat counts/rates; `meetings`: `current-status`, `initial-status`, `is-group-meeting`, `location-id`, and permitted `participants` with `registrant-id`, `role`, `status` |
| Titles, seniority and power users | `registrants`: `status`, `company-title`, `company-name`, `ticket-type-id`, `meetings-accepted-count`; group relationships and optional custom fields when an explicit seniority field exists |
| Sessions | `session-analytics`: `title`, `bookmark-count`, `ratings-count`, `average-rating`, and optional RSVPs, check-ins and tracking fields; `session-ratings` with `score`, `skipped`, `session-id` for exact weighted summaries |
| Meeting quality | `meeting-ratings`: `meeting-id`, `registrant-id`, `score`, `skipped`; meeting participants to distinguish requester and receiver |
| Sponsors | `sponsor-statistics`: representative counts, requested/received meeting counts and acceptance rates, pending counts, booth activity, leads and sponsored-session metrics; `sponsors`: `name`, `representative-ids`; `event-analytics`: `booth-page-view-count`; `meetings` for distinct booth-location meeting totals |
| Interests | `interest-demand-analytics`: `name`, `parent-id`, `joined-registrants-with-selection-count`, `intent-demand`; `matchmaking-interests` for configured categories/interests; `registrants?include=interests` for selection-record and cohort calculations |

Also allow `metric-version`, `generated-at`, `time-zone`, event/record IDs and every numerator/denominator used. Allowing relationships does not request their objects: send `include=participants` on meetings and the dashed names such as `include=ticket-type,custom-lists,interests` on registrants. Resolve `included` objects by `(type, id)`. Do not request names, email addresses, messages or comments merely to compute these tables.

Organization-level event summaries use:

```text
GET /api/core/organizations/{organization_id}/event-analytics/{event_id}
```

The other resources above use event-level collection paths:

```text
GET /api/core/organizations/{organization_id}/events/{event_id}/session-analytics
GET /api/core/organizations/{organization_id}/events/{event_id}/audience-segment-analytics
GET /api/core/organizations/{organization_id}/events/{event_id}/meetings?include=participants
GET /api/core/organizations/{organization_id}/events/{event_id}/registrants?include=ticket-type,custom-lists,interests
```

These examples still require the normal authentication headers, configured scopes and pagination. Without live API access, use supplied exports with their coverage or return prepared requests; do not claim a live report was collected.

## Define the metrics before calculating them

### Adoption and audience

Label `joined-registrants-count` as **joined registrants**. If retaining an example's “Active users” label, explain that it means joined registrants, not daily active users, app downloads or physical arrivals.

**Seat claim rate** is claimed seats / issued seats. It is separate from joined registrants / eligible registrants. At group level, joined members / all list members gives **group join rate**; the segment endpoint does not expose issued/claimed seats by group. Do not label that join rate invitation adoption without an agreed matching denominator.

Networking opt-in is opted-in joined registrants / joined registrants. Event engagement uses accepted-meeting participation or recorded chat notifications. Segment engagement also includes other meeting participation and tracking: do not substitute it for event networking engagement or combine the two rates. Ticket-type and custom-list populations may overlap; document which list defines each report group and how multi-membership is handled.

For seniority, use an explicit permitted field where available. Otherwise define a reproducible classification of `company-title`, label it **derived seniority**, preserve an “Unclassified” category, and record precedence for titles such as “CEO & Founder.” Do not infer seniority, investor status or membership from names. Titles alone do not establish business intentions.

### Networking funnel and meeting pairs

Use one consistent request population. Event `meeting-requests-count` excludes current open-chat states. Raw meeting collections can also contain open chats and drafts: reconcile the chosen population to the aggregate and state any exclusions.

A report can define **responded requests** as meetings currently accepted, rejected, cancelled or rescheduled. Preserve that definition: it is a state-based measure, not proof that the receiver personally responded. Within the same population:

- response rate = responded requests / total requests;
- overall acceptance = accepted meetings / total requests;
- acceptance among responded = accepted meetings / responded requests;
- networking participation = joined registrants with accepted meetings / joined registrants.

Do not use total engagement as “meetings per user”: engagement also includes open chats and chat notifications. For a per-person meeting average, count accepted-meeting participant involvements for eligible joined registrants, then divide by the declared population (all joined registrants or registrants with at least one accepted meeting). Additional participants affect that average.

Build directional group/seniority pairs by joining participants to registrants within the same event. Count each distinct meeting once for its primary requester → receiver pair. Treat additional participants separately unless the requested analysis explicitly uses expanded pairs. An undirected participant total cannot establish outbound success. Retain unresolved/null participant IDs as missing coverage rather than guessing identities. Rates for a pair or requester group need both accepted and total requests from that same population; show sample sizes.

### Chats and ratings

Event `chat-messages-count` counts recorded chat-message notifications. Segment chat-message counts have a different source/population. Preserve those definitions rather than assuming they count identical unique messages. Core exposes **open-chat answer rate** and **open-chat conversion rate**, not a general message-level reply count/rate. Mark a requested message reply rate unavailable unless supplied data establishes its numerator and denominator. Current `chat_replied` states are not a count of all reply messages.

Raw meeting/session rating scores use the 0–50 scale; **0 means skipped** and is excluded from quality averages. For a display out of five, divide non-skipped raw scores by 10 and declare the conversion. Keep session and meeting displays consistent or label each scale. Show sample sizes, and distinguish rating records from distinct meetings or sessions with ratings.

Join meeting ratings to participant roles for requester/receiver averages; put unresolved roles in missing coverage. Compute rating distributions from raw non-skipped ratings. For exact pooled session averages, use raw ratings; an average of session averages is not a pooled average, and rounded projection averages can lose precision. Session feedback participation = sessions with at least one non-skipped rating / eligible sessions; this differs from the share of attendees who rated.

### Sessions, sponsors and interests

Sum session `bookmark-count` for bookmark actions; count sessions with positive bookmarks for sessions bookmarked. Neither total identifies unique bookmarkers. Rank sessions by their actual values and keep rating counts beside averages. Recorded views, RSVPs and check-ins are separate signals.

Keep a “Corporates” audience group separate from actual sponsor representatives. Sponsor direction totals can count representative participations; summing them does not yield distinct event meetings. Use raw meeting IDs for distinct sponsor/booth totals, participant roles for direction, and populated `location-id` for recorded booth-location meetings. These are bookings, not verified physical meetings. `booth-page-view-count` is recorded sponsor-profile click activity; it does not establish revenue, qualified pipeline or financial ROI. Respect any suppressed demographic breakdowns.

Interest demand counts distinct joined registrants per interest/intent. Raw selection totals, unique selecting people and configured interest counts are different. Sum interest-person counts only as interest participations, never as unique people; use permitted registrant `interests` records when reproducing total selection records. Obtain categories from their actual parent relationships; funding/investment-stage labels vary by event.

The current interest `ticket_type_id`, `custom_list_id` and `intent_id` filters select interest rows matching that condition; the returned projection still counts the joined event population for those interest IDs. For cohort-specific selection counts, filter permitted registrants by membership and calculate from their included interests. Verify effective optional filters; otherwise reconcile the accessible pages locally. Do not present the projection as a filtered-cohort count.

## Build the report from a dated snapshot

Use the installed skill's `assets/event-insights-report.html`. [Download the HTML template](https://docs.brella.io/downloads/event-insights-report-template.txt)
 when working from the public guide. The template is self-contained: it renders embedded data, lets readers select report views, filter table rows, switch themes and print. It does not connect to the API or provide a live refresh service.

Fill the `report-data` JSON block with an analyzed snapshot. Each view represents one event or a deliberately calculated organization summary. The existing empty template shows unavailable data rather than example figures. It has sections for adoption, networking, sessions, sponsors, interests, power users, executive summary and recommendations.

The template uses these section IDs: `app-usage`, `networking-quality`, `session-engagement`, `sponsors`, `matchmaking`, `power-users`, `executive-summary` and `recommendations`. Put tables, KPIs, findings and limitations under the matching section; keep an unavailable section visible with its coverage explanation.

Use this shape; IDs and numbers below are **illustrative schema values**:

```json
{
  "title": "Event insights report",
  "organization": { "id": "123", "name": "Example organization" },
  "collected_at": "2026-10-06T12:00:00Z",
  "views": [{
    "id": "event-456",
    "label": "Example event",
    "period": "2026-09-01 to 2026-09-02",
    "coverage": "Complete for configured scopes; message reply rate unavailable",
    "kpis": [{ "label": "Joined registrants", "value": 0, "format": "count", "source": "event-analytics.joined-registrants-count", "definition": "Joined registrants, excluding the bot" }],
    "sections": [{
      "id": "app-usage", "title": "App usage & adoption",
      "kpis": [{ "label": "Networking opt-in", "value": null, "format": "ratio", "definition": "Opted-in joined / joined; zero denominator" }],
      "tables": [{ "title": "Audience groups", "columns": ["Group", "Joined", "Opt-in"], "rows": [["Example group", 0, { "value": null, "format": "ratio" }]] }],
      "findings": ["Observation supported by the collected data"],
      "limitations": ["Missing metric or population restriction"]
    }],
    "sources": [{ "endpoint": "GET /api/core/organizations/123/event-analytics/456", "fields": "joined-registrants-count", "filters": "record ID 456", "pages": "1/1", "metric_version": "1.0", "time_zone": "Europe/Helsinki" }]
  }]
}
```

Use `format: "ratio"` only for 0–1 ratios; `count`, `number`, `rating` and `per-100` preserve their own units. An omitted `value` displays “Unavailable”; `null` displays “Not calculable”; a measured zero remains zero. Add `unit` and `definition` for ratings, counts per person, percentages and custom calculations. A raw table cell of `null` means unavailable; use a metric object to distinguish a non-calculable result.

Serialize embedded JSON with a real JSON encoder, then escape `<` as `\u003c` (and U+2028/U+2029 where needed) before putting it in the script element. This prevents source text containing `</script>` from closing the data block. The renderer uses text nodes; keep that approach when adapting it. Do not place credentials, unnecessary personal information, chat content or arbitrary HTML in the snapshot.

Write observations from the new event's numbers. Keep recommendations distinct from observations and identify their supporting evidence; never copy another event's recommendations as conclusions. A senior audience or many accepted meetings does not prove investment outcomes, deal flow or financial ROI.

Before delivery, reconcile totals, denominators, meeting/participant counts, classifications, rating scales and event coverage. Test the selector, table filters, keyboard access, both themes, narrow screens and printing. Keep source notes, missing metrics and collection time visible. Provide the HTML plus a Markdown summary and source notes; label prepared or partial outputs accurately.

## Prompt to copy

```text
Use the Brella Core API skill to create an event insights report for
organization [ID] and event [ID], or selected events [IDs / period].
Read only. Use credentials already configured in the trusted runtime.

Follow the event-insights workflow. Create event-insights-report.html
and a Markdown summary covering adoption, networking quality, meeting
pairs, sessions, sponsors, interests, power users and recommendations.
Use the bundled HTML template and select report views for multiple events.

Use aggregates first and permitted records for detailed calculations.
Define seniority/group classification and every denominator. Preserve
missing values, overlapping populations, rating scales and counting grain.
Identify unavailable message reply rates and incomplete scopes explicitly.
Show sources, collection time, metric versions and coverage. Keep credentials
and unnecessary personal data out. Save locally; do not publish or send.
```