Fix personalized content that isn't showing

You can use the debugger to find out why a visitor still sees your original page. Start with the browser where it happens and check the campaign, the visitor's data, and the page element you want to change.

A matching UTM parameter is one part of the decision. The campaign also needs to be published and enabled, the visitor needs to receive personalization rather than holdback, and the target element needs to match.

The debugger shows my change, but an ordinary visit doesn't

1. Check whether the debugger is using the draft or published setup.
2. Remove forced overrides when checking whether the visitor naturally matches the audience.
3. Check that the campaign and its latest changes are published.
4. Check the campaign's Split Tests settings and any available activity from ordinary visits.
5. Compare with a page load outside the debugger.

The debugger can force audience values and shows the personalized version. It doesn't replace the browser's real campaign assignment, so an ordinary visit can look different without the campaign being broken.

Open the debugger through the dashboard's Debug on site action. Adding debug=true to the URL doesn't provide the signed authorization it needs.

The visitor doesn't match the audience I expected

1. Check the affected visitor's identity and segment rules.
2. Check the full arrival URL, any redirects, and the final URL.
3. Inspect the actual field or query value rather than the value you expected your ad platform to send.

Connected email-platform data requires identification in that browser. A contact you recognize on desktop isn't automatically recognized on their phone. UTM and query conditions also depend on whether the rule reads the current page or stored visit history.

See visitor identification and UTM conditions.

The visitor matches, but may be in holdback

Check the campaign's activity when it's available. For a visitor in holdback, the personalized content they would have seen is labeled Would have received.

Holdback deliberately leaves the campaign's original content visible. Matching an audience and being assigned personalization are separate decisions. The debugger previews personalization, so it doesn't show an ordinary browser's real holdback assignment as its current preview assignment.

A campaign with 10% holdback doesn't tell you whether this particular visitor is in that group. Look for activity that confirms it. Changing the percentage doesn't immediately redistribute existing recorded browser assignments.

The audience matches, but the page element doesn't change

Open Personalizations in the debugger and inspect the campaign's changes. Check the action's domain, path, selector, and Smart Match information.

Enlarge

Personalizations debugger panel showing the agency campaign variant and its homepage headline changeOriginalOriginal

The visual editor distinguishes Wrong page, No matching elements on this page, and Element is hidden on this page. Using the visual editor requires Scale or Pro. Mobile sites may render different elements or hide the desktop headline. A redesigned CSS class can also leave the campaign without a matching target.

Use Inspect on hover to identify what changed on the actual page.

Enlarge

On-site element inspector identifying the homepage headline changed by the Agency teams campaign variantOriginalOriginal

Retarget the element with a stable ID or class, then retest the page. Check for later changes from overlapping campaigns that replace the same content too.

The script doesn't run or the page has an error

Check that the correct project's snippet loads on the affected URL. Inspect browser network failures and console errors, and record the failed URL and time before changing security settings.

A script blocker, content-security policy, consent tool, or network failure can stop the snippet from loading. Blocking can differ between browsers. Keep the site's firewall and form validation in place while you investigate.

If only the editor fails, follow visual editor loading troubleshooting.

It still fails on one device or browser

Capture what happens in the affected browser when possible. Send support:

• The device and browser.
• The full arrival URL with sensitive values removed, any redirects, and the final URL.
• The approximate time and whether the session was identified.
• The expected audience, the content you saw, and the published campaign state.
• Any relevant network or console error.

A desktop comparison can help, but it won't necessarily explain a mobile failure. Don't send cookies, signed debugger URLs, authentication tokens, or personal contact data.

After a fix, test the ordinary visitor path again outside the forced preview. That's how you'll check what visitors see with their own data and campaign assignment.