What is Back Redirect and when to use it on your checkout

The customer reached the checkout, had second thoughts and clicked "back". In most stores, that sale is lost right there. Back Redirect is a technique created to give that moment one last chance.

What is Back Redirect

Back Redirect is a technique that sends users to a new page when they click the browser's back button. Instead of returning to the previous page, they see a page chosen by the store owner, usually with an offer to recover the sale.

It's common in e-commerce and direct response offers, mainly on conversion pages: cart, checkout, payment and order completion.

How it works

Browsers keep a history of visited pages. Back Redirect uses the browser's History API to add an extra entry to that history when the page loads. When the user clicks "back", the page detects the navigation and sends the visitor to another address instead of letting them leave.

In practice, the redirect usually leads to:

• a downsell offer, with a lower price or a simpler version of the product;
• a discount or bonus to complete the purchase now;
• a better-value bundle;
• new payment methods, such as enabling Pix and boleto in Brazil for customers who got stuck on card payment;
• a page that addresses the most common objections of people who drop off at checkout.

Benefits of Back Redirect

High bounce rates on purchase pages are one of the biggest challenges in online sales. By showing something appealing right when the customer gives up, Back Redirect turns some of those drop-offs into orders. The main benefits are:

• more sales, by recovering customers who were already at the end of the funnel;
• lower bounce rates on conversion pages, since visitors get a new proposal instead of simply leaving.

Script example

Below is a Back Redirect script commonly used on checkout pages. It goes in the HTML of the page where the redirect should happen:

<!-- Back Redirect -->
<script>
  !(function () {
    var url = window.location.href;
    url = url.split("?");
    var t;
    try {
      for (t = 0; 10 > t; ++t) history.pushState({}, "", "");
      onpopstate = function (t) {
        t.state &&
          location.replace(
            "https://example.com/special-offer?" + url[1]
          );
      };
    } catch (o) {}
  })();
</script>

What each part does

• !(function () { ... })();: a function that runs itself as soon as the page loads (IIFE). It keeps the script's variables from leaking into the rest of the page. The leading ! just makes the browser treat the function as an expression and run it right away.
• var url = window.location.href; url = url.split("?");: takes the current address and splits it into two parts: before and after the ?. So url[1] holds the URL parameters, such as utm_source, utm_campaign and click IDs.
• for (t = 0; 10 > t; ++t) history.pushState({}, "", "");: adds 10 fake entries to the browser history, all pointing to the same page and without reloading it. Each one gets an empty object {} as its "state". In practice, the user would have to press back several times to really leave.
• onpopstate = function (t) { ... }: registers a function the browser runs whenever the user navigates through history, for example by pressing back.
• t.state && ...: checks whether the entry the user went back to is one the script created. Those entries have the state {}, which counts as true; the page's original entry has a null state. The redirect only happens in the first case.
• location.replace("https://example.com/special-offer?" + url[1]): sends the user to the offer page and passes along the original URL parameters, so pixels and tools like RedTrack keep the sale's attribution. replace swaps the current history entry instead of creating a new one.
• try { ... } catch (o) {}: if something goes wrong (an old browser or an environment that blocks the History API), the error is ignored and the page keeps working normally.

Things to watch in this script

• ?undefined without parameters: if the page is opened with nothing after the ?, url[1] is undefined and the redirect goes to ...special-offer?undefined. Using window.location.search fixes it.
• 10 history entries: flooding the history with fake entries is exactly the behavior browsers fight against. Chrome skips entries created without user interaction, and ad platforms may disapprove the page. One entry is enough to detect the back click.

A leaner version

<!-- Back Redirect -->
<script>
  (function () {
    var redirectUrl = "https://example.com/special-offer";

    try {
      // Adds a single extra history entry pointing to the same page
      history.pushState({ backRedirect: true }, "", window.location.href);

      // On back, go to the offer while keeping UTMs and click IDs
      window.addEventListener("popstate", function () {
        window.location.replace(redirectUrl + window.location.search);
      });
    } catch (error) {
      // Unsupported browsers keep the normal behavior
    }
  })();
</script>

It does the same with a single history entry, passes parameters along only when they exist, and documents what each part does in comments. Add the script only to pages where the redirect makes sense, such as the checkout, and never to institutional or content pages.

When it makes sense

• Checkouts with high abandonment: if many customers reach payment and give up, an alternative offer can recover part of those sales.
• Offers with a clear downsell: it works best when there's a real alternative for people who found the main offer too expensive.
• Traffic that has shown intent: someone who reached the checkout is close to a decision, so a second proposal has a better chance than on a top-of-funnel page.

What to watch before implementing

Back Redirect changes a behavior users expect to be predictable. Used carelessly, it can backfire.

• User experience: stopping someone from leaving feels odd and frustrating. The destination page must offer something genuinely useful, and users should be able to leave if they want to.
• Audience profile: some audiences welcome a second offer; others see the technique as pushy and lose trust in the brand. If your customers tend to get annoyed by it, the technique backfires.
• Ad policies: ad platforms have rules about landing page experience and may disapprove pages that make navigation harder. Review the policies of the platform you use before going live.
• Browser behavior: browsers such as Chrome now skip history entries created without user interaction. That means the technique may not work for every visitor, and results need to be measured.
• Measurement: compare conversion rate, chargebacks and complaints with and without Back Redirect. If recovered sales come with more refunds, the math doesn't work.

Back Redirect and post-purchase

Recovering a sale at checkout is only half the job. A customer who bought after a second offer needs a clear post-purchase experience so they don't regret it and open a dispute. We cover this in How a post-purchase membership area reduces chargebacks.

Want to learn other industry terms? Check out our direct response marketing glossary.