Software normalization is a SAM process that aims to remove irregularities in software titles so that they converge to a single publisher, product title and version. This will enable you to manage licenses more easily.
Normalizing your software data is essential to getting accurate, quality reports needed for Software Asset Management.

The problem in software normalization is that there is so much variation in these fields that the normalization process has never resulted in satisfactory results for quality reporting, until now.
If you’re frustrated by the lack of normalization in tools like SCCM or Lansweeper, or unimpressed by the normalization from Snow of Flexera, keep reading. AssetLabs normalization and categorization is miles ahead of what you might be accustomed to.
AssetLabs Software Normalization, Categorization and License-type identification is available for any tool such as SCCM, Service Now, Lansweeper, Kace, Tanium, Altiris, Solar Winds and more.
Software Normalization Approaches
Today, many SAM tool providers still maintain a one-to-one brute-force method of exact record cataloging. Due to the high variability in software titles, this approach has never achieved a significant level of confidence, and requires costly human effort. Even today, many of the more-popular SAM tools still struggle to maintain a 50% normalization success rate.
AssetLabs approaches this 20 year old problem of software normalization from a different perspective. We have architected proprietary methods in which every software title has no choice but to be normalized.
Unique to AssetLabs is the Productline. This is a new SAM data element that represents a version-less product title that belongs to a publisher in which all past, present & future versions of a product can fall into and automatically adopt the metaproperties of its parents. For example, Excel XP, Excel 7 and Excel 2010 are all child versions of the Microsoft Productline of Excel. More importantly, the Productline inherently declares and maintains the normalization requirement for all current and future versions of that product discovered. As a result, AssetLabs is able to maintain a 100% normalization of all new software titles. AssetLabs’ ProductLine structure was adopted into the ISO-19770-2 architecture in 2012.
Normalization Examples
AssetLabs uses advanced algorithms to correct publisher names, malformed software titles, and extract versions from the software title. The result of our extensive 10-year software catalog combined with thousands of normalization rules results in the best software normalization on the market. Our world-class normalization is available in our Streamline service, available as a free trial.

Publisher Adoption
A common problem in the SAM world is the absence of key information in the expected fields. For example:
Raw Record
RawPublisher | RawTitle | RawVersion |
Microsoft Office Professional | 15.11 |
If you tried to report on products where publisher=”Microsoft”, you would miss this record (and potentially many others.)
Our engine automatically detects Publisher names in the title field using a catalog of 90,000+ publisher names and 20,000+ publisher Aliases (alternate names, acquisitions, name changes, mutations of names etc.) The publisher name is then automatically filled in to the normalized record and trimmed from the software title.
Normalized Result:
Publisher | Title | Version |
Microsoft | Office Professional | 15 |
No Publisher information at all
A more advanced technique exclusive to AssetLabs is the ability to identify missing publishers when the publisher name is absent in the raw record. Given our extensive catalog, we are able to intelligently insert publishers.
Example:
RawPublisher | RawTitle | RawVersion |
Acrobat | 18.0 |
By checking the uniqueness of the product called Acrobat, the product is then adopted by that publisher.
Normalized Result:
Publisher | Title | Version |
Adobe | Acrobat | 18 |
Version & Model Extraction
Versions are another attribute that are not commonly populated in the expected Version field, or incorrectly populated. We are able to extract any numbers from the product title and version field to create Version Candidates. All version candidates then go through a separate version algorithm which ranks the candidates to eliminate bad or unlikely versions and find the most likely version.
Ex.
RawPublisher | RawTitle | RawVersion |
Microsoft Office Professional 2013 v15.11 build4a | 1.00 |
Version Candidates:
v15.11 <= High Ranking version
2013 <= More likely a model, but in the absence of a high ranking version may be a version
1.00 <= Unlikely version
build4a <= build number
Publisher | Title | Version | Model |
Microsoft | Office Professional | 15 | 2013 |
The resulting normalized title has all version candidates stripped out to provide a clean title name, and the raw declared version “1.00” was changed to the more likely “15” version. In addition, 2013 is inserted as a model number. We can also use the model number as a lookup to insert a version when no version is present because our catalog knows that model 2013 of this Product-Line is version 15.
Vendor Specific Rules
Our advanced normalization even has rules that are vendor specific. For example, Oracle sometimes publishes Java versions as 1.x.yyy where X is the actual version and YY is the update number. Our engine automatically extracts this information to create proper versions as follows:

Title Noise
One of the most difficult aspects of normalization is removing “noise” from the title. Noise is considered any part of the title that creates a mutation from the actual title, preventing the title from converging to the proper productline. Examples are foreign language variations, build and revision numbers in the title, and “mojibake” created through the conversion of one type of character set to another (ex. UTF-8 to ANSI text)
In the following example, these 12 raw titles from Altova all converge to a single Product Line after removing the noise.

Because they all converge to a single Product Line, they automatically inherit the pre-established meta attributes of the parent:

Because the title has been normalized, we can add in all sorts of information automatically from our catalog such as license-type information, category information, and even end of support information.
In conclusion, you can see that Normalizing, Standardizing software information results in much better quality data. Better quality data results in better quality reporting. This is KEY in a good software asset management workflow.
About AssetLabs normalization catalog:
Founded: 2010
90,000+ Publishers
20,000+ Publisher Aliases
3 Million+ Software Products
Normalization speed up to 450,000 Records per second
100% Normalization Rate
For additional inquiries or for more information on AssetLabs, please contact us.