Tracking dependencies

Our approach to tracking dependencies involves comprehensive analysis of each repository and contributor. This process includes downloading the relevant repository for a single-repository contact or all repositories for a contributor. We then scrutinize common configuration files for signs of your technology's usage and examine commit timestamps to distinguish between new and existing users based on when your technology was incorporated.

Specifying your dependency

Begin by specifying your dependency. This could be anything typically defined in a configuration file or a package.json-like file that lists such dependencies. Our tracking capabilities extend to blockchain networks as well, where we look through standard deployment files for evidence of use.

Identifying files holding the dependency

We automatically search the following files for dependencies:

• package.json
• .config
• .yaml
• .yml
• truffle
• .toml
• network
• hardhat
• deploy
• go.mod
• composer.json

Feel free to extend this list by appending additional file names, each separated by a comma. While we do not typically recommend scanning markdown files to identify technology usage due to methodological concerns, our experience and manual cross-referencing have shown that this approach generates very few false positives.

Naming Your Tracker

Assign a name to your tracker. This feature is important as we are planning to introduce the ability to run multiple trackers within a single campaign, allowing for direct comparison of different datasets. For instance, you might compare how many of your users are also familiar with tools from competitors.

Deep fingerprinting

We call our method of tracking dependencies "deep fingerprinting" because we clone all repositories of a user and analyze each of them for signs of your dependency being used.

Understanding the meaning of each state

Deep mode:

• lead: Contributor or repository started using the dependency during the campaign period for the first time.
• new lead: Contributor or repository started using the dependency after the campaign period for the first time.
• customer: Contributor or repository was already using the dependency previous to the campaign start date and is still actively using it.
• lead (sleeping): Contributor or repository started using the dependency during the campaign period for the first time but has not been active over the 6 weeks preceding the date of the evaluation.
• new lead (sleeping): Contributor or repository started using the dependency after the campaign period for the first time but has not been active over the 6 weeks preceding the date of the evaluation.
• post-campaign lead (dashboard only metric): Contributors who started to use the dependency after the campaign period for the first time.
• customer (sleeping): Contributor or repository was already using the dependency previous to the campaign start date, and has been active after the campaign start but showed no activity over the 6 weeks preceding the date of the evaluation.
• lead (x): Contributor or repository started using the dependency during the campaign period for the first time but later removed it.
• new lead (x): Contributor or repository started using the dependency after the campaign period for the first time but later removed it.
• customer (x): Contributor or repository was already using the dependency previous to the campaign start date, and has been active after the campaign start but later removed it.
• inactive: Contributor or repository used the dependency before the campaign start date, but has been inactive since the campaign start date.
• churned: Contributor or repository used the dependency before the campaign start date, but removed it before the campaign start date.
• cold: Contributor or repository never used the dependency.

Light mode:

In light mode, the "campaign period" corresponds to the 6 weeks preceding the day of the evaluation.

The repository analysis regarding the dependency status remains the same, hence the same system as above applies. However, the timeframe and amount of repositories analyzed for users is too short/small to be as precise - hence for the user status, the following applies:

• active: The contributor used the dependency over the 6 weeks prior to the evaluation date.
• inactive: The contributor does not show any activity in a repository containing the dependency over the 6 weeks prior to the evaluation date.
• churned: The dependency was removed from the repositories to which the contributor committed in the 6 weeks prior to the evaluation date.

NB:

These insights are currently based on an analysis of:

• deep mode: A maximum of 25 repos per year & contributor since 2020
• light mode: An analysis of a maximum of 7 repos to which each contributor has committed to in the past 6 weeks.

In our closed beta, we also filter out repositories exceeding 100 MB in size, and private repositories.

Due to these current settings, some users may appear to be inactive when they are not.