NetHunt Case
About the client
NetHunt CRM is a CRM system designed for managing sales and customer relationships. It combines every stage of the sales process, from collecting leads and communicating with them to handling deals, automating team workflows, and analyzing results. Companies in over 70 countries use NetHunt to manage customers, deals, and communication in one place.
NetHunt CRM’s customers include RozetkaPay, LOKO, uklon, mono, LIKI24, Parkovy Convention and Exhibition Center, Karpatia, Superhumans, Zakaz.ua, and Helsi. NetHunt also maintains dedicated localized websites for different markets..
A NetHunt CRM customer is not an individual but a company: it creates a shared workspace for its team and is billed for each user in it. Therefore, all analytics discussed below are calculated at the workspace level.
The Problem
When we began working with NetHunt, the company already had extensive tracking in place, among them server-side GTM, tracking for a wide range of GA4 events, and product events sent directly from the backend to GA4 using Measurement Protocol. Data was stored in several different systems and merged manually. UTM tracking parameters from a user’s first visit to the website were also stored.
Good analytics can’t rely on inaccurately collected data. That's why, whenever a setup already exists at the start of a project, we always conduct an audit to confirm it works correctly, or to detect data collection issues and suggest improvements to tracking.
The audit revealed that website analytics had gaps in traffic data. A significant number of browser events were not tracked correctly. We found duplicate events under different names, and overall inconsistency that made it hard to work with the large number of disparate events. Backend events required the most attention. GA4 attributes data received through Measurement Protocol in a specific way, and without valid session identifiers, all server-side events ended up in the Unassigned traffic channel, so they couldn’t be used for traffic source analysis.
Furthermore, the UTM parameters from each user’s first visit were retained, but referral and organic channels were missing, and analysis was only possible by first touch. This considerably limited campaign analysis for a B2B business, where users often have a long journey and may interact with the company through multiple channels before converting into customers.
Finally, a major business problem was that third-party systems couldn’t adapt to NetHunt’s specifics and analyze data at the workspace level, NetHunt's primary unit of analysis, because a NetHunt customer creates a workspace for an entire team rather than just one person. Consequently, one workspace could have several customer profiles, and the customer profile is Stripe’s primary unit. As an example, when one of these customers left a workspace, Stripe showed churn even though it was actually a downgrade. Similarly, when a new user was added within a workspace, Stripe treated it as a new customer with new MRR, while for the business it was an upgrade.
As a result, the team couldn’t answer several simple but important questions:
- How much monthly recurring revenue (MRR) does the company generate, and how does it change by customer type?
- How much revenue is expected in the coming months, so that costs and activities can be planned?
- Which marketing activities, and at which touchpoint, bring in customers who then become paying customers?
- At which step between visit and subscription do the most people leave the funnel?
What we did
We created a complete analytics system for NetHunt. Overall, it included two workstreams: correcting data collection issues on the website and creating reports that the team uses every day.
Fixing Data Collection from the Website and Backend
After the audit, we discussed and agreed with the client everything that needed to be tracked on the website and which data would be sent from the backend. Our tracking logic was to build an event system based on user intent* and include parameters that let you drill down into each event in more detail.
*Our task was to implement tracking for a large number of interactions on the website. In such cases, a separate event is often created for each individual action, for instance, one event for a CTA click in the header and another for a CTA click in the footer (a simplified example).
Such an approach leads to a huge number of event names that are extremely challenging to analyze in reports. For instance, building a funnel in GA4 that includes a step for CTA button clicks becomes difficult, because you have to specify literally every event name related to the intent to click a CTA.
With our approach, the event name represented the user's intent: for example, a button click, or opening, interacting with, or submitting any lead form. We captured various characteristics of the event as parameters, which can then easily be used to break down the data for more detailed analysis of a specific intent.
Using this approach and the collected data, we later built a report for analyzing onboarding survey responses.
The data collection setup is shown below:
The diagram above displays sample events only for clarity. In practice, we completely restructured event tracking to make everything coherent and easy to work with, and to track all the website actions that are relevant to analyzing how users interact with it.
As a result of this setup, browser events are sent to the web GTM container, then to server-side GTM, and then to GA4 and, if they are conversions, to advertising platforms as well. Sign-up and login events additionally send a user_id.
We then set up a connection between website events and backend events. During registration and login, server-side GTM saves the technical identifiers that GA4 uses to recognize users and their sessions. As a result, developers no longer needed to collect anything additional in the browser or run checks before sending each event. This is important because if a server-side request passes an identifier that GA4 cannot recognize, two separate, unrelated users will appear in analytics.
From the backend, developers send only the minimum necessary information: user_id and parameters from the database, such as the payment amount or subscription plan. The event doesn’t go directly to GA4. It is first sent to server-side GTM, which enriches it with the necessary session identifiers and only then sends it to GA4 through Measurement Protocol. This makes it possible for GA4 to attribute server-side events to a session, and consequently to a traffic source, so they can finally be analyzed in the interface.
Another important fix to the data transfer logic was modifying the value of the reserved user_id parameter: we sent the workspace ID in this field so that GA4 would calculate data at the workspace level, NetHunt’s main unit.
Identifying and Storing Traffic Sources in the CRM
This part also belongs to the data collection process, but it works separately from third-party systems such as GA4. We created our own solution that identifies the traffic source, including the first touch and the last non-direct visit. It determines the source following GA4's logic: it processes not only UTM parameters but also organic and referral traffic.
As a result, the client’s CRM now stores complete data on where a user first encountered the website and which source played the decisive role before they signed up for the product.
This data is valuable to have in the CRM, but it is mainly used to build marketing reports.
Storing Data in BigQuery and Building Reports
Alongside with improving data collection, we started loading data from all the necessary systems into BigQuery (a cloud-based data warehouse in Google Cloud) and setting up automatic updates.
We set up the native GA4 export and Data Transfer with custom queries for Google Ads. We also used Cloud Run functions to export data from Facebook Ads, data from the Stripe payment service, and exchange rates, since different systems stored data in different currencies. NetHunt is a global business that also receives payments in multiple currencies. To make analysis possible, we converted every payment to a common currency at the exchange rate for the specific day.
During data processing and modeling for future reports, we addressed one of the main business problems: unifying all calculation and attribution logic around the workspace entity. This gave the business what it needed to see its performance at the appropriate level, and we built three reports:
- Revenue Report: MRR and customer movement by type, along with expected revenue.
- End-to-End Funnel: a funnel from visit to subscription, broken down by responses to the onboarding survey.
- Marketing Attribution: the contribution of marketing channels and campaigns to registrations and payments across three attribution models.

Revenue Report: Accurate MRR by Workspace Type
As mentioned earlier, NetHunt’s payments and subscriptions are handled through Stripe, but Stripe calculates metrics at the customer profile level. Stripe has no workspace as a separate unit, so even a similar breakdown by customer type in its interface wasn’t appropriate for workspace-level analysis.
The report centers on MRR (monthly recurring revenue), the amount a customer pays per month for using the product. For a monthly subscription, MRR is equal to the paid invoice amount for the month of use. For an annual subscription, the invoice amount is split into 12 equal parts, and that amount is shown for each following month of use. For example, if an annual subscription costs 1,200, the report displays 100 for each of the following 12 months from the moment of payment. Based on the MRR value, we determine the workspace type.
The rules for categorizing workspaces by type are as follows:
- Customers or MRR: the total number of workspaces or total MRR in the selected month.
- New: the count of workspaces that made their first-ever payment, and their MRR.
- Existing: existing workspaces whose MRR in the current month was the same as in the month before.
- Upgrade: workspaces that moved to a higher plan and/or added new users, so their current MRR is higher than in the previous month. Upgrade ∆ is the amount by which MRR increased in the current month.
- Downgrade: the reverse of an Upgrade. These are workspaces that decreased their number of users and/or switched to a cheaper plan.
- Churn: NetHunt customers who stopped using the product, and their previous-month MRR, which the company lost as a result.
- Reactivation: customers that returned after they had stopped using the product, and their MRR in the month of reactivation.
- Growth: calculated as New + Reactivation + Upgrade ∆ − Downgrade ∆ − Churn. It shows the number of workspaces or the amount of MRR by which the business grew or shrank.
A quick look at the data immediately shows what a month was made of: whether the month was driven by stronger customer acquisition, lower retention, or customers moving to cheaper plans.
The demo report shows anonymized data to protect trade secrets, but visually it fully matches the original client report.
The demo is designed for desktop viewing, so it may be less convenient to use on mobile devices. We recommend exploring the reports on a desktop.

Filters above the main table let you segment the audience by various parameters. In the Dimensions block on the left, report users can quickly choose the breakdowns they need, in the order they need, by clicking the dimensions one after another. This lets users to drill down not only to the plan or region level but to an individual workspace. That is especially valuable for the Customer Success team, which can quickly get in touch with a customer whose subscription has changed.
The chart below the main table shows in a few seconds how the business is performing. An MRR Growth line above 0 is a good sign: the company is gaining more than it loses.
We also included expected revenue. This was one of the key parts of NetHunt’s request: the team needed to understand upcoming revenue in order to plan business activities. A dedicated report page displays scheduled payments for the coming months, and the breakdown can list customers whose renewals are approaching.

End-to-End Funnel: From Visit to Subscription, Plus the Onboarding Survey
The Revenue Report focuses on workspaces that already pay and illustrates how their MRR changes over time. It’s a report about the product’s current customers, and by design it can’t answer the question: how many people were potential customers but stopped at some step before subscribing and left the website?
To address this, we built another report: a funnel from the first website visit to payment. It became possible thanks to the data collection fixes made earlier in the project. The upper funnel steps are built on intent events from GA4, and the lower ones on backend events, which now have correct parameters and IDs. As a result, the entire funnel can be filtered by traffic source, channel, or ad campaign, making it easy to assess marketing performance not only in attracting traffic at the top of the funnel but also in conversion to the the business's most valuable event, payment.
The funnel includes five steps:
- Page view
- Intent click: sign-up, demo request, or other call-to-action buttons
- Registration start
- Workspace creation
- First subscription
The demo report shows anonymized data to protect trade secrets, but visually it fully matches the original client report.
The demo is designed for desktop viewing, so it may be less convenient to use on mobile devices. We recommend exploring the reports on a desktop.

For every stage, you can see the number of users, the conversion from the previous step and from the first step, and the share that dropped off. Next to it is the value for the previous period, and color highlights significant changes. This shows not only where the most people drop off but also whether that step has gotten better or worse over time.
Throughout onboarding, a prospective NetHunt customer answers the following questions:
- What they plan to manage using the CRM. The answers appear in the What Manage section.
- Which integrations they need. The selected options go to Integrations.
- How they heard about the product. The answers can be analyzed in the How Found section.
- What their main requirements for a CRM are. The answers to this question appear in CRM Requirements.
The responses are stored as event parameters, following the same logic that lets parameters drill down into more detail. As a result, within the report these answers can filter the funnel directly through cross-filtering. For instance, you can see how users who require a specific integration progress to a subscription, or compare payment conversion for those who discovered NetHunt in different ways.

Before this report, survey responses were simply collected, but analyzing them and identifying patterns was difficult. Now it’s clear which needs are most common among customers who complete a payment.
Marketing Attribution: The Real Campaign Impact
The funnel reveals the stage where a user dropped off, but it doesn’t answer what brought them to the website or what convinced them to register. As we mentioned above, B2B buyers often have a long journey and may interact with multiple channels before registering. Therefore, it’s important for NetHunt not to rely on a single attribution model but to see the bigger picture.
The question raised by NetHunt’s PPC specialist is one we encounter often in our work: what is the true impact of an ad campaign on conversion? Specialists often run different types of campaigns, some for awareness and first touch, and others, such as branded campaigns, that attract prospective users at the final stages of the funnel. It’s common for a substantial portion of conversions in the ad account to be attributed to the branded campaign.
This can create the impression that first-touch campaigns don’t work at all. If you’ve run a test and tried turning such campaigns off, you may have noticed that the total number of conversions drops after they are paused, including those from branded campaigns. It's a very common situation. Unfortunately, third-party interfaces can’t show how marketing campaigns actually perform across the whole path to conversion. This is another area that requires a custom analytics solution.
The Marketing Attribution report answers a range of questions and applies custom processing logic. Specifically, it shows several conversions across different stages: leads from people who filled out the demo form, trials from people who started using the product, and first-time payers and their MRR. The last two metrics match New customers and MRR in the Revenue Report.
The first screen of the report displays a large table for data exploration and can show calculations in three attribution models:
- First: all credit goes to the first touch.
- Last non-direct: all credit goes to the last touch that isn’t a direct visit.
- Linear: credit is split equally among all touches along the path.
If a channel performs well under first touch and weak under last touch, it opens paths that other channels close. In the opposite case, it captures demand created earlier.
The report also allows you to change the attribution window with just two clicks, that is, the period before the conversion from which sources are taken and among which the value is distributed: 30, 60, or 90 days.
As with the other reports, calculations are done at the workspace level. Touchpoints that preceded registration are combined within the workspace, so the value of a conversion is distributed among all the sources that influenced the decision, not just the last one.
The demo report shows anonymized data to protect trade secrets, but visually it fully matches the original client report.
The demo is designed for desktop viewing, so it may be less convenient to use on mobile devices. We recommend exploring the reports on a desktop.

The table in the screenshot is a custom-built visual we developed ourselves. When a comparison period is selected, it displays the delta under the absolute value. It also lets you manage which columns are displayed, formula-based columns, and save the current settings as bookmarks for quick access.
In the section below, the report shows how the selected conversion is distributed across the three attribution models, broken down by channel or campaign, as you choose. This helps see which channels or campaigns are stronger at the start of the path and which close leads or purchases. Next to it, you can also see how many customers have more than one touchpoint before conversion, as well as the average time between visit and registration and between registration and payment. If this time is long, we recommend adjusting the attribution window to a longer period to capture longer chains.
At the bottom of the page are the complete paths to the conversion that the report user selected in the previous visual. Here you can further explore how channels interact with one another. For instance, the screenshot below shows that paid search often goes together with organic and with paid search itself. In other words, users make multiple touches through ads, and do so more often than through other traffic channels.
Patterns like these help test hypotheses such as the one the PPC specialist had: do first-touch campaigns actually play a part in acquisition? With properly processed data and clear visualization, such hypotheses can be validated or rejected much faster.

Results
As a result of this project, NetHunt can now:
- Analyze metrics at the level of its own unit, the workspace, independently of third-party calculation methods, with analytics tailored to its own needs.
- Monitor actual MRR and its correct breakdown by type. When a user leaves their workspace, it no longer looks like churn but is correctly shown as a downgrade.
- Plan ahead, since expected revenue and renewals are visible in advance.
- Segment users by the needs they stated through the onboarding survey and analyze the needs of prospective customers.
- See which campaigns initiate the conversion journey, even when branded search later closes the registration. Three different attribution models, a switchable attribution window, conversion paths, and the cost of acquiring a paying workspace are all available in one report.
We have been working with NetHunt since 2025. Currently, together with the client, we are developing a unified pricing model for calculating MRR. At present, MRR is based on actual payment amounts, converted into a single currency, so exchange rate fluctuations can produce a “downgrade” in dollars where the plan hasn’t changed. The unified model will tie MRR to the plan instead of the exchange rate.
Services Used
- GA4 audit: detecting gaps in data collection.
- Traffic source storage: a custom solution developed by Proanalytics.Team.
- GTM setup following a technical specification: fixing data collection.
- Server-side GTM setup: resolving configuration issues in the server container.
- Event delivery using Measurement Protocol: NetHunt’s backend product events sent to GA4 through server-side GTM.
- GA4 export to BigQuery and Stripe data export to BigQuery: a centralized data warehouse.
- End-to-end analytics (report): a funnel from visit to subscription.
- Attribution models report: Marketing Attribution.
- Custom report: Revenue Report.

I also want to say a few words about the team itself. They are strong technical specialists who are easy to work with. Everything is clear and straightforward, with transparent processes, agreements, and deadlines. We only need to say what we want to see as a result, and they tell us what data is needed, how to collect it properly, and how to turn it into a convenient report. That is very valuable to us, because it lets us think about business needs rather than technical details.