Troubleshoot snippet installation and missing widgets

Find the symptom below to get RightMessage working on your site. If the snippet is already receiving data, you can move on to the widget or contact that isn't behaving as you expected.

Note the project, page URL, browser, what you expected to see, and whether you're testing a draft or the published site. If you haven't added the snippet yet, start with the installation guide.

RightMessage hasn't received any website data

1. Check that you're in the correct project.
2. Open Settings, then JavaScript Snippet.
3. Compare the code on your website with the code under Live website.
4. Publish the website change. A saved CMS setting or Tag Manager preview isn't a public installation.
5. Visit a public page where you've installed the snippet.
6. Return to Snippet Health and check its last-received timestamp.

Enlarge

Snippet Health showing the last data receipt timestamp for the local example projectOriginalOriginal

If there's still no activity, ask your website owner to check the page's loaded scripts and network requests. Check that the script loads the correct project and look for failed requests. Consent settings or browser protection can prevent the snippet from running. A tag manager can add the script without it appearing in the original page source.

The Staging / development snippet disables analytics, so use the live snippet for this check. See how the two snippets differ.

You don't need to publish unrelated RightMessage changes to clear an installation warning.

The dashboard asks me to bring visitors back

Choose Check my site now to check the website saved in your project. You'll see snippet found, not found, or check inconclusive. This check doesn't publish your draft.

• If the snippet is missing, use Email it to my developer or Platform guides to get it installed.
• If the snippet is found, visit the page and look for recent activity in Snippet Health. Finding the script and receiving browser activity are separate checks.
• If the check is inconclusive, inspect the browser and website response before changing the installation.

The dashboard shows Bring visitors back to RightMessage when the project has had no visitors during its recovery window. It includes the installation snippet to help you check the setup.

Setup progress says it's unavailable

In Get set up, choose Try again. If a milestone says Unavailable, check the setting it refers to, such as Snippet Health or the published flow, before rebuilding anything.

This message means the dashboard couldn't load setup information. It hasn't marked that milestone complete or failed, and it hasn't confirmed that the snippet is missing.

If the warning stays, send support the project ID, time, and visible error.

The snippet is healthy, but my widget is missing

Open Debug on site from the app. In This page, you'll see the widget and campaign decisions for the page you're visiting. The debugger guide shows how to start an authorized session. Adding ?debug=true alone doesn't authorize one.

Enlarge

RightMessage debugger on This page, showing the homepage campaign, team assessment widget, and visitor segmentationOriginalOriginal

Use what the debugger shows to check these settings:

1. Open the widget and check that Enabled is on in the draft or published configuration you're testing.
2. Check that the widget is attached to the flow or offer you want.
3. Compare the draft with the published version. A widget can work in preview while ordinary visitors still see the older version.
4. For popup-style widgets, check Targeting rules, permitted devices, and page exclusions in Display. Embedded widgets don't have those same controls.
5. For an inline widget, check Where it appears. Its embed shortname or selected placement needs to exist on this exact page.
6. For other widget types, check When it appears. A timed, scroll, click, manual, or exit trigger needs that event to happen.
7. Follow the flow's path for this visitor. A branch can end without an offer, or an Exit Flow can deliberately dismiss the widget.

The widget appears in a private window but not my usual browser

Check your usual browser's saved answers and identity in the debugger. Then:

1. Check the widget's Question handling. Ask questions we don't know the answer to skips questions that already have answers.
2. Make sure returning visitors still have a useful path and final offer.
3. In the debugger's Flows tab, use Clear dismissed to remove dismissal state for this debugging session.
4. To start the flow over, use Restart flows for this session.

Your usual browser and a private window can have different answers, identity, targeting, and dismissal state. A private window helps you compare those differences, but doesn't fix them for returning visitors.

The debugger clears relevant dismissal state in both local and session storage for the debugging session. Deleting only a localStorage key can leave a session dismissal behind. These controls don't change every ordinary visitor's saved state.

For a fresh test outside the debugger, see testing your changes. Only clear real visitor data if you intend to remove that browser's saved state.

The page stops working when I enable caching or optimization

Ask your website owner to compare the page with and without the affected rule in a safe test environment. Check delayed JavaScript, combined scripts, cached HTML, and duplicate snippet installation through plugins or the theme.

If a specific optimization is interfering, exclude the RightMessage script from that rule. After an approved installation change, clear the relevant website cache. Keep your other optimization and security controls in place.

Caching or optimization can change when the snippet loads or serve an older installation. The comparison helps you find which rule needs changing.

Privacy protection blocks the snippet

Compare the affected browser with an approved test browser that doesn't have the blocking extension. Record the blocked URL and error, and keep required consent and security controls in place.

An extension, browser shield, network policy, or consent decision can block the script or its requests. RightMessage can't bypass those controls, and browser-based behavior can't run with JavaScript disabled.

Keep your original content, forms, and important resource links useful without personalization.

Preview works, but the public page doesn't

Check the project, published version, widget's enabled state, placement, and visitor conditions. Then open the same public URL without forced segments or draft flags. Find the condition the normal visitor fails before changing targeting.

Preview can use a draft, forced audience state, or debugger behavior that differs from an ordinary visit. A campaign holdback can also deliberately show an eligible visitor the original page. Forcing a variation in preview skips that normal assignment.

Answers appear, but the contact's field doesn't change

1. Check that the browser is identified as your test contact.
2. Check that the project's Integration connects to the correct provider account.
3. Inspect the question's sync destination and every answer-to-value mapping.
4. Check the provider's field type, permitted values, and required contact action.
5. Run a test that permits provider writes, then open the destination contact to check the update.

Saving an answer, identifying the browser, mapping the answer, and accepting the update are separate steps. Connecting your provider doesn't identify every browser. Preview can also suppress external writes.

See contact synchronization and the subscriber survey checks for the setup you're testing.

I still need help

Send support the project ID, public page URL, expected and observed behavior, browser and device, test time, and whether you tested a draft or published configuration. Include any relevant console or network error and a screenshot of the failed decision.

Keep contact addresses, credentials, and identifying preview links out of public reports. If you're reporting a provider update, say whether you've checked the destination contact record.