NVECTA vs GA4: Why Your Analytics Numbers Differ and How to Validate Them

Modified on Thu, 17 Sep at 8:01 AM

It is normal for NVECTA and Google Analytics 4 to report slightly different numbers for the same website over the same date range. Each platform collects data with its own tracking code, applies its own sessionisation and user-identity logic, and filters traffic in its own way, so the two figures are rarely identical.

A small gap is expected. A large or one-sided gap usually points to something specific: tracking code missing on a page or a domain, tracking code firing twice, a consent banner that blocks one platform, a single-page application that does not send a page view on route change, or a mismatched timezone or date range.

This article explains how to compare the two platforms report by report, how much variance is acceptable, and how to isolate the cause when the difference is larger than it should be.

Table of contents

Before you start comparing

Most reported discrepancies disappear once the two reports are set up identically. Confirm the following first.

  • Both reports use exactly the same date range.
  • Both platforms report in the same timezone.
  • Both reports are filtered to the same hostname, including any subdomains you expect to see.
  • The platform filters match: Platform = Web in GA4, and Platform = website and m-site in NVECTA.
  • Both platforms are pointed at the same environment, so live traffic is not being compared with staging or test traffic.

Once these settings match, work through the validation checks below in order. Each check compares one GA4 report with its equivalent report in NVECTA.

Part 1: Validating your data

1. Compare page views and active users

This is the first check to run. It confirms that both platforms see the same pages, the same hostnames and a similar volume of traffic.

→ GA4 Steps:

Navigate to Reports → Engagement → Pages and Screens.

Apply the filter Platform = Web, then use the Add filter + button to filter by Hostname for the domain you are checking, and add Hostname as a secondary dimension.

Apply the desired Date filter.

Ensure the hostname is visible in the data table.

→ NVECTA Steps:

Go to Analytics → Page Traffic Report.

Apply filters for Page URL contains hostname and Platform = website and m-site.

Compare:

  • Page URL
  • Hostname
  • Page Views
  • Active Users

If both platforms are configured the same way, the same pages and hostnames should appear in both reports, with page view and active user counts inside the variance ranges listed later in this article. Make a note of any row where the numbers are far apart, or where a page appears in only one of the two platforms. Those rows are your starting point for troubleshooting.

Verify:

  • Missing pages

  • Missing or extra hostnames

When a page URL or hostname appears in one platform but not the other, the cause is almost always tracking implementation, a report filter, or data collection on that specific page or domain. The troubleshooting section of this article shows you how to confirm which one it is.

2. Compare landing pages

Landing pages show where sessions begin, so this check tells you whether both platforms agree on how visitors are entering the site.

→ GA4 Steps:

Navigate to Reports → Engagement → Landing Page.

Add Secondary Dimension = Hostname.

Filter Platform = Web.

Apply the same Date filter.

→ NVECTA Steps:

Go to Analytics → Landing Page Acquisition Report.

Apply filters for Page URL contains hostname and Platform = website and m-site.

Compare:

  • Landing Page URL
  • Sessions
  • Active Users
  • New Users

Sessions, active users and new users should line up for each landing page, within the variance ranges listed below. If a single landing page is clearly out of line while every other page matches, treat that page as the problem rather than the whole implementation.

3. Compare traffic acquisition

This check confirms that both platforms attribute visits to the same sources, so channel and campaign reporting stays consistent.

→ GA4 Steps:

Navigate to Reports → Acquisition → Traffic Acquisition.

Filter Platform = Web, and add Hostname as a secondary dimension.

Apply the same Date filter.

→ NVECTA Steps:

Go to Analytics → Traffic Attribution Report.

Apply filters for Page URL contains hostname and Platform = website and m-site.

Compare:

  • Source
  • Medium
  • Campaign
  • Traffic Channel

Source, medium, campaign and channel values should match for the same hostname and date range. If a source or campaign appears in one platform only, or the same visit is classified into different channels, check whether the UTM parameters survive the landing: redirects can strip them before the tracking call is sent.

4. Compare key business events

Conversions are the most sensitive numbers in any report, so compare each event on its own rather than looking at a single combined total.

Events to compare:

  • Purchase
  • Lead
  • Signup
  • Add to Cart

→ GA4 Steps:

Navigate to Reports → Engagement → Events.

Apply the same Date filter.

→ NVECTA Steps:

Create an Event Report for the required event (e.g., Purchase).

Compare:

  • Page URL
  • Hostname
  • Total Events
  • Total Users

Compare Page URL, Hostname, Total Events and Total Users for each event, using the same date range and platform filters. Look for events that are missing on one side, counts that are far apart, or an event that fires on some pages but not others, which usually means the trigger has not been implemented everywhere.

→ Cross-check against your backend or CRM

Your own backend or CRM is the final source of truth for conversions, so it is worth comparing when the two analytics platforms disagree. Export your records for a specific date range, export the same event data from NVECTA for that period, and compare the total number of records and the status of each event. If the totals do not line up, run event-level tests to find the exact scenario in which the event is not recorded, such as a particular payment method, device or checkout step.

How much variance is acceptable

Use these ranges as a guide. A difference inside these limits is normal and does not need investigation.

  • Page views: under 5%
  • Sessions: under 5%
  • Active users: under 10%
  • Conversion events: under 5%
  • Revenue: under 2%

⚠️

An exact match is not possible. The two platforms define sessions differently, identify users differently, filter bots differently, handle consent differently and process data on their own schedule, so a small ongoing gap is expected even when everything is implemented correctly.

Part 2: Troubleshooting the difference

1. Tracking code missing or not firing

This is the most common cause of numbers being lower on one side. If page views or user counts fall short in one platform, check that its tracking code is present, loading and sending page-view data on every page you expect to see.

→ Symptoms:

  • Missing pages
  • Missing or extra hostnames
  • Lower page views

→ Check:

  • NVECTA SDK present
  • GA4 tag present
  • Tag loads successfully

To identify the affected pages and hostnames, run the report comparison in 1. Compare page views and active users.

Step 1: Verify NVECTA SDK

Open the affected page and launch Developer Tools → Network. Reload the page and check whether the NVECTA SDK is loaded successfully. If the SDK is not present or fails to load, NVECTA may not be able to capture page-view activity from that page.

Step 2: Validate Page View Network Calls

While keeping the Network tab open, reload the affected page and check the network requests generated during page load. Verify that the expected page_view calls from both NVECTA and GA4 are being triggered.

Note

Start from the reports and find the exact page or hostname where the numbers diverge. Then open that page with developer tools and confirm that the NVECTA SDK and the GA4 tag both load, and that both platforms send their page-view request successfully. If one of them never fires, you have found the cause.

2. Tracking code firing twice

If one platform reports roughly double the traffic, the same page view or event is probably being recorded more than once.

→ Symptoms:

  • Roughly double the page views
  • Duplicate events
  • Inflated sessions

→ Check:

  • Multiple SDK initialisations
  • GTM + hardcoded implementation
  • Duplicate GTM containers

Start from the reports: page views roughly 2x higher on one platform (1. Compare page views and active users), or the same event recorded twice for a single user action (4. Compare key business events).

Step 1: Validate Network Requests

Open the affected page and navigate to Developer Tools → Network. Reload the page and filter the network requests for the relevant GA4 or NVECTA tracking calls.

Verify whether multiple identical requests are generated from a single page load or user action.

Step 2: Check Multiple SDK Initialisations

Check whether the NVECTA SDK or the GA4 tag is initialised more than once on the page. A second initialisation makes the same page view or event count twice.

Step 3: Check GTM + Hardcoded Implementation

Check whether tracking is implemented in Google Tag Manager and also hardcoded into the website source.

When both exist, the same page view or event is sent twice from a single page load.

Step 4: Check for Duplicate GTM Containers

Check that the page is not loading duplicate GTM containers, or two different containers that hold the same tracking tags.

Duplicate containers firing the same tag inflate page views, events and sessions.

Note

When page views, events or sessions look inflated, identify the affected pages in the reports first, then use developer tools and your tag setup to find out why the same activity is being counted more than once: duplicate network calls, a tracking code that initializes twice, the same tracking in both GTM and the page source, or two GTM containers firing the same tag.

3. Compare the network requests

If both tracking codes are present, the next question is whether their requests actually complete.

Open Developer Tools → Network.

Compare the page_view requests of NVECTA and GA4.

→ Verify:

  • Request is sent successfully
  • HTTP status is 200
  • Payload contains the correct page URL and hostname
  • Both requests are initiated at approximately the same time (Waterfall)

A significantly delayed request may be cancelled if the user leaves the page before it completes.

4. Check tracking on single-page applications

Applies to sites built with React, Angular, Vue, Next.js and similar frameworks.

→ Ensure:

  • One page_view is sent for every route change.
  • Initial page load is not duplicated.
  • Browser back/forward navigation is tracked correctly.
  • Manual and automatic page tracking are not both enabled.

Note

In the two examples above, one site reloads the browser on every navigation while the other changes the page without a reload. On a single-page application, the URL can change without a page reload, so confirm that a new page_view is sent for every route change. If it is not, only the first page of each visit is counted.

5. Check consent management

If a consent banner is implemented:

Check whether:

  • NVECTA starts tracking only after user consent.
  • GA4 starts tracking only after user consent.
  • Both platforms follow the same consent logic.

Differences in consent implementation are a common cause of lower page views, sessions and users.

6. Check timezone and date range

Timezone, date range and environment are already covered in Before you start comparing. Re-confirm them here: different time zones shift events across day boundaries and create a gap that looks like a tracking problem.

7. Check bot and internal traffic filtering

Different analytics platforms apply different filtering rules.

→ Verify:

  • Internal IP exclusion
  • Test traffic exclusion
  • Known bot filtering
  • Monitoring tool traffic

Filtering differences show up mainly in page views, sessions and users, and they are easy to miss because both reports look internally consistent.

If the numbers still do not match

If you have worked through every check above and the gap is still outside the ranges listed earlier, collect the following before raising it with support:

  • the hostname and the specific page URLs affected,
  • the date range and timezone used in both platforms,
  • the figures reported by each platform, and
  • screenshots of the two reports.

With this detail, the difference can be traced to a specific page or event instead of being investigated from the beginning.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article