B2B analytics is a different discipline from B2C analytics. The user population is smaller, the purchase decisions are larger, the sessions are longer, and the behavioral signals that matter are different. A B2B buyer researching heavy-duty parts inventory is not comparison shopping the way a consumer is. They are trying to solve an operational problem, usually under time pressure, and the friction points in their experience have immediate business consequences.
This national aftermarket automotive distributor operated an invitation-only B2B ordering portal used by fleet managers, repair shops, and dealerships across the country. The portal had been in production for several years and had accumulated significant technical debt, including a partially implemented analytics setup that could not answer the questions the business needed to ask.
The Problem No One Could See
The platform's product and operations teams suspected they had a search and discovery problem. Customers would call the support line asking for products that the company carried, which suggested those customers had searched the portal and not found what they were looking for. But without analytics instrumentation on the search experience, there was no way to quantify the problem, identify which products were hardest to find, or understand how often zero-result searches were occurring.
The existing analytics consisted of basic page view tracking and a handful of conversion events around order completion. There was no behavioral data on how customers used the search and filtering tools, no visibility into which inventory attributes customers prioritized, and no way to segment the user population by account type or purchase history.
The business case for better instrumentation was clear: every search that returned zero results and led to a support call was a cost. Every order that a customer started and did not complete was lost revenue. The question was how to build an analytics layer that could quantify these problems precisely enough to act on them.
Designing the Measurement Architecture
The dataLayer Specification
The foundation of the implementation was a dataLayer specification that we wrote collaboratively with the client's development team over several working sessions. The specification defined every dataLayer push the portal needed to produce, including the exact key names, data types, and values expected for each one.
The specification had to account for data that lived in multiple systems. Product data came from the ERP. Inventory data came from warehouse management systems at three geographic tiers: local, regional, and national. Customer account data came from the CRM. Pulling these data sources together into a coherent dataLayer required careful coordination with the development team and several rounds of QA to confirm that the right data was arriving in the right format.
SKU-Level Inventory Tracking
The most technically distinctive element of the implementation was inventory tracking at the SKU level. Every product interaction event carried three inventory parameters: the quantity available at the customer's nearest local warehouse, the quantity available across the regional warehouse network, and the quantity available through the national distribution system.
This meant that when a customer viewed a product and did not add it to their order, we could determine whether the reason might have been zero local availability, even if national inventory was plentiful. It also meant we could analyze the relationship between inventory levels and conversion rates across different warehouse tiers, which gave the operations team data they had never had before about how inventory positioning affected order completion.
Search and Filter Instrumentation
Every search event captured the search query, the number of results returned, the filters that were active, and whether the customer refined their search after seeing the results. Zero-result searches were tagged with a specific event parameter that made them easy to filter for in reports.
The filter system was particularly complex to instrument because customers could apply multiple filters simultaneously and in any order. We built a filter state serialization approach that captured the full set of active filters as a single parameter on each search event, which made it possible to analyze which filter combinations were most common and which were most associated with successful order completion.
User-level account data was appended to every event through a user property that captured account tier, geographic region, and purchase frequency segment. This made it possible to slice all search and filter behavior by account characteristics, which turned out to be important because the search patterns of high-volume fleet accounts differed significantly from those of smaller repair shops.
What the Data Surfaced
The implementation went live and within the first two weeks produced findings that changed how the business thought about its catalog and its portal design.
The zero-result search analysis was the most immediately actionable. The Looker Studio dashboard ranked search queries by zero-result frequency and updated daily. The top of that list contained product names and part numbers for items the company stocked but had indexed under different naming conventions than customers were using. The catalog team made terminology adjustments to the search index and resolved a significant portion of the highest-frequency zero-result queries within a month of go-live.
The inventory correlation analysis revealed that products with zero local availability had substantially lower add-to-cart rates even when regional and national inventory was plentiful, suggesting that customers either did not notice the availability tiers or did not trust that regional fulfillment would meet their timing requirements. This finding informed a UX change that made fulfillment timelines more prominent on product pages.
GTM 360 and Enterprise Tag Management
The implementation used GTM 360, Google's enterprise tier of Tag Manager, which was appropriate given the complexity of the container and the organization's need for SLA-backed performance guarantees. GTM 360 also provided access to custom templates and server-side tagging capabilities that we used to reduce the number of third-party scripts loading directly in the browser.
The GTM container was organized into clearly labeled folders by function: eCommerce events, search and filter events, user property management, error tracking, and advertising pixels. Every tag included notes documenting its purpose, the developer who implemented the underlying dataLayer push, and the date it was deployed. This level of documentation was unusual for a container of this complexity but made the ongoing maintenance significantly more manageable.
Reporting Environments
We built three distinct reporting environments in Looker Studio. The operations dashboard focused on search and inventory analytics, surfacing zero-result queries, low-inventory product interactions, and fulfillment tier utilization patterns. The sales dashboard showed order pipeline metrics by account tier, geographic region, and product category. The executive dashboard combined revenue attribution, customer retention metrics, and portal health indicators into a weekly summary view.
The operations dashboard became the most actively used. The catalog team reviewed it daily and used the zero-result query list as a standing work item for search index improvements. Within three months of launch, the percentage of searches returning zero results had declined measurably, and support call volume for product location questions had dropped in the same period.
Key takeaway: For B2B portals, the most valuable analytics are often the ones that surface what customers were trying to do but could not. Zero-result searches, filter combinations that lead to empty results, and products viewed but never ordered are signals that direct you to the friction in your customer experience before that friction shows up in your churn rate.
Technologies Used
- Google Analytics 4 with custom eCommerce and behavioral instrumentation
- Google Tag Manager 360 with server-side tagging
- Custom dataLayer specification integrating ERP, WMS, and CRM data
- Looker Studio with three separate stakeholder dashboards
- Custom search and filter event architecture with state serialization
- SKU-level multi-warehouse inventory parameter integration
Facing a similar challenge?
Every engagement starts with a complimentary consultation. We will assess your current setup and tell you exactly what it would take to get the visibility you need.
Talk to TestedPath →