Organizations & projects

Intempt gives you tools for data access control and logical separation of data: organizations and projects.

Organizations

An organization is the highest abstraction level within a Intempt instance. It's made up of projects (see more on them below) and members. Most commonly a Intempt organization represents a real-world company or other type of isolated grouping.

At Intempt, each organization has a single billing plan associated with it, and that determines the data volume limits and features available across all projects in the organization.

Within organization settings, you can:

  • Create new Projects
  • Access Projects to whcih they have been invited
  • Add new members to the Organization
  • Update Organization member access rights (given the access rights)
  • Manage Billing and subscription plans (given the access rights)
  • Manage Organization settings (given the access rights)

To switch between organizations or create a new one, open the current organization's settings.

Adding new members

Any organization admin or owner can create organization invites. Such an invite is valid for 3 days after creation and only for the specified email.

Projects

A project is a silo of data within Intempt. All data belongs to a single project, and all queries are project-specific.

Every project has its own distinct API keys, which you can use to initialize your integration of choice, as well as to connect to our API.

To switch between projects, navigate to project settings, or create new projects, use the project switcher in the middle of the top bar. You can also quickly go to the current project's settings from the sidebar.

Ways of organizing projects

For most companies, we recommend creating three projects:

  • Local Development - when you're running the app on your own device
  • Staging - when you're running your app on a staging server
  • Production - for all your production data (e.g. your live website/app)

This way you can test out analytics in development and staging environments while keeping that test data separate from production.

Even if you have multiple customer-facing products e.g. a marketing website + iOS app + web app, it works best to have them share the same production project. This way you can track the user journey holistically (e.g. how many blog readers convert to paid product users) and see all the relevant events for a person in one place.

However, if have products that are fully siloed with unliked authentication systems you will likely want to create separate projects for them. For example, if you have an admin app that should be a separate project from your customer-facing products.