Metrics and telemetry (plain English)¶
This is the non-technical twin of the technical metrics map. It explains what WorkWingman counts, what stays on your machine, and what “user testing” changes. It does not invent promises that are not already written in product docs or code.
Why the app counts anything¶
Three different reasons, kept separate on purpose:
- Your job-hunt receipts — so you can see whether the app saved real effort on real applications (Value Metrics).
- User-testing learning — so the team can see how testers use modes, pages, and apply runs, and answer short skippable questions (WING-208).
- Your AI usage log — so when the app uses your AI keys or CLI tools, there is an honest record of calls (provider, model category, tokens when known) without storing your résumé or the model’s text.
There is also a business evidence ledger (separate markdown file) for claims like “people will pay” or “pilot worked.” That is not the same as the app’s event log.
What you see in the app: Value Metrics¶
Open Value metrics in the sidebar (the /metrics page).
It answers: was WorkWingman actually worth it for my hunt?
It tracks things like:
- Applications you confirmed you submitted
- How long automation was actually working (pauses while it waits for you do not count as “work time”)
- Estimated time saved as a range, with the smaller number shown first
- Responses, interviews, and offers alongside volume (so raw “apps sent” is never the whole story)
- Study links you opened inside the app (a click means “opened,” not “studied for N hours”)
Why the headline is careful¶
If the page only celebrated “how many applications,” it would reward spraying weak applications. So:
- The main number focuses on qualified applications (ones you submitted that also looked like a real fit).
- Time saved only banks on those.
- Choosing not to apply after fit analysis is treated as good judgment, not failure.
Everything on that page is meant to recompute from a local log on your machine. The design goal is: your receipts stay with you.
What “telemetry” means here¶
In WorkWingman docs, telemetry mostly means: small usage events such as:
- Which control you used (stable ids, not free typing)
- How long a page was active vs idle
- Whether you use Simple or Power mode
- When a live apply run starts or ends
- Short survey answers (chips or 1–5) or skips
Rules written into the design:
- No job titles or company names in these usage events
- No pasting your answers or résumé text into them
- Skips count — the app is not supposed to treat “answered the survey” as a success goal
The client batches these events to the local API quietly. If sending fails, the app is designed to drop the event rather than break.
Surveys¶
In user-testing builds, small one-question prompts can appear at certain moments (for example after switching mode or stopping a run). You can always skip. There are caps so you are not nagged endlessly (limits are documented in the testing spec).
Outside user-testing configuration, those survey triggers stay off.
AI usage: what is (and isn’t) logged¶
When the app calls AI through its single internal gateway, it records labels and numbers, for example:
- Which provider slot (not your secret key)
- Model name when known
- What kind of task it was
- Whether the call succeeded, came back empty, or failed
- How long it took
- Token counts when the provider reports them
CLI-based AI tools often cannot report tokens. In that case the log stores “not measured,” not zero. Zero would falsely look like free.
By design, that AI log has no place to put prompt text or model answers. Your documents are not supposed to land there.
This log is stored separately from the job-hunt / usage event log.
What stays local vs what can leave the machine¶
| Kind of data | Typical home |
|---|---|
| Value Metrics receipts and baselines | Local app data on your machine |
| UX telemetry events | Local event log; copied off-box only on special user-testing cloud builds |
| AI usage ledger | Local, separate file family |
| First-run onboarding milestones | Browser storage only (no upload path for that log) |
| Business “did customers pay?” claims | Written in the venture evidence ledger docs — not auto-inferred from clicks |
User-testing cloud builds can mirror accepted events into Google Cloud logs and a BigQuery dataset used for Looker Studio dashboards. That path is config-gated (UserTesting), stamps environment/tenant on the server, and is aimed at operators learning from testers—not at selling candidate data.
TODO(verify): exact retention time for cloud logs and who may open the Looker report.
What the app does not claim¶
- It does not claim that more clicks mean a better product or a better job hunt.
- AI metering does not yet turn usage into dollar savings on screen as a settled “we saved you $X” story (later work).
- Usage numbers alone do not prove people will buy the product; demand claims need their own evidence rules.
- Marketing language in one pitch doc still says “no telemetry” and mentions opt-in crash reports. That wording may lag the user-testing telemetry work — TODO(verify) which public sentence should win.
Crash reports¶
A pitch document mentions opt-in, redacted crash reports. A dedicated crash-report pipeline was not confirmed in the same code search that found Value Metrics and WING-208 telemetry. Treat crash reporting as TODO(verify) until that path is documented next to this page.
Where to read more¶
- Technical detail:
docs/technical/metrics-and-telemetry.md - Your receipts design:
docs/plain/value-metrics.md - AI efficiency promises:
docs/plain/byok-efficiency.md - Business evidence rules:
docs/business/venture-evidence-ledger.mdanddocs/business/metrics-strategy.md