Installs, by where they came from
The source is recorded when the install is created and never changed, so attribution stays
honest. The breakdown covers the last thirty days; the total above it is every install since
you published.
Load failures
When your remote fails to load, the host draws a card with Retry and Report to vendor. An owner who presses Report sends the error, the stack, the page, your release checksum and the host version — no owner data. Reports land on your Runtime page, newest first, and the previous day’s are summed into a digest email to your vendor admins each morning with a count and the error you saw most. The reason is on the card. A bundle that exceeds the 8-second remote entry timeout readsremoteEntry.js timed out after 8s; anything else is the error your code threw as the host
mounted it.
Owner reports
An owner can report your extension from the install’s page with a note. A Tappify admin reads it, and you are told: the note, and whether it is open, reviewed or dismissed, appears on your Runtime page, and a notice reaches your vendor admins. A suspended extension stops loading in every host on its next install refresh, about a minute, and shows a card readingStarter is temporarily unavailable. The rest of Tappify is unaffected.
Telemetry you declare
snake_case names, flat properties, 60 events per minute per install. A name that
is not on the live release’s list is refused rather than stored, so declare it and ship a
release before you send it.
The Runtime page’s event table counts the last thirty days by event type, which puts every
telemetry event on one row; the per-name breakdown arrives with the metrics below. The
owner’s own install page lists that install’s recent runtime events.