Revenue Path Health

Behavioral Performance Dashboard

Last updated: September 17, 2026 · Source: Fullstory via MCP

Executive Summary

September 2026 in three numbers

What behavioral data found on the revenue path, priced against InMotion's own September figures. Each item is tagged by how much of it is measured and how much still needs validation.

The measured miss

−$33.9K

September pacing below the 2026 average. Dedicated Servers is $29.6K of it.

The largest unpriced exposure

$11K–$69K

Per month, from 303 customers whose renewal requests fail. Range, not estimate — one event setting closes it.

Cost of the checkout errors

~$0

Tested and not detectable. Finding that out quickly is the capability, not the error count.

The one-line version. The alarming-looking checkout errors are not costing orders — we can now prove that in an afternoon. The quiet two-month renewal failure probably is, and we cannot price it because no order value flows into Fullstory. That single gap is the ask.

Revenue context

InMotion's September new-hosting report — 16 days actual, pacing to month end. Every figure below is judged in proportion to these.

September pacing ?

$192.3K

New hosting revenue across all five product lines.

2026 monthly average ?

$226.3K

The baseline September is measured against.

Variance to average

−$33.9K

Tracking 15% below. Dedicated alone is $29.6K of the gap.

Front-of-site order value ?

$264

373 orders, 1–16 Sept. 73% carry an add-on; those average $319.

One caveat on the figures above. The September report covers new hosting only. Measured against the full order export, that is 59% of the cash actually collected — $102K of $172K across 1–16 September. Domains and add-ons make up the rest.

What we found, ordered by money at stake

Exposure is what the finding could be worth if it behaves as feared. The tag says how much of that is measured. Open any row for the evidence on both sides.

$11K–$69K

per month exposure
303 customers · 30 days

Needs validation

AMP renewal requests failing since 21 July

/amp-js/billing/confirm-renewal has returned errors every day for two months — roughly 22 a day, without a single clean day. These are existing customers trying to pay. The range reflects what they were renewing: $35.88 is the median renewal price across all subscriptions, $227.88 the median for hosting. We cannot narrow it because no renewal value reaches Fullstory.

Evidence for and against

Points to a real problem

Unbroken daily occurrence for 58 days — not a spike
Paired with 226 abandoned forms on Manage Payment Methods
94 more customers failing to save a credit card
No benign explanation for a renewal endpoint failing continuously

Reasons for caution

Some failures are likely declined cards, not system faults
No conversion event, so lost renewals cannot be confirmed
Retries inflate counts; affected customers may be fewer
Renewal revenue sits outside the new-hosting figures above

Recommendation: take this one to engineering. Two months of continuous failure on a payment endpoint warrants root-cause work regardless of how the revenue models out.

−$29.6K

measured shortfall
vs 2026 average

Measured shortfall, unproven cause

Dedicated Servers is the bulk of September's miss

Dedicated is September's largest revenue gap and 87% of the total variance. It is also the second-most-refreshed page on the marketing site, with 80 refreshes and 28 abandoned forms in 30 days. The shortfall is measured; the link to the page friction is not. This is the kind of question the data lets you ask in minutes rather than quarters.

Evidence for and against

Points to a real problem

Largest single product-line miss against the 2026 average
Page refreshes are the standard tell for something appearing stuck
28 abandoned forms on a high-consideration, high-value product

Reasons for caution

Dedicated is low-volume and high-value, so revenue is naturally lumpy
80 refreshes is small against total marketing traffic
No causal evidence whatsoever — correlation only

Recommendation: a question for the product team, not a finding for the board. Ten minutes of session replay before the meeting would settle it.

$27.7K

exposure, 4 days
measured cost: not detectable

Tested — no impact found

Checkout order-save errors began on 14 September

105 customers hit an HTTP 500 from api/order/save in four days, after zero occurrences going back to 1 March. At $264 an order that is $27.7K of exposure — but the exposure did not convert into loss. Affected customers clicked Submit Order at 15.2% against a site-wide 15.9%, and daily revenue rose after the 14th. Worth fixing as a bug, not escalating as an incident.

Evidence for and against

Points to a real problem

Genuinely new: zero occurrences in the preceding six months
Affects 7.5% of everyone reaching checkout
A clear server fault in _verifyEnabledProducts, not a third-party issue
Suggests a catalog change on the 14th the cart cannot handle

Reasons for caution

Submit Order rate 15.2% affected vs 15.9% site-wide. No measurable drop in purchase intent.
Daily revenue since the 14th averaged $7,510 vs $6,412 month-to-date — it rose
500s here can fire during configuration without blocking purchase
September's shortfall sits in Dedicated and predates the 14th

Recommendation: raise as a bug. The honest headline is that Fullstory surfaced it within days of onset and then showed it probably isn't costing orders — the second half being the more valuable capability.

Not yet
priceable

82 customers · 30 days
direct cash is small

Blind spot, not a cash figure

The email checkout modal fails, and replay cannot see it

Email and Titan products check out through a modal posting to /amp-js/vue-marketplace/purchase, failing daily since 22 July and spiking to 69 failures on 17 September. Email products booked only $683 in 17 days, so the direct cash at stake is small — the cost is that the modal does not appear in session replay at all. At the moment a customer clicks Confirm Purchase, the recording shows the page behind it. The highest-frequency checkout surface in AMP cannot be diagnosed.

Evidence for and against

Points to a real problem

82 customers hit a failed purchase call in 4 weeks — against 88 who completed an order
Spiking now: 69 failures on 17 September, the highest in 90 days
A sampled session returned HTTP 402 on Confirm Purchase
Same 14 September inflection as the front-of-site checkout error

Reasons for caution

402 can be a legitimate decline rather than a system fault
Error counts include retries, so customers affected may be fewer
Email is a low-revenue line; the loss is strategic, not material this month
No conversion event on this path, so completion cannot be confirmed

Recommendation: two asks. Have engineering check the 402s, and get the modal into replay. While it stays invisible, nothing on that surface can be measured.

Revenue impact test

If the 14 September errors were blocking purchases at scale, daily revenue would step down after the dashed line. It does not.

Daily new hosting revenue · September 2026

All product lines combined · dashed line marks error onset

No visible dent. The three days following onset averaged $7,510 against a month-to-date average of $6,412. Whatever is holding September back started earlier and sits mostly in Dedicated.

Instrumentation gaps

Everything above came from page and element instrumentation alone. These four gaps are what stand between a model and a measurement. None is a large piece of work.

GAP 01

No Revenue Event

No order value flows into Fullstory, so friction cannot be priced directly. Every dollar figure here is inferred from your own revenue reporting instead.

GAP 02

No conversion event

No custom or defined events exist at all. But /amp/marketplace/confirmation/ and /amp/checkout#purchase-success are real confirmation routes already being recorded — both could be defined as conversion events today, with no engineering work.

GAP 03

One user property

Only plan_names is captured. Without plan tier or account age, friction can't be weighted by customer value.

GAP 04

Checkout spans two domains

central to secure1 breaks session continuity at exactly the moment money changes hands.

The ask: a Revenue Event and a single order-completed event. Those two settings turn the $11K–$69K range above into one number, and would have answered the "did the 500 cost us anything" question definitively instead of circumstantially.

Marketing Site

Marketing site friction

The top of the revenue path. Friction here is quieter than in a cart — nothing errors loudly, people simply leave. These are the signals that mean something appeared broken, rather than merely uninteresting.

Friction signals

Last 30 days, unique customers. Page refreshes and abandoned forms are the two signals that most reliably mean "this looked stuck." No cash figure is attached here: marketing-site friction costs a visit, not an order, and pricing it would be a guess.

Signal	Where	Customers
Page refreshed by the customer The universal tell that a page appeared stuck or failed to load properly.	Home Page	335
Page refreshed by the customer On the product line with September's largest revenue shortfall.	Dedicated Servers	80
Error clicks on the AMP Login button In the main site header, so it appears on every page. Existing customers failing to reach their account.	Site header	74
Error clicks on the HubSpot form submit Lead capture form erroring on submit — direct pipeline impact.	Sales enquiry form	30
Form abandoned before submitting Details entered, then left without completing.	Dedicated Servers	28
Page refreshed by the customer	Bare Metal Servers	27
Page refreshed by the customer	Shared Hosting	23
Form abandoned before submitting	Bare Metal Servers	17

The one to look at first: 74 customers throwing error clicks on the AMP Login button in the site header. That is an existing customer trying to reach their account and failing at the first step — a support call and a retention risk in one, on every page of the site.

Marketing site to cart

The saved funnel built during the trial. Read the first step carefully.

Marketing site → checkout

Last 30 days · unique users

Read with care: step one counts every marketing-site visitor, so 0.53% is a traffic ratio, not a conversion rate. The useful finding is that of the 5,272 people who reach the cart, fewer than half arrive from the marketing site — the rest come directly from ads, affiliates and email.

September revenue by product line

Pacing to month end vs 2026 monthly average

September pacing2026 average

Dedicated is $29.6K behind its average and is the largest contributor to September's shortfall. VPS is the only line ahead, by $7.4K.

Order Process · Front of Site

The front-of-site cart

The front-of-site cart on central.inmotionhosting.com, where new hosting is sold. September's $192K of new revenue flows through this surface — and it carries both the most instrumentation and the most consequential blind spot.

Cart funnel

Last 30 days, unique users, entering the cart from any source.

Order Process funnel

Cart entry through to order submission

The blind spot: the funnel ends at the Submit Order click because no order-confirmation event exists on this domain. We can see 839 people try to buy. We cannot see how many succeeded — which is why "did the 500 cost us orders" can only be answered circumstantially.

Order-save errors per day

Last 30 days · zero before 14 September

Present in releases 2.82.2 through 2.82.4, so the code path predates the spike. Something changed in the product catalog on the 14th that this validation cannot handle.

Error impact on purchases

If the 500 were preventing orders, customers who hit it would submit at a lower rate than everyone else. They do not.

Submit Order rate — affected vs everyone

Share of cart visitors reaching the Submit Order click

Essentially identical. 16 of the 105 affected customers went on to click Submit Order (15.2%), against a site-wide rate of 15.9%. On the evidence available this error is not measurably suppressing purchases. It is a bug worth fixing — it is not a fire.

What one affected session looks like

Santa Ana, CA · desktop · 17 September

Arrives from a VPS campaign, browses Bare Metal and VPS pages
Enters the cart, selects cPanel VPS Admin and an OS
500 returned by /api/order/save
Session ends — no payment step, no error message shown

Sessions like this are why the signal is worth investigating. But one session is an anecdote — the rate comparison on the left is the evidence, and it points the other way.

Order value

/amp/checkout#purchase-success is the order-confirmation route for this cart, which makes completed orders countable for the first time. The September order-tracking export now settles what those orders are worth — and how many of them Fullstory sees.

Front-of-site order value ?

$264

373 orders, $98,568 collected. Median order $109.

New customers

$201

213 orders. First purchase on the account.

Existing customers

$349

160 orders. 74% higher than a new customer.

Fullstory's capture rate ?

89%

332 of 373 orders recorded. Not half.

Add-ons are where the order value is. 73% of hosting orders carry at least one add-on. Those orders average $319; orders without an add-on average $114 — 2.8× the difference. The attach step inside the order process is worth more per order than the hosting sale itself, and it is the part of the cart no one currently watches.

Two gaps worth a conversation. Among new customers, a rep-assisted order averages $329 against $150 self-serve — 2.2×. Sales placed 28% of new-customer orders and booked 46% of new-customer revenue. Separately, existing customers account for 80% of orders and 75% of cash; new acquisition is a fifth of order volume. Neither gap is a fault — but both say the self-serve cart is where the upside is, and it is the surface with the least instrumentation.

Correcting two things stated earlier on this page. The earlier $349 figure divided hosting-only revenue by Fullstory user counts — wrong on both sides: it left out add-on cash and it under-counted orders. The corrected figure is $264. The earlier claim that Fullstory sees roughly 48% of orders was also wrong; measured against actual order counts it sees 89%. And an earlier "cross-checks to within 1% of pacing" claim was circular — order value cancelled from both sides of it, so it tested nothing.

What this changes about the rest of this dashboard. At 89% capture, the customer counts on these pages are close to the real population rather than roughly half of it. "478 customers saw an error" is approximately 537 customers, not 1,000. Friction counts throughout should be read as slight under-statements, not as a sample.

Method, stated plainly. Source is the September order-tracking export, 1–16 September, line items grouped into carts by account and timestamp. An order is one cart; its value is the cash actually collected that day, including add-ons and domains bought alongside. Upgrades, downgrades, term changes and reinstated subscriptions are excluded, per how the business counts new sales. Front-of-site is defined as any cart containing hosting — hosting is sold only through the order process, and marketplace hosting cards redirect into it. Zero-dollar carts (free trials, included add-ons) are excluded from the average.

What customers are told when it fails

A decline is normal business. Being told nothing about it is a recoverable loss — and 56% of what this checkout says is exactly that.

Recoverable at stake ?

$2.6K

Per 10 customers recovered, at $264 an order. 268 were told nothing actionable.

Told nothing useful ?

56%

Generic "could not process", no cause given. 268 of 478 customers.

Genuine bank declines

39%

787 occurrences. Expected business, not a fault.

Actionable decline reasons

2.3%

Only 45 of 1,994 told the customer what to fix.

Why this is the cheapest revenue on the page. The error card was shown 1,994 times to 478 customers in four weeks, in 41 distinct strings across 7 languages. Surfacing the decline reason the processor already returns is a copy change, not an engineering project. The recovery rate is unmeasured — needs validation — but the per-customer value is measured at $264.

Consolidated by what went wrong

All 41 strings merged across languages, so each underlying failure counts once.

Failure	What the customer is told	Occurrences	Share
Generic system failure Order API returned an error — seen alongside 403 and 500 responses.	"We could not process your order." — and its Spanish, French, German, Turkish, Portuguese and Chinese equivalents.	1,109	55.6%
Bank decline, no reason given Issuer refused, but the reason was not surfaced.	"Order Declined by Bank" / "Orden rechazada por el banco" / "Ordonnance refusée par la banque" / "Auftrag von Bank abgelehnt" / "银行拒绝该笔交易"	787	39.5%
Specific card decline The only messages a customer can act on.	Insufficient Funds (12), Issuer Generated Error (6), Invalid Transaction (5), Expired Card (3), Restricted Card (3), Account Closed (3), Lost/Stolen Card (2), and 8 more.	45	2.3%
Fraud / risk filter block Worth watching — legitimate customers can be caught by threshold rules.	"Advanced Fraud Filter Score Below Threshold" (26), "Suspected Fraud" (11), plus the Spanish variant (1).	38	1.9%
Error card with no message at all The card renders with just the word ERROR and nothing after it.	"ERROR:" (7) and "ERREUR :" (1)	8	0.4%
PayPal transaction failed	"PayPal Transaction failed."	6	0.3%
Duplicate purchase guard Fired once — a customer who submitted twice.	"A purchase is already in progress or has been completed for this order."	1	0.1%

Localisation

Language	Occurrences	Share
English	1,880	94.3%
Spanish	62	3.1%
French	21	1.1%
Mixed — localised label, untranslated message	16	0.8%
No message at all	8	0.4%
German	4	0.2%
Turkish	2	0.1%
Chinese	1	0.1%

A real localisation bug, visible in the strings. Sixteen occurrences carry a translated label with an untranslated body: "ERREUR : Order Declined by Bank", "HATA: We could not process your order.", "FOUT: Order Declined by Bank", "错误： We could not process your order.". The error wrapper is localised; the message inside it falls back to English. Any customer in that path gets a half-translated failure at the moment they are trying to pay.

Three things worth acting on. First, 56% of all errors say nothing useful — "we could not process your order" is the single largest message and gives the customer no next step and support no diagnosis. Second, only 2.3% carry an actionable reason, even though the gateway clearly returns them (Insufficient Funds, Expired Card and Lost/Stolen all appear) — those reasons exist upstream and are being collapsed into the generic message. Third, the fraud filter blocked 38 attempts; that threshold is worth reviewing against how many were genuine customers.

Friction on the checkout page

Last 7 days, against roughly 1,390 customers who reached checkout. Ranked by customers affected, not event volume.

Signal	Type	Customers	Share

Worth a separate conversation: the single largest source of console errors on your checkout page is LogRocket loading twice — 279 customers, one in five. It is the incumbent tool, and on the most valuable page InMotion owns it is the loudest thing in the logs.

AMP & Marketplace · Back of Site

Where retention revenue is lost

Where customers manage accounts, renew, change plans and buy add-ons. No new hosting is sold here, so order values are much lower — but this is where retention revenue lives, which makes it a revenue surface even though it is budgeted as a support cost.

Failed transactions

Last 30 days, unique customers. Every row is someone attempting a transaction that did not complete cleanly.

$11K–$69K a month, needs validation. The top row alone — 303 customers failing to renew — is worth between $10,872 and $69,047 a month depending on what they were renewing ($35.88 median across all subscriptions, $227.88 for hosting). Add the 226 who abandoned a payment-method update and the 94 who could not save a card, and this surface holds more unpriced exposure than anything on the front of site. None of it appears in the $192K new-hosting figure, because renewals are not new business.

What the customer was trying to do	Signal	Customers
Renew their subscription confirm-renewal endpoint erroring every day since 21 July	Network error	303
Update a payment method Form abandoned on Manage Payment Methods	Form abandon	226
Save a new credit card save-credit-card endpoint returning errors	Network error	94
Renew from the cancellation screen Create-invoice link erroring inside the retention modal — the worst possible place for a failure	Error click	59
Complete an order renewal Form abandoned on the Order Renew page	Form abandon	43
Change their hosting plan change-plan/process endpoint returning errors — this is upsell revenue	Network error	40
Change their plan (form) Form abandoned on AMP Change Plan	Form abandon	28
Toggle auto-renew Error clicks on the auto-renew control — the most churn-relevant switch in the product	Error click	27
General navigation Dead clicks across AMP main content — the UX debt already identified in the trial	Dead click	580

Renewal endpoint over time

The clearest argument for behavioral monitoring on this page. Failing every day for two months, and no alert fired — because the servers were up the whole time.

AMP /billing/confirm-renewal failures per day

Since first occurrence on 21 July 2026

58 consecutive days. Roughly 22 failures every day, 303 unique customers in the last 30 days alone. Renewal revenue is not in the new-hosting figures on the summary tab, so this exposure sits entirely outside the $192K.

Marketplace cart

Add-on purchases by existing customers. Order values are materially lower here, since no hosting is sold on this surface.

AMP Marketplace funnel

Last 30 days · unique users

The story is step one. 3,319 existing customers browsed the Marketplace and 143 reached a cart — 4.3%. Once they reach the cart they almost all proceed (96.5%). Whatever is losing people happens in the Marketplace itself, well before checkout.

Order confirmations observed

Unique customers reaching the AMP order-completed page, 30 days

1,669

the only purchase signal instrumented anywhere

Reached by AMP-native orders only. Neither cart lands here, so this is not a company-wide conversion count — it is the closest thing that exists, which is the point.

Marketplace order value

Measured, not assumed. Fullstory carries no revenue event, so these figures were read directly off the order-confirmation screen in 14 sampled sessions, drawn from the 102 confirmed Marketplace orders in the last four weeks. Every sampled order is itemised below and traceable to its confirmation ID. The September order export has since confirmed the figure independently: of 357 add-on-only carts, the 243 under $50 average $16.38 and the full set has a median of $23.20.

Marketplace AOV in use ?

$25

Corroborated twice: $22.84 from replay, $23.20 median from the order export.

Sampled paid orders ?

$22.84

Median $21.31. Range $5.82–$41.99. Blended with free orders: $11.42.

Orders that cost nothing

50%

7 of 14 sampled orders totalled $0.00.

Implied 4-week Marketplace value

~$1.2K

102 orders × $11.42. That is 0.6% of September new hosting revenue.

The finding that matters more than the average: half of all Marketplace orders are free — dedicated IPs against existing credit, and domain transfers on promotion. The Marketplace is running largely as an entitlement-fulfilment surface rather than a revenue surface. Any argument for investing in it should be made on retention and support-deflection grounds, not on the add-on revenue it generates.

Order	What was bought	Total
92384	Domain Name Transfer + Domain Privacy	$41.99
92403	Domain Name Transfer + Domain Privacy + tax	$40.74
92410	Domain Name Transfer	$23.00
92407	Monarx Security, 1 month + tax	$21.31
92414	Domain Privacy	$15.99
92397	Softaculous, prorated	$11.01
92406	Snapshot Storage Container, prorated	$5.82
92413	Dedicated IP × 3 — free on credit	$0.00
92401	Dedicated IP — free	$0.00
92393	Dedicated IP — free	$0.00
92391	Dedicated IP, 3 year term — free	$0.00
92368	Dedicated IP — free	$0.00
92392	Domain Name Transfer — free	$0.00
92217	Domain Name Transfer — free	$0.00

These figures exclude every modal checkout. Email products (InMotion Hosting Email / Titan) check out through a modal that never changes the URL and never reaches a confirmation page, so none of those orders are in the sample above. Their published pricing is $2.00, $3.00 and $6.99 per mailbox per month — small recurring subscriptions rather than one-off purchases, which would pull the per-order average down while adding recurring value the per-order figure does not capture. Exact totals are not recoverable: the modal is absent from session replay, and mailbox quantities are masked.

What this does and does not size. These values cover Marketplace add-on purchases only. Renewals do not pass through this cart — they run through the billing flow, and a renewal is a hosting plan, not a $23 add-on. So the 303 customers hitting renewal errors are not sized by the figure above, and their exposure is almost certainly far larger. That number can be measured the same way, from the renewal confirmation screen, and has not been yet.

Method: every figure here was read from the rendered confirmation page of a recorded session — no revenue event, no data warehouse, no engineering ticket. It also shows that on-screen values Fullstory already captures can be turned into revenue data on demand, which is the capability the Revenue Event would make permanent instead of manual.

Method and assumptions

All behavioral figures pulled from Fullstory via the MCP connector on 17 September 2026. Funnels, metrics and segments created during the analysis are saved in the org prefixed [MCP] and can be opened and challenged directly.
Revenue figures are InMotion's own September new-hosting report (16 days actual, pacing to month end). They exclude add-on and renewal revenue, so AMP exposure sits outside them.
The Submit Order rate comparison uses a Fullstory segment of users who hit the order/save error, measured against the Order Process funnel's own baseline over the same window.
Front-of-site order value is measured from the September order-tracking export, not from Fullstory: cash collected on the 373 carts containing hosting between 1 and 16 September, divided by those carts. It includes add-ons and domains purchased in the same cart and excludes upgrades, downgrades and term changes. Fullstory recorded 332 confirmation views against those 373 orders, which is where the 89% capture rate comes from.
Customer counts are unique users and may overlap where one person hit more than one signal.
No conversion or revenue event exists in Fullstory, so no figure here proves a lost sale. Every causal claim is labelled as an inference.