Applications with Corbado Observe

Applications let you segment tracking data by product channel inside one Corbado Observe project, for example web, ios and android. Use applications when you want to compare authentication behavior across channels without splitting your analytics into multiple projects.

1. Default application behavior

Each Corbado project includes a default application automatically. You only need to configure applicationId when you want to split analytics by channel. If you only track one channel, you do not need to configure anything. Corbado Observe already has a default application for your project.

2. When to create multiple applications

Create separate applications when the user journey differs by channel, for example:

Web checkout login vs. native in-app login
iOS vs. Android passkey UX differences

3. Send application context

The Corbado Observe SDK supports applicationId in tracker initialization options (TrackerOptions). The SDK lowercases the value and stamps it as a tag on every flow start. You can pass application context in two ways:

Set applicationId once during initialization.
Pass applicationId as a tag on flowStarted() when the channel is only known per flow.

For SDK installation and setup, see Integrate custom events.

3.1 Configure `applicationId` globally

import { init, getTracker } from "@corbado/observe";

init({
  projectId: "<ProjectID>",
  apiBaseUrl: "<APIBaseURL>",
  applicationId: "web",
});

getTracker().flowStarted({
  flowName: "login",
  touchpoint: "account",
});

3.2 Set `applicationId` per flow

import { init, getTracker } from "@corbado/observe";

init({
  projectId: "<ProjectID>",
  apiBaseUrl: "<APIBaseURL>",
});

getTracker().flowStarted(
  {
    flowName: "login",
    touchpoint: "checkout",
  },
  {
    applicationId: "ios",
  },
);

3.1 Configure `applicationId` globally

<script>
  Corbado.init({
    projectId: "<ProjectID>",
    apiBaseUrl: "<APIBaseURL>",
    applicationId: "web",
  });

  Corbado.get().flowStarted({
    flowName: "login",
    touchpoint: "account",
  });
</script>

3.2 Set `applicationId` per flow

<script>
  Corbado.init({
    projectId: "<ProjectID>",
    apiBaseUrl: "<APIBaseURL>",
  });

  Corbado.get().flowStarted(
    {
      flowName: "login",
      touchpoint: "checkout",
    },
    {
      applicationId: "android",
    },
  );
</script>

Pick short, stable IDs such as web, ios and android. Avoid renaming IDs frequently so trend charts stay comparable over time.

4. Recommended naming strategy

Use one canonical ID per channel (web, ios, android)
Keep IDs lowercase and immutable
Avoid environment-specific IDs (for example web-staging) inside the same project

5. Environments: use separate projects

Use separate Corbado Observe projects for separate environments, for example:

One project for production
One project for staging
Optional additional project for development

This keeps environment traffic isolated and prevents non-production data from distorting production analytics.

6. Next steps

Continue with Flows to model complete auth journeys.
Continue with Decisions to track method choices within each application.

Overview

Get started

Custom events

Developer tools

Monitoring & alerting

Passkey Intelligence

Data access

Security & compliance

Event model

Applications with Corbado Observe

1. Default application behavior

2. When to create multiple applications

3. Send application context

3.1 Configure `applicationId` globally

3.2 Set `applicationId` per flow

3.1 Configure `applicationId` globally

3.2 Set `applicationId` per flow

4. Recommended naming strategy

5. Environments: use separate projects

6. Next steps

​1. Default application behavior

​2. When to create multiple applications

​3. Send application context

​3.1 Configure applicationId globally

​3.2 Set applicationId per flow

​3.1 Configure applicationId globally

​3.2 Set applicationId per flow

​4. Recommended naming strategy

​5. Environments: use separate projects

​6. Next steps

1. Default application behavior

2. When to create multiple applications

3. Send application context

3.1 Configure `applicationId` globally

3.2 Set `applicationId` per flow

3.1 Configure `applicationId` globally

3.2 Set `applicationId` per flow

4. Recommended naming strategy

5. Environments: use separate projects

6. Next steps