Metrics and Telemetry

ProVouchers submits pseudonymous, aggregate usage statistics through bStats and FastStats. The data helps prioritise which platforms, integrations, and features to invest in. It is enabled by default and can be turned off with a single setting.

Metrics are aggregate and non-identifying. No player names, UUIDs, IP addresses, voucher contents, or command output ever leave the server. Everything below is either a server-wide count or a coarse category.

Opting out

Set metrics.enabled to false in config.yml and restart the server:

config.yml

metrics:
  enabled: false

This disables every chart and both providers at once.

What is collected

The same definitions are reported to bStats and FastStats. Charts fall into two groups: a snapshot of how the plugin is configured, and counts of activity since the server started.

Environment and configuration

Read from the loaded configuration on each submission.

Chart	Meaning
`storage_backend`	Which database backend is in use (`sqlite`, `mysql`, `mariadb`, `postgres`).
`active_integrations`	Which optional integrations are installed (Vault, PlaceholderAPI, LuckPerms, WorldGuard, ItemsAdder, Oraxen, Nexo, Head Database, MiniPlaceholders).
`loaded_vouchers` / `loaded_codes`	How many vouchers and codes are loaded.
`voucher_count_bucket` / `code_count_bucket`	The same totals as a coarse range (`0`, `1-5`, `6-20`, `21-50`, `51-100`, `100+`).
`most_common_reward`	The most-used reward type across all configured vouchers and codes.
`reward_types_used`	The distribution of reward types in your configuration.
`condition_types_used`	Which condition types you gate redemptions behind.
`item_providers_used`	Where voucher items come from (`vanilla`, `player-head`, or a custom provider).
`uses_random_rewards`	Whether any voucher or code uses weighted random reward sets.
`uses_cooldowns`	Whether any voucher sets a cooldown.
`uses_expiry`	Whether any voucher or code sets an expiry.
`uses_conditions`	Whether any voucher or code gates on conditions.

Activity

Each report carries the increase since the previous report, so the charts read as activity per interval rather than a line that climbs with uptime. They never contain anything about who redeemed what.

Chart	Meaning
`redemptions`	Total successful redemptions.
`voucher_redemptions` / `code_redemptions`	The split between item vouchers and typed codes.
`dupes_blocked`	Duplicate voucher items rejected by anti-dupe.
`condition_denials`	Redemptions blocked because a condition failed.
`top_reward_granted`	The reward type granted most often.

Where the data goes

bStats publishes a public page per plugin, with the charts above rendered as graphs.
FastStats receives the same definitions.

Each chart is defined once and reported to both backends, and the single metrics.enabled switch governs both.

Checking it works

Run /voucher doctor. Its Metrics line reports what each backend is doing:

Metrics: bStats on, FastStats bukkit 0.30.2 on (errors on)

Reads	Meaning
`off (metrics.enabled: false)`	Turned off in `config.yml`. Nothing is collected.
`not started`	Metrics are on, but no backend started. The console logs why at startup.
`bStats not started`	bStats failed to start, usually no network at startup.
`FastStats opted out on this server`	Opted out in `config/faststats/config.properties`, or started with `-Dfaststats.enabled=false`.
`FastStats not submitting metrics`	FastStats runs but its metrics submission is off in that file.
`(errors off)`	Error reports are not sent, either by that file or because the service did not start.

FastStats submits nothing on a brand new server: the first start writes config/faststats/config.properties, and submission begins on the next start. A first run showing on is normal and correct.

To watch it submit, start the server with -Dfaststats.debug=true. The console then logs the FastStats context on startup and each submission as it is sent. On a test or development server, start with -Dfaststats.enabled=false instead, so its data stays out of the live project.