Journal · 2026-07-28
How to read a usage brief without drowning in token counts
A useful brief can be read in one sitting. It names sites, waiting versus not, and the questions the logs still cannot answer. Token totals are a footnote.
Token counts feel precise. They are also easy to hide inside. Two sites can spend similarly and mean opposite things: one is a person waiting on a paragraph, the other is a job rewriting titles at 2 a.m.
When we write a brief, the first page is the inventory in waiting order. If a reader only has ten minutes, that page is the brief. Everything else is evidence.
The second thing to look for is the gap list. A report that does not admit what it could not see is selling certainty. If request identity is missing, the brief should say which rows are inferred from timestamps and which are observed. Inferred rows are still useful; they are not the same as counted rows.
Disputed items deserve their own heading. Engineering and product often disagree about whether a call is ‘really’ user-facing. We record both claims. A briefing is for settling that in a room, not for a report to pick a winner in private.
Ignore decorative comparisons with other companies. Your app’s composer is not a benchmark object. It is a control in a specific product with a specific audience. The useful comparison is last window versus this window, or expected sites versus observed sites.
If you are the person who has to take the brief to a wider group, resist translating it into a single health score. Scores flatten the waiting column into the nightly job. Take the inventory instead. People can argue with rows.
We keep language plain on purpose. If a sentence cannot be read aloud in a mixed room, it does not belong on page one. That is a writing rule, not a taste. The usage picture has to survive contact with people who will never read a trace.