app_install

When it fires

On the run that created the anonymous id, which is once per installation and never again. It is written before the launch entry of that same run.

Off by default, and that is deliberate rather than an oversight. A source has no kind, so a client cannot know whether an install and a launch mean anything where it is running: in a request handler they mean nothing at all. The application says.

It counts an installation, not a person. The anonymous id lives in machine-local storage, so one human on three machines is three installs, and that is the correct answer rather than a bug to fix. On Windows that means %LOCALAPPDATA% and never %APPDATA%, because a roaming profile would sync one id between machines and report three installs as one.

Attributes

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.

What it never carries

Nothing about where the installer came from. There is no download token, no landing page, no campaign carried across, and no join back to a file_download on your marketing site. That join was once the stated product here and was deleted rather than deprecated.

If you want to know which campaign an install came from, the only honest way is for your installer to carry something you chose and for your app to send it as an attribute you own.

Questions it answers

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.

See also

• app_launch
• file_download
• Identity