Field

Data Type

Format

account_id

string

Unique identifier for account

user_id

string

Unique identifier for user

feature_id

string

Name of the feature.

Eg: "Project Created", "Project Status Updated", "Project Deleted"

​

Points to Note:

1. feature_id should be unique for different module_ids and product_ids

2. The value passed in the feature_id will be displayed as the name of the feature in CustomerSuccessBox UI.

Limit:

1. 64 Characters. Characters beyond first 64 characters will be auto truncated.

2. You can pass up to 256 Unique Features in CustomerSuccessBox. Once this limit is reached, new features will not be tracked.

module_id

string

Name of the Module.

Eg: "Project", Dashboard", "Users".

​

Points to Note:

1. module_id should be unique for different product_ids

2. feature_id should be unique for different module_ids

3. The value passed in the module_id will be displayed as the name of the module in CustomerSuccessBox UI.

Limit:

1. 64 Characters. Characters beyond first 64 characters will be auto truncated.

2. You can pass up to 256 Unique Modules in CustomerSuccessBox. Once this limit is reached, new modules will not be tracked.

​

product_id

string

Name of the Product.

Eg: "MySaaSProductName".

​

Points to Note:

1. module_id should be unique for different product_ids

2. feature_id should be unique for different module_ids and product_ids

3. The value passed in the product_id will be displayed as the name of the product in CustomerSuccessBox UI.

Limit:

1. 64 Characters. Characters beyond first 64 characters will be auto truncated.

timestamp

timestamp

​ISO 8601 format

The date in the timestamp (in GMT) of the feature usage event should be the same as the date (in GMT) when the event was pushed to CustomerSuccessBox

Backdated events will not be aggregated and hence should not be pushed to CustomerSuccessBox

total

integer

This is optional.

If NO value is passed, this is equivalent to "1".

If "0" (zero) is passed, then it will be treated as zero. i.e. feature usage was zero. As good as that feature event was never used / never sent / never received for that particular account/user combination for that date/time.

We discourage passing "0" (zero) since it will unnecessary make an additional call for your systems as well our systems, and can consume your rate limit. It best NOT to make that call, instead of passing it with zero. The effect will be the same.

​

When to use this?

Rather than sending each feature usage event individually, you can choose to make on end of day api call for each feature (for every relevant account/user combination) with the total feature usage count for the day.

​

This will be helpful, if you're pulling out the value from your internal product database. And can save engineering effort in cases where data is available in your internal product database.