Package Telemetry Data
How package telemetry data collected from Umbraco installations is used to order packages
Umbraco installations that have opted into providing basic or detailed telemetry data will indicate which packages are installed. We use that information to order packages by "Most Active Installs".
We have two measures that we can use to rank packages by popularity:
- Total Number of NuGet Downloads (obtained from nuget.org)
- Number of Active Installs (obtained from CMS package telemetry over the past 14 days)
Both of these are available for website users to select when filtering the list of packages they are reviewing.
Currently, the "Total Number of NuGet Downloads" is used as the measure for "Most popular" packages shown on the Marketplace home page.
We plan to switch this in the near future to use the measure of "Number of Active Installs".
Umbraco installations that have opted into sending telemetry data will send information periodically to a central collection service. This may include information about packages that are installed.
On a nightly basis this information is aggregated and stored in the database that serves the Marketplace API and website.
Packages are identified in the telemetry service based on one of the following:
- The package name provided in a
- The name of the folder within
/App_Plugins/that the package creates.
This may not be the same as the NuGet package ID.
If not, please ensure to supply the name that will be found by the package telemetry in your
umbraco-marketplace.jsonfile, under the
AlternatePackageNameskey. For more details see the article on listing your package.
For example, a package may be registered at NuGet with
Umbraco.Community.MyPackageas the alias and create a folder at
/App_Plugins/MyPackage. The following should be added to the
umbraco-marketplace.jsonfile to ensure it's telemetry data is correctly allocated:
"AlternatePackageNames": [ "MyPackage" ],
Some packages may not have either of the two identifying methods available. This would normally be the case if the package is providing only server-side functionality, and is written purely in C#.
For these cases there's an option to add and register a class that ensures the name is set.
An example is shown here:
internal sealed class PackageManifestFilter : IManifestFilter
public void Filter(List<PackageManifest> manifests) =>
PackageName = "MyPackage",
The class needs to be registered as part of the application startup, via a composer or an extension method as shown here:
public static class UmbracoBuilderExtensions
public static IUmbracoBuilder AddMyPackage(this IUmbracoBuilder builder)