{"_id":"@bluedex/analytics-events","name":"@bluedex/analytics-events","dist-tags":{"latest":"2.10.0"},"versions":{"2.10.0":{"name":"@bluedex/analytics-events","description":"Bluedex analytics events","license":"MIT","publishConfig":{"access":"public"},"version":"2.10.0","exports":{".":{"import":{"types":"./lib/esm/types/index.d.ts","default":"./lib/esm/index.mjs"},"require":{"types":"./lib/cjs/types/index.d.ts","default":"./lib/cjs/index.js"}}},"types":"./lib/cjs/types/index.d.ts","main":"./lib/cjs/index.js","scripts":{"clean":"rm -rf ./lib","build":"yarn run clean && yarn run build:esm && yarn run build:cjs","build:esm":"tsc -p ./tsconfig.esm.json && mv lib/esm/index.js lib/esm/index.mjs","build:cjs":"tsc -p ./tsconfig.cjs.json","prepack":"yarn run build","lint":"yarn eslint .","release":"semantic-release","tarball":"npm pkg set version=0.0.1 && npm pack && npm pkg delete version && mv bluedex-analytics-events-0.0.1.tgz bluedex-analytics-events-dev.tgz","tarball:install":"yarn run tarball && ./scripts/install-in-repo.sh"},"devDependencies":{"@semantic-release/changelog":"^6.0.1","@semantic-release/git":"^10.0.1","@types/jest":"^29.2.1","@types/node":"^18.11.7","@typescript-eslint/eslint-plugin":"^5.42.0","@typescript-eslint/parser":"^5.42.1","eslint":"^7.11.0","eslint-config-prettier":"^6.11.0","eslint-plugin-prettier":"^3.1.3","eslint-plugin-react":"^7.21.5","eslint-plugin-react-hooks":"^4.6.0","eslint-plugin-simple-import-sort":"^7.0.0","eslint-plugin-typescript-sort-keys":"^2.1.0","eslint-plugin-unused-imports":"^2.0.0","prettier":"^2.7.1","semantic-release":"^19.0.5","typescript":"^4.4.3"},"engines":{"node":">=14"},"_id":"@bluedex/analytics-events@2.10.0","gitHead":"3a447054deb66cbbdbeac982fa63bde04e0d491a","_nodeVersion":"18.19.0","_npmVersion":"10.8.1","dist":{"integrity":"sha512-weGTJlFDEY+Hmn2w9Agty/Rn/CnQaUXso66s3hBKnKJD2ml8O0ehSQvhj/VLZB2yps9ot/vK0VpYLoFaH7Y3mg==","shasum":"f6f10634be51bd1400e3eb50a89488237d4f0591","tarball":"https://registry.npmjs.org/@bluedex/analytics-events/-/analytics-events-2.10.0.tgz","fileCount":99,"unpackedSize":136629,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIC0XkEw+S1AvpG+BAF3KeV67hl7HGaNlI5/nPNqYIVciAiEAxDiOIlMwcs4xX5FxN+JE/7WVwdBFvIp+Ko/RHb/HuJE="}]},"_npmUser":{"name":"afzalkhan","email":"afjal.khan@speqto.com"},"directories":{},"maintainers":[{"name":"afzalkhan","email":"afjal.khan@speqto.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/analytics-events_2.10.0_1718877660353_0.4970628630676497"},"_hasShrinkwrap":false}},"time":{"created":"2024-06-20T10:01:00.232Z","2.10.0":"2024-06-20T10:01:00.498Z","modified":"2024-06-20T10:01:00.831Z"},"maintainers":[{"name":"afzalkhan","email":"afjal.khan@speqto.com"}],"description":"Bluedex analytics events","license":"MIT","readme":"# Bluedex Labs Analytics Events\r\n[![npm](https://img.shields.io/npm/v/@bluedex/analytics-events)](https://www.npmjs.com/package/@bluedex/analytics-events)\r\n\r\nThe `@bluedex/analytics-events` package is a [npm package](https://www.npmjs.com/package/@bluedex/analytics-events) of constants used as the inputs into our [@bluedex/analytics](https://www.npmjs.com/package/@bluedex/analytics) package ([Github Link](https://github.com/Bluedex/analytics)). It is used in repos such as [interface](https://github.com/Bluedex/interface) and [docs](https://github.com/Bluedex/docs).\r\n\r\n## Installation\r\n\r\nInstall via `npm` or `yarn`.\r\n\r\n```bash\r\nyarn add @bluedex/analytics-events\r\n```\r\n\r\n```bash\r\nnpm i --save @bluedex/analytics-events\r\n```\r\n\r\n## Adding Events\r\n\r\nEvents 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.\r\n\r\nThis README will go over how to design, name, organize, and test your event names, event properties, and property values.\r\n\r\nHere is a short illustrative example of what events will look like in code once defined:\r\n\r\n```javascript\r\n// Event names example\r\nexport enum NFTBuyEvents {\r\n  NFT_BUY_ADDED = 'NFT Buy Bag Added',\r\n  NFT_BUY_BAG_CHANGED = 'NFT Buy Bag Changed',\r\n  NFT_BUY_BAG_REFUNDED = 'NFT Buy Bag Refunded',\r\n  NFT_BUY_BAG_SIGNED = 'NFT Buy Bag Signed',\r\n  NFT_BUY_BAG_SUCCEEDED = 'NFT Buy Bag Succeeded',\r\n}\r\n\r\n// Event properties example\r\nexport enum WalletEventProperties {\r\n    WALLET_ADDRESS = 'wallet_address',\r\n    TO_ADDRESS = 'to_address',\r\n    TIMESTAMP_EPOCH_SECONDS = 'timestamp_epoch_seconds',\r\n}\r\n\r\n// Property values example\r\nexport enum DocsSentiment {\r\n  NEGATIVE_SENTIMENT = 'Negative Sentiment',\r\n  NEUTRAL_SENTIMENT = 'Neutral Sentiment',\r\n  POSITIVE_SENTIMENT = 'Positive Sentiment',\r\n}\r\n```\r\n\r\n## Designing Events: The Trace Framework\r\n\r\nThe [analytics](https://github.com/Bluedex/analytics) library implements the [Trace framework](https://slack.engineering/creating-a-react-analytics-logging-library/) 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.\r\n\r\n| Context     | Description                                                                                                                           |\r\n| :---------  | :------------------------------------------------------------------------------------------------------------------------------------ |\r\n| `page`      | The highest order context in the app. Describes the page / tab, such as Swap, Explore, Pool, Vote, etc.                               |\r\n| `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. |\r\n| `modal`     | A modal, if one exists at the time of the event.                                                                                      |\r\n| `element`   | The most specific element that triggered the event such as a specific button or link.                                                 |\r\n\r\nNo 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.\r\n\r\nTrace context values should follow property value naming conventions.\r\n\r\n## Naming Conventions\r\n\r\nEvent names should:\r\n- follow the Object-Action naming convention (based on this [article](https://segment.com/academy/collecting-data/naming-conventions-for-clean-data/)).\r\n- be human readable\r\n- capitalize each word (e.g [Proper Case](https://www.computerhope.com/jargon/p/proper-case.htm))\r\n- start with object/product to ensure events are grouped together in Amplitude (sorted alphabetically)\r\n- us past tense verbs (e.g. Button *Clicked*).\r\n- *not* use acronyms or short hand (e.g. use `Transaction` over `Txn`)\r\n\r\nProperty names should:\r\n- be `snake_case`\r\n- be prefixed with `is_` when representing a boolean value\r\n- end in units (unabbreviated) when needed (e.g. `time_seconds`)\r\n- *not* use acronyms or short hand (e.g. use `Transaction` over `Txn`)\r\n\r\nProperty values should:\r\n- be a boolean, number, string, or enum (of strings) type.\r\n- strings: be consistent within all possible values, opting for either `Proper Case`, `kebab-case`,  or `snake-case`. The default selection should be `Proper Case`.\r\n\r\n## Defining Events In Code\r\n\r\nEvent names, property names, and property values should all be defined in Javascript using `enum`'s and follow the following conventions:\r\n- `enum` names should be as specific as possible (e.g `DocsProtocolVersion` over `Version`).\r\n- `enum` names should be in `PascalCase`.\r\n- Code values of enums should be named in `UPPER_SNAKE_CASE`.\r\n\r\n## Organizing Events\r\n\r\nThese 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.\r\n\r\nTop level files are for such as [primitives](./src/primitives.ts) 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.\r\n\r\nFolders should be made by origin or product. For example, [docs](./src/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.\r\n\r\n## Testing Events\r\n\r\nFor rapid development, a convenience flow is available that allows you to do the following in a single command:\r\n- create a tarball copy of the latest events\r\n- copy this tarball to the specified project\r\n- install this package in the specified project\r\n\r\nTo set this up, define the following environment variables (in your bash/zsh profile or as desired):\r\n```bash\r\nexport ANALYTICS_IMPLEMENTING_REPO_PATH={PATH}\r\nexport ANALYTICS_IMPLEMENTING_REPO_INSTALL={npm|yarn}\r\n```\r\nOnce set up, run the following command to run the sequence above:\r\n\r\n```bash\r\nyarn tarball:install\r\n```\r\n\r\nThis flow also clears your `tmp` cache only for yarn, ensuring yarn install times are not degraded after testing your analytics changes.\r\n\r\nWhen you're done testing, undo the changes so you don't commit the temporary file to remote:\r\n`git restore package.json yarn.lock && rm bluedex-analytics-events-dev.tgz && yarn`.\r\n\r\n### Manually Installing\r\n\r\nTo test generate a tarball of the new test package and install it directly, using the following command:\r\n\r\n```bash\r\nyarn tarball\r\n```\r\n\r\nThis will generate a `bluedex-analytics-events-dev.tgz` including your changes and a `0.0.1` package version number.\r\n\r\nTo install it in your implementing repo, copy/move the tarball to the top level of your implementing repo and then run the following commands:\r\n\r\n```bash\r\n# yarn\r\nyarn cache clean\r\nyarn add file:bluedex-analytics-dev.tgz\r\n\r\n# npm\r\nnpm install bluedex-analytics-dev.tgz\r\n```\r\n\r\n## Releasing Events\r\n\r\nReleasing a new version of the package is performed automatically after pushing code to main using the [release](/.github/workflows/release.yaml) Github workflow.\r\n\r\nThis repository uses [semantic-release](https://github.com/semantic-release/semantic-release) for the release process,\r\nwhich in turn uses the [Angular commit message suggestions](https://github.com/angular/angular/blob/main/CONTRIBUTING.md) to identify the type of release.\r\n\r\nOnce a release is published, integrating your new events is as simple as updating to the latest version of the package via `npm`/`yarn`, replacing your local tarball.\r\n\r\n## Legal notice\r\n\r\nBluedex Labs encourages integrators to evaluate their own regulatory obligations when integrating this package into their products, including, but not limited to, those related to economic or trade sanctions compliance.\r\n","readmeFilename":"README.md"}