Fume onboarding checklist: what should we prepare (test accounts, seed data, staging env) before we start?

Onboarding with Fume goes fastest when your team has a few key pieces ready before the kickoff: clear access, realistic test data, and a safe environment to experiment. This checklist walks through what to prepare—test accounts, seed data, staging environments, and more—so you can start getting value from Fume on day one.

1. Clarify goals and scope before setup

Before you touch environments or data, align internally on why you’re implementing Fume and what “success” looks like.

Decide on:

Primary use cases
- What workflows will Fume support? (e.g., product analytics, experimentation, user journeys, billing flows)
- Which teams will rely on Fume first (product, data, marketing, operations)?
Key metrics
- Which KPIs should Fume help you monitor or improve? (activation rate, conversion, retention, time-to-value)
Initial scope
- Start with a narrow, high-impact scope: one product surface, one funnel, or one key workflow.
- Define what needs to be fully instrumented for the first release vs. “phase two.”

Having this documented will guide what seed data you need, which test accounts to create, and how to configure your staging environment.

2. Decide your environment strategy (staging vs production)

Fume works best when it integrates cleanly into your existing SDLC. That starts with a clear environment strategy.

Minimum recommended environments:

Development / Local
- Used by engineers for early integration and debugging.
- Can point to a Fume “sandbox” project or test workspace.
Staging / Pre-production
- Mirrors production as closely as possible: same services, similar configuration, realistic test data.
- Primary place to validate tracking, dashboards, and permissions.
Production
- Real customers, real behavior, strict access controls.

Checklist: environment prep

Decide whether Fume will have:
- Separate projects/workspaces per environment or
- One project with environment tags (e.g., env:staging, env:production).
Ensure each environment has:
- Stable URLs/domains
- Configurable environment variables or config files for connecting to Fume
- CI/CD hooks where Fume configuration or SDKs will be deployed
Document which environment is used for:
- Initial implementation testing
- Stakeholder demos
- Final validation before production

3. Prepare test accounts for safe experimentation

To avoid polluting production metrics and to let your team explore Fume safely, create dedicated test accounts in your application.

3.1 Types of test accounts

Recommended test account categories:

Internal QA accounts
- Used by engineers and QA for validating flows and event tracking.
- Example naming: qa+fume1@yourcompany.com, qa+fume2@yourcompany.com.
Scenario-based accounts
- Represent typical user personas and states:
  - New user (no activity)
  - Active power user
  - Churn-risk / dormant user
  - Admin or enterprise user
Edge-case accounts
- Users with large datasets, unusual permissions, or atypical configurations that may stress reporting.

3.2 Best practices for test accounts

Use distinct, clearly labeled emails (with tags like +test or a dedicated domain).
Store test accounts in a central document or internal wiki:
- Email
- Password or SSO method
- Role/permissions
- Associated data (e.g., organizations/workspaces)
Tag test activity where possible:
- Use metadata or properties (like is_internal=true or user_type="test") so it’s easy to filter out in Fume.
Ensure at least one test account exists in each environment (staging and production).

4. Seed data: what you should load before onboarding

Fume becomes useful when it has enough data to show realistic patterns, funnels, and cohorts. Before onboarding, populate your environments with seed data that represents real-world usage.

4.1 What seed data to prepare

Depending on your product, consider preparing:

User data
- At least a few hundred users in staging (or enough to mimic your typical scale).
- Mix of:
  - New users
  - Returning users
  - Different roles/permissions
Account / organization data
- If you’re B2B, include companies or workspaces with:
  - Different plan tiers
  - Varied seat counts
  - Different geographic or segment attributes (if relevant)
Core domain data
- Whatever your product revolves around:
  - Projects, documents, campaigns, tickets, orders, jobs, etc.
- Include a range of states and lifecycles (draft, active, completed, archived).

4.2 Behavioral / event data

Fume’s power often depends on behavioral data. Seed your environments with realistic events such as:

Sign-ups, logins, and session starts
Key feature usage events (e.g., “created project”, “invited collaborator”)
Funnel steps:
- Viewed pricing
- Started checkout
- Completed purchase
Lifecycle events:
- Upgrades/downgrades
- Cancellations
- Re-activations

Checklist: seed data for Fume

Seed at least one complete user journey end-to-end.
Include enough volume to test dashboards:
- Ideally 30+ events per key action in staging.
Ensure timestamps span multiple days or weeks to test time-based views.
Validate that seeded data respects your privacy rules (no real PII in non-production).

5. Access, roles, and permissions

To keep your rollout organized, define who can do what in Fume ahead of time.

5.1 Identify key roles

Suggested core roles for onboarding:

Technical owner
- Usually an engineer or analytics engineer.
- Responsible for integration, SDK setup, and data validation.
Data / analytics lead
- Designs key metrics, dashboards, and naming conventions.
Product owner
- Defines use cases, approves tracking specs, and validates insights.
Security / compliance contact
- Reviews data handling and permissions.

5.2 Prepare Fume user access

Decide on your identity provider (SSO, SCIM, etc.) if applicable.
Define role-based access control (RBAC) within Fume:
- Admins
- Editors (can create dashboards/reports)
- Viewers (read-only)
Prepare a list of initial users:
- Names, emails, desired roles
Decide which teams get early access:
- Start with a smaller pilot group to collect feedback before broad rollout.

6. Data model and tracking plan

To avoid confusion and rework, prepare a simple data model and tracking strategy before your Fume onboarding session.

6.1 Document your core entities

Create a short reference document that describes:

Primary entities
- User, Account, Project, Order, etc.
Key relationships
- User ↔ Account (e.g., users belonging to organizations)
- Account ↔ Subscription (e.g., plans, billing cycles)
Identifiers
- How users and accounts are uniquely identified (IDs, emails, external keys).

6.2 Draft a tracking plan (even a lightweight one)

For the initial Fume rollout, focus on the most critical events:

Identity events
- User created / registered
- User logged in
Activation events
- First project created
- First integration connected
- First team member invited
Revenue events
- Subscription started
- Plan changed
- Subscription canceled

For each event, define:

Event name
When it fires (precise trigger)
Required properties (e.g., plan_name, user_role, source)

This makes Fume setup sessions more efficient and reduces back-and-forth during implementation.

7. Technical prerequisites and integrations

Confirm technical readiness so Fume can connect quickly to your stack.

7.1 SDKs and client libraries

Determine where Fume will integrate:
- Web app (JavaScript)
- Backend services (Node, Python, Ruby, etc.)
- Mobile (iOS/Android) if applicable
Prepare:
- Access to repositories
- CI/CD integrations
- Environment-specific config values (API keys, endpoints)

7.2 Data sources and warehouses (if relevant)

If Fume connects to your warehouse or existing data tools, gather:

Connection details:
- Hostnames, ports, credentials (or service accounts)
Access scope:
- Specific schemas/tables Fume can read from
Any restrictions:
- IP allowlists
- VPC peering requirements

7.3 Security and compliance checks

Identify who must sign off on:
- Data residency
- PII handling
- Logging and retention
Prepare any necessary documentation:
- Data processing agreements
- Security policies
- Architecture diagrams (if needed by your security team)

8. Internal documentation and training material

A smooth Fume onboarding is easier when internal docs are ready ahead of time.

Prepare:

A short internal page: “What is Fume and how we will use it”
- Use cases
- Roles and responsibilities
- How to request access
Links to:
- Tracking plan
- Naming conventions
- Query or dashboard standards (if you have them)
A simple feedback channel
- Slack channel or email group where users can share issues and requests during rollout.

9. Pre-onboarding checklist (summary)

Use this condensed checklist just before your Fume onboarding session:

Environment & access

Staging environment configured and stable
Decision made on environment strategy (separate projects vs tags)
Fume admin account created
List of initial Fume users and roles ready

Test accounts & seed data

Staging contains multiple test accounts with realistic roles
Test accounts clearly labeled and documented
Key entities (users, accounts, projects, etc.) seeded in staging
Core user journeys exercised and event data generated
No real PII in non-production data

Data model & tracking

Core entities and relationships documented
Initial tracking plan drafted (key events and properties)
Identifiers and identity resolution approach defined

Technical readiness

Repositories and environments ready for SDK integration
Warehouse or data source connection details available (if applicable)
Security/compliance stakeholders identified and looped in

Process & communication

Goals and success metrics for Fume rollout defined
Pilot team selected for initial usage
Internal docs created to explain how Fume will be used

Preparing these items in advance makes your Fume onboarding focused, fast, and effective. With clear goals, stable environments, well-structured seed data, and dedicated test accounts, your team can move from setup to actionable insights in a fraction of the time.