Operating Dashboard — Data Access Summary
What this is
Pear's leadership needs a daily view of the business — usage, growth, Vibe, devices — without pulling Carson off the product to build it. Cadence is building an operational dashboard on top of the data Pear already has. Carson isn't asked to build or maintain anything. All we need is one read-only access point, and his call on the best source.
The prototype, live today
This is what it looks like
Illustrative data, built on Pear's real visual identity so it's a true preview, not a mockup from a template. The real build swaps this placeholder data for live numbers from whichever access point Carson picks below.
Numbers shown are illustrative example data, clearly labeled on the page itself — not a count of Pear's real users.
How it works
Mechanics
- Once a dayA scheduled job reads the numbers below and refreshes the dashboard. It never writes to Pear's systems.
- Aggregates onlyWe pull counts and averages, never individual user records or raw wearable data.
- Two layers of securityCredentials are stored as encrypted, write-only secrets — no one can view them after entry, and they're regenerated on any move. The dashboard itself sits behind a password-protected URL.
- Pear owns itThe plan is to build inside Pear's own GitLab and Cloudflare under an ops project, with Miller added as a user.
The data points
What the dashboard pulls
| # | Data point | Our best guess at the source | Access point |
|---|---|---|---|
| 1 | App opens / active users today | PostHog events | Carson to confirm |
| 2 | Monthly active users, 120-day trend | PostHog | Carson to confirm |
| 3 | Average Vibe score today (company-wide) | Pear database (likely not in PostHog) | Carson to confirm |
| 4 | Users by device (iOS / Android) | PostHog person properties | Carson to confirm |
| 5 | Users by wearable (Whoop, Fitbit, Garmin, Oura) | Pear database (connected integrations) | Carson to confirm |
| 6 | Stretch: city-level Vibe map | Pear database, city-level location, aggregated only | Carson to confirm |
Four questions for Carson
What we need his call on
- PostHog API, direct database, or both?For a once-a-day pull, which is simpler and safer on your side? Our default guess: PostHog for usage (1, 2, 4) and a read-only database view for Vibe and wearable data (3, 5, 6). Happy to go whichever way you prefer.
- What kind of credential?For example, a read-only PostHog personal API key plus the project ID, and/or a read-only database user limited to a few views you define.
- Anything that must not leave the database?We only need aggregates. If any field is sensitive (health data, PII), tell us and we'll stay away from it.
- Where should it live?An ops project in Pear's GitLab + Cloudflare, with Miller invited. Any conventions or guardrails there we should follow?
Definition of done
What V1 looks like
The data points above are live on a Pear-branded dashboard, refresh daily, sit behind a password, and run on Pear-owned infrastructure. Once access is set up, Carson's involvement ends.