Before you start
Analytics should explain identity and growth behavior without weakening privacy or access boundaries. Retention, export, and depth depend on plan capabilities and the selected Project environment.
What you build
Useful analytics dimensions include:
- MAU and rolling usage windows
- auth success and failure rates
- session activity and revokes
- Project membership changes
- webhook delivery outcomes
- campaign sends and delivery state
- loyalty events and retention activity
- notification channel activity
Implementation steps
1) Choose the reporting scope in the console
Each metric should map to a Workspace, Project, environment, and time window. MAU is production usage in a rolling 30-day window according to pricing copy.
2) Separate sandbox and production
Sandbox analytics are useful for rollout checks, but production billing and enforcement should not be polluted by sandbox sessions or campaign tests.
3) Tie growth metrics back to identity
Campaign, loyalty, and notification metrics are most useful when they can be explained through the Lamba User, Project, membership, session, and event that produced them.
4) Control exports
Analytics exports should respect plan availability, audit the actor, and avoid including secrets or raw bearer tokens.
API coverage note
Use documented public APIs and webhook events for integration. When an analytics view is console-only, link users back to the console instead of inventing an unsupported export path.
Security and operational notes
- Do not use analytics aggregates as the only authorization check.
- Apply retention boundaries before showing historical rows.
- Keep anomaly and failure signals tied to trace IDs where possible.
Related docs
- Plan Limits:
/docs/pricing/limits - Campaigns:
/docs/growth/campaigns - Loyalty:
/docs/growth/loyalty