In an age of digital transformation where data is a primary asset, having a clean and consistent view into customer relationships can be a competitive advantage. Linq provides Clients a clean and continuously maintained customer account hierarchy to derive accurate conclusions from their go-to-market data. In this blog post, we will outline the methods Linq uses to parse data and create these hierarchies to ensure confidence in the functionality of our product.
The diagram below shows the basic components and data flow of the Linq Hierarchy Manager Solution. There are five components to the Linq platform: our ingestion engine, the LinqIQ match processes, the Linq Hierarchy Manager, the APIs that allow Clients to leverage Linq’s data in their analytics or operational environments, and optional Linq Insights Modules that can help jumpstart analytical use cases. 
Configuration and Ingestion
When we begin working with you, our first task is configuring Linq to generate the hierarchy structure that matches how you go to market. In other words, how do you group Accounts within a global customer (i.e. by geography, by line-of-business)? As an example, the most common configuration we see is a combination of both geography and line-of-business, such as “North America – Commercial” or “EMEA – National Government.”
Once core configuration decisions are made, we map the Account and Customer fields from your source CRM and ERP instances to Linq’s standard data model and profile your source data to identify inconsistencies and challenges that the product may encounter.
We use the following approach to configure Linq:
- First, we identify and correct for any inconsistent data. For example, we may find that a Region field contains a mix of values such as North America, NA or NAC. We configure a set of aliases within Linq to normalize those values and apply select clean-up rules. Note that any aliasing or clean-up is only used internally by Linq.
- We configure Linq to utilize any existing linkages or hierarchy setup within your source systems. For example, we may establish a cross-reference field between an ERP Customer and a CRM Account.
- We also set configurations to isolate select Accounts from the main hierarchy. For example, in the profiling exercise we may find you have many Accounts with names such as “N/A” or “None” that may be in a CRM or ERP instance for historical purposes but should not be part of the active hierarchy. We will isolate those accounts so that they do not appear in the main account hierarchy. Additionally, we give the option of isolating any Accounts that use Freemail addresses.
- Finally, we tune Linq’s matching rules based on your data profile: adjusting fuzzy matching algorithm thresholds and updating rules on how to handle things such as leading and trailing values.
After analyzing the source data and configuring accordingly, it is time to run LinqIQ for the first time and generate the hierarchy.
The LinqIQ Approach
Since the Global Parent/Parent structure will match our configuration (for example, generating a Parent for each unique Region and LOB Classification combination) and the aliasing/clean-up configurations will ensure Accounts are assigned the correct Parent level groupings, we can now approach how Linq assigns Global Parent Groupings.
Linq uses an iterative bottom-up process, building clusters of Accounts that belong together. The first pass creates clusters of Accounts that have a direct match to Linq’s proprietary master data on global organizations, their subsidiaries, and the various names and internet domains used by those subsidiaries.
After the initial clusters are created, Linq utilizes the configured rules and algorithms to match the remaining single Accounts to an existing cluster or create new clusters. Once the clustering process is complete, Linq generates a Global Parent (Name and ID) corresponding Parents (Names and IDs), and the Global Parent/Parent combinations are ready with their assigned Accounts.
After the initial setup, new Accounts are ingested regularly (based on configured frequency), and Linq places them in the best spot in the Hierarchy. This process continues perpetually, effectively automating Hierarchy maintenance as Accounts are added, edited, or removed in Clients’ source systems.
Linq’s approach to creating hierarchies and organizing client data intends to make the process flexible to the various and dynamic needs of our clients while minimizing the often stressful barriers to correcting inaccuracies presented by more rigid systems.
Linq Customer Hierarchy Manager
The ingestion and LinqIQ processes run based on a configured frequency to continuously update the hierarchies that are established. However, despite the depth of rules and configurations, nothing is going to be perfect, and we want to ensure Clients have the flexibility to move specific accounts into the hierarchies that make sense based on their specific sales and marketing motions.
The Hierarchy Manager screens allow users to manage customer hierarchies, mark specific accounts as “approved” (and ensure they are in the same hierarchy position going forward), and manage workflows for data and account-level hierarchy decisions.
APIs
The Global Parent IDs and Parent IDs that Linq creates are the keys that enable deep analysis and new operational capabilities across multiple CRM and ERP systems. Details of these keys can be found in our earlier post here.
We continue to enhance our APIs to access the Linq data in various ways. As we add new functionality to the broader product, API enhancements will accompany those new releases, enabling access to new data and different output formats.
Our Clients continue to drive new and exciting use cases for the Linq data, and our client-led development approach will enable consistent support of those use cases over time. If you have any questions or interest in the Linq approach, we will be happy to share more about our solution, and we encourage you to contact us here.