Any launch of an installed app, including the first one.
| Field | Value |
|---|---|
| Name | app_launch |
| Severity | 9 (INFO) |
| Written by | .NET, Tauri and Python, with lifecycle tracking on. |
| Turned off by | Lifecycle tracking is off unless you ask for it, so this is written only if you turned it on. |
Once per run, at start-up, after app_install on the first run and after session_start on .NET and Tauri.
A launch is not a visit and not a person. It is one process starting on one installation, which is what makes it worth counting next to installs: the ratio between them is retention, and it is a ratio you can read without anybody being identified.
The entry is queued, not sent. A desktop client writes to a durable queue and uploads later, so a launch on a laptop that is offline all week arrives on Friday carrying Monday's timestamp, and every board buckets it on Monday. That is the single most common cause of a number that looks wrong and is not.
None of its own. The entry is the fact that it happened, and what it carries is what every entry carries.
Every entry also carries the resource its client sends once per batch: session.id, user.id once you have called user(), and the rest of the list on the overview. Anything you pass yourself lands in the same map, and your key wins on a collision.
A widget is a filter, a group by, an aggregate, a time bucket and a limit. These are those five parts written out, and every one of them is something you can build yourself.
| Question | The query |
|---|---|
| Launches per day | Name is app_launch . count of entries . bucket by day |
| How many installs are still running it | Name is app_launch . count of uniques . bucket by week |
| Which build people are on | Name is app_launch . group by service.version . count of uniques |
| Whether an old version lingers | Name is app_launch . service.version is 1.4.0 . count of uniques . bucket by week |