What is the difference between a custom field and a label?

Labels are flexible, free-form tags where a bug can have several, good for loose classification. Custom fields are structured, typed slots where each bug has one value, good for a defined attribute like a build number, date, or pick-from-list category. Use labels for multi-valued categorization and custom fields for precise, single-valued data.

Why would I use custom fields for game bugs?

To capture and query game-specific dimensions that built-in fields miss, so you can answer questions like which storefront generates the most refund-driving bugs or which game mode is least stable. Structured custom fields make those attributes filterable and analyzable, rather than buried in prose descriptions where they cannot be queried.

What Is a Custom Field in a Bug Tracker?

Q: What is a custom field in a bug tracker?

An extra, user-defined field you add to issue records to capture information specific to your game or workflow, beyond the built-in fields, like build number, storefront, save version, or game mode. It stores structured data you can filter, group, and analyze by, tailoring the tracker to your game's particular concerns.

Quick answer: A custom field is a field you define yourself to store information a bug tracker does not capture by default. It lets you extend issue records with data specific to your game, such as the build number, platform store, save version, game mode, or any structured attribute you want to track and filter by.

Bug trackers come with standard fields, title, description, status, priority, but no fixed set of fields fits every game. A custom field lets you add the specific data points your game and workflow need, turning a generic issue record into one tailored to your context. Whether it is a build number, a storefront, a game mode, or a platform detail, custom fields capture the structured information that helps you organize, filter, and understand your bugs in terms that matter to your game.

What Custom Fields Are For

A custom field is a developer-defined slot on each issue for a specific piece of structured data. Where built-in fields cover the universal basics, custom fields cover what is specific to you. If your workflow cares about which storefront a bug came from, which game mode it occurred in, which save version was involved, or any other structured attribute, a custom field captures it consistently on every relevant bug.

The value of structured custom fields over just writing it in the description is that structured data can be filtered, grouped, and analyzed. A 'game mode' written in prose is just text; a 'game mode' custom field lets you pull up all the bugs in a specific mode, or see which mode has the most issues. Custom fields make your game-specific dimensions queryable.

Custom Fields vs Labels

Custom fields and labels both add information, but they serve different purposes. Labels are flexible, free-form tags, good for classification where a bug might have several. Custom fields are structured, typed slots, good for a defined attribute each bug has one value of: a build number, a numeric value, a date, a pick-from-list category. Use labels for loose, multi-valued categorization and custom fields for structured, single-valued data.

For example, 'platform' might be a label (a bug could affect several platforms) while 'build number' is a custom field (a specific value). The two complement each other: labels for the fuzzy classification dimensions, custom fields for the precise data points. Together they let you model your game's specific concerns in the tracker.

Custom Fields in Practice

The point of custom fields is to make your tracker speak your game's language. Set up fields for the attributes you actually need to filter and analyze by, and resist adding fields you will not use (every field is overhead on the report). Well-chosen custom fields let you answer game-specific questions, which storefront generates the most refund-driving bugs, which game mode is least stable, that generic fields cannot.

Bugnet supports custom fields so you can capture the data specific to your game and workflow on each issue, then filter and build saved views around it. Combined with automatic context capture (which already records things like build version and device), custom fields let you add the extra game-specific dimensions you care about, so your bug data reflects the actual structure of your game rather than a one-size-fits-all template.

A custom field makes your tracker speak your game's language, build number, storefront, game mode, captured as structured data you can filter by.