How it works
A small JavaScript on every product page. A full-page recovery experience, native to your theme. Conservative attribution that only counts orders where someone actually clicked a recommendation.
Most exit-intent tools guess. They watch the cursor, the scroll, the seconds-on-page, and fire a popup before the visitor has actually decided. Before You Go waits for the real thing. When a visitor on a product page hits the back button — the actual navigation, not a predicted one — the recovery page renders in place. No overlay. No popup. No “wait! don't leave!” interruption. The departure is real, and the page that meets it is too.
A middleware chain decides whether the recovery page should fire: traffic source, frequency caps, subscription status, app-enabled flag. Paid traffic is exempt by default — you already paid for that click, no need to second-guess it. Repeat visitors are skipped. The recovery page only shows up where it's actually useful.
A two-stage page: skeleton first, then async-loads product cards — session-based, AI-boosted, or popularity-based depending on what signals are available. Recommendations come from precomputed product affinities (co-views, co-clicks, co-purchases) with content similarity from a transformer model as a fallback.
Clicks are tracked. Orders are attributed only when the visitor clicked a recommendation within the session. No referrer guessing. No last-touch inflation. The number in your dashboard is the number of orders that actually came through the recovery page — smaller numbers, more trustworthy.
Common questions
The mechanic above covers the happy path. These are the questions that come up about everything around it.
On an actual back-button navigation away from a product page. Not on a cursor-leave guess, not on a scroll threshold, not on a seconds-on-page timer. The script intercepts the real history navigation, so the recovery page only fires when the visitor has actually decided to leave. If they keep browsing, switch tabs, or close the window, the page never appears. Tying the intervention to a real signal rather than a predicted one is the whole point of how the detection layer works.
Once per visitor per cooldown window, not every back-navigation. The frequency cap defaults to a sensible window so a returning shopper isn't shown the recovery page repeatedly across multiple sessions. The cap is configurable per shop. The behavior is symmetric for the holdout group used for incrementality measurement, so a visitor who got the recovery page once won't be re-eligible until the window resets.
Off by default for paid traffic. The middleware chain inspects the referrer, the UTM parameters, and the click identifiers (gclid, fbclid, msclkid, ttclid, twclid, pinclid) and skips paid traffic unless you explicitly enable it. The reasoning is simple: you've already paid for that click, and the recovery page should be earning incremental visits from organic and direct traffic where the back-navigation is more likely to be discovery friction rather than wrong-fit traffic. Per-source toggles are available if you want to override the default.
The script is a first-party theme asset on Shopify and a first-party Storefront Script on Shopware, so it isn't blocked by the standard ad blocker filter lists that target third-party trackers. The recovery page itself is served from the store's own domain via the app proxy, not from a third-party domain. Visitors with aggressive privacy extensions that block all JavaScript will not see the recovery page, but those visitors are also not seeing most of the rest of the storefront's interactive elements either.
No. Recommendations are anchored to the product the visitor was on when they hit back, blended with what similar visitors viewed and clicked. A different anchor product produces a different recommendation grid. The scoring engine also re-ranks based on what the visitor has already seen in the current session, so a returning visitor sees a different mix than a first-time visitor. For shops with sparse data the system falls back to popularity and content-similarity scoring rather than repeating an empty grid.
Yes. The recovery page renders inside the store's own theme, so it inherits the store's currency formatting, locale, and number conventions automatically. The UI strings (button labels, headings) are localized into eight languages with shop-level overrides if a particular phrase needs a different translation. Multi-storefront setups that route different markets to different theme variations are supported — the recovery page picks up the active market's locale from the storefront context.
No credit card. Native to your theme on day one.
Free Starter plan. 7-day trial on paid plans. No credit card.
