FlowgridDocs
Dashboard

Active Users (DAU / WAU / MAU)

Track daily, weekly and monthly active users by identity — each with their email and name attached — in three lines of setup.

How it works

An active user is a known person who did something in a given day, week or month. FlowGrid counts them by identity: whenever you identify a user or track a user authentication level event, the SDK emits an active_user signal carrying their userId, email and name. Your dashboard then rolls those up into DAU (last 24h), WAU (last 7 days) and MAU (last 30 days), plus a stickiness ratio (DAU ÷ MAU).

The only thing you have to do is identify your users with an email and name. Everything else is automatic.

One call — fg.setUser() (recommended)

Tell FlowGrid who is signed in, wherever your app knows it, and the SDK does everything on this page for you: identifies the user, completes a pending login/signup handshake, grants tracking consent, and emits the daily active_userping behind DAU/WAU/MAU. Every step is deduped inside the SDK, so it's safe to call on every render, mount or route change. Pass null on sign-out; undefined (auth still loading) is a no-op.

1// components/FlowGridBeacon.tsx — mount once in your root layout. 2"use client"; 3import { useEffect } from "react"; 4import { useSession } from "next-auth/react"; 5import { fg } from "@/lib/flowgrid"; // your FlowGrid.init() instance 6 7export function FlowGridBeacon() { 8 const { data: session } = useSession(); 9 useEffect(() => { 10 const u = session?.user; 11 // Safe on every render — consent, identify and the daily 12 // active-user ping are all deduped inside the SDK. 13 fg.setUser(u?.id, { email: u?.email, name: u?.name }); 14 }, [session]); 15 return null; 16}

The steps below are the granular API underneath — reach for them when you need more control (custom traits at identify-time, server-only flows, or auth events that your backend already emits — pass { authEvents: false } to setUser in that case).

Step 1 — Identify your users

Call fg.identifyUser() once you know who the user is. Always pass email and name— they're what lets active-user counts resolve to a real person and match your CRM contacts.

1// Tell FlowGrid who the user is. This writes the identity store, so the 2// person shows up as a "Known visitor" — attach email + name so active-user 3// counts resolve to a real identity (parity with your CRM contacts). 4fg.identifyUser("user_123", { email: "alice@acme.com", name: "Alice Smith" }); 5 6// …or identify up-front at init (also marks the returning user active): 7FlowGrid.init({ 8 webId: "wx_xxx", 9 apiKey: "pk_xxx", 10 user: { userId: "user_123", email: "alice@acme.com", name: "Alice Smith" }, 11});

Step 2 — Track auth (identifies + marks active for free)

The framework-agnostic auth helpers (works the same in Next, React, Vue, Svelte) identify the user and mark them active in one go. See the Signups & Logins guide for the full flow.

1// The auth helpers identify + mark the user active automatically. 2 3// Provider redirects away (OAuth / SSO / magic link): 4fg.markLogin({ method: "google" }); // before the redirect 5// …after the redirect resolves, when you know the user: 6fg.completeAuth(user.id, { email: user.email, name: user.name }); 7 8// No redirect (email + password): one call does everything. 9fg.trackAuth({ event: "login", userId: user.id, email: user.email, name: user.name });

Step 3 — Count returning users (optional)

Users who stay logged in and come back without re-authenticating still count as active. Call fg.pingActiveUser() whenever your app boots with a signed-in user — no throttling needed on your side, the SDK dedupes pings to once per user per day.

1// Count returning users who DON'T re-authenticate: call on app open, 2// whenever you have a signed-in user. Self-throttling — the SDK dedupes to 3// one ping per user per day, so calling it on every page load is free. 4fg.pingActiveUser(user.id, { email: user.email, name: user.name }); 5 6// On sign-out, clear the identity so a shared device doesn't cross-attribute 7// the next visitor to the previous user. 8fg.logout();

Architecture & use case

Every active-user signal is keyed on a resolved identity (userId + email + name) — the same key that powers Known-visitor recognition and CRM matching. That shared key is what lets a single event feed engagement and customer intelligence.

1SDK fg.setUser / completeAuth / trackAuth / pingActiveUser 2 │ emits active_user { userId, email, name, ts } 3 ▼ 4flowgrid ingest ──▶ Dashboard ──▶ Active Users (DAU / WAU / MAU + stickiness) 5 ▼ 6Pipes active_users (DAU/WAU/MAU + stickiness) 7 active_users_series (trend) 8 active_users_by_identity (who) 9 ▼ 10Dashboard tile + Custom dashboards + Customer Intelligence / CRM

What it tracks

MetricDefinitionPipe
DAU / WAU / MAUDistinct identities active in the last 1 / 7 / 30 daysactive_users
StickinessDAU ÷ MAU — how often the monthly base returnsactive_users
TrendActive identities per day / week / monthactive_users_series
Per-identityEach user's active-days, ping count, last-seen + email/nameactive_users_by_identity

Feeds into

  • Customer Intelligence — product-engagement is now part of each customer's profile: an MAU-but-not-recent user is a churn-risk signal; active-days feeds lifecycle/health scoring alongside deals and activities.
  • CRM — email is the join key to CRM contacts, so “last active” and frequency enrich the contact record next to the deal pipeline.
  • Known-visitor recognition — active users reuse the identity resolution (override → CRM → captured → forms), so anonymous UUIDs collapse into named people.
  • Custom dashboards — available as the Active users source for any KPI card, chart or table you build.

What you get

  • DAU / WAU / MAU — distinct identified users over rolling 1 / 7 / 30-day windows.
  • Stickiness — DAU ÷ MAU, a health signal for how often people come back.
  • Trend charts — the same counts bucketed by day, week or month.
  • Who's active — the actual people behind the numbers, with email, name, active-day count and last-seen.

No extra dashboard setup is needed — as soon as identified users are active, the numbers appear.