The swifydex-analytics-events package is a npm package of constants used as the inputs into our swifydex-analytics package (Github Link).

Install via npm or yarn.

yarn add swifydex-analytics-events

npm i --save swifydex-analytics-events

Events are composed of an event name, event properties, and user properties. Event names, event properties, and property values are defined by enumerations in this repository to ensure ensure that event logging is not prone to misspelling, inconsistency, repetition, or unexpected logged values.

This README will go over how to design, name, organize, and test your event names, event properties, and property values.

Here is a short illustrative example of what events will look like in code once defined:

// Event names example
export enum NFTBuyEvents {
  NFT_BUY_ADDED = 'NFT Buy Bag Added',
  NFT_BUY_BAG_CHANGED = 'NFT Buy Bag Changed',
  NFT_BUY_BAG_REFUNDED = 'NFT Buy Bag Refunded',
  NFT_BUY_BAG_SIGNED = 'NFT Buy Bag Signed',
  NFT_BUY_BAG_SUCCEEDED = 'NFT Buy Bag Succeeded',
}

// Event properties example
export enum WalletEventProperties {
    WALLET_ADDRESS = 'wallet_address',
    TO_ADDRESS = 'to_address',
    TIMESTAMP_EPOCH_SECONDS = 'timestamp_epoch_seconds',
}

// Property values example
export enum DocsSentiment {
  NEGATIVE_SENTIMENT = 'Negative Sentiment',
  NEUTRAL_SENTIMENT = 'Neutral Sentiment',
  POSITIVE_SENTIMENT = 'Positive Sentiment',
}

The analytics library implements the Trace framework to enable easy default properties and basic hierarchy of context. The following context properties are available, in order of specificity. This can be used directly for ease or logged manually for custom trigger events.

No specific context is required and any or all of these trace fields may be null. Use these as it makes sense for your context, and define possible values in this repository. These fields will work in tandem with your event names and event properties.

Trace context values should follow property value naming conventions.

Event names should:

• follow the Object-Action naming convention (based on this article).
• be human readable
• capitalize each word (e.g Proper Case)
• start with object/product to ensure events are grouped together in Amplitude (sorted alphabetically)
• us past tense verbs (e.g. Button Clicked).
• not use acronyms or short hand (e.g. use Transaction over Txn)

Property names should:

• be snake_case
• be prefixed with is_ when representing a boolean value
• end in units (unabbreviated) when needed (e.g. time_seconds)
• not use acronyms or short hand (e.g. use Transaction over Txn)

Property values should:

• be a boolean, number, string, or enum (of strings) type.
• strings: be consistent within all possible values, opting for either Proper Case, kebab-case, or snake-case. The default selection should be Proper Case.

Event names, property names, and property values should all be defined in Javascript using enum's and follow the following conventions:

• enum names should be as specific as possible (e.g DocsProtocolVersion over Version).
• enum names should be in PascalCase.
• Code values of enums should be named in UPPER_SNAKE_CASE.

These enumerations and events can be shared across products or be specific to a product or use case. All event names, property names, and property values should be defined using enumerations placed in the best folder for ease of reference, and can be split out into separate files when needed. When defining enumerations, consider that the package exports all names at the top level, so adding a specific prefix for your product or use case may be useful. If your use cases are highly generalizable, you can define your enumeration as a primitive or reuse an existing primitive.

Top level files are for such as primitives contain generic data that is supposed to be reused by different applications. This data describes the events being logged, such as EventName.MENU_CLICK, which reflects an event on a menu. Specific event context should be captured in additional fields beyond the event name to create user-friendly hierarchy groupings.

Folders should be made by origin or product. For example, docs contains events specific to our documentation. Folders can be grouped by product when multiple origins could use these events, such as general actions like swapping.

For rapid development, a convenience flow is available that allows you to do the following in a single command:

• create a tarball copy of the latest events
• copy this tarball to the specified project
• install this package in the specified project

To set this up, define the following environment variables (in your bash/zsh profile or as desired):

export ANALYTICS_IMPLEMENTING_REPO_PATH={PATH}
export ANALYTICS_IMPLEMENTING_REPO_INSTALL={npm|yarn}

Once set up, run the following command to run the sequence above:

yarn tarball:install

This flow also clears your tmp cache only for yarn, ensuring yarn install times are not degraded after testing your analytics changes.

When you're done testing, undo the changes so you don't commit the temporary file to remote: git restore package.json yarn.lock && rm swifydex-analytics-events-dev.tgz && yarn.

To test generate a tarball of the new test package and install it directly, using the following command:

yarn tarball

This will generate a swifydex-analytics-events-dev.tgz including your changes and a 0.0.1 package version number.

To install it in your implementing repo, copy/move the tarball to the top level of your implementing repo and then run the following commands:

# yarn
yarn cache clean
yarn add file:swifydex-analytics-dev.tgz

# npm
npm install swifydex-analytics-dev.tgz