It is important to define entity relationships before integrating your data with Natero.
Define Accounts & Users
The first step is to define your Accounts and Users in Natero.
Accounts are entities that you'd like to track in Natero. Accounts typically map to account, company or customer records within your CRM. In Salesforce, an account is usually mapped to the account object. Multiple users usually belong to an account. In certain cases, an account in Natero may also be mapped to a single user.
Natero features you can use to track or explore accounts are:
Users are typically individual people that either use your product or are CRM contacts. Users belong to a Natero account. Although multiple users may belong to an account, each user must belong to a single Natero account. Product usage data is tracked on a per user basis and aggregated to the account level.
Natero features you can use to track or explore users are:
Define Account Hierarchy
Natero allows you to capture account relationships between parent companies and their subsidiaries. For example, you can designate a parent account with one or more child accounts. Those child accounts can have child accounts of their own, and so on.
Once defined, the account hierarchy feature can be turned on in your Natero instance. Some typical use cases include: accounts with different franchises, office locations, branches, divisions, etc.
Note that account hierarchy will affect how usage, billing and other information will be reported in Natero.
- Natero rolls up activity, product usage and financial data of the child accounts to the accounts at higher nodes.
- Natero does not roll up support tickets, interactions and notes from the child accounts to the accounts at higher nodes.
- Natero only captures product usage data of the very bottom level accounts (leaf accounts).
Map Product Usage to An Account
Natero allows you to track different product usage at the account level. When implementing event tracking via the Natero JS Library, an optional productId can be associated with feature and module events. The productId is set similarly to the moduleId, via the setProductId() call. It stays set until changed or set to null.
When sending event data via the Event API, a separate product field can be added along with the module and feature properties to indicate the product names.