Startup Metrics that Tech Entrepreneurs need to know

. Metrics can be used by firms to make more objective decisions based on data. Software startups in particular are characterized by the uncertain or even chaotic nature of the contexts in which they operate. Using data in the form of metrics can help software startups to make the right decisions amidst uncertainty and limited resources. However, whereas conventional business metrics and software metrics have been studied in the past, metrics in the specific context of software startups have not been studied. In this chapter, we present the results of a multi-vocal literature review to offer you 118 metrics practitioner experts think software startups should measure. These metrics can give you ideas for what your startup should measure.


Introduction
Metrics are data that can be used to measure objects or phenomena. We use various metrics every day, from weighing objects at the store to driving at certain speeds with our cars. Even seemingly qualitative data can be made into metrics by quantifying it. For example, so-called Likert scale surveys are used to convert opinions into numerical values by presenting the responders with statements they are to either agree or disagree with using a numerical scale. However, while data is valuable in supporting decision-making, in the everyday practice manager intuition is still just as important for strategic decision-making in organizations [26]. We argue that though manager intuition can be powerful, using data to support it can make it even more-so. This has been emphasized by the rising value of data in the past few decades. Firms across industries have taken an interest in collecting and analyzing data in order to improve their business based on e.g. customer behavior on their website.
The idea of Big Data [47], a term coined in the 2010s, further highlighted the importance of data. The big data discourse urged companies to gather any and all data even if they did not necessarily have any use for it right there and then. These vast amounts of data, then, could be analyzed later in search of various correlations, especially out-of-the-box ones that may not have ever occurred to anyone without access to such large amounts of data.
Software startups, just like mature organizations, can utilize metrics to make decisions or to track progress. As they typically operate under a lack of resources and in particularly uncertain contexts [44], metrics can help startups make the right decisions at the right time. However, based on past survey data, we discovered that half of the responding 4000+ software startups in fact did not use metrics at all. 41% of the startups felt that it was too early for them to use metrics. Out of the remaining 59%, 16% felt that they did not have the resources to track metrics or that doing so would not benefit them, and another 14% tracked them but reported that they did not use them to support decision-making.
Motivated by this data, we sought to give software startups ideas for what metrics they could use. In this chapter, we present a list of 100+ metrics for Software Startups that we compiled by studying practitioner-oriented literature (e.g. online blogs, articles interviewing experts etc.) discussing metrics for software startups.

Expert Opinions: What Should Software Startups Measure?
In utilizing metrics, software startups combine various types of metrics. They can utilize conventional business metrics, as well as business metrics more specifically aimed at startups, as well as software-related metrics including website metrics. Across different life cycle stages (e.g. those proposed by Wang et al. [48]), different metrics can be important for software startups. For example, conventional financial metrics are not as relevant for early-stage startups that may still be in the process of acquiring their first customers or that are still calculatingly running a deficit for the time being. A more relevant metric in such a situation could be to simply measure the amount of remaining expendable capital. Through a multi-vocal literature review (described in second to last section of this chapter), we compiled an extensive list of 118 metrics for software startups. Much of the literature reviewed for this study consisted of short "n metrics your startup should measure" types of lists. As a result, there was a considerable amount of overlap in the results. This does, however, point to there being some consensus among practitioner experts as to which metrics are particularly interesting or important.
These 118 metrics are divided into three separate categories in this section: business metrics, user and customer metrics, and software engineering metrics. Each category will be presented separately and discussed in detail in the following sub-sections.

Business and Financial Metrics
Business and financial metrics, here, refer to metrics related costs and revenues. Business and financial metrics are largely metrics that communicate the current situation of the business using various monetary indicators. The business and financial metrics presented here are rather universal metrics used by small and large businesses alike, as well as startups. However, metrics that could be considered to be business metrics but which are closely related to the users or customers (e.g. average life-time value of the users) are considered to more importantly be user and customer metrics, which are discussed and presented in the following sub-section.  [12] Transactions abandoned before completion Ad Inventory [12] Total views of each ad in a time period Ad Rates [12] Value of each ad. inventory Annual Contract Value [13,17,22] Avg. annualized revenue per customer contract Annual Recurring Revenue [13,22,41] Predictable revenue annually (e.g. subscriptions) Annual Run Rate [13] Projected annualization of monthly recurring revenue Avg. Revenue per User [13,15,25] Avg. revenue per user over a time period Avg. Revenue per Customer [13,17,25] Avg. revenue per customer over a time period Billings [13] Current quarter revenue plus deferred revenue from previous quarter Breakeven Analysis [3] Analysis to determine the point where revenue covers the costs of receiving it Burn Rate [8,15,18] Rate at which available capital is used Campaign Contribution [12] Added revenue from an ad campaign Capital Raised to Date [23] Amount of investment capital raised in total Cash Flow Forecast [3] Forecast of financial liquidity in a period of time Cash on Hand [19] Available capital Committed Weekly Recurring Gross Profit [45] Percentage increase in profits weekly committed recurring profit Compounded Monthly Growth Rate [13] Avg. % growth per month since inception, or another start point for measuring. Cost of Goods Sold [23] Cost of products or services sold (e.g. hosting) Customer Acquisition Cost [3,7,8] Average cost of acquiring a paying user Customer Acquisition Cost to Life-Time Value Ratio [11,30] Customer Acquisition Cost vs. Customer Lifetime Value Customer Concentration [13,31] Revenue from largest customer vs. total revenue Customer Retention Cost [25] Amount of spending on customer retention Deferred Revenue [13] Revenue received in advance of earning it Fixed vs. Variable Costs [3] A measure of total spending split by source Gross (Cash) Burn [13] Monthly expenses and any other outlays Gross Margin [7,13,15] Total revenue compared to cost of goods sold Gross Profit [13,17,22] Total revenue minus cost of goods sold Market Share [50] Market Value [50] Monthly Cash Burn Rate [13,30] Monthly Recurring Revenue [10,11,13] Monthly predictable revenue (e.g. subscriptions) Month-on-Month Growth [10,13,17] Average of monthly growth rates Net (Cash) Burn Rate [13] Gross cash burn vs. revenue in a period of time Number of Transactions [39] Number of transactions made in a time period Operation Efficiency [15,18] Comparison of firm expenses by source Payback Time [25] Time to recoup from an expense via revenue Payment Failures [45] Number of failed transactions from users Platform Risk [13] Dependence on a specific platform or channel Profit Margin [17,25,30] Revenue minus cost divided by revenue for a product. Different ways to measure for e.g. Software-as-a-Service companies Return on Advertisement Spending [7] Profits divided by advertisement spending Revenue [5,17,22] Total Revenue Revenue Growth Rate [41,43] Revenue Run Rate [11,15] Sell-through Rate [13] No. units sold in a time period in relation to the no. items in inventory at its beginning Time to Customer Breakeven [12,30] Time it takes to recoup from Customer Acquisition Cost Total Addressable Market [13,17,50] Total hypothetical market size Total Contract Value [13,17,22] Value of one-time and recurring charges

User and Customer Metrics
Understanding the users of a software is vital for a software company, just as understanding one's customers is vital for any business. Digital services offer unique opportunities for businesses to collect data from their users which can then help them better understand their needs. Instead of having to actively consult the users or customers, digital services make it possible to observe and track them as they use the service, making it possible to collect large amounts of data from the users without having to ask them anything. For example, Bounce Rate refers to the percentage of the visitors of a website that leave the site without performing any actions on it. It does not directly help one understand why they are leaving, but it can indicate that something is wrong with the website. Recording historical bounce rates, then, makes it possible to see if changing the website in various ways has a positive effect on the bounce rate -or not. Such metrics make it possible to understand users to certain extents even without directly communicating with them. Description of the Metric Acceptance Rate [12] Avg. no. invites accepted by new users Activation Rate [8,13,25] Number of visitors or users performing a specific action such as registering or installing Active User Growth Rate [12] No. new active users in a time period Average Time on Hold [12] Time user spends on hold when calling support Bounce Rate [8,40] Percentage of visitors leaving website quickly Churn Rate [1,15,17] Lost users or customers over a time period Click-Through Rate [12] Visitors that clicked a specific website link Content Creation [12] No. visitors that interact with website content Conversion Rate [1,8,17] No. visitors that become users or customers, or no. users that become customers. Customer Count [39] Total number of customers (paying users) Daily Active Users [9,11,13] No. users who use the software daily Daily Active Users to Monthly Active Users ratio [25] A more detailed measure of user activity Direct Traffic [13] Traffic coming in directly E-mail Conversion Rate [34] Number of recipients that e.g. became users E-mail Open Rate [34] No. mailing list members that open an email Frequency of Logins [17] Average frequency of user logins Frequency of Visits [25] Average frequency of visits to e.g. website Gross Churn Rate [13,37] Total users lost Intent to Use [28,34] Data indicating that a new user is about to start using the service. E.g. they imported custom data Invitation Rate [12] Avg. no. invites sent per existing user Launch Rate [12] No. downloaders that launched the software Leads [29] An estimate of prospective customers Lead-to-Customer rate [29] Number of leads converted into customers Life-time Value [3,7,8] The average total revenue a customer generates Monthly Active Users [8,9,11] No. users who use the software monthly Monthly Churn Rate [13] Lost users or customers per in a month Net Adds [12] Total new customers vs. cancellations Net Churn [13] New users gained vs. users lost Net Promoter Score [9,13,17] How likely users are to recommend service (survey) Network Effects [13] Effect of one user on the value experienced by other users (e.g. Metcalfe's Law) New Visitors [17] Number of new visitors Number of Logins [5,13] Logins per user over a period of time Organic Traffic [13] Unpaid traffic from e.g. Google search results Prospects [12] Number of users that might become customers Purchases [12] No. purchases made by a user in a time period Recency [21] Days since last visit of user Referrals from current users [8,27,31] How often current users refer new users Referral rate [1] Volume of referred users or purchases Registered Users [17] Total number of registered users Repurchase Rate [23] No. customers that made a purchase during the previous and current period of time Retention Rate [1,7,8] Percentage of users or customers still using the service after a period of time Retention by Cohort [13] % of original user base still using the software or conducting transactions in it Reviews Considered Helpful [12] Number of reviews considered helpful Reviews Written [12] Number of reviews written Session Interval [17] Average time between software use sessions Session Length [17] Length of average software use session Sources of Traffic [17,27,31] Source and volume of user traffic per source Time to First Purchase [12] Avg. time users take to become customers Total Ad Clicks [12] Number of advertisements clicked by visitors Total Number of Customers [8,32] Total Number of Users [5,50] Based on e.g. registered user accounts Traffic [1,5,18] Total number of website visits (non-unique) Traffic-to-Leads [1] Total traffic in relation to potential customers User Acquisition Rate [5,9] Total new non-paying users in a time period User Demographics [5,9] Avg. age, gender distribution, location etc.
Unique Visitors [11] Unique website visitors during a time period Viral Coefficient [11,13,32] No. new customers each existing one converts

Software Engineering Metrics
SE metrics, as discussed in the second section, comprise both process and product (or service) metrics. They thus include metrics both related to the development process carried out by the organization responsible for the development, as well as metrics related to the software in its operational life. They also include website metrics that are not considered user and customer metrics first and foremost.  [18,39] Time it takes to implement a new feature Downloads or Installs [22] Total amount of downloads or installs Innovation Metabolism [14] No. completed build-measure-learn cycles Load Time [9] Time it takes for software to start or respond to user commands Office Morale [5] How motivated the team is (diff. metrics) Stability [9] Frequency of crashes in software use Top Keywords Driving Traffic to You [12] Search terms used by visitors to find your site Top Search Terms [12] Both those that lead to revenue, and those that don't have any results. Uptime [40] Percentage of time software or website is available and operational

Social Media Metrics
Social media platforms such as Facebook are important for businesses looking to grow their visibility. It enables them to interact with users or customers and potential users through the platforms. For software startups, the way social media offers a cost-free way of potentially boosting the visibility of their service is highly valuable. Though it is possible to purchase paid advertisements on many of these platforms, it is equally possible to simply use the platforms to gain visibility free of charge by creating content on the startup's page on each platform. Though much of the potential success hinges on how interesting the posts of the company are seen as being by the general public on the platform, metrics can help you understand how successful your content there is. However, the experts did not place much emphasis on social media metrics in the literature we reviewed. Below are the metrics they discussed and recommended. How to Utilize These Metrics?
Any single metric will never solve all problems in all startups, and no single metric is as useful to every startup. However, tracking metrics helps you gain valuable data that you can then use to make decisions. Simply looking at your revenue does tell you something about how you are doing financially, but it will not tell you why. Furthermore, when used in unison, a combination of various metrics can tell you far more than any one metric alone can. For example, if you wish to understand how many users you really have, looking at the amount of total registered users you have only scrapes the surface of the truth. You can then measure how many (unique) Monthly Active Users (DAU) users you have to gain an understanding of how many of the registered users are actually still active. By then measuring Daily Active Users (DAU) you get more detailed information about how active the still active users really are. You can combine this with Cohort Analysis by splitting your users into groups based on when they initially created their accounts or began to use the service. How many of the users who registered more than a year ago are still active?
Having a basic understanding of your user activity, you can go into further detail by using more general-purpose user activity metrics. By looking at how often the users log in or use the software (session intervals), you can see how many times per month the monthly active users log in. While at it, you can track the duration of their session lengths. How long do they stay on your site or play your game?
Time spent logged in does not tell the whole story either. Do they actually do the things you want them to do (user engagement)? Track their actions in your service while they are logged in. If they are not doing the things you want them to do, maybe something needs to be changed in your software? You could even approach the users who do not perform certain actions with a brief survey upon logout.
In this fashion, you can use combinations of metrics to gain a deeper understanding of some aspect of your business. However, even single metrics can provide valuable insights. For example, merely by tracking Daily Active Users you are able to see how many users are logging in every day. If the number suddenly starts dropping the day after an update was deployed, something was likely wrong with the update. Perhaps the update made the software unstable on some operating systems. Had you not been tracking your user activity through DAU or other such metrics (or been receiving error reports from the potential crashes), you may have only noticed the problem as a stark drop in revenue at the end of the month.
Finally, it can be beneficial to understand what metrics help you better your business and what metrics your stakeholders are interested in. Metrics that are important for your software and your team may not be interesting to potential investors who are mostly concerned with being able to see that you can become a viable business (if you are not already). Thus, you may wish to consider utilizing different metrics for internal use and for communicating with stakeholders. As you grow, the different people in your startup may also become interested in completely different metrics related to their job in your startup. Metrics do not have to be organization wide.

Using Metrics: A Practical Example
Various real-world stories depicting metric usage in startups exist online, from books to blogs. Whereas the previous example was a theoretical one, we cite a blog article by Sindre Hopland on the itnig blog 1 in giving you a practical one from a startup called Quipu. Quipu is a B2B (Business to Business) software startup providing a billing Software-as-a-Service (SaaS) solution.
The Quipu team considered churn rate as one of their key metrics indicating their performance. The less customers a SaaS solution loses over time, the better, and for a B2B one, acquiring new ones is even more expensive than for a B2C (Business to Customer) software startup. However, in practice, a low churn rate was simply their target. The team utilized various other metrics to help keep the churn rates low.
In the case of Quipu, the CEO considered customer support to have been the most important way of keeping their churn rate in check. Early on, he handled it by himself. By dealing with customers hands-on, he was able to understand what they were having problems with. Additionally, he was able to discuss the product with them and ask for any improvements they might wish to see. This can be a valuable way of conducting user interviews that requires little setting up.
While data gained in this fashion is typically qualitative, understanding your users is always valuable. Another valuable source of qualitative data for the Quipu team was their unsubscribe feature. Upon cancellation, the team would be notified and would contact the customer before finalizing the cancellation. In some cases, the customer was experiencing problems the team was then able to solve, keeping the customer.
Aside from providing users support when they ask for it, Quipu actively approached their customers based on various metrics. As they provided a SaaS solution, they were able to utilize various metrics discussed in this section to track the actions of their users while they used the service. In doing so, they were able to pre-emptively contact customers who were struggling with their service. Using this data, they were also able to establish patterns. E.g. a user who created three invoices in their system was much more likely to stay as a customer.
This highlights an important lesson: it can be worthwhile to adopt the idea of big data even early on. Even if you have no immediate use for the data you are collecting, you can study it in retrospect to discover patterns that may turn out to be helpful for your company. Furthermore, this example showcases the way metrics are best used in conjunction. Though the churn rate was what they company was concerned with, they utilized a number of metrics and gathered various types of data to actually control their churn rate.

Related Academic Work: Software Startups and Metrics
Startups are studied across disciplines, primarily in various economic disciplines and in information technology ones. Though in software engineering we speak of software startups, many practitioners simply speak of startups while in practice referring to software startups. By definition, software startups are startups that use software to deliver value. A software startup does not have to sell software or even focus on developing software to be a software startup. Uber, for example, delivers its value through its software application and is thus a software startup. While not all startups are indeed software startups even using this definition, the majority of them nonetheless are. Furthermore, economic disciplines commonly refer to (software) startups as New Technology-Based Firms (NTBF) [2].
From the point of view of metrics, software startups are not entirely unique. Rather, metrics that can be considered relevant for software startups come from various different areas of metrics. Software startups can utilize common financial metrics such as Net Present Value (NPV) or Return on Investment (ROI) when communicating with their stakeholders. Similarly, they can look at typical software or website metrics such as uptime to determine the status of their service.
As software startups do, however, differ from mature organizations, metrics that are important to more mature organizations may not be relevant at all for an early-stage startup. Even software startups are highly likely to find different metrics relevant in different stages of their life-cycles, according to the stages proposed by Wang et al. [48]. After all, if you have no revenue yet, using revenue-related metrics makes no difference to you, although you can use them to make and communicate future revenue forecasts. In the following sub-sections, we will briefly discuss different categories of metrics that can be relevant for software startups, and which have been extensively studied in the past in various contexts and across scientific disciplines (e.g. [24]).

Software Engineering Metrics
Software startups can utilize generic Software Engineering (SE) metrics. More specifically, these SE metrics can be divided into product and process metrics [49]. Product metrics comprise metrics related to the software (e.g. uptime, load times) either during development or during its operational life. On the other hand, process metrics refer to metrics related to developing the software (e.g. development sprint duration) and are related to the development and operations team and their way-of-working [24].
Software Engineering metrics also be considered to include website metrics as websites are ultimately software [49]. For businesses whose product (service) is not directly accessed through their website as SaaS, website metrics can offer different insights into their business. In such cases, website metrics are also clearly separate from product or service metrics. For example, website metrics can be used to determine conversion rates: how many visitors ultimately end up downloading the product or registering on the website?
Conventional website metrics such as site uptime or bandwidth [46] are still relevant, even though assuring site uptime even during heavy traffic has become easier in the wake of technological progress. Consequently, the focus on website metrics has shifted more towards understanding how the users interact with the website [4].
Finally, it is worth noting that few Software Engineering metrics related to the process side of SE metrics were discussed in the literature reviewed for this study. This is likely a result from the fact that SE methods and practices utilized by startups and mature businesses are highly diverse [16], from ad hoc methods to various in-house methods and by-the-book methods [35]. Different methods such as Scrum use different inbuilt metrics (sprint duration etc.) and while these metrics are certainly applicable to any software startup utilizing these methods, they are not necessarily applicable to software startups not using that particular method. As such, if you are using a commonly used SE methodology or practice(s), you should consider looking into any metrics that are recommended to be used for measuring progress while using that method or practice.

Business and Financial Metrics
Though software startups differ from mature businesses, they can nonetheless still utilize various established business metrics. Business metrics are largely related to costs and revenues. By keeping track of your cost and revenue structure, you are able to have a better understanding of how your business is doing, and if costs need to be cut to stop making a loss, you know where to start. These types of metrics are also of interest to investors who want to see whether you can make a profit and keep growing your business.
However, especially early-stage startups are different from mature organizations in this regard as well. A newly-founded startup may not even have any revenue to speak of yet. Thus, they might be far more interested in measuring their Cash Burn Rate and Cash-on-Hand to understand their current situation, as opposed to conventional business metrics such as Net Present Value [38]. They may utilize business metrics to make forecasts, though, and many investors are indeed interested in seeing estimates for e.g. future revenue streams and how they can change based on different potential pricing models for the startup's service.

Usability Testing, Usability Metrics, and User Experience
Involving the user in the design of software was something advocated for in the Agile Manifesto when Agile Software Development (ASD) began to take root in the late 1990s. By involving the user, it was argued, it would for be possible to better understand what they want, and it would, for example, make it possible to change the software during development to better match user needs as they emerge. This can be highly beneficial as it is much cheaper to make larger changes to a software service during development than during production or operation.
In practice, this typically means having a potential user test some version or a prototype of a software while either being observed or by self-reporting their use. There are different protocols for how the tests should be carried out, but generally the idea is to have a user use the software independently. If they struggle to get something done using the software, the observer, if one is involved in the test, will then typically step in to help them so that the test can continue without causing too much frustration to the subject. In this fashion, it is possible to see how people interact with the software in practice and what kind of difficulties they face while using it. They may ask for features that do not presently exist or they may end up being confused about something that you felt was very intuitive. This is still a valid approach used today, although recent developments have seen the user focus shift towards indirect user involvement as opposed to direct user involvement. Rather than asking users anything directly, many software companies choose to collect data of the users of their software while they use the software and make changes on their software based on how the users use it. While this is a much less resourceintensive approach to understanding one's users, understanding the why behind the actions of the users requires more effort as you cannot ask them directly.
Usability testing has been widely studied in the academia and various guidebooks for involving the user into product design exist. In terms of usability testing, startups can arguably use the same methods as more mature organizations and thus we do not discuss them in-depth here. If you are curious to read more about usability testing, Jakob Nielsen for example is a high-profile author for website usability.
Though these categories of metrics are well-established and have been studied and used extensively in the past, little literature discussing these metrics from the point of view of startups exists. In this chapter, we thus discuss them from the point of view of startups by presenting the opinions of various practitioner experts on what startups should measure.

Methodology: How Did We Gather This Data?
The metrics presented in this article were compiled through a multi-vocal literature review of mainly practitioner literature. We conducted the literature review in three steps: (1) we reviewed literature written by high-profile experts (e.g. Eric Ries); (2) we carried out Google searches to find opinions of less high-profile experts; and (3) we reviewed sources the authors mentioned or cited in their texts For the google searches, we followed a protocol in order to conduct the review in a systematic fashion (as opposed to, so-to-say, just googling around). We used the following search queries to find literature: "software startup metrics", "startup metrics", "startup metrics list", and "startup what to measure". Out of the results retrieved in this fashion, only hits that fulfilled the following criteria were included into this study:  Not a clear advertisement (e.g. a firm writing a blogpost to recommend their own data analytics tool)  No unclear metrics or vague groups of metrics (e.g. "look at your sales")  Text documents only (no videos etc.)  Only stand-alone documents written under real names (e.g. no Reddit posts)  Only publicly available documents; not behind a pay-wall or registration  Only general-purpose metrics (e.g. not e-commerce metrics only)  Not a duplicate result already reviewed

Conclusions
In this chapter, we discussed metrics from the point of view of software startups. To give software startups ideas for what to measure, we compiled 118 metrics from literature (books, blogs, articles etc.) written by various practitioner experts such as investors or startup incubator representatives. These metrics were divided into three categories: (1) software engineering metrics, (2) business and financial metrics, and (3) user and customer metrics.
Based on the data we gathered, we cannot make any sweeping claims as to what the best thing for your startup would be to measure. Different metrics are important for different software startups for different reasons. An early-stage software startup that has no users cannot measure user activity, and a B2B startup has far fewer customers than a B2C one. Taking this line of reasoning even further, metrics specific to your service may ultimately be the most important ones for your startup. If you are developing and operating an online game, you may be most interested in tracking how many of your users perform an action specific to your game every day after logging into it.
It can also be relevant to differentiate between metrics that are relevant to your startup team and metrics that are relevant from the point of view of your stakeholders. As software startups largely operate under very limited resources and are consequently reliant on outside funding especially early on, satisfying investors and potential investors is also important. While metrics related to tracking user behavior inside the software may be the most important ones for developing the software further, especially non-technical investors are likely to be far more interested in metrics directly related to current revenue and future revenue forecasts.

Key Take-aways
 Metrics help you make decisions based on data and not just intuition  Metrics can and should be combined to gain a more in-depth understanding of your business  User and customer metrics are the most important metrics, although B2C and B2B startups should approach them differently  Software-as-a-Service services let you track your users as they use the service online. Use this to your advantage and gather data of their use habits in order to better understand them.  Do not focus on vanity metrics such as total registered users: alone they do not tell you anything of value, although when combined with other metrics they can still provide value. A better metric than total registered users would be e.g. Monthly Active Users that actually shows you how many people still use the service.  Differentiate between metrics for internal use and for stakeholder communication. Metrics that are very useful to your team may not be interesting at all to potential investors.  Consider using method-specific (e.g. Scrum) or practice-specific Software Engineering metrics if you are using some common method(s) or practices  Gathering data for later use in the spirit of big data can be valuable.
Even if you do not have an immediate use for the data you are collecting, analyzing it in retrospect can help you discover surprising patterns.