# Defining Events for AutoDocs

An event in AutoDocs is comprised of up to 3 descriptors.

Each descriptor is comprised of a JPath property and an optional alias.

# Choosing Your Descriptors

The most common scenario for describing events relies on a property like @.eventName or @.eventType etc.

However, if you're working in an organization with multiple products or services emitting similarly named events, it may be helpful to add a distinguishing property that helps you separate them.

If you're working on a mobile app, you may want to add the platform as a descriptor to compare their events against eachother for consistency or to track their version releases independently.

# Changing Descriptors

At the moment, descriptors are locked in once a config is saved. If you find you need to modify them, the best course of action is to disable (or delete) the config and create a new one.

# Descriptor Limits

You can have up to 250 unique descriptor combinations for a given AutoDocs config.

This limit is flexible, so please Contact Us if you need more.

# Versions

You can choose a property on your payloads that represent a release of your application. You can choose between a numerical and a semantic version setup, and the property is defined using JPath.

Any payload found to not contain the defined property (or where the property cannot be parsed to the specified version format) will be skipped.

# Semantic Versions

Semantic Versionining is formatted as Major.Minor.Patch.

# Version 1.2.3

Identifier Value
Major 1
Minor 2
Patch 3

You can also include metadata to indicate a Pre-Release version of your events, which will be persisted as well.

This would be in the form of Major.Minor.Patch-PreRelease

# Version 1.2.3-beta

Identifier Value
Major 1
Minor 2
Patch 3
Pre-Release beta

# Version Limits

You can have up to 200 unique versions for a given AutoDocs config.

This limit is flexible, so please Contact Us if you need more.

# Disabling an AutoDocs Config

When a config is disabled, its associated data remains accessible in the Events Explorer and Versions Explorer, but no new data will be parsed. The related ingest(s) will be freed up for use on other configs.

# Deleting an AutoDocs Config

When a config is deleted, all of its associated data will be purged within a few days.

# Restricting Properties

You can opt to restrict properties from being included in AutoDocs in two ways:

  1. Ignore Properties completely

  2. Disable Sample Collection

# Ignoring Properties

When you opt to ignore a property, it will be completely excluded from all Events Explorer and Versions Explorer functionality, and the completely ignored when traversing events. If you opt to ignore an object or array property, all children properties will be ignored as well.

# Disabling Sample Collection

When you opt to disable sample collection, the property will still be included in Events Explorer and Versions Explorer functions, but no samples will be shown or retained. This may be useful for fields that you emit that have more sensitive data. If you disable sample collection on a property that is an object (or array of objects) - all its descendent properties will have sample collection disabled.

# Cardinality Calculations

In order to provide accurate cardinality measures, we assume every property may be restricted and cardinality is calculated on a hash of the data. Therefore, if you opt to disable sample collection - the existing data and the newly collected and hashed samples will be consistent.

# Existing Data

When you restrict a property, all existing data will be cleared out within a short time window (usually within an hour, depending on the volume of data).