---
title: Troubleshooting an 'Unknown' Track
slug: js-api/troubleshoot-unknown-track
description: How to troubleshoot an "Unknown" track error after implementing Monetate's JavaScript API
image:  https://archbee-image-uploads.s3.amazonaws.com/ceIfEvQHzQk1IVxoRWUh7/K9eTL4jKm7UQINb6zNziJ-20250912-181225.png
docTags: 
createdAt: 2024-06-21T16:21:46.674Z
---

When the Monetate tag runs, Monetate runs [custom.js](docId\:zcx_p3d6ND2Rr5bJLOyUG), a compiled JavaScript file with all the necessary code to execute actions and collect relevant page information. By default, this script waits until the `DOMContentLoaded` browser event completes and then looks for the existence of the [monetateQ](docId\:Jt7O1LQ8aUTjhFOLknLnV) object on the page. If the `monetateQ` object isn't available at that time, then the `custom.js` script runs its own track so that Monetate tracks the page.

## 'Unknown' Track Appears Before API Calls

If you see the "unknown" track before the API calls for a page, the reason is that the API method calls are most likely not firing before the `DomContentLoad` event. The initial track request from the `custom.js` script is firing before your site pushes any API method calls to the `monetateQ` object.

When this sequence happens, no information, such as page type, has been pushed to the `monetateQ` object, so only default values are sent when the `custom.js` script makes the failsafe track request. If a page type isn't set in the `monetateQ` object, then Monetate intentionally returns the page type as "unknown" to prevent errors.

In this screenshot from the [Monetate Inspector browser plug-in](https://docs.monetate.com/docs/install-the-monetate-inspector-browser-plug-in), the "unknown" error appears for Page Type on the **Components** tab.

![Example of the 'unknown' error appearing for Page Type in Monetate Inspector](https://dyzz9obi78pm5.cloudfront.net/app/image/id/64f75061e705d4208d0c00c3/n/monetate-inspector-components-page-type-unknown.png)

If you cannot update your tag management system (TMS) running the API calls to fire Monetate JavaScript API method calls before `custom.js` makes a [trackData](docId\:gcm0H169GurCQMv6sBota) request, then the "unknown" track is unavoidable without moving the API calls out of the TMS. It's possible though not always advisable for Monetate's engineers to update the `custom.js` script to delay the initial track request and allow more time for your TMS to populate the `monetateQ` object.

## Consequences of an 'Unknown' Initial Track

While this issue isn't the worst thing that could go wrong during an API implementation, side effects could hinder experiences from running on the right pages if they're not properly conditioned. "Unknown" tracks also skew bounce rate metrics because technically you won't bounce from the site with two tracks on the landing page. Additionally, this issue can increase the number of page views since Monetate records each track.

[Flicker](https://docs.monetate.com/docs/manage-flicker) is one of the most prominent detrimental impacts of an "unknown" track. Because [masking](https://docs.monetate.com/docs/content-masking) evaluates purely based on the URL path and is not restricted by any audience segmentation or other targeting, a mask executes when Monetate fires on the initial track request. It doesn't fire on any subsequent tracks. Therefore, masks execute immediately on the "unknown" track, but any later `trackData` request containing action-triggering information is executed without masking. The result is that the customer is more likely to encounter flicker in the experience than if a single `trackData` request has the appropriate timing.