Skip to content

Community Analytics

Jellyfin Enhanced can optionally report a small set of anonymous usage statistics back to a community analytics project, entirely opt-in and off by default. Nothing is sent unless an admin turns it on from the plugin's config page (Admin → Usage Statistics), and that page shows the exact payload before it's ever sent.

This page shows the current aggregate results, live, straight from the same database every opted-in install reports to. It reads four public, read-only views. No per-install data, no IP addresses, no identifying information of any kind is exposed here or anywhere in this system.

What these numbers are, and aren't

These figures cover only installs that have explicitly opted in.
They are not a total install count for Jellyfin Enhanced, and shouldn't be read as one, since opting in is off by default, so this is a self-selected sample, not a census. Use it to see feature-usage trends among reporting installs, not overall adoption or reach.

What's collected

The config page's Preview button always shows the exact JSON that would be sent, built from the same code that does the real send. What follows is the detailed breakdown of what that JSON can contain.

Always included

(even with every option below unchecked)

Turning the master toggle on alone, with all three categories below left unchecked, sends only:

  • A random install ID (server-minted, never derived from anything about you or your server)
  • The plugin version
  • The Jellyfin server version and build target (jf10/jf12)
  • The reporting period's start date

Enough to answer "how many installs are on the latest version" and nothing else.

Info

Despite the heading, "always" means "with every report", not "unconditionally": nothing at all is sent until the master toggle is enabled and saved.

Feature toggle states

Every bool setting in the plugin's config (on/off only), reflected automatically, so a newly added toggle is automatically added in the next sync. See the Feature toggle adoption section below for the live, current, complete list, grouped by settings-page section.

Also included: two derived "is a key configured" flags (TmdbEnabled, MdblistEnabled), showing whether a TMDB/MDBList API key is set, never the key itself, and a small, explicitly hand-picked set of non-boolean fixed-choice settings, since a string could be a URL or API key and only specific ones are ever safe to include:

  • Icon style (IconStyle)
  • Maintenance Mode action (MaintenanceModeAction), and whether it applies to all users or a selection (MaintenanceModeAffectedUsers, sent only as all/selected — the actual user selection never leaves your server)
  • Tag overlay positions (QualityTagsPosition, GenreTagsPosition, LanguageTagsPosition, RatingTagsPosition)
  • Language tag priority list (LanguageTagsPriority) — normalized before sending: only tokens shaped like language codes (e.g. en,ja,fr) are included, anything else typed into that box is dropped

No other string setting is ever included: URLs, API keys, branding text/images, and every other free-text field are permanently excluded by design, not by an admin-configurable option.

Feature usage counts

  • Seerr requests submitted: a counter that goes up by one each time you submit a request, sent each report, then reset to zero, so it tracks recent activity rather than an ever-growing total.
  • Item totals: bookmarks, hidden-content items, spoiler-blur items, and reviews. Instead of counting an action, the plugin just counts what's currently in each file, every time it reports. Shown on the dashboard as: total count, how many installs have at least one, and how many installs reported at all.

Counts only, always: never which items, never any title or content, never who specifically.

Data file sizes

Byte size only (never contents) of the custom branding folder, if anything has been uploaded there (logo/banner/favicon images). This answers "is this feature actually used" the same way the usage counts above do for other features.

Loading live data…