Accurate tracking helps you understand customer journeys and make reliable decisions. Use the checks in this article to find common tracking issues on the platform, including initialization problems, duplicate events, identity issues, consent gaps, and page visits without session starts.
This article covers two website tracking paths:
The legacy JavaScript SDK uses
exponeamethods and a project token.The Event Streams/Data hub Web SDK uses
brwebmethods, astream_id, and Data hub target endpoint.
Choose the path that matches your deployed implementation. Don't run both SDKs on the same website because they can cause cookie collisions, lost visitor identification, and inconsistent tracking.
Identify your SDK and check initialization
Start by identifying which SDK your website uses. In the deployed code, look for exponea for the legacy SDK or brweb and stream_id for the Event Streams/Data hub Web SDK.
Check a legacy JavaScript SDK implementation
Open your website in a new browser window, preferably in a staging environment.
Visit several pages.
In the platform, go to Settings > Web integration.
Confirm that the page shows Your tracking code is working.
Open your browser's Developer tools and confirm that the SDK snippet appears on the page exactly once.
Verify that the project token and API target match the environment you're testing.
If you use Google Tag Manager, confirm that the initialization tag fires before event tags and that you're testing the published container version.
The Web integration screen shows the legacy code available for setup. Always verify the code that's actually deployed on the website. Loading multiple SDK snippets, mixing SDK types, or using a token from another environment can send data to the wrong project or create inconsistent tracking.
Check an Event Streams or Data hub Web SDK implementation
In Data hub, go to Events > Event streams, then select the stream associated with your platform project.
Open the stream's Access security tab and copy the
stream_idand target endpoint.Confirm that the Web SDK snippet appears in the website's
<head>and uses the correctstream_idand target endpoint.Confirm that the implementation loads
brweband callsbrweb.start().Check that the stream connects to the correct destination and accepts the event types your website sends.
Confirm that the website doesn't also load the legacy JavaScript SDK snippet.
Use the Web SDK setup guide and the event stream setup guide for the full implementation steps.
Some migration setups expose exponea as a backward-compatible alias for brweb. Check the deployed snippet and SDK configuration instead of identifying the implementation by a method name alone.
Before either SDK sends tracking data, obtain and store the required customer consent. If the SDK starts only after consent, activity before consent won't be tracked.
Check tracking cookie stability
Use your browser's Developer tools > Application > Cookies section to check the tracking cookie as you navigate between pages.
The cookie should remain stable across page loads in the same browser session. If it changes on every page, check for multiple SDK instances, repeated initialization, custom code that clears cookies, or unexpected calls to the SDK's anonymize() method.
A new cookie in a new private browsing session can be expected. A cookie that changes on every page in the same session usually indicates an implementation issue.
Use the Tracking Console to verify events
Use the Tracking Console with either SDK. For legacy implementations, How to test and preview a weblayer on the page explains how to open the console. For Event Streams implementations, use the Tracking Console documentation.
The console can help you:
Use the Timeline tab to confirm that events fire at the expected time with the correct URL, timestamp, and properties.
Use the Customer tab to check the anonymous cookie ID and identified customer IDs.
Use the Configuration tab to verify the project token for the legacy SDK or the
stream_idand target endpoint for the Web SDK.Compare the console with the Events tab for the matching customer profile in the platform under Data & Assets > Customers.
Use the browser's Network tab when the Tracking Console doesn't show enough information. Check the outgoing tracking requests and the browser console for JavaScript errors.
Verify system and custom events
Events fall into two categories:
The platform tracks system events automatically across projects. Review the System events article for the complete list.
Custom events are specific to your project and require a tailored implementation.
For Event Streams implementations, use the Required events reference to confirm expected event names and properties.
For each custom event, check that:
The tracking code runs when the customer action occurs.
The browser console shows no tracking errors.
Your implementation sends the event only once for each intended action.
The event name, properties, data types, and values match your Tracking Document, if you have one.
If you use a single-page application, verify that route changes trigger the expected page and custom events. Full page loads alone might not capture virtual page changes.
Check event deduplication
The platform checks tracked and imported events for possible deduplication and discards exact duplicates. Near-identical events can still appear separately.
If you see repeated or near-identical events, review the tracking flow and confirm that your website or import process sends each event with the intended data only once.
This check covers duplicate event ingestion. If the issue is inflated report counts because several legitimate status events belong to the same entity, read How to prevent duplicate counting in event-based reports.
Reset tracking after sign-out
Call exponea.anonymize() for the legacy SDK or brweb.anonymize() for the Web SDK when a customer signs out. This resets the visitor identification on the device so later activity is tracked under a new anonymous profile.
This check is especially useful for shared devices and public computers, where multiple people might use the same browser. Without a correct sign-out flow, activity from different customers can remain associated with the same profile.
Identify customers after registration
Call exponea.identify() for the legacy SDK or brweb.identify() for the Web SDK after a customer registers, signs in, or provides a unique identifier. Pass the correct hard ID configured for your project so the platform can associate the current session with the correct customer profile.
The SDK uses separate calls for customer identity, customer updates, and event tracking. Use the identity method that matches your SDK and the SDK's tracking method for customer actions.
To test the identity flow:
Visit the website as an anonymous customer and note the cookie ID.
Register or sign in and confirm that the matching
identify()call sends the correct hard ID.Find the customer profile on the platform and confirm that the anonymous activity is associated with the identified profile.
Sign out, sign in as a different customer, and check that the new activity isn't associated with the previous profile.
Investigate page visits without session starts
For the legacy JavaScript SDK, page_visit events are turned off by default. If you've enabled them but don't see corresponding session_start events, check multiple customer profiles and timestamps. This helps you distinguish a real anomaly from a profile-specific pattern.
For Event Streams implementations, also check the event stream's configuration, permissions, destination, and stream_id.
Check the automatic event configuration
If custom events are present but system events are missing or inconsistent, review the SDK configuration:
For the legacy SDK, confirm that
ping.enabledisn't disabled. Session events depend on SDK activity pings.If you expect page visits, confirm that
track.visitsor the equivalent Web SDK setting is enabled.For Event Streams, confirm that the stream accepts
page_visitand other expected event types.For a single-page application, confirm that URL changes and virtual page views trigger tracking.
Check whether consent timing delays SDK initialization until after the initial page load.
By design, the platform can omit events when you turn off the relevant tracking options.
Check for bot traffic
Bots can access pages without behaving like typical customers or starting a normal session. Email link scanners can also generate activity that appears to be a customer visit.
To identify bot-generated email clicks, enable Automatic bot detection in emails in Project settings > Campaigns > Channels > Email > Automatic bot detection. The feature flags honeypot clicks with the clicked_honeypot status. It doesn't suppress events, so use the status to identify bot activity in your analysis.
Check for incomplete visits
A customer might click a link in an email and close the browser tab or navigate away before the website records session_start. In this case, the email click or page visit might exist without a complete session.
If the email click event itself is missing, read Why email click events aren't tracked. It covers redirects, removed URL parameters, and tracking consent.
Check for technical and consent issues
Connection problems, interrupted page loads, blocked scripts, privacy extensions, and ad blockers can prevent session_start from being recorded.
Consent tools can also affect tracking. If the SDK starts only after consent, the first session_start might represent the page where the customer accepted consent rather than the original landing page.
Cross-check related metrics
Use UTM parameters in your email campaign settings to connect email activity with website behavior.
Compare the resulting website data with email engagement metrics, such as open rates and click-through rates. These secondary metrics can help you distinguish genuine customer activity from bot traffic, incomplete page loads, and other tracking gaps.
Finally, monitor Data Manager > Events for sudden spikes or drops in event volume after a tracking change. Compare the volume with a known baseline and investigate unexpected changes before relying on the affected data.