Intempt
  1. Installation
Intempt
  • Installation
    • Basic Intempt Installation
    • Create source
    • Web Snippet
    • Google Tag Manager
    • Autocapture setup
    • SPA tracking
    • Environment Setup
    • Validating Installation
  • SDK
    • JS SDK
    • Android SDK
    • iOS SDK
    • Node.js SDK
  • API Reference
    • Track data
      POST
    • Consent
      POST
    • Choose API
      POST
    • Recommendations Feed API
      POST
  • Data Ingestion & Tracking
    • identify()
    • track()
    • record()
    • alias()
    • group()
    • consent()
    • intempt:html / intempt:page / intempt:session
    • Product Catalog Ingestion via API
  • Data Models & Event Schema
    • Event Schema Overview
    • Required Fields
    • Attribute Schema
    • Product Catalog Schema
  • Webhooks
    • Webhook Configuration
  • Server Side Experiments
    • Overview
    • Choose API endpoint
    • Handling Experiment Response
  1. Installation

Environment Setup

Environment Setup (dev/staging/prod)#

Intempt uses organizations and projects to help you separate data, manage environments, and control access.

Organizations#

An organization is the highest-level structure in Intempt. It represents a real company or team and contains:
Multiple projects
Members and their access rights
A single billing plan applied across all projects
Within an organization, you can create projects, manage members, and switch between different organizations using the top panel.

Projects#

A project is an isolated data container inside Intempt. All events, profiles, and analysis belong to a specific project.
Each project also has its own API keys, used when initializing your integrations.
You can switch between projects or create new ones using the project switcher in the top bar.

Recommended Environment Structure#

To keep your analytics clean and avoid mixing test data with real user data, Intempt recommends creating three separate projects:
Local Development – when the app runs on your local machine
Staging – when testing on a staging server
Production – for live user data
This setup ensures you can safely test tracking and behavior in dev/staging environments without polluting production analytics.

When to Combine Projects#

If you have multiple products that share the same customer experience (e.g., marketing website + iOS app + web app), they should share the same Production project.
This allows you to track the full user journey across platforms and keeps all events for each user in one place.

When to Use Separate Projects#

If your products are completely isolated — for example:
Different authentication systems
Different user bases
Admin-facing tools separate from customer-facing tools
Then you should create separate projects to prevent data overlap and maintain clean, logical segmentation.
Modified at 2025-12-03 10:36:55
Previous
SPA tracking
Next
Validating Installation
Built with