Overview

The basic building blocks of the Stigg platform are features, which represent functionality in the product that can be monetized.

Defining features in Stigg allows you to slice-and-dice your products in any way you'd like, while only requiring a single integration with your codebase for every new feature.

Features are usually defined by product managers, but can also be defined by engineers.

Stigg supports 3 types of features:

1. Boolean features - represent functionality that customers can either have access to or not.
2. Configuration features - represent functionality that can be configured, for example: the number of days for data retention, maximum allowed file size.
3. Metered features - represent functionality with varying usage that needs to be tracked, for example: number of seats, number of API calls made, monthly active users (MAUs), etc.

Viewing the list of available features

To view the list of available features, select the Features sub-section of the Product Catalog from the left navigation pane.

Creating features

Creating new features in Stigg is possible by clicking on the "+ New feature" button in the Features sub-section of the Product Catalog.

Enter the below details in the opened modal:

1. Name - the name of the feature.
2. Description (optional) - the feature's description.
3. ID - will be auto-generated by Stigg. Use this ID to refer to the feature in your application. To link an existing feature, override the auto-generated value.
4. Feature type - boolean, configuration or meter.

📘

The values that are entered in the “Name” and “Description” fields will be leveraged by Stigg to render the customer-facing paywall and customer portal; therefore, it’s recommended to use customer-friendly texts.

Creating boolean features

To create a boolean feature select the Boolean feature type.

Confirm the action by clicking on the "Create" button.

Creating configuration features

📘

Stigg currently supports configuration features that have numeric values. For example: number of log retention days.

To create a configuration feature, select the Configuration feature type.

Optionally edit the singular and plural unit names, for example: "day" and "days".

Confirm the action by clicking on the "Create" button.

Creating metered features

To create a metered feature, select the Meter feature type.

Stigg supports 2 data sources:

1. Reported usage - use this source when your application reports calculated usage of the feature to Stigg. This data source is useful for features, such as: seats.
2. Raw events - use this source when your application generates events, which Stigg can filter and aggregate to determine customer usage of the feature. This data source is useful for features, such as: monthly active users (MAUs).

More details about Stigg's metering and aggregation capabilities can be found here:

Usage meters

To create a metered feature that's based on reported usage, select the "Reported usage" data source.

Optionally edit the singular and plural unit names, for example: "seat" and "seats".

Confirm the action by clicking on the "Create" button.

Event meters

To create a metered feature that's based on raw events, select the "Raw events" data source.

Click "Next".

Event filters

Define the event filters - the most basic filter is a filter according to the reported event name. Add additional conditions to filter unwanted events.

Aggregation

Select the aggregation method that Stigg will leverage to calculate the usage of each customer:

1. Count
2. Count unique
3. Sum
4. Max
5. Min
6. Average

All aggregation methods besides count require specification of an event property that will be leveraged to perform the aggregation, for example: when calculating a sum it's required to select what property should be summed.

Select this property.

Click "Next".

Unit names

Optionally edit the singular and plural unit names, for example: "seat" and "seats".

To complete the feature creation, click on the "Create" button.

Presenting usage to customers in a different granularity

Stigg allows you to report usage in a high granularity (for example: bytes) and present it customers in a different granularity (for example: GB).

When this configuration is enabled, even though the usage is reported in the higher granularity (i.e. bytes), throughout the Stigg app and SDK methods the units will be returned in the lower granularity (i.e. GB).

When integrated with a billing solution, the lower granularity units (i.e. GB) will be rounded up to the nearest integer. This means that if a customer is paying per used GB and has used 0.02 GB, they'll be billed for 1 GB.

To enable this configuration, toggle on the "Feature is sold in different units" setting.

Define the units that will be presented to customers and the conversion rate between the reporting units and presented units, for example: 1 GB = 1,000,000,000 bytes.

Save the changes.

🚧

Changing the conversion rate is only possible when there are no active subscriptions that use this feature.

Importing an existing list of features

If you're using a large list of features in your application and would like to import them into Stigg, let us know and we'd be happy to assist you with the process.

Integrating the features into your codebase

In order to leverage the Stigg platform for enforcing access and charging customers according to feature usage, you'll need to integrate the Stigg SDKs and API into your application's codebase.

You can leverage the snippets under the "Code" tab to do so.

More details about Stigg's codebase integration can be found here:

Storing metadata

It's possible to store metadata on each feature. The metadata can then be leveraged by the hosting application and third-party solutions via the Stigg SDKs, API and webhooks to implement custom functionality, for example: group features under a specific group in a pricing comparison table.

To store metadata on specific feature, under the "Metadata" tab of selected feature click on the "Add" (if there's no metadata) or "Edit" buttons.

Enter the relevant keys and values.

Click "Add" (if there was previously no metadata) or "Save changes" buttons to apply the changes.

Editing feature details

To edit the details of a feature, select the relevant row from the feature list.

Update the value of the relevant fields.

Save the changes.

📘

Some properties of a feature (for example: its ID), cannot be modified after the feature is created or when the feature is already in-use by a plan or add-on.

Archiving features

When you no longer want to grant new access to a specific feature, you can archive it.

When a feature is archived:

1. The feature will no longer appear in the list of features.
2. It will not be possible to grant new access for this feature in plans and add-ons, or via a promotional entitlement. Customers who previously had access to this feature (for example: by subscribing to an old plan or add-on version or via a promotional entitlement) will not be affected.
3. It will not be possible to analyze the feature's usage using the Feature Inspector.

To archive a feature, click on the dotted menu icon of the relevant row, and select the "Archive" action.

In the opened modal, confirm the action by entering the feature name and clicking on the "Archive" button.

🚧

1. It's not possible to archive a feature if it's in use by a published plan or add-on. To archive it, first publish new plan and add-on versions without it.
2. When a feature is archived, its feature ID is still considered in-use.

Unarchiving features

Plans can be unarchived using the unarchiveFeature mutation of Stigg's GraphQL API.