Questions merchants actually ask.

Before You Go is a product discovery recovery tool for Shopify and Shopware stores. When a visitor lands on a product page and decides to leave without buying, the app catches the moment they navigate away and shows a full page of personalized recommendations rendered natively inside the store's theme. The recommendations come from precomputed product affinities — what similar visitors actually viewed, clicked, and purchased — rather than from generic bestseller lists. The job isn't to talk the visitor out of leaving. It's to surface alternatives the store already sells, in the moment the visitor is still in research mode.

A popup overlays the page the visitor was already looking at. The recovery page replaces it. There is no modal chrome, no overlay shadow, no close button, no dismiss-and-leave-anyway pattern. The page is rendered natively inside the store's own theme using the store's product card snippet, so it reads as part of the catalog rather than a third-party widget. The visitor sees a full page of products organized by behavioral signal, not a discount wheel or an email capture form. Different shape of object, different question being asked.

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. A small JavaScript asset on every storefront page intercepts the back navigation, and only then does the recovery page render. If the visitor never tries to leave, the page never fires. If the visitor leaves through any path other than the back button, the page also doesn't fire. The intervention is tied to a real exit signal, not a predicted one.

A full page rendered inside the store's own theme: header, footer, fonts, product cards — all the same building blocks the rest of the storefront uses. The page itself shows a grid of product recommendations selected for that visitor based on what they were looking at and what similar visitors purchased. There is no discount banner, no countdown timer, no email capture. The visitor either finds something else they want from the catalog, or they continue with the back navigation they originally intended.

A scoring engine blends four signals computed nightly from the store's behavioral data: co-views (weight 0.45), co-clicks (0.30), content similarity from a transformer model (0.20), and co-purchases (0.05). Co-views dominate because they are the most abundant signal on most stores; co-purchases are weighted lowest because they're rare on the smaller stores where the engine matters most. The output is a ranked list of products that visitors with similar paths actually engaged with — not a generic bestseller list, and not a category-based widget.

Yes. The app installs as a native theme app extension and renders the recovery page using the store's own product card snippet, so cards inherit the theme's typography, spacing, hover states, and currency formatting. During setup the app walks the theme's collection template to find which snippet renders the product cards in the products section, then uses that same snippet on the recovery page. Themes that use the newer block-based templates fall back to a default card that still respects the theme's colors and fonts.

Yes. On Shopware the recovery page is rendered through Storefront Scripts inside the Twig template engine, so it runs natively in the storefront rather than in an iframe or an overlay. The integration uses the same scoring engine, the same attribution logic, and the same admin dashboard as the Shopify version. The only difference is the rendering layer — Twig instead of Liquid — so the visitor experience and the merchant experience are the same on both platforms.

About two minutes from the app store. One click to install, the OAuth handshake completes, and the theme app extension is added automatically. There's no theme code to edit, no snippet to paste, no developer involvement. After install the app spends a few minutes in the background syncing the product catalog, detecting which product card snippet your theme uses, and computing the first round of recommendations — that part you don't have to wait for. The recovery page starts firing on the next product-page back navigation.

The on-page footprint is a small minified JavaScript asset that loads asynchronously and does almost nothing on most page loads — it only does work when the visitor actually triggers a back navigation from a product page. There's no blocking script, no synchronous network request, no heavy third-party SDK. The recovery page itself is a separate route, so it doesn't add weight to the product page that loaded it. Core Web Vitals on the host pages should be unaffected.

Typically no. The script only listens for a back-navigation signal on product pages and only fires if that signal arrives. It doesn't hook into the cart, the checkout, the search bar, or any other app's surface area. Popup tools, email capture tools, review widgets, and analytics scripts run independently. The one case worth knowing about is if another app is also intercepting history navigation on product pages — uncommon, but if you see something odd, the support team can check the order of script execution with you.

Session-based click attribution. When a visitor clicks a product on the recovery page, the app stores a timestamp on their device. If an order from that visitor arrives within the same shopping session, the app credits the order to the recovery page. Orders from visitors who never saw the recovery page, or who saw it but didn't click anything, or who returned much later in a separate session, are not attributed. The deliberate intent is to undercount rather than overcount, so the dashboard number is closer to the orders the recovery page actually contributed to.

No. The pricing is a flat monthly subscription. You keep one hundred percent of the revenue your store earns from the recovery page. The plan tiers are gated by how much recovered revenue the app produces in a given month, not by a percentage taken off the top. There are no per-order fees, no per-impression charges, no commission on attributed orders, and no escalating overage fees if you exceed the cap.

The subtotal of orders that meet the attribution rule above: a visitor saw the recovery page, clicked a product on it, and an order from that visitor landed in the same session. Recovered revenue is the sum of those order subtotals in your store's currency, converted to USD for the plan cap. It does not include orders that happened to arrive after a recovery page impression without a click. It does not include orders attributed by a 30-day last-touch window. The number on the dashboard is the same number that counts toward your plan's revenue cap.

Yes. The Starter plan is free forever, with no time limit and no credit card required. It is capped at $149 of recovered revenue per month, which is enough for most small stores to confirm the recovery page works on their actual catalog and traffic before deciding whether to upgrade. All the core mechanics are included: traffic-source targeting, native theme rendering, click-based attribution, and the dashboard. The cap exists so the free plan isn't a backdoor for high-revenue stores to use the app indefinitely without contributing.

The recovery page stops firing for the rest of the month. It resumes automatically on the first day of the next billing cycle, or immediately if you upgrade to a higher tier. There are no overage charges, no surprise bills at the end of the month, and no commission on revenue beyond the cap. The cap is the same definition you see on the dashboard, so when the dashboard says you've hit it, the dashboard is right.

Yes. There's no contract and no minimum term. Cancel from your store's app management screen on Shopify or Shopware, the subscription stops at the end of the current billing period, and the app removes itself cleanly. You're not charged a cancellation fee, and any historical data the app collected can be exported or deleted on request.

No personal data. The app stores a randomly generated session UUID in the visitor's localStorage so it can match a back-navigation event to the same visitor's later checkout. There is no email address captured, no name, no shipping address, and no advertising identifier. The session UUID is not joined with any external identity graph and isn't shared with third parties. Order data the app receives from the store webhook contains the order ID and subtotal — used for attribution accounting — and is retained according to the privacy policy.

No. Before You Go isn't an email tool. The app doesn't capture visitor email addresses, doesn't send abandoned-cart emails, doesn't run a mailing list, and doesn't integrate with email marketing platforms as a sender. The recovery page exists entirely on the storefront, in the moment the visitor is about to leave. If email is the right channel for a particular visitor segment, a dedicated email tool is the better choice — the two categories solve different parts of the funnel.