Why is your popup not firing — and how to fix it

How to fix a popup that isn't firing on your SGEN site

You set the popup to Published, opened your site, and nothing appeared. The overlay does not appear. This guide runs you through every reason a SGEN popup can silently skip — from the most common (it is still in Draft) to the least obvious (a cookie-consent script is gating it, or your browser already saw it this session and will not fire it again).

The scenario throughout this guide: your business built a "Free shipping over $50" exit-intent popup, set it to Published, and sent visitors to the homepage — but no popup ever appeared. The decision tree below is the exact path they followed to find and fix the problem.

Work through each step in order. Stop as soon as you find the cause and apply the fix. If a step passes (the symptom does not apply to you), move directly to the next one. Do not skip ahead — the order is arranged so the most common causes appear first.

What is this for?

This guide is a structured decision tree for a published SGEN popup that does not appear on the public site. Each step checks one possible root cause, tells you the exact admin screen to open, and describes what a passing result looks like. Seven steps cover every root cause documented in the SGEN testing pipeline.

The guide does not walk you through creating a popup from scratch. If you have not yet created the popup, see Create a popup first. If the popup appears but looks wrong — wrong width, wrong copy, missing form inside — that is a configuration issue on the popup's Edit page, not a firing issue, and this guide does not cover it.

Here is what the Popups list looks like for your business at the start of this investigation. The "Free Shipping Exit Intent" row reads Published in the Status column, so a Draft mistake has not been ruled in yet — but the other steps still need to run. Notice also the second Published row: multiple Published Autoload popups can interfere with each other (step 6 covers that):

Good use cases

Example 1: Status is Draft instead of Published. The single most common cause — someone saved the popup as Draft without flipping to Publish. The popup is stored in SGEN and appears in the list, but renders on zero public pages. Open the Popups list, find your popup, check the Status column. If it reads Draft (amber label), open Edit, change Status to Publish, and click Save Popup. The popup goes live immediately — no other change needed.

Example 2: Exit-intent has already fired in the testing browser session. Exit-intent fires once per browser session by design. If you triggered it earlier in the same tab, SGEN already set the session flag in localStorage and will not show the popup again until the tab closes or that flag is cleared. Open your homepage in a private / incognito window — if the popup fires there, your regular browser's session cache is the cause, not a configuration problem. Your real visitors who have never seen the popup will see it correctly.

Example 3: The popup uses button-trigger instead of Autoload, and the trigger button is not on the homepage. Some setups use href="#sgp_<id>" on a button rather than Autoload. If the trigger button is on a product page and not the homepage, the popup never fires on the homepage — by design. Check whether Autoload is ticked on the popup's Edit page. If Autoload is off, the popup only fires when a visitor clicks a link whose href value is the popup's hashcode.

What NOT to use this for

Wrong width, wrong copy, or a missing form inside the overlay are configuration issues on the popup's Edit page. Open Edit, check Popup Width, the body content area, and the configuration checkboxes, and adjust there.

Custom-code conflicts are real but uncommon. Status mistakes and session-cache hits account for the large majority of silent popups. Follow the decision tree from step 1 — skipping steps can lead you to disable codes that have nothing to do with the problem.

Logged-in admins are sometimes excluded from Autoload popup display in SGEN so you can work on the site without your own overlays interrupting you. Always verify in a fresh private / incognito window as your primary test environment.

Each step in this guide has been the root cause of what initially appeared to be a platform defect. Confirm all seven pass before escalating to SGEN support.

How this connects to other features

Steps 1, 2, 3, and 6 of this guide send you back there to verify those fields.

Step 4 checks whether the popup's script has been caught by an overly broad consent-gating regex in the Other scripts field. Full consent configuration reference: Configure the cookie consent banner.

Step 5 walks through isolating which code is at fault. Reference: Create and manage custom codes.

Step 2 checks whether that button exists on the page you expect, with the correct href="#sgp_<id>" value.

Before you start

Have the Popups list open in your SGEN admin: Popups → All Popups.

Close any incognito window that has previously loaded your homepage this session; it may already have the popup session flag cached from an earlier test.

For your business, that is the homepage at yourdomain.com.

You will need to test as a visitor who has not yet made a consent decision (step 4) and as one who has accepted (to confirm the popup fires post-consent).

Editor and Author roles cannot edit popup settings or toggle Custom Codes active/inactive.

• You know the name of the popup that is not firing.

Where to go

The decision tree runs across three admin areas. All three are reachable from the left navigation in your SGEN admin:

1. Popups → All Popups — steps 1, 2, 3, 6, 7
2. Tracking Consent → Settings — step 4
3. Custom Codes — step 5

Open Popups → All Popups now and find your popup in the list before reading further. Keep that browser tab open throughout the process — you will return to it several times.

Steps — Seven-step decision tree

1. Confirm the popup status is Published, not Draft

Open Popups → All Popups. Find your popup by name. Look at the Status column on its row.

• Published (green label): status is not the cause. Move to step 2.
• Draft (amber label): this is the cause.

Open the popup's Edit page, change Status to Publish, and click Save Popup. The popup goes live immediately. Open your homepage in a fresh private / incognito window to confirm the overlay appears.

The status label is small and easy to miss when scanning a long list. A reliable check: click the Publish filter tab at the top of the list — if your popup does not appear in that filtered view, it is not published regardless of what the original save dialog appeared to show.

Here is what the Edit page looks like with the Status dropdown open — both options visible so you can confirm which is selected:

After saving as Published, a green confirmation flash appears at the top of the Edit page:

2. Confirm Autoload is ticked — or your button-trigger exists on the right page

On the same Edit page, look at the Autoload checkbox.

If Autoload is ticked: the popup fires automatically on the visitor's first page view across every public page on your site. No button or link is required anywhere. Move to step 3.

If Autoload is NOT ticked: the popup fires only when a visitor clicks a link or button with href="#sgp_<id>" somewhere on your site. For an exit-intent campaign this is almost always a mistake — SGEN's exit-intent detection requires the popup script to be loaded and listening on the page, which only happens when Autoload is on. Tick Autoload and save.

If Autoload is intentionally off (you are using the button-trigger method on purpose): Go to the page where the trigger button should be. Open it in the Pages editor. Confirm the button's link target field contains #sgp_<your-popup-id> — for example #sgp_3. If the button is missing, add it. If the href value points to a different hashcode or is blank, correct it and save the page.

The popup's hashcode is displayed on its Edit page just below the Title field. It reads something like #sgp_3. Copy it from there — do not type it from memory, since a single character difference makes the trigger completely silent.

3. Check the Frequency cap — your browser may have already seen this popup

On the popup's Edit page, look at the Frequency field (visible only when Autoload is ticked).

Frequency 0 means show once per visitor and never again. If you previously visited your site in a non-incognito browser window, the popup already fired and your browser stored a localStorage flag recording that it did. SGEN checks that flag on every page load before firing the popup — so the popup correctly stays silent for you from that point forward.

The test: open your homepage in a fresh private / incognito browser window that has not visited your site before. If the popup fires there, your regular browser's session memory is the cause — not a configuration problem. Your real visitors who have never seen the popup will see it correctly.

To reset your own browser for repeated testing: Open browser developer tools (F12 on Windows, Cmd+Option+I on Mac). Go to Application → Local Storage → your domain. Find and delete the key that contains sgp in its name. Reload the page in that same tab — the popup fires again.

Frequency values and what they mean for repeat visitors:

If you want the popup to re-fire during testing without clearing localStorage each time, temporarily set Frequency to 1 and save. Revert to 0 when testing is done so real visitors do not see the popup on every visit.

4. Check whether the Tracking Consent banner is gating the popup script

If your site has a Tracking Consent banner configured, the popup's JavaScript may be suppressed for visitors who have declined — or not yet responded to — the consent banner. SGEN's consent gating checks every script tag against the regex patterns in the Other scripts textarea. If any pattern is broad enough to match your SGEN domain, it catches the popup script as well as the intended tracking tool.

Open Tracking Consent → Settings in your admin sidebar. Scroll to the Other scripts textarea. Read every regex pattern listed there.

Watch for unintentionally broad patterns:

• /sgen/i — matches your own SGEN domain and everything hosted on it, including the popup loader.
• /popup/i — matches any script whose URL or inline body contains the word "popup."
• /script/i — dangerously broad; matches every script on the page.

Compare against correctly specific patterns:

• /hotjar\.com/i — matches only scripts loaded from hotjar.com.
• /cdn\.amplitude\.com/i — matches only Amplitude's CDN.
• /connect\.facebook\.net/i — matches only Facebook Pixel loaded directly.

To confirm consent gating is the cause: Open your homepage in a fresh incognito window. Accept the consent banner immediately when it appears. Then move your cursor toward the top of the browser chrome to trigger exit-intent. If the popup fires after you accept but would not fire for a pre-consent visitor, an overly broad regex is gating the popup script for anyone who has not yet consented.

Fix: edit the broad pattern in Tracking Consent → Settings → Other scripts to be domain-specific. Click Save Config after editing.

5. Check for a Custom Code that is blocking the trigger event

A <head> or <body> Custom Code running before SGEN's popup script can intercept the JavaScript mouseleave event that drives exit-intent detection. This happens when a third-party cookie-consent library or analytics script registers its own mouseleave listener and calls event.stopPropagation() — which prevents SGEN's exit-intent handler from receiving the event at all.

Test: open Custom Codes in your admin. Look at every entry with Active status. Toggle each Active entry off one at a time. After each toggle-off, open a fresh private / incognito window, load your homepage, and test the exit-intent gesture (move the cursor toward the top of the browser chrome). When the popup fires after you disabled a specific code, that code is the source of the conflict.

Common culprits:

• Third-party cookie-consent libraries that also hook mouseleave to show their own opt-out prompt — and call stopPropagation() in that handler.
• Heat-mapping scripts (Hotjar, Mouseflow, Crazy Egg) — usually fine, but misconfigured versions can suppress downstream event listeners.
• Chat-widget loaders that register broad global pointer event handlers on page initialization.

After identifying the conflicting code: Do not leave it toggled off permanently — that removes whatever tracking or feature the code provides. Contact the vendor who gave you that snippet and ask about a configuration flag to disable their exit-intent hook. Most vendors expose something like exitIntentEnabled: false in the script initialization object. Toggle the code back on after the vendor confirms the fix, and retest.

If no active Custom Code is causing the conflict, re-enable any entries you toggled off and move to step 6.

6. Check whether Avoid Multiple Popup is suppressing this popup

If your site has more than one Published popup with Autoload ticked, and Avoid Multiple Popup is enabled on some of them, SGEN shows only one popup per page view — the one with the lowest numeric ID. Your exit-intent popup may be getting silently suppressed because a different Autoload popup is claiming the single-popup slot.

Check: open Popups → All Popups, switch to the Publish filter tab, and review every Published popup whose Trigger column reads "Autoload." For each one, open its Edit page and look at the Avoid Multiple Popup checkbox.

If Avoid Multiple Popup is ticked on your exit-intent popup and on at least one other Published Autoload popup with a lower numeric ID, the lower-ID popup always wins and yours is suppressed.

Fix options:

If the two popups fire at meaningfully different moments — one fires on page load, the other fires on the exit gesture — untick Avoid Multiple Popup on the exit-intent popup. The two popups do not compete; they appear at different points in the visitor's session.

If you want strict one-popup-per-visit behavior and your exit-intent popup must be the one that shows, you cannot reorder popup IDs (the ID is assigned at creation and cannot be changed). Instead, set the other Published Autoload popup to Draft status until the exit-intent campaign ends, then republish it.

7. Confirm exit-intent works in the visitor's browser and on their device

Exit-intent detection in SGEN works by listening for the mouseleave event on the document — specifically when the cursor moves toward the top of the browser chrome (the address bar area), which signals the visitor is about to navigate away or close the tab.

This trigger has two constraints worth knowing before concluding there is a platform problem:

Constraint 1 — Mobile devices do not generate a mouse cursor. The mouseleave event never fires on a phone or tablet. Exit-intent popups set to Autoload will still appear on mobile devices, but only via SGEN's time-delay fallback — not via the exit gesture. If you are testing on a phone and the popup is not appearing, set Frequency to 1 and wait 10–15 seconds on the homepage. If the popup appears after the delay, mobile is working via the fallback trigger. The exit gesture itself is desktop-only.

Constraint 2 — The test gesture must be deliberate and cross the viewport boundary. Moving the cursor slowly across the top navigation bar of your own page does not trigger exit-intent. The cursor must cross the viewport boundary upward — toward the browser's address bar and tab strip. Move the cursor decisively from the middle of the page straight up and beyond the top edge of the page content area. The popup should fire within one to two seconds of that gesture.

Test: open your homepage on a desktop browser in a fresh private / incognito window. Move the cursor decisively toward the browser address bar. If the popup fires: exit-intent is working correctly. If the popup does not fire after completing steps 1–6 and performing the gesture correctly: contact SGEN support with a screenshot of the popup Edit page, the browser name and version, and the operating system you are running.

What success looks like

What to do if it does not work

Continue through steps 2–7 in order. One passed step does not clear the remaining six.

Your regular browser recorded the popup session flag from an earlier test. Open browser developer tools (F12 on Windows), go to Application → Local Storage → your domain, find the key whose name contains sgp, delete it, and reload the homepage. The popup fires again in that same tab.

Re-enable all Custom Codes (you have confirmed they are not the cause) and continue to step 6 (Avoid Multiple Popup) and step 7 (browser / device). If all seven steps pass without identifying a cause, contact SGEN support with a screenshot of the popup Edit page.

If Frequency is 0, this is correct behavior. The popup fires once per visitor — after the first fire, the session flag is set and the popup will not re-fire on any subsequent page in that session. Set Frequency to 1 if you want it to appear once per page visit.

A heavy <head> Custom Code that blocks page parsing is the most common cause. Toggle each active <head> code off one at a time and check whether the delay shortens after each.

Reload the page after accepting — SGEN's consent gating releases suppressed scripts on the next full page load, not immediately after the Accept click. After reloading, test the exit-intent gesture again.

Confirm Frequency is not set to 0 with a cached session flag already present. Open the homepage in a fresh private browser session on the mobile device and wait 15 seconds without scrolling. If the popup appears, the time-delay fallback is working correctly. If it does not appear, and you have confirmed the session is genuinely fresh, contact SGEN support with the mobile device model and browser version.

Tips for reliable popup testing

Always use a private / incognito window as your test browser. Your regular admin browser has session flags, consent decisions, and cached states that obscure what a real first-time visitor sees. The private window is the only clean slate.

Reset one variable at a time. If you change Status, Frequency, and Autoload all in one save and then test, you cannot tell which change fixed the problem. Change one field, save, test in a fresh private window, and confirm the result before making the next change.

Keep a note of which Custom Codes were active before you started toggling. If you toggle several codes off to isolate a conflict and then lose track of which ones were originally on, you may accidentally leave tracking tools disabled after your debugging session ends. A quick screenshot of the Custom Codes list before touching anything is enough.

Test on desktop first, then mobile. Exit-intent is desktop-only. Confirming the desktop case works first removes one variable before introducing the mobile device and its time-delay fallback behavior.

After any Tracking Consent change, always open a completely new incognito window for the next test. The incognito window you used to accept the consent banner now has a consent decision stored for the rest of that browser session. Open a new private window to test as a fresh pre-consent visitor.

Example scenarios with outcomes

Example 4: Cause at step 3 — Frequency 0, same browser session. your business built and tested the "Free Shipping Exit Intent" popup in the same admin browser they use every day. They triggered exit-intent once, saw the popup, and then never saw it again — even after saving content changes to the popup body. Cause: Frequency was set to 0 (show once, never again) and the testing browser already had the session flag from the first trigger. Fix: opened a fresh private window. Popup fired immediately on the first exit gesture. No config change was needed — the popup was working correctly for real visitors. Only the testing method was wrong.

Example 5: Cause at step 4 — broad consent regex matching the popup script. After confirming Published status and Autoload ticked, your business checked Tracking Consent → Settings → Other scripts. The textarea contained /sgen/i — placed there to gate a third-party tool hosted at sgen-analytics.com. That pattern also matched SGEN's own popup loader URL because it contained the substring sgen. Fix: replaced /sgen/i with /sgen-analytics\.com/i. Clicked Save Config. Result: popup fired correctly for visitors who had not yet consented, because the popup script was no longer being caught by the overly broad pattern.

Example 6: Cause at step 5 — third-party cookie-banner script blocking the mouseleave event. All config checks passed but the popup still would not fire on any desktop browser. Toggling off the "Cookie Banner (Third-Party)" Custom Code entry immediately fixed it — the popup fired on the next private-window test. The third-party banner script was registering its own mouseleave listener and calling event.stopPropagation(), which consumed the event before SGEN's exit-intent handler could receive it. Fix: contacted the third-party vendor and added exitIntentEnabled: false to the script initialization config in the Custom Code snippet. Toggled the Custom Code back on. Retested. Popup fired alongside the third-party banner without conflict.

Example 7: Cause at step 6 — Avoid Multiple Popup suppressing the exit-intent popup. your business had two Published Autoload popups: Newsletter Signup (ID 1) and Free Shipping Exit Intent (ID 3). Both had Avoid Multiple Popup ticked. On every page view, Newsletter Signup (lower ID) claimed the single-popup slot — the exit-intent popup was suppressed every time. Fix: unticked Avoid Multiple Popup on the exit-intent popup only. Newsletter Signup fires on page load; exit-intent fires when the visitor moves to leave — they appear at different moments and no longer compete. Result: visitors saw both popups during their session, each at the appropriate moment, with no overlap.

Next step

Once the popup is firing correctly for real visitors:

Save the popup.

Scroll halfway down, wait 10–15 seconds (the time-delay fallback), and confirm the popup appears. If mobile coverage matters for this campaign, this test is not optional.

The popup body itself is not a tracking tool — only add the popup script to the Other scripts consent list if you have a specific legal reason to do so.