> ## Documentation Index > Fetch the complete documentation index at: https://docs.senderz.app/llms.txt > Use this file to discover all available pages before exploring further. # Popup testing and results > Pre-launch checks, A/B variations and the step funnel: how to verify a popup before it goes live and read what it did afterwards. A popup has three checkpoints. Senderz checks it can work before you publish, splits traffic between variations while it runs, and reports a step funnel once real visitors have seen it. ## Pre-launch checks Click **Publish or schedule** in the builder header. The panel that opens carries a **Pre-launch checks** card, headed with how many passed out of the total. Most checks are **blocking**: publishing is refused while any of them fails, and clicking Publish reopens this panel with the message "Fix the blocking pre-launch checks before publishing". One check is advisory and never blocks. | Check | Passes when | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | Popup has a name | The name field is not empty. It is what you see in the popups list and in reports. | | Has an email or phone field | Every layout carries at least one email or phone capture field. | | Has a submit button | Every layout carries a submit button. | | Audience is reachable | At least one device and at least one active day are selected under Targeting and display. | | Coupon code is set | Only checked when the after-submit action shows a coupon. | | Reward selected | Every coupon block points at a real coupon. A coupon block with nothing linked renders an empty box on the storefront. | | Reward can be delivered | Only checked when the reward is delivered by email. Every layout needs a required email field, and there has to be a reward for the visitor to receive. | | Schedule is valid | A scheduled popup has a start, and any end date comes after it. | | Click trigger is valid | A click trigger's CSS selector is one a browser can actually use. | | A/B variations are valid | A test has at least two variations, each with its own letter. | | Redirect URL is set | Only checked when the after-submit action redirects. | | Consent checkbox present | **Advisory.** Recommended for Israeli and GDPR compliance. It never blocks publishing. | ### Checks only judge layouts that can render This is the part that surprises people most. A popup has a separate mobile layout, and that layout only diverges from desktop the moment you first edit it on the mobile canvas. From then on it is never re-synced. Add a field on desktop afterwards and the mobile layout still does not have it. So the checks run once **per device layout the popup actually targets**, not on every layout that happens to be stored: * Targeting desktop or tablet is checked against the desktop layout. A tablet is served the desktop layout, so it counts as desktop. * Targeting mobile is checked against the mobile layout. * A popup that targets only one of them is never blocked over the layout it will never show. When a check passes on one layout and fails on another, the row swaps its usual description for a line naming the offender, for example "The mobile layout does not pass this check". Today that applies to the capture-field and submit-button checks, which are the two that read a specific layout. It is almost always a stale mobile layout that is missing a field or a button. If a check fails and you are looking straight at the thing it says is missing, read the row again for the layout name, then switch the canvas to that device and check there. When an A/B test is ready, every variation is checked, on every targeted device. A field missing from one variation blocks the whole popup. ### Suggestions Separately from the checks, selecting a step opens **Step settings**, which carries a collapsible **Suggestions** list for that step. These are advice about the copy and layout of that one step. They never block publishing: * A missing heading, or a heading shorter than three words. * A heading that does not mention a specific offer. * Too much text on the step. * No submit button, or a generic label such as "Submit", "Send" or "Continue". * No image on the step. * More than one input field on a single step. * Consent wording with no text, no link to a privacy policy or terms page, or no business name. * Two consent boxes covering the same channel. Suggestions are heuristics, not rules. Ignore one when it does not apply to the popup you are building. Nothing in this list stops you publishing. ## Testing before you publish The step bar at the top of the builder has preview modes: **Desktop**, **Mobile**, **Desktop and mobile**, and **All steps**. A mode is greyed out when the popup does not target that device, with the note "This popup targets a single device. Change its targeting to enable this view." Preview shows you the design. To test the real thing on your storefront, publish it and open the site in a private browsing window, or force it open from the browser console. See [Installing popups on your store](/en/messaging/popup-install) for both. ## A/B variations Open the fourth icon in the builder rail, **A/B test**. Click **Create A/B test**, name the test, and name the two starting variations. Both start as a copy of the popup as it is now. The step bar gains **A**, **B** and so on next to the preview modes. Click a letter to switch the canvas to that variation and edit it. Each variation holds its own settings and its own steps. The test reads **Draft test** while you build it. Click **Continue to test settings** and it becomes **Ready to publish**. Only a ready test is ever served. Publish the popup itself the normal way, through **Publish or schedule**. The panel then reads **Test running**, the variation rows start showing results, and the primary button becomes **Pause popup**. ### How traffic is split A test holds **at least two and at most four** variations. The split is **even by construction**, so two variations get 50% each and four get 25% each. The panel states it directly: "Traffic is split evenly". There are no per-variation weights. If you need an uneven split, that is not available. Assignment is **sticky per visitor**. A visitor is put into one variation and keeps seeing that same one on later visits from the same browser. Adding or removing a variation only changes which variation new, unassigned visitors get. Variations only serve once the test is marked ready and the popup itself has left draft. A test sitting on a draft popup shows no results, because nothing has been served yet. ### Reading the results While the test is running each variation row shows **Views**, **Sign-ups** and **Rate**, and the rows are sorted best rate first. One variation gets a **Leading** badge, but only when the result means something. A variation leads once it is ahead on conversion rate **and** has at least **100 views**. Until then the panel says so plainly: "No clear leader yet." A tie crowns nobody. Leading is not statistical significance. It is a threshold that stops the badge appearing on a handful of views. Treat a narrow lead on a few hundred views as unproven and let it run. ### Ending a test **Decide winner** on a variation row ends the test. The winner's content is promoted onto the popup itself, every visitor sees it from then on, and the popup keeps running. It is not paused. **Deleting** a variation removes it from the test. New visitors stop seeing it and its results are removed. If deleting would leave only one variation, the test ends instead and the survivor's content is promoted, which the confirmation says before you commit. Either way the per-variation results are cleared when the test ends. The popup's own lifetime impressions and conversions are not. The panel also carries **Pause popup** and **Resume popup**, so you can stop and restart a running test without leaving it. ## Popup results The popups list is the top-level view. Four workspace totals sit above it: **Total popups**, **Live**, **Impressions** and **Avg. CVR**. Every popup card then shows its own **Impressions**, **Conversions** and **CVR**. Open the menu on a popup card and choose **Analytics** for the detail. The same menu holds **Edit**, **Duplicate**, **Pause** or **Resume**, and **Delete**. ### What the Analytics dialog shows Impressions, conversions and the conversion rate for the whole popup. One bar per step, showing how many visitors completed it, with the drop-off from the previous step alongside every step after the first. Views, conversions and rate per variation, listed under the funnel while a test is running. Shown until the popup is live and collecting. Senderz reports an empty state rather than inventing numbers. ### What counts * An **impression** is the popup being displayed to a visitor. * A **conversion** is a successful sign-up submitted from the popup. * Both are only recorded while the popup's status is **Live** and its publish window is open. A paused, scheduled-but-not-started, or ended popup records nothing. ### Tracking incomplete Sometimes conversions come in higher than recorded impressions. That happens when some impression signals never reach Senderz, usually because a tracking or ad blocker dropped them, while the sign-up itself went through as a normal form submission. Senderz does not paper over it. The rate is shown as a dash and labelled **Tracking incomplete**, and the impression count is prefixed with `≥` to say it is a floor rather than an exact number. Conversions are unaffected and remain accurate. ## Next Per-platform install and how to confirm a popup is serving. Steps, targeting, triggers, games and rewards. The rewards a popup can hand out, shared and unique codes. Send the welcome message after a popup sign-up.