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.
Context | Description |
---|---|
page |
The highest order context in the app. Describes the page / tab, such as Swap, Explore, Pool, Vote, etc. |
section |
A section within the top level context. When a modal is open, section describes the part of the page from which the modal originated. |
modal |
A modal, if one exists at the time of the event. |
element |
The most specific element that triggered the event such as a specific button or link. |
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
overTxn
)
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
overTxn
)
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
, orsnake-case
. The default selection should beProper 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.gDocsProtocolVersion
overVersion
).enum
names should be inPascalCase
.- 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