Test your changes before and after publishing
You'll preview your draft on your own website, try each path as a visitor, and check that everything works after you publish.
You can try your changes on your real website before visitors see them. Preview on your site loads your draft with the debugger docked at the bottom of the page. It shows what RightMessage knows about you and why it's showing each question, offer, or page change.
You'll need the project's snippet installed on the page and a RightMessage login with access to the project. Keep a dedicated test contact for the final contact-sync check. Don't use a customer's identifying link, since a normal visit can save answers to their record.
Open your draft on your website
- Finish your edits and let them save.
- Choose Preview on your site in the unpublished changes bar at the bottom of the dashboard.
- To start on another page, open Choose preview URL. Select a suggestion or choose Enter URL…, enter the full HTTP or HTTPS address, and choose Open Preview.
- Sign in or approve the website host if prompted. Only approve a website you intend to test.
- Check that Draft is selected in the debugger.
Use this dashboard entry to open the debugger. Adding ?debug=true doesn't give someone access, and you shouldn't share debugger URLs or tokens. If the session expires, reopen it from the dashboard.
Follow each path
Answer your questions and follow every branch through to its form, offer, redirect, or end. Check shared questions and offers wherever they're used, including paths you didn't edit.
In the debugger:
- Open This page to see what's showing, waiting for a trigger, not eligible, or only in the draft. Expand anything unexpected to see why.
- Open Flows to inspect the path and current step.
- Use Restart flows for this session to repeat the path. Use Clear dismissed when you want to remove a widget's dismissal from this test session.
- Open Events to inspect what happened, including Would send details for contact updates.
RightMessage doesn't send analytics or integration writes while you're debugging. Would send shows the intended update. You'll check delivery after publishing. Your website's own forms and external services aren't part of this sandbox, so don't submit unrelated live forms during the test.
Try another audience
Segment overrides let you check what different people see without changing a real contact.
- Choose Override beside the segment group you want to try.
- Select an answer, then inspect the page and the explanation in This page.
- Repeat with other relevant answers or combinations. For a single-select group, include Not known yet.
In this WorkForge (opens in a new tab) example, the visitor has no known Work Type. Choosing Agency or creative services makes the agency headline eligible.
Use Reset for one override or Reset overrides for all segment overrides. Reset forced campaign and A/B test assignments separately.
To try data from your connected email platform, open Visitor and choose Impersonate a contact…. Enter your test contact's email, choose Look up, and confirm the contact. This simulates their data without writing to their record. Detach returns you to the actual browser visitor. The debugger reference covers the remaining controls and access requirements.
Check how visitors qualify
Now test the rules that put people in each audience. Keep your real rules in place rather than adding a temporary rule to force a match.
- Reset segment overrides and forced test assignments.
- Open the real URL visitors will use, including any expected query parameters.
- Answer the question or visit the page that should put them in the audience.
- Check their segment and the campaign or flow decision in the debugger.
- Repeat with an answer or visit that shouldn't qualify.
For a rule that matches affiliate=example-partner, add that parameter to your own page URL. On the WorkForge demo, that would be https://workforge.rightmessage.com/?affiliate=example-partner. Also test a visit that doesn't match.
The illustrated rule uses On any occurrence, so an earlier matching visit can still count after you remove the parameter. A current-page-only rule checks a different scope.
For a new-visitor check, use a fresh browser profile or a new private session with no saved site data. Close all private windows to end a private session. Another private tab alone doesn't clear it. Test a returning visitor separately to check known answers and dismissed widgets.
Click through the flow in the builder
The builder's preview lets you walk every branch of a flow and check narrow layouts and themes without leaving the app.
- Open your flow in Flows and choose the eye button labeled Preview flow. The preview opens in a floating window beside the canvas.
- If the flow uses several widgets, choose one in the widget menu.
- Answer each question. When the preview reaches a condition it can't work out, such as one about page views or the referrer, choose the branch to follow.
- Use Restart to try another path as a new visitor, or Next page view to continue as the same visitor.
- Check Desktop and Phone, and the widget's light and dark colors.
A widget with the Unstyled theme takes its look from your site's CSS, so the preview shows it on one of your own pages instead. A widget that belongs to a hosted page offers Preview on the page, which opens that page's preview.
To check a known contact's path, preview as one of your email platform's contacts. Not sent lists the updates, webhooks, and emails a real visit would have made. See preview a flow in the builder for every control.
Use the on-site preview above to check page rules and display triggers on your actual website.
Check an A/B test's versions
If a campaign has an Original page or audience A/B test, check every version before you start it. Starting is a draft change, so nobody sees a challenger until you publish.
- In the campaign editor, choose Preview, then pick the version under its audience or the Original page test group.
- Choose Preview on your site to check your draft on your real page with the debugger.
- Check that tested elements above the fold are protected with
rmcloak, so visitors don't see the original before their version. See prevent a flash of original content.
After the test starts, Send to your analytics on its Testing tab card lists each version with Preview this version on your site, which opens your site showing that version.
Once the test is live, a few things are worth knowing:
- Your own visits. Use Exclude this browser in Project settings > Website & install, or open the debugger, so your visits don't count. See exclude test visitors.
- Measurement periods. Publishing a change to what a test measures restarts its measurement, and the publish dialog lists it under Restarts measurement. Earlier results stay in the test's history.
- The first verdict. The earliest verdict comes at the week 2 check, about three weeks after the test starts. Many tests take longer. See how verdicts work.
- Deploy and Undeploy. When you end an Original page test, you can keep showing the winner until your website is updated, then Undeploy once your site shows it. Check your live page before and after undeploying. See end a test and deploy the winner.
Publish and try it as a visitor
Once you're happy with the draft, review and publish your changes.
- Choose Exit in the debugger and confirm.
- Start a fresh visitor session without debugger or preview parameters.
- Follow the same entry path on your published page.
- Check the content, widget trigger, question order, branch, final offer, and destination.
- For a contact-sync check, identify your dedicated test contact through the supported identification path.
- Submit the answer or form, then check that contact's record in your email platform.
When visitors get the right content and your test contact receives the intended update, you've checked both the website and the integration. If preview and live visits differ, use the preview and live-site FAQ to narrow down why.