If a Listener isn't updating profile properties the way you expect, the cause is usually one of a small set of configuration or page-structure issues — not a bug in the Listener itself. This article walks through the most frequent causes, organized by Listener type, plus a general checklist you can run through for any Listener.
Before digging into a specific Listener type, work through these steps. Together they resolve the large majority of "Listener isn't capturing" cases.
Confirm the BlueConic script is loaded — and talking to the right tenant. Open your browser's developer console on the page you're testing. Disable the BlueConic Chrome Extension first, the extension injects the script and can make a missing production tag look like it's working.
Run:
window.blueConicClient
If this returns undefined, the script isn't loaded on that page. Check script placement, tag-manager / CMP conditions, and ad blockers. Then run:
blueConicClient.getHostname()
This should return your BlueConic tenant hostname (for example your production or sandbox host). A hostname for a different environment means the page is running the wrong script. Also confirm the site hostname in the address bar is registered on a channel — acme.com and www.acme.com are not the same hostname.
For testing without a production tag, you can re-enable the Chrome extension and inject the script (make sure the extension's user script field points at the tenant you intend to test).
Confirm the Listener is on, saved, and allowed to run on this page. New Listeners are off until you toggle them on and click Save. Then check the Listener's Where setting. A limited set of channels or URL rules (including
Don't runrules) will silently skip the page you're testing. In URL rules, use.*as a wildcard (*alone is not the same),^to anchor the start, and$to anchor the end.Check that the target profile property allows visitor (browser) write access. New profile properties default to no visitor access. Listeners run in the browser, so the property must have Visitor access set to allow Write. Without that, the Listener can run correctly and still never persist a value. Batch/server-side connections do not use this setting. See Profile Properties Overview.
Check Objectives and consent against your legislation zone. A Listener with no Objective still runs. If it is added to a privacy Objective:
In opt-in zones, it runs only after the visitor has consented to at least one linked Objective.
In opt-out zones, it runs unless the visitor has refused that Objective.
Testing in a session where you've already granted (or refused) consent can hide this. Try an incognito window. Also check whether European visitors: only profile after consent is active on the channel — that Listener prevents a profile from being created for EU visitors until they consent, so nothing can be written yet.
If a CMP or tag manager loads BlueConic only after consent, the script itself may be absent on the first pageview (see step 1). If the CMP syncs consent after BlueConic has already requested interactions, a Listener tied to an Objective may not run until the next pageview.
Make sure you're checking the right property on the right profile. Some data BlueConic tracks automatically (like the Global Listener's read-only Last visited date) is separate from any custom profile property your Listener is configured to write to. These can look similar but are not the same field.
To confirm you're inspecting the profile that was just on the page, run:
blueConicClient.profile.getProfile().getId()
Copy that ID into Profiles and search by unique ID. Also check the property's data type: a Number, Email, or Date/time property will reject a value that doesn't validate, so the Listener can fire and still store nothing. If the rule is Only set if empty, a later visit will not overwrite an existing value.
Rule out a same-page-load timing issue. A value written by a Listener may not be available yet if a Dialogue or segment is evaluated in the same page load. BlueConic loads segment membership at the start of the pageview. Try a hard refresh or a second pageview before concluding the value wasn't captured at all.
On a single-page app, confirm BlueConic sees the navigation. If the URL or view changes without a full reload, add a Page Change Listener for the events your app actually uses (
hashchange,popstate,pushState, and/orreplaceState). Without that, Form, Behavior, Funnel, and Visit Listeners may only run on the first view. See Using BlueConic with Single Page Applications.
If none of these resolve it, the cause is likely specific to how your site's page, form, or URL structure interacts with the Listener — see the relevant section below.
Visit Listener
Common cause: comparing the wrong "last visit" property, or expecting the Global Listener's read-only field to change.
BlueConic's built-in Last visited date is maintained by the Global Listener. It is a system, read-only property. No configurable Listener can write to it. The Visit Listener writes only to the profile properties you select in its configuration (visit timestamp, last visit date, number of visits, and so on). Always verify against those configured properties.
The Visit Listener is a separate plugin and is not installed by default. If you don't see it under Add listener (even with Show all enabled), it isn't available on the tenant yet.
If the configured property stays empty after the checks above, also look at Only Direct Visits. When that box is checked, visits with a referrer are ignored.
Restrict Where to the brand or channel you actually want to measure. Running it on all channels will mix traffic you may not be looking at.
If your use case is a timestamp for a specific page or action (rather than channel-level visit metrics), a Behavior Listener configured against that event is usually a better fit.
Form Listener
This section is for the Rule Based Form Listener. The Visual Form Listener is a different plugin with its own setup.
Common cause: the way your site handles form submission doesn't match how the Listener rule is configured to detect it.
Form inside an iframe: If the form lives inside an iframe (including many third-party form tools), the BlueConic script must also be present inside that iframe. The script on the parent page alone will not see form activity in the frame.
Form submitted via AJAX/JavaScript: Many sites prevent the browser's default form submission and send the data programmatically. The default surrounding form is submitted rule listens for the native
submitevent and will not fire. Try:Form field value changes — stores the value when the field itself changes, without waiting for a submit.
Custom position is clicked — for a submit action handled via JavaScript on a specific element.
Custom defined form is submitted — when you need to point at a specific form, including one that is dynamically inserted after the page loads. That's usually the first variation to try on single-page or late-rendered forms.
Location hash changes — if a successful submission appends a hash (for example
#success). Enter the hash name without the#.
See Form Listening for configuration steps for each rule type. If you are not sure how the site submits, try the variations rather than assuming native submit.
Dynamically generated field attributes: Some sites (especially component frameworks) regenerate an input's
idornameon every page load. A selector targeting one of those will stop matching as soon as the value changes. If you inspect the field and theid/namelooks auto-generated or changes between reloads, you'll need a stable attribute (a fixedname, or adata-*attribute) added by your development team.Shadow DOM / web components: Fields inside a closed shadow tree are not reachable with a normal page selector. That needs a stable element outside the shadow root, or a change from your development team.
Permission level: If the profile property's permission level is higher than the level the visitor has consented to, the value is not written even though the form submission was detected.
Behavior Listener
Common cause: the element or source being targeted isn't present or stable when the rule runs.
Unstable selectors: If the page element you're tracking has a dynamically generated ID, prefer a class, element type, or
data-*attribute. Targeting a class or attribute shared by multiple elements can match more than you intended, so a stable unique ID is still best if the site can provide one. The same shadow DOM limitation as Form Listeners applies here.Content or clicks that aren't in the DOM yet: On SPAs or lazy-loaded content, a Content or Click rule can run before the element exists. Combine this with the Page Change Listener (general checklist, step 7), or use a source that doesn't depend on the DOM (URL, query parameter, JavaScript variable, or cookie).
JavaScript variables and cookies: A "value from JavaScript variable" source only sees variables on
window. HttpOnly cookies are not readable by JavaScript, so BlueConic cannot pick them up.Add / Set / Sum and Only set if empty: Sum only works when both the existing property and the new value are numbers; otherwise the property is left unchanged. Only set if empty will look like a failure on every visit after the first write.
Multiple sources writing the same property: If a Behavior Listener and another system (another Listener, a Dialogue, or an import) write to the same property, check which source is meant to be authoritative. The Listener may be working while something else overwrites or conflicts with its value. See Behavior Listening for rule types (Content, Click/Tap, URL, Social Event, Advanced Event).
Funnel Listener
Common cause: the URL or page content configured for a step doesn't match what visitors actually reach — including variants your own test session never used.
How matching actually works: Each step matches if the visitor's URL contains the configured pattern (case-insensitive).
http://,https://, and a leadingwww.are ignored. Query strings and hashes are part of the URL being tested. BlueConic does not require an exact full-URL match unless you anchor the pattern with^(start) and$(end). Use.*in the middle of a pattern as a wildcard.If a step was saved with a specific query string, UTM parameters, trailing slash, or hash, visitors who arrive without that exact extra piece may not match — or the opposite, a short path like
/checkoutmay match more pages than you intended.If the flow has multiple valid paths (locales, environments, redirects, route variants), add each variant on that step with Add URL. Reaching any listed URL counts as the step.
Word filters: If a step has a word filter, that word must be visible on the page (not only present in the HTML). Hidden or delayed content will prevent the step from counting until the word appears.
Where vs step URLs: The Listener's own Where rules must include every step page. A step URL that sits outside those rules will never run.
Unique Funnel ID: The Funnel ID (for example
shopcart) must not be reused by another Funnel Listener. Step progress is stored on shared funnel profile properties and namespaced by that ID, so a duplicate ID mixes two funnels together.Look at the properties the Funnel Listener actually writes: It creates its own properties — Funnel steps, Last step, Busy with funnel, Funnel entrance, Last field — rather than a custom property you may have created for something else.
Single-page application flows: If the URL changes without a full reload, add a Page Change Listener so BlueConic treats each view as a pageview. Without it, later steps often never fire.
Investigating missing steps: When some profiles skip a step but you can't reproduce it, open the affected profile and compare its actual page-view URLs to the URLs (and word filters) on that step. Landing in the middle of the funnel is expected; Funnel Insight treats those profiles as new visitors on that step. See Funnel Listening for full setup steps.