Skip to main content

Measure Flaggr console adoption with admin funnels, adoption cohorts, and experiment cycle-time analytics

Last updated May 31, 2026

Admin Analytics

Admin analytics measures how teams use the Flaggr console itself. It complements browser analytics: browser analytics measures your application experience, while admin analytics measures the flag workflow from discovery to activation.

Use it to answer operational questions:

  • Are users finding the flags they need?
  • How many users move from flag detail views to toggles or targeting rules?
  • How long does it take an experiment to move from start to decision?
  • Do teams return to newly created flags after setup?

Where to Find It

Open a project and navigate to Console > [Project] > Analytics. The tool launcher includes:

PageRouteUse it for
Admin Funnel/console/[slug]/analytics/admin-funnelConsole activation funnel and experiment cycle proxy
Adoption Cohorts/console/[slug]/analytics/adoption-cohortsWeekly create-to-view adoption cohorts

Both pages require project read access and use the same project isolation rules as the rest of the console.

What Gets Collected

The console records first-party admin events from the web app. Events are batched in the browser and posted to /ingest/admin-events.

AreaEvents
Navigationscreen_viewed, flag_list_viewed, flag_viewed, docs_viewed
Flag authoringflag_created, flag_deleted, targeting_rule_created
Activationflag_toggled, rollout_stage_advanced, rollout_autopaused
Experimentsexperiment_created, experiment_started, experiment_decision
Setupsnippet_copied, sdk_first_evaluation, auth_prompt_viewed, auth_prompt_completed
Reliabilitybackend_request_failed

Event properties are limited to primitive values such as strings, numbers, and booleans. Project identifiers, project slugs, flag keys, route names, app version, build number, and platform are included where available so analytics can be filtered by project and release.

Admin Funnel

The admin funnel turns console events into three workflow steps:

StepEvent logicMeaning
Flags indexscreen_viewedA user entered the console or flag workflow
Flag detailflag_viewedThe same user viewed a flag
Toggle or ruleflag_toggled or targeting_rule_createdThe same user activated a flag or configured targeting

Each step reports:

  • users: actors who reached the step
  • conversionRate: share of entry users who reached the step
  • dropOffRate: share that dropped from the previous step

The page also shows a cycle proxy based on the median time between experiment_started and experiment_decision events.

Adoption Cohorts

Adoption cohorts group activity by week. A cohort is considered adopted when a project creates a flag and then records a matching flag_viewed event for that flag in the same weekly bucket.

Each row reports:

  • createdProjects: project-week cohorts with created flags
  • adoptedProjects: project-week cohorts that returned to view created flags
  • adoptionRate: adopted cohorts divided by created cohorts

Use this page to check whether new flag setup leads to follow-up work instead of abandoned configuration.

Generate Local Test Data

Use the seed utility when you want realistic data for local bug bashing or UI validation:

npm run seed:consumer-analytics -- \
  --project-id proj_abc123 \
  --project-slug acme \
  --base-url http://127.0.0.1:3000 \
  --users 32

The command posts synthetic admin events to /ingest/admin-events and prints direct links to the admin funnel and adoption cohort pages.

To inspect the generated payload without writing data:

npm run seed:consumer-analytics -- \
  --project-id proj_abc123 \
  --project-slug acme \
  --print

Query via API

Admin analytics endpoints are documented in the Analytics API Reference:

  • GET /api/analytics/admin-funnel
  • GET /api/analytics/adoption-cohorts
  • POST /ingest/admin-events

All query endpoints require authentication and project access. If Postgres analytics storage is not configured, the API returns 503 Analytics not configured.

Next Steps