Two registration pages ran for the 26 August live training. On the two days that carried real registration traffic, B received more visitors than A and produced five registrations against A's thirty-seven. B's form is still on the module's factory default — set to redirect, with no redirect target — so a visitor who submits sees no confirmation of any kind.
Provisional — 24 August 2026. Variant B is paused. The submission-path defect is confirmed in the page configuration but has not yet been reproduced in a live browser test; until that test is run it is not settled whether the form also fails on load for some visitors. This page updates in place.
Both pages point at the same HubSpot registration form, so this is not a reporting or attribution split — the gap is in behaviour on the page.
B is not underperforming at the margin — it is failing. Across the whole window B took of the combined traffic and produced of the registrations. On the two days registration traffic actually flowed, B held visitors on the page longer than A and bounced them at a higher rate, which is the signature of a page that is read and then abandoned rather than one that is ignored.
Isolating the two days that carried registration traffic removes the noise from the soft-launch period and makes the comparison direct.
B was not starved of visitors on these days — it received more of them than A. The difference sits entirely in what those visitors did once they arrived.
The divergence appears only once registration traffic starts; before that both pages sit near zero and the daily figures are too thin to read.
Scale maximum 60%. Bars for 18–22 August rest on denominators of three to twenty-seven views and should not be read as rates; they are shown for completeness. The meaningful comparison is the last two groups.
| Date | A views | A regs | A rate | B views | B regs | B rate |
|---|
Daily buckets are UTC as returned by HubSpot content analytics; the webinar itself runs 15:00 ET on 26 August, so a UTC day boundary splits late-evening US traffic differently from a local-time report. Totals in section 01 cover 1 June to 24 August and therefore exceed the sum of the rows above.
These are read directly from the page's saved module configuration, not inferred from behaviour.
Both form instances on B — the one in the hero card and the one in the closing register block — carry the module's untouched factory default: response type set to redirect, with an empty redirect URL. Because the response type is redirect, the inline confirmation message stored alongside it is never displayed either. A visitor who completes the form receives no confirmation, no thank-you page and no visible acknowledgement. The module's own help text instructs the editor to point the redirect at a confirmation page; that step was never carried out. Variant A is set to inline response with a confirmation message and behaves correctly.
The proof section has its logo row switched on while all six logo image slots are empty, so the section renders a row of blank placeholders in the middle of the page's strongest credibility moment.
Four written client outcomes are present in the module but the toggle that displays them is set to off. Only the screenshot strip renders. The equivalent copy is visible on A.
The "what you'll learn" and "your host" blocks both have blank heading fields, leaving empty heading elements in the document.
Beyond the defects, B and A are built on different conversion logic — and B's is the weaker of the two for this audience.
In order. The first item settles whether the rest of the list matters.
Run a live submission test on B in a private browser window. Load the page, submit a test registration, and watch the browser console through submit. This settles whether the form merely lacks a confirmation or fails outright for a share of visitors — the single fact that decides whether this was a build defect or a copy result.
Tech OpsSet the post-submit behaviour on both form instances. Either point the redirect at the confirmation page or switch the response type to inline so the stored confirmation message displays. Apply to the hero card and the closing register block.
WebFix or hide the empty logo row and switch the written client results back on before B is served to anyone again.
WebAdd mid-page registration calls to action to B — at minimum one after the learning outcomes and one after the social proof — and restore the live-attendee bonus.
MarketingRe-run the comparison as a genuine split rather than two separately distributed URLs, with allocation controlled at a single entry point so the traffic mix is identical. Until that happens no copy or layout conclusion from this round should be treated as tested.
MarketingAdd a pre-launch checklist item for post-submit configuration on any page built from the webinar theme modules, since the defective state is the module's shipped default and will recur.
Tech OpsRead this before quoting the conversion gap as a copy test result.
Each needs an answer before the next registration page ships.
| Question | Owner |
|---|---|
| Does B's form submit successfully in a live browser, or does it error? | Tech Ops |
| Where was each URL distributed, and were the two audiences comparable? | Marketing |
| Did any B registrant contact us saying their registration did not go through? | Sales Ops |
| How many other live pages are built on the same theme modules with the same default form configuration? | Tech Ops |
| Should the module default be changed so an unconfigured form falls back to inline confirmation rather than an empty redirect? | Tech Ops |