Use it to create a collector which records product state.

1. Inherit the class, implement {@link ApplicationUsagesCollector#getGroup()} and {@link ApplicationUsagesCollector#getMetrics()} See fus-collectors.md for more details.
2. Implement custom validation rules if necessary. For more information see {@link DotnetSensitiveDataValidator}.
3. Otherwise, create a YT issue in FUS project with group data scheme and descriptions to register it on the statistics metadata server

1. Open "Statistics Event Log" toolwindow.
2. Add group to events test scheme with "Add Group to Events Test Scheme" action.
   {@link com.intellij.internal.statistic.actions.scheme.AddGroupToTestSchemeAction}
3. Record all state collectors with "Record State Collectors to Event Log" action.
   {@link com.intellij.internal.statistic.actions.RecordStateStatisticsEventLogAction}

Use it to create a collector which records user or internal IDE actions.

1. Inherit the class, implement {@link CounterUsagesCollector#getGroup()}, register all events you want to record and register collector in plugin.xml. See fus-collectors.md for more details.
2. Implement custom validation rules if necessary. For more information see {@link IntellijSensitiveDataValidator}.
3. If new group is implemented in a platform or a plugin built with IntelliJ Ultimate, YT issue will be created automatically
4. Otherwise, create a YT issue in FUS project with group data scheme and descriptions to register it on the statistics metadata server

1. Open "Statistics Event Log" toolwindow.
2. Add group to events test scheme with "Add Group to Events Test Scheme" action.
   {@link com.intellij.internal.statistic.actions.scheme.AddGroupToTestSchemeAction}
3. Perform action to check that it's recorded in "Statistics Event Log" toolwindow.

Use it to create a collector which records IDE/project state or user/IDE internal actions.

Called by a scheduler once a day and records IDE/project state.

Don't use it directly unless absolutely necessary. Implement {@link ApplicationUsagesCollector} or {@link ProjectUsagesCollector} instead.

To record IDE events (e.g. invoked action, opened dialog) use {@link CounterUsagesCollector}

{@code
             {
               "groups": [
                 {
                   "id": "actions",
                   "builds": [],
                   "versions": [ {"from": "9"} ],
                   "rules": {
                     "event_id": [ "{enum:action.invoked}" ],
                     "event_data": {
                       "action_id": [ "{util#action}" ],
                       "context_menu": [ "{enum#boolean}" ],
                       "parent": [ "{enum#parent}", "{util#class_name}" ]
                     },
                     "enums": {
                       "parent": [ "LineMarkerActionWrapper", "TreeActionWrapper", "MyTreeActionWrapper" ]
                     }
                   }
                 },
                 {
                   "id" : "run.configuration.exec",
                   "builds" : [ {"from" : "191.4811"} ],
                   "versions" : [ {"from" : "1"} ],
                   "rules": {
                     "event_id" : [ "{enum:started|ui.shown|finished}" ],
                     "event_data": {
                       "id" : [ "{util#run_config_id}" ]
                     }
                   }
                 }
               ]
             }
             }

FeatureUsageData represents additional data for reported event.

Example

My usage collector collects actions invocations. "my.foo.action" could be invoked from one of the following contexts: "main.menu", "context.menu", "my.dialog", "all-actions-run".

If I write {@code FUCounterUsageLogger.logEvent("my.foo.action", "bar")}, I'll know how many times the action "bar" was invoked (e.g. 239)

If I write {@code FUCounterUsageLogger.logEvent("my.foo.action", "bar", new FeatureUsageData().addPlace(place))}, I'll get the same total count of action invocations (239), but I'll also know that the action was called 3 times from "main.menu", 235 times from "my.dialog" and only once from "context.menu".

Validates event id and event data before recording it locally. Used to ensure that no personal or proprietary data is recorded.

• {@link ValidationResultType#ACCEPTED} - data is checked and should be recorded as is;
• {@link ValidationResultType#THIRD_PARTY} - data is correct but is implemented in an unknown third-party plugin, e.g. third-party file type
• {@link ValidationResultType#REJECTED} - unexpected data, e.g. cannot find run-configuration by provided id;

Base class for custom validation rules. If your data cannot be validated with enumerated values or by a regexp, inherit the class and implement {@link CustomValidationRule#doValidate(String, EventContext)}. For more information see {@link IntellijSensitiveDataValidator}.

Example: {@link com.intellij.internal.statistic.collectors.fus.ClassNameRuleValidator}, {@link com.intellij.internal.statistic.collectors.fus.LangCustomRuleValidator}, etc.

Validates event id and event data before recording it locally. Used to ensure that no personal or proprietary data is recorded.

• {@link ValidationResultType#ACCEPTED} - data is checked and should be recorded as is;
• {@link ValidationResultType#THIRD_PARTY} - data is correct but is implemented in an unknown third-party plugin, e.g. third-party file type
• {@link ValidationResultType#REJECTED} - unexpected data, e.g. cannot find run-configuration by provided id;

The data from all collectors is validated before it's recorded locally. It's necessary to make sure that the data is correct and it doesn't contain personal or proprietary information.
Validation is performed right before logging in {@link IntellijSensitiveDataValidator#validate}.

Therefore, each collector should define data scheme and rules which will be used in validation.
Rules are stored in a separate repository, IDE loads rules from the server during runtime.
If you use new FUS API (docs: fus-collectors.md) and group is implemented in a platform or bundled plugin, synchronization between statistics metadata repository and source code is performed semi-automatically. In other cases or when you need to change group scheme without changing the code, create an issue.

There are 3 types of rules:

1. Enum: a list of possible values, e.g. "{enum:started|finished}" checks that the value is equal to 'started' or 'finished'.
   See: {@link EnumValidationRule}
2. Regexp: e.g. "{regexp#integer} checks that the value is integer.
   See: {@link RegexpValidationRule}
3. Custom rule: class which inherits {@link CustomValidationRule} and validates dynamic data like action id or file type, e.g. "{util#class_name}" checks that the value is a class name from platform, JB plugin or a plugin from JB plugin repository.
   See: {@link com.intellij.internal.statistic.collectors.fus.ClassNameRuleValidator}

There is also a list of common event data fields which doesn't require validation because they are always validated in {@link FeatureUsageData}, e.g. "plugin", "lang", etc.

Example:

• "actions" collector records invoked actions ({@link com.intellij.internal.statistic.collectors.fus.actions.persistence.ActionsCollectorImpl}).
  It is validated by the following rules:

               {
                 "event_id" : [ "{enum:action.invoked|custom.action.invoked}" ],
                 "event_data" : {
                   "action_id" : [ "{util#action}" ],
                   "class" : [ "{util#class_name}" ],
                   "context_menu" : [ "{enum#boolean}" ],
                   "current_file" : [ "{util#current_file}" ],
                   "input_event" : [ "{util#shortcut}" ],
                   "place" : [ "{util#place}" ],
                   "plugin" : [ "{util#plugin}" ],
                   "plugin_type" : [ "{util#plugin_type}" ]
                 }
               }
               

• "file.types" collector records information about project files ({@link com.intellij.internal.statistic.collectors.fus.fileTypes.FileTypeUsagesCollector}).
  It is validated by the following rules:

               {
                 "event_id" : ["{enum:file.in.project}" ],
                 "event_data" : {
                   "file_type" : [ "{util#file_type}" ]
                 }
               }