Learn from real use
See what happened—and be honest about what the data means.
Keep privacy-safe run records and summary data with the exact action version. Separate “it worked” from “people use it,” “it helped,” and “this release caused the change.”
Start with one run
See what happened first. Add the wider picture second.
Measure starts with the newest local run. The first question is simple: what happened, which action version ran, and what record supports that answer?
Summary data comes next when it helps explain the run. A result can lead back to Build or the next Audit without pretending that limited data proves everything.
What you can review
Keep each result with the action and version it describes.
Run records
The exact action and version, whether it worked, how long it took, and what started it when known.
What failed
Successes, failures, cancellations, and simple error groups without saving private inputs or content.
Use over time
Privacy-protected Apple summaries with clear dates, app builds, minimum counts, and reporting delays.
Business results
Optional, consented links to product results that stay separate from proof that the action merely ran.
Four separate questions
One run cannot answer everything.
A completed run can show that the action worked. By itself, it cannot show that people keep using it, that they got the intended result, or that a release caused a wider change.
Did the action finish?
Run records and privacy-safe success totals
RecordedIs this exact version being used?
Privacy-safe summary counts
LimitedDid the user get the intended result?
Approved product data
OptionalDid this release cause the change?
A controlled test and permission to use the data
UnknownWhere the data comes from
One timeline, with each source kept clear.
Local runs, Apple summary reports, outside tools, and optional business results can describe the same app action. They do not all prove the same thing.
Run records for the exact action version, result, time, and caller when known.
AvailablePrivacy-safe counts and success totals that may need a minimum amount of data and arrive late.
ImportMCP, API, or command-line records from a connection that has been tested.
Source recordedA business or user result from a separate, approved data connection.
Not connectedPrivacy by default
Record the action, not the person.
The local record works without a network connection. You control how long it is kept, how it is exported, and when it is deleted. Linking outside business results requires separate consent.
Read the Measure documentation- Stable action ID and exact version
- Result and a simple failure category
- Run time and app build
- Caller only when the system identifies it
- Approved categorical dimensions
- Raw inputs, searches, web addresses, or phrases
- Names from app data, contacts, or location
- Free-form errors or private content
- Stable user, device, or install identifiers
- Guessed caller or shortcut labels
Compare releases carefully
Notice differences without claiming one caused the other.
A difference between releases can point to the next question. It does not prove that the release caused the difference without a stronger test and the right consent.
Close the loop
Turn what you learned into the next product decision.
A run record can show a reliability problem, missing data, or an open product question. Send that finding into the next Audit with the action version and supporting record attached.
Plan what to measure
See what the action did. Keep the limits clear.
Choose what to record, what to leave private, and what each source can honestly tell you.