At the end of 2022, the entire frontend community was surprised by an unexpected announcement: [Shopify acquired Remix](https://shopify.engineering/remix-joins-shopify). At first glance, this news offers little information; after all, Shopify is famous for investing many resources into open-source projects. However, after further research, the reason for this merger became clear: Remix is deeply aligned with Shopify’s new framework: Hydrogen.

Shortly after the big news, the dev team behind Hydrogen [made another announcement](https://hydrogen.shopify.dev/roadmap/): the entire framework was being re-created from scratch using Remix, thus giving birth to Hydrogen v2. While the upgrade path will likely be a struggle for existing Hydrogen v1 users, Hydrogen v2 offers several benefits over its predecessor.

In this article, we’ll look at some of the most significant enhancements Hydrogen v2 brings to the developer experience, what they mean for your user experience, and how you can start adopting them in your storefront.

## A Brief Primer on Remix

To fully comprehend Hydrogen’s latest changes, we must first understand Remix.

For those unfamiliar with it, Remix is an up-and-coming Javascript framework based on React. It was developed by Kent C. Dodds, Ryan Florence, and Michael Jackson, all well-known contributors to the Javascript open-source community.

Unlike the previous generation of React frameworks such as Next.js, Remix is full-stack, monolithic, and fully server-side-rendered, and it will feel like a breath of fresh air to all the Ruby on Rails and Laravel lovers. In fact, Remix’s primary goal is to merge the benefits of the “old Web” with the smooth developer experience React offers. This way, developers get higher productivity, simpler code, better SEO, less backend-frontend communication overhead, smaller client bundles, and near-instantaneous page transitions.

![](https://cdn.sanity.io/images/kqgmf0g2/production/030082583dd37bf225378d98322d8b1993cf3e0b-2960x2400.png?fit=clip)

When developing the first version of Hydrogen, Shopify created a framework very similar to Remix in spirit: it was React-based, but it was also rendered on the server. This was a surprising choice back in the early days of Hydrogen, but it did make a lot of sense in retrospect: anyone who has tried to implement an eCommerce storefront quickly found that the dynamic nature of eCommerce doesn’t play well with static site generation and client-side rendering.

In October 2022, Remix announced that Shopify was acquiring it. As part of the deal, Shopify will offer continuous support to Remix’s authors to continue developing the framework, and Remix is becoming the React framework powering Hydrogen. On their side, Hydrogen’s development team can now delegate most of the core framework functionality to Remix, focusing only on Hydrogen-specific functionality.

## The Main Changes in Shopify Hydrogen v2

Even though the Shopify developer community (and Shopify themselves, [in some places](https://github.com/Shopify/hydrogen/blob/2023-04/packages/hydrogen/CHANGELOG.md#202317)) dubbed this release “Hydrogen v2”, this isn’t technically correct: Hydrogen simply follows calendar versioning, with each version number being a combination of the date and month of the release (e.g., v2023.1.0). However, for the sake of simplicity, we will refer to “Hydrogen v2” as the version of Hydrogen that uses Remix.

As you might expect, this release introduces _a lot_ of changes. In fact, pretty much everything in the framework has changed, meaning developers with an existing Hydrogen storefront have a whole bunch of rewriting to do.

### Retrieving Data with Loaders

The most significant change–which will affect pretty much every route in your project–is the introduction of Remix’s `loader` function.

The `loader` function is where all of your data retrieval logic is stored. The `useShopQuery` and `useQuery` hooks from Hydrogen v1, responsible for querying the Shopify Storefront API, have been replaced with `loader` in Hydrogen v2.

For example, imagine building a product detail page with a product options selector. In a typical React storefront, you would need to store the selected options in a state entry:

![](https://cdn.sanity.io/images/kqgmf0g2/production/e553a7b7b1f1e0d77e3cd95a9ecef7a1893b29c9-1200x520.png?fit=clip)

The problem with this implementation is that this component also needs to change the URL whenever a new variant is selected, so that users can easily bookmark or share the URL to the correct product variant. Unfortunately, there is no “native” way of achieving this with React. You would need to create a function that alters the URL when the user changes their selection.

With Remix, just like Ruby on Rails or Laravel, you can solve this by simply taking advantage of Web fundamentals. In this case, whenever the user selects a new product option, you simply direct them to a new URL, and the `loader` function gets executed again, querying the desired product variant from the Storefront API.

![](https://cdn.sanity.io/images/kqgmf0g2/production/3217fe54a31e57a20a6240808dd00e4937c4f7eb-1200x856.png?fit=clip)

The benefits of this new implementation are clear: we achieve the same outcome with less code and fewer abstractions to learn.

This approach was used to refactor all the major components in Hydrogen: the cart, analytics, SEO, and session management were rebuilt from scratch, resulting in a much more straightforward developer experience and a less steep learning curve!

[Learn more about the `loader` function in the Remix guides.](https://remix.run/docs/en/1.16.1/route/loader)

### Mutating Data with Actions

While the `loader` is used to _retrieve_ data, the `action` function is to _mutate_ data. As a consequence of segregating business logic into loaders and actions, you can now remove a bunch of code, especially client-side logic and state.

As an example, take a look at what the default `AddToCart` component looks like in the Hydrogen v1 demo store:

![](https://cdn.sanity.io/images/kqgmf0g2/production/253be981f9a0861351e4e2bcba39e77df56fec53-1374x2904.png?fit=clip)

And now, look at the same component in the Hydrogen v2 demo store:

![](https://cdn.sanity.io/images/kqgmf0g2/production/5c38c039f5c5132d9b9ba34c6d19d0b0075b7f0b-1424x1786.png?fit=clip)

As you can see, a lot of state management and querying logic has been removed in favor of a more straightforward implementation that relies on Web fundamentals such as... Web forms! This simplifies your code and makes your online store more resilient to network issues and more accessible to screen readers and old devices.

[Learn more about the `action` function in the Remix guides.](https://remix.run/docs/en/1.16.1/route/action)

### Handling Errors with Error Boundaries

A common and annoying problem with React applications is isolating errors. Typically, when you get any error on the frontend, the whole UI breaks, and the website becomes unusable. This is obviously not a desirable experience for our customers.

By taking advantage of Remix’s [nested routes](https://remix.run/docs/en/1.16.1/guides/routing#what-is-nested-routing), you can use [nested error boundaries](https://remix.run/docs/en/v1/guides/errors#nested-error-boundaries). If you export an error boundary function from a nested route and an error occurs, the error will be isolated, and the rest of your application will remain usable. This allows you to offer the best possible UX, even when things go wrong:

![](https://cdn.sanity.io/images/kqgmf0g2/production/e73f3849c1e52c9a44c721ff4b43976455174ab8-1207x1685.png?fit=clip)

[Learn more about error handling in the Remix guides.](https://remix.run/docs/en/1.16.1/guides/errors)

### Speeding Up Page Loads with Streaming

By using Remix’s [defer](https://remix.run/docs/en/1.16.1/guides/streaming#using-defer) function, you can easily decide which parts of your page should be rendered right away and which parts can be streamed after the page has loaded:

![](https://cdn.sanity.io/images/kqgmf0g2/production/d1fc77778b2760be478d391326acc7ede28f1abe-1207x1685.png?fit=clip)

This technique allows you to easily defer the loading of lower-priority parts of your UI, such as a “Related products” section on your PDP, making for a better user experience and faster loading times.

[Learn more about streaming in the Remix guides.](https://remix.run/docs/en/1.16.1/guides/streaming)

### Speeding Up User Interactions with Optimistic UI

Optimistic UI is a powerful technique that lets you completely hide loading states from the end user. For instance, when a user clicks on your Add to Cart button, rather than waiting for the cart to be updated on the server, you might immediately display the new item in the user’s cart. Then, if an error occurs, you can revert the state and display an error to the user:

![](https://cdn.sanity.io/images/kqgmf0g2/production/1cdb09cad49d184358eb840920173250a2061bc1-1250x800.png?fit=clip)

While not available yet, Hydrogen’s development team plans to adopt optimistic UI in all the standard components. Because Hydrogen is powered by Remix, you will also have the opportunity to use the same pattern in any custom user interactions you offer on your storefront.

[Learn more about optimistic UI in the Remix guides.](https://remix.run/docs/en/1.16.1/tutorials/jokes#optimistic-ui)

### Oxygen Is now Available to All Shopify Plans!

Although there was no official announcement, this is massive news for all Shopify developers! Hydrogen’s official deployment platform, [Oxygen](https://shopify.dev/docs/custom-storefronts/oxygen), which was only available to Shopify Plus users, is now available to all Shopify plans.

Oxygen is an excellent tool for engineers who want a seamless deployment and hosting experience. By keeping your storefront within Oxygen, you can not only reduce your infrastructure costs, but also have access to a fantastic developer experience that includes:

* Preview environments for testing changes in isolation.
* Custom environments (e.g., if you want a staging area).
* Version control and GitOps for your storefront.
* A Content Delivery Network (CDN) powered by Shopify.
* Support for both backend and frontend code.
* CI/CD via GitHub Actions and the Hydrogen channel.

If you’re familiar with Vercel, you’ll find that Oxygen offers a very similar development experience, but more accurately tailored to the needs of Shopify developers.

## Migrating from Hydrogen v1 to Hydrogen v2

If you are using Hydrogen v1 today, there’s a [handy migration guide](https://shopify.dev/docs/custom-storefronts/hydrogen/migrate-hydrogen-remix) in the Hydrogen docs that you can follow to upgrade your storefront.

The process takes a lot of effort, but the guide is comprehensive and accurate, so you should be able to upgrade your Hydrogen app by simply following the steps outlined.

## Is Hydrogen Ready for Production Use Yet?

That depends on your risk tolerance!

On a technical level, both Hydrogen and Oxygen are most definitely production-grade products, and they are being used successfully in the wild by large Shopify stores such as [Allbirds](https://hydrogen.shopify.dev/case-studies/allbirds). The developer experience is pleasant and powerful, and Shopify’s hosting infrastructure will easily handle any production load you throw at it.

On the other hand, it’s unclear whether Hydrogen will see any more extensive refactorings, such as the one we’ve just witnessed. As an example, [Remix v2](https://remix.run/docs/en/main/pages/v2) will be released soon, bringing many improvements over its predecessor, but also requiring developers to upgrade to a new API and file naming convention. These changes will most likely affect Hydrogen users as well. It’s also unclear what synergies Shopify will create between Hydrogen and [Commerce Components](https://www.shopify.com/commerce-components), but we expect some movement there.

![](https://cdn.sanity.io/images/kqgmf0g2/production/e038f0246b07a894d83a8ae5cb1d3fe545d2bc6a-2960x2335.png?fit=clip)

Another factor to consider is how long it will take for the Shopify app ecosystem to catch up to Hydrogen’s philosophy. While some Shopify apps don’t need to worry about the frontend at all, others will have to expose an API or JavaScript SDK of some sort to be usable with a headless commerce architecture. We expect the situation to improve over the coming years, but there’s still a long way to go, and many Shopify apps today cannot be used with Hydrogen.

Overall, Hydrogen is well worth a try if you have the engineering firepower. It solves a significant number of problems for Shopify developers and gives brands unmatched flexibility in building a custom storefront, allowing them to create shopping experiences that would be very hard to replicate with Liquid themes.

However, if you’re a small brand and don’t have the resources to invest in experimental technology, you’re probably better off sticking with Liquid themes until Hydrogen becomes a true first-class citizen in the Shopify ecosystem.

Shopify Just Released Hydrogen v2. What’s In It for You?

The modern direct-to-consumer brand has potential access to a plethora of information about their customers: post-purchase surveys, CSAT scores, site analytics, [A/B testing](https://nebulab.com/blog/ecommerce-ab-testing), market research… Often, it can all be a bit too much, with brands not being sure how to use this information in a structured and strategic way to scale their business.

Luckily, that is precisely the problem product management was born to solve. Product management is the job of defining _what_ you should build, _how_ you should build it, and _when_ you should build it. It is a proven problem-solving methodology that allows you to collect and deploy information to work toward your business objectives.

Even though you might not have direct product management experience, you may already be doing some product management. For example, if you are looking at your conversion funnel analytics to understand where users are dropping from your checkout flow and then [running A/B tests](https://nebulab.com/blog/ecommerce-ab-testing) to determine how to improve your conversion rates, you’re doing product management.

In this article, we’ll try to provide you with a more structured approach that will allow you to elevate your product management skills, turning them into a repeatable workflow for identifying, prioritizing, and pursuing the most impactful goals for your brand. These are the same techniques used by behemoths such as [Zappos](https://www.zappos.com/) and [Warby Parker](https://www.warbyparker.com/) to achieve the impressive scale they’ve experienced over the last decade, so you’ll be in good company!

## Understanding and Applying Research Methodologies

At the core of product management lies product research, the practice of collecting data and insights that can inform which problems you should solve and how to solve them best.

Over their career, experienced product managers learn to master various research techniques. You might have heard about some of them–such as A/B testing, customer interviews, and surveys–while others might be more obscure–such as tree sorting, fake door tests, and contextual inquiry. You’re encouraged to do your own research (no pun intended!) and learn more about each technique.

For now, you should know that every research technique exists on two spectrums: quantitative or qualitative and generative or evaluative. Let’s see what that means!

### Quantitative vs. Qualitative Research

Quantitative research is used to collect numerical data, generally through automated techniques such as closed-ended surveys or product analytics. The data is then consolidated and interpreted to identify a problem or opportunity in front of your business.

For instance, if your checkout conversion rate is well below the average for your industry, that might be something you want to work on with your team.

However, the numbers alone might not always tell you exactly _why_ something is happening: your conversion rate might be low because your prices are too high or the user experience of your checkout flow is confusing. That’s where qualitative research comes in.

Qualitative research, on the other hand, is used to collect in-depth information, generally through techniques such as customer interviews or open-ended surveys. The information is then collected, parsed, and distilled by a human being into insights–tiny nuggets of information that have some practical implication for your business.

For instance, if you interview ten customers who dropped out of checkout, and seven of them mention that they weren’t sure when they would receive their order, you might conclude that customers find your order tracking process challenging to understand. You can then use this information when prioritizing your work to improve the conversion rate (more on this below).

Note that quantitative research doesn’t always have to come before qualitative research: you will find yourself going back and forth between the two depending on the problem you’re currently focusing on and how you’re approaching it.

### Generative vs. Evaluative Research

The examples we have made in the above paragraph are all about _generative_ research, which is done to identify a problem to solve or an opportunity to tackle. In generative research, your goal is to gain an intimate understanding of your market, customers, and product to understand _what_ you should build and _when _you should build it.

The research doesn’t stop when you have identified a problem or an opportunity. In fact, that’s just half of the equation. The other half is about using product research to evaluate potential solutions to the situation in front of you. That’s where evaluative research comes in.

In evaluative research, you aim to understand _how_ to solve the problem or tackle the opportunity. This can be done with various techniques, some of which can be generative or evaluative depending on the context: for instance, usability testing can be performed to identify problems with your existing checkout flow, or it can be performed to validate the UX of your proposed redesign.

Mastering some generative and evaluative research techniques will help ensure your work is product-driven end-to-end. Many retailers let the data and insights guide their product roadmap but fail to validate their design solutions. This can lead to doing work that doesn’t move the needle or even moves it in the wrong direction.

### Establishing a Continuous Discovery Practice

While it’s tempting to do product research only when you run out of things to do, the best teams are running research systematically–a practice referred to as “continuous discovery.” Continuous discovery combines automated and manual work to ensure a stream of qualitative and quantitative insights flows into your brand.

There’s no one-size-fits-all approach to continuous discovery, but there are some techniques that we’ve seen work for the majority of eCommerce and direct-to-consumer brands:

* **Post-purchase surveys.** Every eCommerce business should be running post-purchase surveys. At a minimum, you want to ask customers how they found out about you, which will help enrich your attribution data, but you can also use these to collect feedback about other aspects of the customer experience.
* **On-site analytics.** Solid on-site analytics will help you collect valuable first-party data, which you can use to spot challenges and opportunities and validate the effectiveness of new features, products, or UX improvements. The trick is not to overdo it: otherwise, you risk drowning in a sea of metrics.
* **Business reports.** Your eCommerce platform should offer some out-of-the-box reporting that you can use to quickly answer critical business questions, such as where your customers are coming from or what products are driving the most sales. However, you shouldn’t be afraid of implementing custom reports as needed.
* **Continuous interviews.** We’ve left this for last, but it’s arguably the most crucial research technique in your tool belt. You should try interviewing at least two customers a week, asking a mix of generative and evaluative questions about whatever you’re currently working on.

As you’ve seen, the key is embedding little product research opportunities at critical moments of the customer journey so that you don’t have to think about them consciously. If you need more in-depth information about a specific aspect, you can still go out and execute a full-blown research project, but continuous discovery will provide you with a solid foundation to start.

## The 6-Step Process to Accomplish Anything

Now that you understand what product management is and how to conduct product research, you might wonder how to tie these techniques to your business goals in a structured, systematic way. That’s precisely where the Opportunity Solution Tree (OST) comes in.

The Opportunity Solution Tree is a visual framework that helps your team stay focused on the current business goal while also ensuring they’re exploring the entire problem space. Depending on what you’re doing, you can either see the whole picture at a glance or drill down into the nitty-gritty of each project. Furthermore, an OST is designed for continuous optimization and evolution, which makes it the perfect tool in environments where you want to move fast but with intentionality.

![](https://cdn.sanity.io/images/kqgmf0g2/production/f4efe697bad7b33a7525c24f001cf2936087db01-2056x3272.png?fit=clip)

Here’s how you build an OST:

1. **Start from the desired outcome.** This is usually informed by your overarching business strategy. For instance, an outcome might be “Lower the return rate for our online store to 20%.”
2. **Identify opportunities to achieve the outcome.** You will typically do this through generative research. For instance, you might interview ten customers who have returned a product in the last month and find that they got the wrong size. You would then create an opportunity labeled “Customers purchase the wrong product size.”
3. **Brainstorm solutions.** In this phase, involve as many relevant stakeholders as possible: your marketing team, your development team, etc. Use research insights and your team members’ intuition to develop ideas for tackling each opportunity. Ideally, you refine the solutions to 1-3 per opportunity to keep the process manageable.
4. **Design experiments.** Each solution should come with an experiment, which ensures the solution is actually going to tackle the opportunity. This is a crucial step: by adopting a data-informed approach, you’ll eliminate your biases, assumption, and emotional attachment to specific ideas. In some cases, you might want to run multiple experiments to evaluate different aspects of a solution.
5. **Evaluate your solutions.** The next step is to run the experiments you’ve designed to test the validity of your solutions: are they creating the impact you expected? Can you see any side effects to address before moving forward?
6. **Implement the winners.** At this point, you should have a list of solutions your team can implement to achieve the desired outcome!

Here’s a bonus tip: in the OST included above, you might notice that we have broken down the main “Customers get the wrong size” opportunity into two sub-opportunities: “Customers get the wrong size when buying for themselves” and “Customers get the wrong size when buying for others.” This is a common and encouraged practice when designing an OST: you should split your opportunities into the smallest possible size while ensuring that your opportunities are Mutually Exclusive, Collectively Exhaustive (MECE). This will help you work in small chunks, which makes the process faster and more efficient.

The OST is a dead-simple yet incredibly powerful tool that can help you pursue virtually any business goal when appropriately followed. It might not be obvious, but OSTs aren’t limited to your eCommerce site: you can apply this process to improve other areas of your brand, such as fulfillment or customer service. The value of this technique lies in the fact that it forces you to structure your work and follow facts, not intuitions.

## Good Product Management Takes Practice

Most eCommerce companies are skeptical of product management at first. When you’re a small startup, every bit of process you add to your day-to-day seems like a luxury you cannot afford.

And yet, we’ve seen time and again that the brands with a clear vision and strong product management fundamentals to execute it are the ones who thrive: they exhibit lower customer acquisition costs, higher retention rates, and higher average order values. Most importantly, they move more quickly and intentionally than their competition.

You might be very excited to go out and try the new techniques you’ve just learned, and we very much encourage you to do so. However, remember that we’ve barely scratched the surface of product management in this article: while the fundamental principles are relatively simple, product management remains a vast discipline.

We have not said anything about when to use which research technique, how to develop an overarching product strategy rather than simply tackling one outcome at a time, what systems and tools are best to collect the outcomes of your research, and many other aspects that take years of practice to master fully.

If you’re curious to try product management or already have a product-driven approach and want to take it to the next level, we’re happy to help!

Supercharge Your DTC Performance with Product Management

With the rising cost of advertising and inflationary pressures making it hard to acquire, activate, and retain customers profitably, direct-to-consumer (DTC) brands are increasingly looking for ways to lower operating costs and scale more efficiently. This often takes the form of wholesale partnerships or marketplace expansions, which allow brands to tap into existing audiences and offload last-mile distribution.

We strongly believe a wholesale motion should be a crucial part of any modern brand’s go-to-market strategy. However, the DTC channel offers several opportunities that would allow brands to disengage from performance marketing as their only methodology of customer acquisition. At the same time, DTC brands can benefit from unique advantages, such as end-to-end control over the customer experience and direct access to zero- and first-party data.

This article will explore product-led growth, a methodology adopted by startups such as Dropbox, Slack, and Zoom to achieve low-cost, exponential growth. We’ll unpack the fundamentals and benefits of product-led growth, how it can be applied to eCommerce and DTC, and how you can take your first steps toward establishing a product-led growth strategy for your DTC presence.

## What Is Product-Led Growth?

Product-led growth (PLG) is a business methodology originally popularized by [OpenView](https://openviewpartners.com/) in 2016. It consists of techniques that allow you to shift away from spending marketing dollars to capture and retain customers, letting your product do the selling instead.

In contrast to more traditional approaches, such as market-led and sales-led growth models, companies that adopt product-led growth put their product experience at the center of the brand journey and take a product-first approach to scale their revenue and customer base.

They also automate secondary functions such as customer success and invest heavily in self-serve onboarding experiences, which allows potential customers to experience and play with the product before committing to the purchase.

For SaaS startups, this can take different forms, such as: offering customers a free trial, taking them through a self-guided onboarding tour, automating customer support, or facilitating word-of-mouth by rewarding customer referrals.

A well-executed product-led growth strategy has numerous benefits:

* **Lower Customer Acquisition Cost (CAC):** by letting your product and existing customer base do the selling and relying less on marketing campaigns, brands can reduce their CAC.
* **Higher Lifetime Value (LTV):** product-led growth leads to more engaged customers, which exhibit a higher Average Order Value (AOV) and Repeat Purchase Rate (RPR), making for a higher customer lifetime value.
* **Higher Revenue per Employee (RPE):** by automating as much as possible of the customer journey, you can lower your operating costs and free up resources to focus on more strategic initiatives.
* **Deeper customer understanding:** to adopt a PLG strategy, you’ll need an intimate knowledge of your customer base. This positively impacts all areas of the business, such as your fulfillment, customer service, and marketing teams.
* **Improved team alignment:** since product-led growth encompasses the entire organization, team members in a PLG company are more aligned and focused than marketing-led or sales-led teams, which makes them happier and more efficient.

As you can see, product-led growth allows you to create a flywheel that positively impacts key metrics across all areas of your organization. As you become more experienced at practicing product-led growth, you’ll start seeing the world through a different lens: rather than relying exclusively on paid acquisition channels, you will begin experimenting with ways your product can generate traction and create efficiencies.

## Does Product-Led Growth Apply to eCommerce?

The answer is: it depends. While product-led growth has been initially designed for traditional software companies, you can–with some creativity–adapt many of its elements to work for the business model and customer journey of an eCommerce/DTC brand.

For an eCommerce brand to become a product-led company, you must broaden your perspective of what constitutes your “product.” Many brands identify this directly with their physical product and consider the rest of the shopping experience an implementation detail. This mindset severely limits your ability to benefit from a product-led growth strategy.

![](https://cdn.sanity.io/images/kqgmf0g2/production/16f5b011c01d62e0d9a223638a5fc607bf5a84df-2560x2402.png?fit=clip)

Instead, product-led brands consider every customer touchpoint part of their product, and they’re constantly thinking about how to create new touchpoints to engage, activate and retain the customer. Here are a few examples of brands that are using techniques borrowed from product-led growth:

* Vitamin brand [Care/of](https://careof.org/) has a [mobile app](https://apps.apple.com/us/app/care-of/id1273387955) that allows to personalize their subscription plan, track their vitamin and health routines, and get rewarded for consistency. The app allows potential buyers to experience Care/of’s product’s value while building further engagement with established/active users.
* Swiss sportswear brand [On](https://www.on-running.com/) recently released [Cyclon](https://www.on-running.com/en-us/collection/cyclon), a program that allows customers to “subscribe” to specific products, such as running shoes and tees. They have taken a sporadic event, such as buying a new pair of shoes, and turned it into a SaaS-ified experience that boosts customer retention.
* Rather than asking customers to pay for their orders upfront, apparel brand [Stitch Fix](https://www.stitchfix.com/) allows subscribers to try outfits and only pay for what they keep. This allows customers to experience the value of the brand before committing.

Subscription-based and membership-based brands have an inherent advantage over brands that favor a one-time purchase journey. This is because they start with a much larger “surface area” to engage their customers. However, brands that don’t have a subscription or membership program–and have no intention of establishing one–can still see success by borrowing and implementing individual elements from product-led growth.

## Embracing Product-Led Growth for Your Brand

Brands looking to start with product-led growth often get discouraged by the number of initiatives they could experiment with. If you’re coming from a traditional marketing-led approach, it can be hard to adopt the right mindset. 

If you don’t know where to start, an excellent first step is to map customer touchpoints across different stages of your shopping funnel and user experience, from brand awareness to order fulfillment. There are a few ways to do this:

* Involve stakeholders from different departments to understand how they interact with the end-user, directly and indirectly.
* Talk to your most loyal (and least loyal!) customers to collect feedback on how your brand fits into their day-to-day, their current pain points, and any ideas they might have.
* Look at quantitative analytics to uncover usage and engagement patterns.

The more feedback and data you can collect, the more holistic your understanding of your brand-customer relationship will be, and the more opportunities you’ll uncover for a product-led growth transition!

Once you have your customer touchpoints mapped out, look at each critically and ask yourself the following questions:

* **How can you command a greater share of customer attention?** Many DTC brands have a transactional relationship with their customers and fail to invest in a longer-term relationship. In reality, zero-party and first-party data allow most brands to create deeper connections: what are some “aha” moments you can generate?
* **How can you deliver value before capturing value?** For a DTC brand, this often takes the form of content-driven education or offering a tool that helps customers enter your brand’s world and experience its value _before_ a traditional activation. Sneaker marketplace [The Edit](https://www.theeditldn.com/), for example, provides a free [personal shopping service.](https://www.theeditldn.com/en-eu/pages/personal-shopping-service)
* **Can you create efficiency by investing in automation?** This is often more nuanced than a simple yes-or-no answer. Any investment in automated/self-service workflows must offer a justifiable return on team efficiency or customer engagement (or both!). Generative AI, in combination with low-code/no-code platforms, creates some fantastic opportunities to automate customer service, product quizzes and similar while mainaining a human touch.
* **How can you spark virality?** Product-led companies are masters at making their products viral. eCommerce brands have many opportunities in front of them: packaging, transactional notifications, and even customer service interactions can become ways to generate positive word-of-mouth.

If you come up with an endless list of initiatives, don’t panic! Start with smaller experiments that allow you to build momentum and train your product muscle, and see how your customers respond. A strong product management foundation can help identify the biggest point of leverage.


## 5 Examples of Product-Led Initiatives for eCommerce Growth

For inspiration, here are the five most common product-led initiatives that we see eCommerce and DTC brands apply:

* **Membership programs.** While traditional loyalty programs primarily reward spending through cashback or similar models, well-designed membership programs take the brand-customer relationship one step further by leading customers to identify with the brand. This can take the form of early access to new products, in-person or virtual get-togethers, direct access to company founders, and any other perks relevant to a brand’s unique customer base.
* **Referral programs.** Happy customers love to spread the word, and referral programs allow them to do just that. It’s common for brands to reward referrals with discounts and promo codes, but we encourage brands to design a bespoke strategy that will resonate more with their customer base. If you’re a luxury brand, offering swag/products in partnership with other brands might be better than offering $20 off.
* **Try before you buy.** Allowing your customers to experience your physical product before committing to a purchase is the epitome of delivering value before capturing value and can be a great way to engage undecided customers (especially when paired with some of the other initiatives in this list!).
* **Educational content.** Content is one of the most common organic marketing efforts pursued by DTC brands, and with good reason. Producing valuable, educational content for your audience is a straightforward way to generate brand awareness by solving a genuine problem. If you go down this path, nvesting in a solid [content infrastructure](https://nebulab.com/blog/ecommerce-content-management) will pay dividends.
* **Web-based/mobile apps.** Often, brands design mobile apps that are purely transactional, making them useless to customers that have not already decided to shop with the brand. In doing so, they miss invaluable opportunities to nurture their audience through content and interactions that don't aim for a direct sale.

While these are all good starting points that will apply to many brands, you should have the courage to explore unique ideas that will make you stand out. Rolling out a successful product-led strategy requires a deep understanding of your customers, how they experience your brand, and what opportunities you can capitalize on to become an indispensable part of their daily routine.

If you need help rolling out your product-led approach, [reach out!](https://nebulab.com/contact-us) Since 2012, we’ve helped tens of DTC brands scale their presence by developing unique experiences. We’re happy to help you figure out if product-led growth is right for you and how you can get started on your product-led journey.

Scaling DTC Brands Through Product-Led Growth

In our [latest article](/blog/ecommerce-ab-testing), we wrote about the value of A/B testing (also
referred to as “split testing”) and how eCommerce brands can set up and scale an effective A/B testing strategy. By
getting the fundamentals right, brands can use A/B testing to generate unbiased, data-informed market insights. Large
brands often run tens of experiments at any given time and use the results to directly inform their product strategy.

However, we also touched briefly on the hidden complexity behind an A/B testing operation: in fact, **one of the curses
of A/B testing is its apparent simplicity.** It’s easy to get lured into signing up for an A/B testing tool without a
clear understanding of how it works, only to find ourselves weeks later with tests that are inconclusive or just plain
incorrect.

This article will dig deeper into this complexity, highlighting some of the most common pitfalls brands face when
running experiments. We will also discuss the scenarios in which A/B testing is _not_ the way to go and the alternative
practices brands should adopt instead.

## The 7 Most Common A/B Testing Mistakes

A/B testing is a form of statical hypothesis testing. As such, it is prone to all the typical pitfalls of statistical
analysis: most notably, **if the data you’re using to run the analysis is incorrect, biased, or skewed in any way, the
results of your analysis are also very likely to display the same problems**–garbage in, garbage out.

Even with modern A/B testing platforms, it is still unbelievably easy to skew the results of an A/B test. Your tools can
help you write less code and run the math for you, but they won’t be able to make strategic decisions for you–such as
which metric to pick–or to shield your test from external factors–such as a concurrent A/B test skewing your test
population.

With this in mind, let’s see some of the most common mistakes and oversights a brand might make when designing,
executing, and analyzing an A/B test.

### 1. Type I and Type II errors

All A/B tests are subject to two different types of errors:

* **Type I errors (false positives)** occur when we detect a non-existent difference between the experiment and the
  control group, i.e., we conclude that our experiment affected our target metric when it actually didn’t.
* **Type II errors (false negatives)** occur when we fail to detect a difference between the experiment and the control
  group, i.e., we conclude that our experiment failed to affect our target metric when it actually did.

We can guard our tests against Type I and Type II errors by picking an appropriate statistical significance and power:
the _higher_ our significance, the more resilient our test will be against Type I errors; the _lower_ our power, the
more resilient our test will be against Type II errors. Combined, these numbers represent our desired confidence in the
test result.

As an example, if we pick a significance of 80% and a power of 5%, it means that:

* There’s only a 20% probability that our experiment group will outperform our control group by chance.
* There’s only a 5% probability that our control group will outperform our experiment group by chance.

**Higher confidence levels mean we can take more drastic actions as a result of our test but also require larger test
populations,** which may be challenging to reach for smaller brands.

An 80% significance and a 5% power is a good starting point for most A/B tests, but you should use your judgment: in
some tests, the cost of making a mistake in either direction might be higher or lower than usual; in others, you might
only want to worry about false positives or false negatives.

### 2. Novelty Effect and Change Aversion

Two interesting dynamics can threaten the validity of A/B tests, and they both stem from how your users react to change.
These are more relevant for products with a high percentage of returning users, so you should be extra careful if your
brand offers subscriptions, for instance, as they could prevent you from getting reliable results.

**The Novelty Effect occurs when users engage with a product more than usual because they’re fascinated by a new feature
or a change in an existing feature.** For instance, users might purchase more if you introduce a brand-new loyalty
program to drive incremental recurring revenue. However, as they adapt to the change, most people will gradually regress
to the average user behavior patterns.

Change Aversion is the exact opposite and often happens with significant redesigns of existing functionality: **you
might find that affectionate users engage less with your experiment,** as they were used to the previous way of doing
things and don’t like that their workflows got disrupted. Over time, they will likely get used to the new design and
re-engage with your brand as usual.

For both problems, **the solution is to segment your A/B test results by new and existing users.** By analyzing the
performance of these two buckets separately, you can more easily isolate the effect of your experiment from the effect
induced by novelty/change aversion. Of course, you'll have to figure out what counts as a “new” or “existing” user, and
it might differ depending on the test you’re running.

### 3. Network Effect

**The Network Effect occurs when users of an A/B test influence each other,** effectively “leaking” outside the bucket
they belong to (i.e., the control group interacts with the experiment, or the experiment group reverts to control). This
most often occurs with “social” functionality, where users interact with each other directly.

Consider the case of a second-hand marketplace that wants to offer users the ability to exchange goods directly without
a cash transaction. By definition, such a feature will require two users to participate: the sender and the receiver.
One quick solution would be to assign users randomly to the experiment or control group and only allow users in the
experiment group to use the new functionality. However, this might lead to a sub-par UX, causing frustration and skewing
the test results.

Instead, **you should cluster users into groups, with all users in the same group being more likely to interact with
each other.** For instance, you might cluster users by state, assuming that most of your marketplace’s transactions
happen within the same state. You would then assign each state to the control or experiment group. Users might still
interact across different states, influencing each other, but clustering helps minimize the likelihood of spillover.

The Network Effect is relatively uncommon in eCommerce, but it’s still worth understanding if your brand allows users to
interact with each other (as in the case of a marketplace). It can lead to unexpected results and can be incredibly
sneaky to detect. As a rule of thumb, you should always consider whether any tests you’re designing have the potential
to introduce a network effect and plan accordingly.

### 4. History Effect

**The History Effect occurs when an event in the outside world affects the results of your A/B test.** This can be
anything from a marketing campaign to a shopping holiday. These events are likely to change the behavioral patterns of
your visitors compared to the average, which will cause you to extrapolate incorrect insights.

For example, let’s assume you’re testing whether offering a discount in exchange for newsletter signups significantly
increases subscribers. If you decide to run the test during a site-wide sale (e.g., because of Black Friday/Cyber
Monday), your test might be inconclusive.

**To mitigate the History Effect, ensure you have solid processes to ensure you’re not running A/B tests concurrently
with major media coverage and PR events.** It also helps to run your A/B tests for at least two complete business
cycles, which typically translates into 2-4 weeks for most brands.

### 5. Simpson’s Paradox

**Simpson’s Paradox is a particularly sneaky type of error that occurs whenever you inadvertently introduce weighted
averages into an A/B test,** which can happen in a few cases:

* **When you adjust the traffic split for an A/B test during test execution.** Example: you start your test at 50%/50%,
  then change it to 90%/10% when you see that the experiment is outperforming the control.
* **When your website traffic segmentation is not consistent across different variants of your test.** Example: you
  segment your test by returning vs. new visitors, but you have 1,000 new customers visit the experiment, and only 500
  visit the control.

In these scenarios, you might find that any correlation identified in individual test segments disappears or is inverted
in your aggregate results. This is because the aggregate result calculation effectively becomes a weighted average, and
your larger segments will “overwhelm” the smaller ones.

You can find a more academic explanation of Simpson’s paradox
[here](https://learn.microsoft.com/en-us/archive/msdn-magazine/2005/december/test-run-software-testing-paradoxes), but
there are a few things you can do to prevent Simpson’s Paradox from finding its way into your test results:

* **Ensuring your test populations are accurately randomized** and evenly distributed among different test variants. In
  other words, you should have the same number of visitors from each segment to each variant of your test.
* **Running an A/A test** (i.e., a “fake” A/B test where both variants are the same) can be helpful to ensure proper
  randomization.
* **Looking at test results across different segments** ensuring and not just at the aggregates so that you can spot any
  inconsistencies.
* **Relying on your A/B platform’s built-in capabilities,** e.g., Optimizely’s
  [Stats Accelerator](https://support.optimizely.com/hc/en-us/articles/5326213705101-Stats-Accelerator-Acceleration-Under-Time-Varying-Signals),
  to make your tests more resilient to Simpson’s Paradox.

### 6. P-hacking

P-hacking is an extremely common A/B testing pitfall–so much so that it used to be _encouraged_ by A/B testing tools
such as Optimizely. Simply put, **P-hacking is the practice of changing a test’s original parameters to reach a
pre-determined conclusion.** This can come in different forms:

* Some teams stop a test as soon as it reaches statistical significance rather than letting it run for its established
  duration.
* Some teams increase the test population until they reach statistical significance.

**P-hacking is often caused by pressure from your leadership or digital marketing team** to get a specific result from an
A/B test or to maximize the impact of a successful experiment as quickly as possible. Unfortunately, this is not how
traditional A/B testing works: once you have established your sample size, you simply need to let your run test run its
course and evaluate the results only at the end.

Because this methodology isn’t particularly well-suited to the speed at which startups typically move, many A/B testing
platforms ended up implementing alternative algorithms. Optimizely, for instance, introduced Stats Engine in 2015, which
allows A/B testers to peek at test results without the risk of taking action prematurely–you can learn more about how it
works in
[this introductory article](https://www.optimizely.com/insights/blog/statistics-for-the-internet-age-the-story-behind-optimizelys-new-stats-engine/)
by the Optimizely team.

While features such as Optimizely’s Stats Engine or VWO’s Bayesian engine help A/B testing teams avoid pitfalls such as
P-hacking, they don’t eliminate the need for proper test planning.

### 7. Instrumentation Effect

While most pitfalls outlined in this article are statistical, the Instrumentation Effect is much simpler: **it occurs
when your analytics, A/B testing infrastructure, or test implementation don’t work correctly**, skewing test results.
Here are a few examples:

* Your analytics setup sometimes reports conversions twice, skewing the total number of conversions you use to evaluate
  your test results.
* Your A/B testing setup sometimes puts the same customer in different buckets throughout the same A/B test.
* One of your test variants has a user experience edge case that prevents specific customers from completing their
  interaction with the webpage.

Because these bugs happen at the very source of your data, no statistical methods can solve any of these problems for
you. Instead, you need to regularly and rigorously test every part of your A/B testing infrastructure:

* Before running an experiment, **make sure that all the metrics you are interested in are being reported accurately.**
* **Test your experiments for usability and integrity** with the same attention you’d reserve to a permanent feature.
* **Run A/A tests to verify that your A/B testing setup works correctly** and that your upstream data collection is
  reliable.

## A/B Testing Is Not a One-Size-Fits-All Methodology

Reading this article, you might think that we want to discourage eCommerce brands from running A/B testing, and you’d
be–at least partially–correct. It’s not that A/B testing doesn’t have its place in an eCommerce brand’s strategy. But
**the effort involved in planning, executing, and analyzing an A/B test, assuming that you want to get significant
results, is often not sustainable by most early-stage brands.**

Anyone not adequately trained in the statistical techniques behind A/B testing will have a tough time guarding their
tests against the pitfalls we’ve outlined–which, by the way, are a subset of all the different statistical and practical
errors A/B testers can incur. Tools can help mitigate some of these errors to an extent, but they can’t turn an
inexperienced team into data analysis experts overnight.

Furthermore, **A/B testing is very often not the best research methodology.** There are many scenarios in which A/B
testing falls short.

* First and foremost: **A/B testing, by its very nature, is focused on short-term gains.** As we have seen, these can
  sometimes come at the expense of long-term business results: focusing on click-through and conversion rates might come
  at the expense of retention and customer LTV.
* As a result of the above: **A/B testing tends to deprioritize disruptive innovation,** leading teams to focus on
  incremental gains instead—its typical application is in conversion-rate optimization. If your brand is working on a
  massive product launch, or a brand new membership program, A/B testing will not offer any meaningful insights into how
  your customers might respond.
* **The cost of designing and launching an A/B test is high:** every test you run effectively creates two “branches” in
  your digital experience. This means your team will have to tiptoe around your A/B test until it’s run its entire
  course, slowing down further innovation and improvements in that product area.
* **A/B testing is a quantitative and evaluative research methodology.** As such, it needs an initial hypothesis to
  validate–and one that can be clearly and unequivocally validated with a data-driven approach. Anything requiring
  generative or qualitative research, which often involves talking to your customers, is not a good fit for A/B testing.

## Start A/B Testing When You Have Product Management Fundamentals

So, are we suggesting that retailers shouldn’t A/B test? Not at all: A/B testing has its place, and when employed
correctly, it can be instrumental in improving a business’s KPIs and bottom line. To dismiss A/B testing as too
complicated to be worth the effort would be incredibly short-sighted and detrimental.

However, **many eCommerce businesses dive head-first into A/B testing without proper product management fundamentals.**
We’re talking about generative and evaluative research methodologies such as heatmaps, user interviews, user testing,
on-site surveys, session replays, historical analytics, feature flags, and many other techniques.

These practices have a broader set of potential use cases and are also a prerequisite for being able to A/B test
intentionally. Plus, they’re almost always _simpler_ to implement and leverage than an effective A/B testing
infrastructure!

The next time you–or someone else on your team–want to run an A/B test, stop for a moment and ask yourself: **is there a
more straightforward, more efficient way to answer this question/validate this testing hypothesis?** You might be
surprised about how many alternatives you have at your disposal.

In the next few weeks, we’ll be exploring precisely these product fundamentals, explaining when and how they are best
used, and how you can orchestrate them together to form the basis of a strong product management practice for your
eCommerce brand.

How to Make Your eCommerce A/B Tests Useless

eCommerce brands have a variety of techniques at their disposal for understanding their customers and optimizing their KPIs: most of these techniques have been borrowed from modern product management practices and can be directly applied to eCommerce–A/B testing is one of these.

A/B testing (sometimes referred to as “split testing”) is a technique that uses statistical algorithms to determine which variation of a given behavior is most likely to optimize for a predetermined quantitative outcome. **By using live traffic to analyze user behavior, A/B testing can provide an objective, data-driven answer to nebulous questions**, such as whether offering free shipping to your customers will significantly affect add-to-cart rates.

With that said, **A/B testing is one of many techniques brands can employ and arguably one of the most complicated to execute correctly**. Unfortunately, we often see brand founders and executives jump into A/B testing without clearly understanding the required skillset or effort, only to arrive at disappointing conclusions and abandon the practice altogether.

We firmly believe that A/B testing has its place. Still, we also have strong opinions about when it should and shouldn’t be employed and the requirements for running a successful A/B testing operation. In this guide, we will break down some of the complexity behind A/B testing, help you understand whether it’s a good option for your brand, and offer practical tips and considerations for rolling it out.

## A Primer on How A/B Testing Works

At its core, A/B testing is a simple concept: we design two variations of the same web page (version A and version B), distribute our traffic evenly among the two variations, then see which one reported the best performance.

Going back to the “free shipping” example, an online store could show a free shipping banner to half their customers (this is the experiment group) and use the original page for the other half (this is the control group). At the end of the test, whatever version got the highest conversion rate would be considered a winner (with some statistical caveats).

This is the simplest possible type of A/B testing, but there are a few alternatives:

* **In A/B/n testing**, more than two variations are tested (e.g., no free shipping indication vs. a free shipping banner vs. a free shipping popup).
* **In multivariate testing**, each variation alters multiple elements on the page (e.g., a free shipping banner and a popup, just the banner, just the popup, no free shipping indication).
* **In bandit testing**, more and more traffic is automatically directed to the winning variation (e.g., if the free shipping banner converts more than the original page, we automatically start showing it more and more often).

![MailChimp A/B testing](https://cdn.sanity.io/images/kqgmf0g2/production/9c659965ed7f4ff19fa622d3e58e7b19fc883353-2560x2512.png?fit=clip)

It’s important to note that while this article talks specifically about A/B testing web pages, the technique can be applied—at least to an extent—to email marketing, social media, and other types of digital properties. Furthermore, eCommerce platforms, marketplaces, and marketing tools often provide native A/B testing capabilities:

* Amazon allows its merchants to A/B test content such as product images
* Hubspot allows testing landing page templates and email campaigns.
* Google Ads allows testing different ads to optimize clickthrough rates.

These concepts are deceptively simple, which is why so many A/B testing platforms promise exceptional ROI and quick results. **In reality, A/B testing comes with many pitfalls and “gotchas” that practitioners should understand thoroughly**. Running an effective A/B testing operation on an eCommerce website requires significant preparation, effort, and discipline.

## What an Effective A/B Testing Process Looks Like

Let’s take a peek into what a successful, effective A/B testing operation looks like in detail.

### 1. Picking a Problem Space

There are many resources online advertising “the best 99 A/B testing ideas,” and it might be tempting for inexperienced executives to jump in and start testing. Unfortunately, these blanket experiments are unlikely to move the needle–in some cases, they might even be detrimental to a brand’s KPIs. Furthermore, they completely ignore the true purpose of A/B testing, which is not conversion rate optimization but refining our understanding of our market, business, and customers.

For this reason, before diving head-first into changing the color of our CTA buttons, we must understand the problem space we want to explore. This can be a very narrow product opportunity, such as whether a new version of the search functionality will lead to better recommendations, or a broader area of the business that we want to understand better, such as how we can improve our conversion rates during the checkout process.

![POA template](https://cdn.sanity.io/images/kqgmf0g2/production/a7dfcc5783e16119a81831284987627f9fcb093f-2560x2512.webp?fit=clip)

Whatever the case, **we need to articulate precisely what questions we want to answer and why we think an A/B test is the correct methodology to answer them**. This is most often done through a Product Opportunity Assessment (POA), a document that explains what problem we’re solving and for whom, analyzes the market and the problem space, any business- and customer-facing implications of solving the problem, and provides a final recommendation (go/no-go) based on the information we have collected.

A/B testing, when employed correctly, is an invaluable tool that allows eCommerce product managers to quantitatively confirm or disprove existing hypotheses related to a particular opportunity. Still, it’s not a replacement for picking and refining an opportunity in the first place. Unfortunately, brand executives and marketers sometimes fall into the trap of running mindlessly through a list of standard A/B tests, leading to short-term, black-box optimizations at best and a waste of resources.

### 2. Designing the Test

Once the opportunity is well understood and prioritized, it’s time to design the A/B test. The first step is formulating a hypothesis that we want to confirm or disproven, which usually looks like this:

> We think that, by [experiment], we can increase [metric] by an [absolute/relative] [Minimum Detectable Effect]%.

Stating the hypothesis is the first step, but we will need a few more elements before launching our experiment. In particular, we need to establish the following:

* **Our current conversion rate**. If we don’t have it, this is a good time to stop and put the proper instrumentation in place.
* **The desired statistical power**. This indicates how likely we are to detect a difference between the control and the experiment, assuming it exists. Higher values give us more confidence in the test results but require larger samples.
* **The desired significance level**. This indicates how likely we are to detect a difference between the control and the experiment when it doesn’t exist. Lower values give us more confidence in the test results but require larger samples.

![Evan Miller's A/B testing sample size calculator](https://cdn.sanity.io/images/kqgmf0g2/production/e69b939e8d2e7df81f552d122ff5d4ffd00fba9e-2560x1534.webp?fit=clip)

Once we have established these parameters, we can plug them into one of many A/B test sample size calculators–Evan Miller’s is arguably the most popular, but any popular A/B testing platform (e.g., **LaunchDarkly**, **Optimizely**, **VWO**) will also do the math for you.

Finally, we must decide how long we want to run our test. **It’s usually recommended to run tests for at least two complete business cycles**. This helps to protect our experiment from a few common pitfalls, such as external validity threats, novelty/maturation effects, and change aversion. We’ll cover these in a separate article!

### 3. Launching the Experiment

The next step is to work with our product team to design and implement our experiment.

Most modern A/B testing platforms allow non-technical users to launch tests with complete autonomy. After copy-pasting a snippet of JavaScript code to their website, brand operators can design and launch experiments that alter UI elements without touching a single line of code: users can alter page layout, CTA styles, and other elements. This capability allows product managers and stakeholders to move quickly and saves engineering bandwidth for high-impact product work. However, it also comes with some caveats of which users are typically unaware.

First of all, **experiments that have been implemented without the assistance of a product team might present bugs or inconsistencies that make them less palatable to new and existing brand customers**. This might skew our test results: what if our latest category page experiment failed to outperform the control because the customer experience was counterintuitive? In some cases, such pitfalls can completely invalidate an experiment, resulting in a waste of resources.

![Optimizely homepage](https://cdn.sanity.io/images/kqgmf0g2/production/f8e3234adf8087323de71b30402eb2e6bdc7133e-2560x1702.webp?fit=clip)

Secondly, it’s not uncommon for a large brand to run tens of experiments simultaneously. **When experiments run in the browser, they can have significant performance implications and harm the user experience**.

**Brands should invest in A/B testing infrastructure that allows them to design and launch experiments quickly while continuing to involve the product team.** This often comes in the form of streamlined processes, strong design/development primitives–such as a reusable design system and UI kit–and clear guidelines on what is considered “good enough” for an experiment.

### 4. Analyzing Test Results

Once the test is completed, it’s time to analyze the results. Typically, there are two questions we’re looking to answer for each A/B test.

**The first and most obvious is whether the experiment outperformed the control**–or, in other words, whether our hypothesis was confirmed or disproven by the test. If the experiment outperforms the control, we can say that our hypothesis is correct–within the established levels of statistical confidence, of course. We might also find that the control outperformed the experiment or that the test was inconclusive (i.e., neither variation significantly outperformed the other, and no winner can be established).

**The second question is what secondary implications the test had on our experiment population.** This might involve looking at other metrics or specific customer segments to understand whether the test affected our customers in non-immediate ways. Here are a couple of examples:

* A test might tell us that offering 50% off on the first order of our subscription product increases our subscription activation rate. However, when we look at secondary metrics, we might find that the experiment group also has a much lower retention rate than the control group, causing us to lose money on every conversion. Is this outcome desirable for our eCommerce business?

* A test might be inconclusive or present the control group as a global winner. However, when we dive into the data, we might find that the experiment blatantly outperformed the control for specific segments. Sometimes, this might indicate an opportunity to offer a more [personalized experience](https://nebulab.com/blog/ecommerce-personalization).

![LaunchDarkly metrics view](https://cdn.sanity.io/images/kqgmf0g2/production/35a9f4a0a28701605f61c311163f4345cd12eec8-1200x857.webp?fit=clip)

As a rule of thumb, it can be helpful to map some of these secondary considerations when designing the test. However, this analysis is very exploratory, and it’s impossible to list all the possible outcomes in advance. **Brands should take the time to review test results with different stakeholders so that everyone can bring their KPIs and perspective to the table.**

Once we have finished analyzing the results, it’s time to archive them. This is a step that most practitioners skip, but it’s incredibly valuable: **archiving the results of our A/B tests allows us to establish them as a first-class research methodology** rather than a short-term approach to conversion optimization. Ideally, insights derived from A/B tests should systematically become part of our organizational knowledge.

### 5. (Bonus) Re-Testing as Needed

What’s true today might not be true tomorrow. When they first embrace a product-led approach to brand growth, we see many founders make the mistake of thinking that any insights they have uncovered are set in stone and will never need to be revisited. In reality, markets change constantly, and so does our business.

We don’t encourage re-running A/B tests for the simple sake of it–in most situations, the effort of re-testing far outweighs the benefits. However, **practitioners should feel comfortable re-running an old test or testing old assumptions in novel ways**.

## An End-to-End A/B Test Example

Let’s see what an end-to-end A/B test execution might look like by following the process we have just outlined:

1. As we’ve mentioned, it all starts with identifying a problem space we want to explore. In this case, let’s assume we are trying to understand why our product page has a particularly high bounce rate. We draft a Product Opportunity Assessment, collecting all the information we have gathered.

2. We collect a few hypotheses about why this might be happening, based on what we know about the business and our customers: maybe visitors can’t find critical information in the product description; maybe the particular variant they are looking for is out of stock; or maybe they aren’t willing to pay shipping costs.

3. We start by testing the shipping cost hypothesis. After looking at Google Analytics, we conclude that increasing add-to-cart rates by an absolute 10% would be considered a win.

4. Because offering free shipping comes at a considerable cost, we want to be very confident about our test results, so we pick a 95% statistical power and a 10% significance level for our test.

5. We plug the numbers into our favorite A/B test sample size calculator, which tells us we’ll need to direct 858 visitors to each branch of our test. Based on our traffic patterns, we think we can accomplish this in two weeks.

6. We work with our design and engineering team to implement an experiment that offers customers free shipping and displays the offer prominently on the product page.

7. We use our favorite A/B testing tool to launch the test.

8. After two weeks, we look at the results of the test. It turns out that the test was overall inconclusive: offering free shipping did not significantly affect the add-to-cart rate. However, when we look into the results across different segments, we find that the experiment group outperformed the control group for products over $150.

9. We archive the results of the test and refine our POA accordingly.

![LaunchDarkly results view](https://cdn.sanity.io/images/kqgmf0g2/production/bb3782925740b9b70a5349429382e14e496c3113-1200x860.png?fit=clip)

Now that we have the results of the test, we may decide to:

* Offer free shipping to everyone. Our business might have a policy of offering the same shipping conditions to everyone.

* Offer free shipping only on products over $150 to maximize our ROI. We might even play with different placements of the free shipping indication: what if we included the banner in the shopping cart or checkout page?

* Run another A/B test on a more promising target audience. We could test free shipping for products over $150, to be confident that it will actually move the needle for that segment.

* Collect more information through alternative product research methodologies like user testing or heatmaps.

* Not do anything: a more detailed evaluation might find that free shipping is not the highest-impact solution to this problem (e.g., perhaps we’d be better off adding testimonials to the product page or offering an upsell).

As we’ve mentioned, **an A/B test doesn’t have to lead to immediate action**. By treating our tests as a source of insights rather than a mere CRO methodology, we can deepen our knowledge of our customers with statistically verifiable, data-driven information that will enrich our product strategy and ultimately increase our bottom line.

## What Comes Next

We could talk for ages about the pros, cons, prerequisites, and implications of A/B testing, but this is more than enough for a single article.

**In the following articles, we’ll explore the most common pitfalls operators, marketers, and product managers incur when setting up and executing an A/B testing strategy**. We’ll talk about statistical significance, the shortcomings of using A/B testing as your only source of product knowledge, and what alternative strategies brands must employ before considering running an A/B testing operation.

In the meantime, if you have any questions about any topics we have discussed or need help designing an A/B testing strategy for your eCommerce site, [don’t hesitate to reach out!](https://nebulab.com/contact-us)

Commerce A/B Testing: Strategies for Success

While the total penetration of headless commerce in the US is still low, we have witnessed an increase in headless builds in recent years. And even though [we don’t believe headless is the end-all solution to all eCommerce problems](https://nebulab.com/blog/headless-commerce), we think it’s about time the industry realized the power of this architecture and started using it responsibly.

The only way for Shopify users to go headless for a long time was to implement their own single-page application from scratch, using a JavaScript library such as React (and hopefully a framework, such as Next.js). Shopify does provide SDKs to make the API integration work slightly more manageable, but that was about it: until recently, there was very little being done for performance, state management, personalization, or SEO.

In November 2021, Shopify released a developer preview of [Hydrogen](https://hydrogen.shopify.dev/), their new framework meant to address precisely these problems. Here at Nebulab, we’ve recently had the chance to take Hydrogen for a spin, and we want to share our learnings.

## What is Hydrogen?

Hydrogen is an open-source, React-based framework that can be used to build custom storefronts on the Shopify platform. It provides a lot of useful functionality:

* A sensible structure for your application code.

* eCommerce-specific components and pages.

* An SDK and hooks to interact with Shopify’s GraphQL-based [Storefront API](https://shopify.dev/api/storefront).

* It uses [Tailwind CSS](https://tailwindcss.com/) for styling.

* It’s optimized for high-performance builds.

Combined, these features almost entirely eliminate the amount of boilerplate code engineers need to write to build their storefronts and allow engineers to spend most of their time on functionality that truly moves the needle.

![Shopify Hydrogen website](https://cdn.sanity.io/images/kqgmf0g2/production/9865cb4da04e7cd861e38c97cc7015d8ea7a1e22-2560x2512.png?fit=clip)

## What are the pros of using Hydrogen?

For Shopify stores that want to go headless, Hydrogen is a huge help. As we’ve mentioned, it abstracts away all the complexity of integrating with the Shopify API and developing your storefront’s skeleton: all you need to do is clone the Hydrogen [demo store](https://shopify.dev/custom-storefronts/hydrogen/getting-started/templates#demo-store-template), configure it, then focus on styling and custom functionality. This alone is a huge productivity boost, and the developer experience has been outstanding in our experiments.

It’s also important to note that Hydrogen is officially developed and supported by Shopify, which should provide peace of mind to brands looking for a stable, robust solution that’s not going anywhere. While some Shopify-specific Next.js templates already existed before Hydrogen, they were mostly small, community-sponsored projects, which made them unsuitable for enterprise use.

## What are the cons of using Hydrogen?

Seasoned developers know that productivity comes with a hidden cost: the more a tool tries to abstract away technical complexity, the more opinionated it is. When it comes to Hydrogen, it’s exceptionally opinionated:

* It uses React server components.

* It uses streaming server-side rendering (SSR).

* It has built-in components, hooks, and caching mechanisms.

* It’s heavily coupled with Shopify’s Storefront API.

* If you need complete control over your React application, Hydrogen is most likely not a good candidate for you.

You should also know that some of these features are bleeding edge in the React ecosystem, and because Hydrogen is tightly coupled with Shopify, the community around it is still relatively small. Hydrogen brands can expect to have a harder time finding online resources and support, and they will have to tap into a smaller pool of agencies and engineers than if they used a more popular framework. That said, much of that will likely change as Hydrogen gains popularity.

Finally, most Shopify Apps and plugins were built to integrate with Liquid templates and won’t be compatible with Hydrogen (or other headless architectures, for that matter). If you rely heavily on specific apps and your app doesn’t provide an API your engineers can integrate with, you’ll need to switch to a headless-friendly alternative or build the functionality yourself.

## Can Hydrogen be used without Shopify Plus?

It’s complicated. The official answer is yes: since Hydrogen is an open-source project whose source code is available to anyone, and because none of the API endpoints it uses are restricted to Shopify Plus customers, at first glance, the framework can be used without Shopify Plus.

In reality, things are more nuanced.

![Shopify Oxygen documentation](https://cdn.sanity.io/images/kqgmf0g2/production/a893aabf4ed6f21f992598100837e4856353c79f-2560x1620.png?fit=clip)

First of all, there’s the matter of hosting your Hydrogen application. Plus users can host their Hydrogen app on [Shopify Oxygen](https://shopify.dev/custom-storefronts/oxygenhttps://shopify.dev/custom-storefronts/oxygen), Shopify’s proprietary hosting solution, which provides native support for directing users who visit your Shopify domain to your Hydrogen storefront.

If you don’t use Shopify Plus, you should still be able to deploy your Hydrogen app to other platforms, but it won’t be a painless experience. For example, Vercel has published a blog post announcing the availability of a [zero-configuration deployment for Hydrogen](https://vercel.com/changelog/hydrogen-projects-can-now-be-deployed-with-zero-configuration). But when we tested it, we had to manually tweak the environment variables used by Hydrogen to match the names used by Oxygen. This was a minor inconvenience overall, but it shows how support for Hydrogen is still in its infancy.

Once you’ve figured out the hosting, it’s time to deal with domains and DNS records. If you manage your domains through Shopify, Shopify will attempt to redirect any requests to your [myshopify.com](http://myshopify.com/) domain to your Hydrogen storefront, which will completely break the checkout. This could be easily solved by using a [routing domain](https://help.shopify.com/en/manual/domains/domain-type/routing-domain) which, ironically, is only available to Shopify Plus customers. (When we reached out to Shopify engineering about this catch-22-esque paradox, they seemed utterly taken aback by this realization.) The current solution is to set up your Liquid storefront to redirect to your Hydrogen storefront via JavaScript, which is far from ideal.

Another aspect to consider is support: in our experience, if you’re not a Shopify Plus customer, you’re only going to get extremely limited technical support from Shopify, with most requests being redirected to Shopify’s Discord community. No one in the Discord community seems to have much experience with Hydrogen, except for Shopify’s own employees, whose presence in the community is very erratic.

To be fair, Shopify did tell us that they are working to address these challenges and make Hydrogen truly available to non-Plus customers. However, _when_ this will happen exactly is unknown.

To sum it up, if you’re not on Shopify Plus and don’t have an experienced engineering team or agency backing you up, we would advise against using Hydrogen right now: you run the risk of spending weeks or months of development only to run into deal-breaking roadblocks.

![Shopify Discord](https://cdn.sanity.io/images/kqgmf0g2/production/ce5f2c4f4565702286b8a1df6cd0d17d418c8538-2560x2068.png?w=450)

## Who should be using Hydrogen?

Shopify’s Hydrogen framework is the perfect solution for online stores that are already running headless, or are planning to go headless, can count on a robust engineering team, and want to lean into a powerful, officially-supported solution that will spare them from boilerplate work. The developer experience is enjoyable, and most React engineers will be more than happy to work on a Hydrogen app.

If, on the other hand, you don’t have an experienced engineering team or don’t want to deal with the complexity that comes with a headless solution, Hydrogen is not a good choice: as much as it simplifies things, it will still require much more upkeep than a Liquid-based Shopify build.

At this point, Hydrogen is also a less-than-ideal solution for brands not on Shopify Plus due to missing functionality and limited support from Shopify. That is likely to change as the framework matures and becomes more widely available, so keep an eye out for any announcements from Shopify (and from us!).

If you’re considering going headless with Hydrogen or other frameworks, and are unsure of the implications, [feel free to reach out](https://nebulab.com/contact-us)! Our team has extensive experience and will help you make the choice that best supports your digital strategy.

Everything You Need to Know About Shopify Hydrogen

With unlimited digital estate, DTC brands can tell their stories, announce, entertain, educate, and keep their name front and center in customers’ minds, all of which is very hard to do in the limited shelf space afforded by wholesale partners. Now that even die-hard digitally-native brands are going omnichannel in pursuit of reach and profitability, **it’s paramount to double down on the exclusive capabilities of each channel to create complementary experiences—for DTC, content is one of the most obvious levers to pull**.

A slew of platforms has emerged over the past decade that promise to offer the definitive solution to all content management pains. These solutions provide functionality that covers the entire content management lifecycle, from writing to publishing, presentation, and SEO, but they do it in very different ways. In fact, we’ve seen at least four generations of content management tooling emerge in these years, all of which coexist today, serving different use cases and market segments.

For eCommerce operators, finding a North star to follow in this vastness can be tricky, and engineering teams are usually not much better off. If you haven’t been exposed to all these tools and understand the nuances of each, it’s easy to get lured in by the promise of unlimited flexibility and endless automation, only to find yourself stuck with a complex piece of software that requires weeks of integration work, or doesn’t play nice with your editorial workflow.

In this article, we will provide an overview of the content management space, as seen from the perspective of an eCommerce brand. You will learn the different types of tools you can use, their advantages and limitations, and some practical recommendations about which tool to adopt depending on your goal, use case, and growth stage. The goal is to equip you with all the knowledge you need to make an informed decision for your eCommerce brand.

## The four generations of content management

Different content management solutions have been launched in the last twenty years. While there’s no universal taxonomy, we can classify them under four categories: monolithic CMSs, headless CMSs, site builders, and page builders. In the following paragraphs, we’ll explore these different solutions, their pros and cons, and the leading players in each space.

### Monolithic CMSs

Monolithic CMSs were the first content management solution to emerge in the market. **These tools take over your entire content experience by handling every single aspect**: they provide an interface that allows you to edit and publish your content and present the content to your audience via a public-facing website.

You’ve probably heard about [WordPress](https://wordpress.org/), arguably the most popular CMS in the world. Initially built for blogging, WordPress has been expanded over the years to encompass an incredible number of use cases, allowing you to publish blogs, entire websites, and even online stores. It’s estimated that WordPress powers over 43% of all websites.

![WordPress website](https://cdn.sanity.io/images/kqgmf0g2/production/908b2d57d03ec193412387c8af8d151b6df2393b-2560x2136.png?fit=clip)

**Monolithic CMSs have been around for over fifteen years, and they’ve stood the test of time**. They offer a user-friendly, streamlined content editing experience and many plugins and apps that make them easy to repurpose for different use cases. Since they have a considerable market share, they also boast rich ecosystems of system integrators.

However, they also come with some limitations: th**ese content management systems are meant for content-centric websites, not for eCommerce brands.** They usually take over your entire website and don’t play nice with other parts of your tech stack. This makes them a less-than-ideal choice for a DTC brand, which needs to present the content on their storefront or even enrich it with dynamic data such as product information.

### Headless CMSs

Headless CMSs were built to solve precisely these limitations. **Compared to monolithic solutions, headless CMSs are much more nimble**: a headless CMS only provides an interface to define your content structure and manage your content. Presenting your content is up to you, and typically requires a design and engineering team to integrate the headless CMS into your existing frontend.

[Contentful](https://contentful.com/) has long been the primary contender in the headless CMS space, but many competitors have launched their solutions over the years: [Prismic](https://prismic.app/), [DatoCMS](https://datocms.com/), and [Sanity](https://sanity.io/) are among the most popular alternatives, offering slightly different functionality such as custom editorial workflows/UIs and internationalization, and wildly different price points.

![Contentful homepage](https://cdn.sanity.io/images/kqgmf0g2/production/551c31bc9b5a60be3f663151ba0172e06f790da5-2560x1810.png?fit=fill)

**Headless CMSs enable brands to treat content as data, making it fully portable and allowing them to present their content wherever they want**. Most headless CMSs also connect to your backend: for instance, an eCommerce brand will be able to pull product and pricing information from Shopify and include it right in the middle of an editorial piece. Such functionality allows you to blur the lines between content and commerce, making for a much richer customer experience.

Headless CMSs are still very popular thanks to their flexibility, but they come with their own limitations: mainly, **they require design and engineering work when marketers want to integrate new types of content into a company’s existing digital properties, or whenever they want to make visual changes to the existing experience**. This may be problematic for brands operating with low budgets or in high-velocity environments.

### Site builders

While site builders are not technically new (Webflow was born in 2012, one year before Contentful), they’ve seen a recent surge in popularity. You can think of site builders as a modern take on monolithic CMSs: like monolithic solutions, site builders also take over your entire website. However, **they offer more modern and advanced functionality**, such as support for drag-and-drop editing across your entire website, responsive design, custom code, API access, and integrations with popular third-party design and development tools. Almost all site builders also include a native headless CMS, or will optionally integrate with a third-party headless CMS.

The most popular site builder is [Webflow](https://webflow.com/), which is often used by SaaS companies to manage their marketing websites, or by eCommerce brands to spin up self-contained editorial experiences. Webflow also allows creating gated content and building Zapier-esque workflow automation. A recent competitor is [Framer](https://framer.com/), which allows designers to build, test and publish websites straight from Figma wireframes.

![Webflow homepage](https://cdn.sanity.io/images/kqgmf0g2/production/0082e34207f075b05269676c871a8d0d49b1601a-2560x2034.png?fit=fill)

**If your team has limited technical experience or you don’t want to use your engineering bandwidth, using a site builder can be an excellent way to quickly spin up new editorial experiences that will meet the standards of the modern Web.** And if you need to implement deeper customizations or complicated workflows, your engineers can still make those adjustments at a reasonable pace.

The main disadvantage with site builders is that, for all their flexibility, **they will still be pretty self-contained, and they’re hard to integrate with other digital properties.** Maintaining brand consistency will also be more challenging since your design system will live both in your site builder and across any other frontends you have. This is fine if you’re building a standalone experience such as a microsite, but can hurt your brand reputation when used for integrated experiences such as a company blog.

### Page builders

After coming full circle with site builders, the content management pendulum is swinging the other way once again with page builders. Like site builders, page builders also offer drag-and-drop editing, built-in headless CMSs, and all the modern developer tooling you might expect. **Unlike page builders, site builders try to be non-obtrusive: rather than taking over your entire website, they allow you to model specific pages or sections of it.** For example, you might let your eCommerce platform power your product catalog and checkout experience while your page builder powers your site navigation and blog.

The most popular page builder is [Builder.io](http://builder.io/), used by several eCommerce brands such as Everlane, J.Crew, and Harry’s. It allows you to use their native visual editor or to import your own components, connects with several third-party data sources, offers built-in A/B testing, and lets you publish your content across the Web, mobile, and wherever else you want. An early-stage contender is [Plasmic](https://plasmic.app/), which offers a very similar feature set, but pairs it with a more modern UX.

![Builder.io homepage](https://cdn.sanity.io/images/kqgmf0g2/production/29e681ed0cb541c8da8d8c65119b10cfe3f08b8d-2560x1528.png?fit=clip)

**Page builders can be an excellent compromise between headless CMSs and site builders**: they allow you to easily integrate your content into your existing digital properties in a non-obtrusive, brand-consistent way, and they offer a visual interface that helps non-technical stakeholders to quickly iterate on both content and presentation.

However, they are not a one-size-fits-all solution. **While an essential page builder integration can be a reasonably low-effort process for your engineering team, getting page builders right can be a complex initiative.** Once you start bringing in your own UI components, performing search engine optimization, running A/B tests, integrating with external data sources, or implementing rich user interactions, the level of complexity goes up dramatically, and keeping everything running smoothly can be a challenge.

## Evaluating the right solution for your brand

As you’ve seen, there’s no easy answer: each eCommerce CMS has its pros and cons, which you should weigh against your company’s stage, requirements, and technical savviness. The three main factors we keep into account when picking a solution for our clients are:

* **Business goals**: what do you want to achieve with your content? This is closely tied to where you’ll want to place your content, which in turn informs your choice of tooling. Are you looking to inform, inspire, or convert? (Often, it will be a mix of these, which is perfectly fine—just make sure you cover all your bases!)

* **Span of control**: site builders give operators maximum flexibility to change whatever they want, whenever they want it. This is both a blessing and a curse: a non-designer making design changes can quickly become a disaster. What’s the sweet spot between not enough and too much control for your team?

* **Implementation effort**: page builders are more complex to integrate than headless CMSs, which in turn are more complex to integrate than a monolithic CMS. Do the benefits outweigh the extra effort of integrating the solution with your tech stack?
Apparel brand and Nebulab client [Huckberry](https://huckberry.com/), for instance, relies heavily on their blog, [The Journal](https://huckberry.com/journal). The Journal is a fully integrated part of Huckberry’s shopping experiences: articles typically feature one or more Huckberry products, which users can add to their cart with a simple click. It’s a very conversion-centric approach.

![Huckberry’s blog, The Journal](https://cdn.sanity.io/images/kqgmf0g2/production/7ce46f90390f88961bbc568a2fafc78deb24b464-2560x2512.png?fit=clip)

Travel brand [Away](https://awaytravel.com/), on the other hand, publishes the travel and lifestyle magazine [Here](https://www.heremagazine.com/). Away’s magazine has a laid-back, inspirational approach with its content, and you can hardly notice that a DTC brand is behind the project.

![Away’s magazine, Here](https://cdn.sanity.io/images/kqgmf0g2/production/85383a0a4b600d7279c82359e0f0da9edf9209b8-2560x1664.png?fit=clip)

### Picking tools vs. building infrastructures

**Rather than only adopting one solution, we recommend creating a content management infrastructure, i.e., a suite of tools that integrate and build on top of each other.** For example, here’s a typical journey a DTC brand might undergo:

1. As a first step, they adopt a headless CMS, which allows them to decouple content and presentation. They use their headless CMS as the source of truth for all their content and integrate it with their existing digital properties (e.g., their product pages).

2. At some point, the marketing team starts complaining that they can’t make visual changes to how the content is presented on their product pages without asking the engineering team. This leads the team to integrate a page builder for specific website sections (e.g., the PDP and the blog). The page builder is connected to their headless CMS, which is still used for managing the actual content.

3. The brand eventually outgrows the page builder as well: the marketing team wants to start experimenting with standalone experiences such as microsites for contests, promotions, and product launches. This is when the team adopts a site builder, giving marketing full power to launch new properties with little to no engineering assistance.

**As marketing teams gain more freedom, brands need to create checks and balances to avoid brand dilution.** This can mean having a content inventory that is continuously monitored for consistency, ensuring the same person is orchestrating all digital experiences, or having a full-fledged design system that can be applied across different platforms. **Ultimately, how much centralization you need depends on your brand’s scale and your reliance on content.**

## Our favorite CMSs for eCommerce brands

At Nebulab, we have helped tens of brands design, launch and optimize their content stack, and we have developed some pretty strong opinions on which CMS platforms to use:

* **Monolithic CMS:** [WordPress](https://wordpress.org/). As mentioned, we rarely pick monolithic CMSs for eCommerce brands—but when we do, we go with WordPress. It has a beautiful, intuitive UX and an incredibly vast ecosystem of plugins and integrations, making it a good fit for many use cases and deployment options.

* **Headless CMS:** [Sanity](https://sanity.io/). A few years ago, we would have recommended Contentful or Prismic ([and we have](https://nebulab.com/blog/five-no-code-ecommerce-management-tools#the-best-headless-cms-prismic)). Ever since we’ve had a chance to try Sanity, we fell in love with its flexibility. While traditional headless CMSs force users to use a standardized UI for managing content, Sanity’s content studio is open-source and can be tailored to your content management needs and editorial workflows.

* **Page builder:** [Plasmic](https://plasmic.app/). While Builder.io has been around for slightly longer, Plasmic offers a more modern UI for their editing backend. With that said, the two tools are incredibly similar, so we encourage you to experiment with both and see which one you prefer.

* **Site builder:** [Webflow](https://webflow.com/). Even though products like Framer offer a more streamlined experience for non-technical users, Webflow remains an incredibly powerful tool if you know how to use it. With support for custom workflows and gated content, your team can quickly spin up rich micro-sites that cover various use cases.

As always, your mileage may vary. Before committing to a solution, you should thoroughly assess your present and anticipated requirements and experiment with different setups to build a stack that can scale with you as your needs evolve. If you need any advice or want to speed up the process, [we’re happy to help](https://nebulab.com/contact-us)!

Building Content Infrastructures for eCommerce Brands

With 9 out of 10 online shoppers stating that they want retailers to offer recommendations based on their interests, and
considering the vast amount of data and technology brands now have, there are few excuses not to have a personalization
strategy in place. eCommerce personalization is proven to increase conversion rates, customer retention, and lifetime
value, creating a virtuous cycle that can turn your visitors into loyal customers.

And yet, we often see brands struggle with rolling out an effective eCommerce personalization strategy: founders aren’t
sure how to segment their customers, evaluate the effectiveness of their personalization program, or what technologies
to adopt.

This article will demystify eCommerce personalization, providing you with a straightforward, data-informed approach for
designing, implementing, and validating your personalization program.

## What Is eCommerce Personalization?

Much confusion stems from the vagueness of the term “personalization.” If you Google it, you’ll find books, articles,
and SaaS products that all give it a different meaning: they talk about A/B testing, machine learning algorithms,
retargeting, user-generated content… It can be hard to understand where to start.

At its core, eCommerce personalization is the technique of using the information you have about your customers to
display content that is tailored to them. You can personalize across different dimensions (e.g., personalize by country,
browsing history, demographics), at different touchpoints (e.g., your website, your email campaigns, your ads), and with
different techniques (e.g., machine learning, user-generated content, human curation). No matter *how* you personalize,
the goal is to create a customer experience that feels unique.

## Designing Experiments with GTDT

When we coach founders that want to start experimenting with personalized eCommerce, we encourage them to think of
personalization as the means, not the end. Like all initiatives, personalized shopping experiences must be designed
thoughtfully and intentionally for maximum effectiveness. Adopting a tool or installing a plugin will only take you so
far if you don’t have a clear understanding of what you want to achieve with your personalization program.

Unfortunately, most resources offer an endless list of personalization examples from famous online retailers but no
indication of *why* or *how* those brands designed their personalization programs. This leaves operators scratching
their heads as they try to replicate the success of these brands. As a result, they tend to go for “blanket solutions”
that are easy to implement but ultimately leave the most exciting opportunities on the table.

Over time, we have developed a model that helps brands roll out thoughtful personalization experiments that get them
closer to their goals. **We call it GTDT, which stands for Goal, Technique, Dimension, and Touchpoint.** In the
following paragraphs, we will explain this process, providing you with all the tools you need to design your
personalization program.

### Goal

This might seem obvious, but surprisingly often, online stores will launch personalization capabilities to tick off a
checkbox with no clear goal in mind. Unfortunately, this not only means they will roll out an ineffective
personalization program, but it also means they will not be able to validate the effectiveness of their program: if you
don’t know what metric you’re optimizing for, you will not know what metric to look at.

The first step for any good personalization experiment is to understand what goal you’re aiming for—everything else
follows. Depending on your brand’s SKU catalog and business model, a personalization experiment for increasing your
average order value will likely look much different from an experiment to improve your add-to-cart or repeat purchase
rates.

If you’re unsure what goals you should be prioritizing, talk to your team and pick the one that feels most urgent right
now. Where are you falling behind compared to the industry benchmarks and your (or your board’s) expectations? What are
your customers telling you in your interviews? (You ***are*** doing customer interviews, right?) What are your plans for
the next 12-18 months?

Don’t make the mistake of falling into analysis paralysis: the beauty of running experiments is that you can quickly
pivot if you find that you’re optimizing for the wrong things. Make a data-informed decision, launch your experiment and
move on!

### Technique

With eCommerce personalization rising in popularity, several tools have emerged that promise to offer the definitive
solution to all your personalization problems. A/B testing tools, content management systems, eCommerce platforms, UGC
aggregators… almost every tool provides some level of personalization nowadays.

Unfortunately, without a clear personalization plan, it’s easy to get carried away by shiny object syndrome and try
every tool in hopes that it will solve all your problems. Do this enough times, and you’ll end up with a Frankenstein
monster of solutions that don’t integrate and annoy your customers with endless popups and broken UIs.

Before picking a tool or technology, decide **how** you want to personalize. You should do this, first and foremost, by
continuously referring back to your experiment goal and dimensions, but you should also lean on your brand’s strengths
and values. If you’re a fitness brand that’s all about community, you might want to leverage the power of user-generated
content, at least in *some* of your experiments. If you’re a luxury brand selling elevated essentials, perhaps you can
offer human-curated recommendations to your customers.

This last example brings us to the next point: don’t be afraid to do things that don’t scale, especially in the early
stages of your company. Many brands go from zero to a hundred by integrating deep learning models that are complex to
tweak and customize, and they don’t realize that they’re missing out on many lower-hanging opportunities. You’d be
surprised by how much you can accomplish with some basic customer segmentation and a human touch.

### Dimension

Once you know what you’re aiming for and how you want to get there, it should be easier to understand which dimensions
you want to personalize across. For example, you might want to personalize content based on geography, customer lifetime
value, previous purchases, demographics, or other factors.

It might help to group personalization dimensions into three big buckets:

- **Historical.** These are actions your customer has taken before. For instance, you might segment customers based on
  their AOV or purchase history.
- **Demographical.** These are traits that will always be true about your customer. For instance, you might segment
  customers based on geography, gender, or age.
- **Contextual.** These are actions your customer is taking now. For instance, you might segment customers based on
  their cart contents or session length.

When thinking about dimensions, don’t get limited by data availability: just because you don’t know your customers’ age,
it doesn’t mean you shouldn’t use it in a personalization experiment. Part of your personalization program should be
designing ways to collect or infer the information you need to carry out your experiments, which has the added benefit
of enriching your understanding of your customers over time.

You also don’t want to limit yourself to generic customer data: we find that the most successful personalization
programs use proprietary brand data to create win-win outcomes. If you sell pet food subscriptions, you might want to
curate your product catalog based on the customer’s pet type or age. If you sell sports equipment, you could send your
customers content specific to their favorite sports. Think about the different ways customers engage with your brand,
and try to design your experiments to optimize and improve those interactions.

### Touchpoint

With your goal, dimension and technique nailed down, it’s time to pick a personalization touchpoint. With this term,
we’re referring to the specific customer interaction you want to personalize. This will likely depend on your goal and
dimension: for example, if you want to increase AOV (goal) by looking at cart contents (dimension) to suggest upsells
(technique), you can only do this after the customer has added something to their cart or completed their purchase.

When deciding which touchpoint to personalize, we encourage brands to look beyond their product pages or on-site user
experience. Even with the average brand, there are so many ways your customers might interact with you and so many
opportunities to personalize those interactions. The most effective personalization programs are omnichannel and focus
on often-neglected interactions, such as transactional notifications, or create entirely new touchpoints, such as
sending customers a personalized card for their birthday.

Again, don’t get limited by your current touchpoints: if you want to send personalized email campaigns but are currently
not doing any email marketing, don’t be afraid to start now. If you think push notifications might resonate with your
customer base, why not give them a try?

The goal is to catch your customers when they need personalization even though they don’t know it, and leverage the
power of data to turn a mundane interaction into an intimate, personalized experience.

## Measuring Experiment Effectiveness

Designing and launching your experiment is only the first step. For an effective personalization program, you want to
validate the effectiveness of your experiment, double down on the ones that work, and kill the ones that don’t.

To do this, you must go into every experiment with a clear definition of success. This means answering the following
questions:

- What metric(s) do you expect the experiment to move, and in what ways?
- Are you already measuring the metrics you need? If not, how can you measure them? Do you need time to get a baseline
  for comparison?
- For how long will you let the experiment run after measuring the results?

### A/B Testing vs. Attribution Models

A special mention here goes to A/B testing: like with AI/ML, inexperienced founders often jump into A/B testing without
a clear understanding of the technique. While it’s tempting to run all personalization experiments as A/B tests,
sometimes this can be overkill or even detrimental: A/B tests require specific expertise, dedicated infrastructure, and
relatively high traffic volumes to reach statistical significance.

Typically, we only recommend A/B testing for large brands, running experiments where the results are highly uncertain,
and a clear control group can be established (e.g., customers that see the regular homepage vs. customers that see the
personalized homepage). In all other scenarios, a robust attribution model is a more reliable way to measure the
effectiveness of your experiment—even better when it’s paired with qualitative customer insights.

### Following Through on Experiment Validation

However you decide to validate your experiment, make sure it’s easy to roll back if needed and remember to look at the
data and take action accordingly! A recurring “experiment review” meeting with your team, where you review all
experiments that need to be validated and decide how to move forward, can do wonders to keep you accountable.

Finally, don’t be too rigid: if you expected a cross-selling experiment to drive $100K in revenue, but it only drove
$80K, it might still be worth keeping, depending on the effort you need to turn it into a permanent, first-class
capability. For some experiments, it might be helpful to establish different thresholds of success. Going back to our
example:

- Anything below $50K might be a clear failure.
- Anything between $50K and $100K might be up for discussion.
- Anything above $100K in incremental revenue might be a clear success.

Generally speaking, whenever you make decisions about your digital experience, you want to be data-informed, not
data-driven.

## Ready to Start Personalizing?

eCommerce personalization can create remarkable outcomes: when leveraged intentionally, personalization programs
increase revenue, customer loyalty, conversion rates, and lifetime value. It’s a tool that should be part of every
eCommerce store’s marketing strategy.

With the GDTD model, you have a streamlined process to design, launch and validate your personalization experiments.
It’s a high-impact tool that evolves with your brand as you scale, better understand your customers, and develop more
sophisticated ways to engage them.

If you have questions or need help with your brand’s personalization program,
[we’d love to hear from you.](https://nebulab.com/contact-us) Let’s start personalizing!

The GTDT Model for Intentional eCommerce Personalization

eCommerce operators often tell us that picking the right tech stack for your eCommerce brand feels like walking on a tightrope. There are so many tools and technologies to choose from, and making the wrong decision can severely impair your online store’s ability to scale with your business.

In this guide, we’ll look at what a tech stack is, why building it is a critical phase in your brand’s life, and how you can create a tech stack that will support your goals and your brand’s evolving requirements.

## What is a tech stack?

In layperson’s terms, a technology stack (“tech stack” for short) is a collection of programming languages, software libraries, frameworks, databases, and online services integrated to deliver a particular user experience.

While some of these technologies are very generic and apply to all kinds of scenarios, others are specific to the eCommerce industry. Here are the basic building blocks of most modern tech stacks:

* **Programming languages:** Developers use specific programming languages (e.g., Ruby, JavaScript, PHP, Java, Python) to code the server-side and frontend logic behind your application. Different languages have different properties and capabilities when it comes to popularity, scalability, and developer experience.

* **Libraries and frameworks:** These are software packages that make it easier for software developers to implement standard functionality. For instance, most backend programming languages provide Web frameworks that speed up the implementation of Web applications, such as Django for Python or Ruby on Rails for Ruby.

* **Infrastructure:** Infrastructure consists of the Web server, database, and other components that run your application’s backend and frontend code and host its data. Depending on your use case and requirements, many different types of infrastructure providers and possible configurations exist: e.g., you may use a relational database like MySQL, or a NoSQL database like MongoDB.

* **SaaS providers:** This is a catch-all term to indicate all the third-party software you pay a recurring fee to access. It can be a small piece of your stack, such as an analytics service or automation platform, or a major component, such as the eCommerce platform your brand runs on.

As you may imagine, picking the right mix of frontend and backend technologies, libraries, infrastructure, and SaaS providers requires a lot of experience: First of all, not all components integrate well with each other; secondly, each set of technologies has its pros and cons, which are very context-dependent.

While recommended practices exist, any agency or Web development team pushing the same software stack onto all of their customers is doing them a huge disservice. **Using the wrong tech stack can slow down your development process, prevent you from efficiently capitalizing on business opportunities, and hold back your startup from scaling.**

In the following paragraphs, we’ll explore the most critical parts of an eCommerce brand’s tech stack and how to make informed decisions when discussing them with your agency or in-house developers.

## What are the components of an eCommerce tech stack?

![Image of an hand that holds a rainbow-coloured MasterCard with two fingers](https://cdn.sanity.io/images/kqgmf0g2/production/4c046c881c959d397caaedf2278e3a95741ec830-1920x1080.jpg?fit=clip)

The average eCommerce brand may integrate many tools and technologies to deliver and optimize their customer experience. Let’s look at some of the most common eCommerce technology you might make as an operator or developer.

### eCommerce platform

Your eCommerce platform (sometimes called “shopping cart”) is the core of your business. Picking the right eCommerce platform is a critical decision when launching or re-launching your online store and one that you should evaluate from many angles.

There are many players in this space, and they come in different shapes and forms: established solutions such as [Shopify](https://shopify.com/) and [BigCommerce](https://bigcommerce.com/) promise reliability and large ecosystems. In contrast, newer solutions such as [Swell](https://swell.is/) and [Commerce Layer](https://commercelayer.io/) offer flexibility and a more modern approach. Then you have disruptors such as [Solidus](https://solidus.io/) (which is open-source) and [Chord Commerce](https://chord.co/) (which is data-driven), which push for a completely different take on building and operating your brand.

You can learn a bit more about the state of the eCommerce platforms market in our article on [headless vs. monolithic eCommerce](/blog/headless-commerce).

### Payment processing

Payment processing is a big part of running an eCommerce business. All eCommerce brands integrate with one or more vendors in the space, called PSPs (Payment Service Providers).

Note that “payment method” and “payment service provider” (or “payment gateway”) are sometimes used interchangeably. Still, they have two different meanings: while a payment method represents a medium the customer uses to pay for goods and services (e.g., credit card, Apple Pay, Google Pay), a payment service provider is a company that builds software to enable specific payment methods. For example, credit cards are one of the most common payment methods in eCommerce. To accept credit card payments, you must partner with a PSP that provides that service, such as [Stripe](https://stripe.com/).

You can either decide which payment methods you want to support and then pick the right combination of PSPs, or pick a PSP you want to use and then choose which payment methods you wish to enable among the ones they support.

There’s no right or wrong answer: whether to go one way or the other depends on your market (e.g., US vs. EMEA), business model (e.g., B2C/B2B), customer demographics (e.g., Gen X vs. Gen Z, household income) and industry (e.g., THC products are highly regulated and only supported by specific PSPs).

### Logistics

The supply chain experience can make or break a brand’s shopping experience. Especially for DTC, the bar is high, with consumers constantly comparing you with their latest experience and not settling for delivery delays or order mix-ups.

“Logistics,” in the context of an eCommerce operation, encompasses at least three different components, which may or may not be provided by the same vendor:

* **Inventory management:** an inventory management system allows you to track the inventory in your warehouse(s). Modern WMSs integrate with your eCommerce platform for real-time stock counts.

* **Shipping management:** a shipping management system allows you to generate shipping labels and track your packages’ journey from the warehouse to the customer.

* **Returns management:** a returns management system allows you to define your return policies, enables customers to handle returns autonomously, and tracks returns on their way to the warehouse.

You can either build/buy these tools and handle your logistics in-house or partner with a 3PL (third-party fulfillment) vendor to store your inventory and handle all logistics- and fulfillment-related responsibilities on your behalf. Which way to go depends on your company stage, product category, market, and many other factors.

### Content management

Depending on your needs, choice of eCommerce platform, and frontend technologies, you may or may not need to pick a content management system (CMS). A CMS allows you to manage the marketing content that appears on your eCommerce website.

Headless CMSs are all the rage nowadays: they allow developers to specify which content types are supported and how they should be presented on screen while still allowing marketers to publish whatever content they want, whenever and wherever they want. This gives your team much power while maintaining a consistent presentation of your content across your storefront, mobile app, and other sales channels.

With that said, headless CMSs are also restrictive: if a particular content module is not supported, your team won’t be able to publish it until a developer implements it. Whether to go with a headless (e.g., [Contentful](https://www.contentful.com/)) or monolithic CMS (e.g., [Webflow](https://webflow.com/)) depends on your scale, technical capabilities, and editorial needs.

For more details, read our article on [eCommerce content management](/blog/ecommerce-content-management).

### Marketing

Reaching your customers at the right touchpoints, and offering relevant, personalized information and offers, is an unbeatable advantage of online shopping. Brands can leverage first-party data to create “aha!” moments and magical experiences, but only if they are supported by the right tools.

You will find many marketing tools serving different channels and purposes: some tools are specifically built for email/SMS marketing, while others will be more targeted at social media marketing. Some tools are specifically designed for eCommerce companies; some are generic but do a good enough job of accommodating the needs of an online brand.

Our suggestion? Start simple. Going too aggressively after too many channels might cause you to disperse your efforts. Instead, be very intentional about which channels you’re pursuing, your segmentation strategy, and how to ensure that all the information you have about your customers is being put to full use. Once you have an established strategy, you can start to iterate and experiment.

### Customer support

Expectations around customer support (“CS”) have never been so high, and the bar is set even higher for digitally-native brands, which have pioneered a new era of customer support. Customers expect you to be responsive, solve their problems, and go above and beyond to provide a memorable experience.

Different CS software solutions support different channels (e.g., email, SMS, phone, social media), and covering as much ground as possible is critical in implementing a successful customer support strategy. If you have an Instagram account, customers expect their complaints to be answered there, not just by email.

Also, when those customers do reach out, you want to have the correct data at your disposal, so make sure your customer support platform integrates well with the rest of your stack: for example, when a customer reaches out, can you quickly identify them and see what they’ve purchased, and maybe initiate a return from within the CS tool itself? The more manual work you eliminate from the process, the easier it will be for your team to offer stellar support.

### Business intelligence

Data is an eCommerce store’s superpower. When a customer buys from you, you instantly get access to a ton of precious information about them and their behavior. You can either aggregate these bits of information to generate valuable insights for your business strategy, drill down to the customer level, or use the data to offer hyper-personalized experiences (ideally, you do both).

Building the right business intelligence (BI) infrastructure is a topic of its own, and entire books have been written about it. Many ready-made solutions allow eCommerce brands to track user behavior and generate fundamental reports and insights about their business. Highly sophisticated solutions enable brands to model their tracking, ETL, and data mining processes.

When it comes to business intelligence, we strongly encourage brands to be intentional about what they’re doing: it’s easy to implement a million different tracking pixels, tools, and reports and still be unable to generate any actionable insights. Start from the questions you want to answer, understand what data will help you answer them, and pick the right tool(s) for the job.

## 8 tips for building your tech stack

![Picture of a green crossroads into the wood](https://cdn.sanity.io/images/kqgmf0g2/production/ef51951e452f8432f6a43df46b9a9c9c598058dd-1920x1285.jpg?fit=clip)

The good news for eCommerce companies is that there are an incredible amount of solutions for launching and operating a brand. The bad news is that, with so many established players and new ones popping up daily, making a choice can feel overwhelming, and the consequences can be disastrous.

Here are eight tips that you should use to build your brand’s tech stack or when evaluating a change in your existing stack:

* **Ease of integration:** some solutions will be easier to integrate, thanks to public APIs and built-in connectors. When building your tech stack, pay attention to how the different parts of your stack will communicate. An integrated tech stack means less manual work and a better customer experience.

* **Build vs. buy:** buying an existing solution is not always the right choice. If you don’t find any vendors that fit your business needs, consider building an in-house solution that will scale with your brand over time. However, be mindful that this comes with caveats (e.g., higher upfront costs)!

* **Hot vs. boring:** should you jump on the latest hot trend or pick a boring solution that has stood the test of time? Unfortunately, there’s no correct answer: sometimes, some experimentation can give you a competitive advantage. But if you overdo it, you can expose your business to unnecessary risk.

* **Pricing:** it may seem obvious that you want to evaluate pricing when building your tech stack. However, we encourage you to look beyond the Pricing page, considering the expected lifespan of the solution, the total cost of ownership, and even the opportunity cost.

* **Decision reversibility:** some tech stack decisions are more challenging than others to reverse. Switching your customer support tool is rarely too complicated, but migrating to a new eCommerce platform is a big deal. Keep this in mind when making a choice.

* **Compliance:** in specific markets and business verticals, you will need to worry about compliance and regulatory issues. Sales tax, the CCPA (in the US), and the GDPR (in the EU) are the usual suspects, but the needs will evolve with your business, so you will need to stay on top of things.

* **Scalability:** while everyone loves to talk about scalability in the performance sense (e.g., how well a solution handles high traffic volumes), that is rarely a problem in most scenarios. Instead, understand how well the solution will support your evolving requirements and how likely you will need to move away from it as your brand grows.

* **Customer support:** we’ve discussed the importance of offering excellent customer support as a brand–you should hold your vendors to the same standard. Look at SLAs, support channels, and even G2 reviews. Ideally, talk to someone who’s already a customer and get their feedback!

## Do you need help building your tech stack?

Hopefully, we’ve convinced you that building your eCommerce brand’s tech stack is no easy feat. It’s a complicated, multi-layered process critical for ensuring your brand’s long-term success.

If you’re launching your brand or need to overhaul your existing brand’s tech stack, we can help. Our eCommerce engineers have worked with tens of brands over the years and can help you make the right decisions, enabling you to move quickly and laying the foundations for aggressive growth.

[Reach out](/contact-us) to tell us more about your project!

How to Build Your eCommerce Tech Stack

With a myriad of B2B eCommerce platforms available on the market today, choosing the best one to use to build your digital store can feel overwhelming.

From SaaS platforms to open-source platforms and open-source frameworks, you have countless options, no matter which functionality or specific technology you are looking for. However, to efficiently review your choices, it’s essential to understand your priorities.

In this guide, we will explore the best B2B eCommerce platforms, highlight their key features, and give you the criteria to use to pick the best one for your needs.

## 5 factors to consider when choosing a B2B eCommerce platform

To select the perfect solution for your eCommerce store, you need to identify your top priorities. The below five factors are crucial for ensuring both your team and your customers have a great experience with your platform.

Use these factors to compare your options and find the B2B eCommerce platform that fits your needs:

### 1. Pricing flexibility

In B2B marketing, you’ll work with diverse price points for your different customers. The best platforms have flexible pricing settings for multiple customer groups.

### 2. B2B payment methods

Choose a B2B eCommerce platform that supports B2B-specific payment methods. These options include payment by invoice, paper checks, ACH transfers, wire transfers, credit cards, and cash.

### 3. Pleasant UI

No matter how brilliant the B2B features of your commerce platform are, if the user interface is clunky and hard to navigate, it’s not a viable option. Go for platforms with an intuitive, user-friendly experience for customers, admins, and developers.

### 4. Robust scalability

You need an eCommerce solution that can grow with you when your B2B sales accelerate. You don’t want to incur costs for re-platforming when your business skyrockets.

### 5. Open source vs. SaaS

Because an [open-source](/blog/open-source-ecommerce) platform gives you full access to the source code, it’s fully customizable and scalable. However, it also comes with a steeper learning curve.

If your biggest concern is support and getting started quickly, then proprietary SaaS software is most likely a better option. SaaS platforms are hosted and run by service providers that charge a recurring fee for using their product.

## Review of 5 top eCommerce platforms

Let’s use the above criteria to examine the five top B2B eCommerce platforms:


### 1. Shopify Plus

![Shopify Plus website](https://cdn.sanity.io/images/kqgmf0g2/production/643675828bfbe9b3ccd168987493d879f0b2c156-2560x2140.webp?fit=clip)

[Shopify Plus](https://www.shopify.com/plus) is a market-leading eCommerce platform for enterprise B2C and B2B companies. Shopify powers 10,000+ global brands in 175 countries and can easily facilitate thousands of checkouts per minute. It gives high-volume brands a suite of powerful sales and marketing tools to scale, sell across multiple channels, and enter new markets.

**Features:**

* **Personalization:** Tailor your business to your customers with personalized storefronts, custom settings for different countries, and custom pricing for 133 currencies.

* **Headless architecture:** Enjoy the innovation and flexibility of a headless architecture that adapts to any device or channel, be it a website, wearable, or mobile app.

* **Ease of use:** Shopify takes care of all the backend and frontend intricacies of running an online store, so you can launch quickly and enjoy solid security and great support.

* **Large ecosystem:** Shopify is arguably the largest player in the eCommerce space, which means it has a vast ecosystem of out-of-the-box integrations and service providers.

* **Pricing:** Starts at $2,000 per month with a variable fee for higher volume sales.

* **Best for:** Fast-growing brands that net ~$1 million in revenue.


### 2. BigCommerce

![BigCommerce website](https://cdn.sanity.io/images/kqgmf0g2/production/5ee8bcead777d1bd9e084ca9a418802dbc95d5a1-2560x1866.webp?fit=clip)

[BigCommerce](https://www.bigcommerce.com/) is a renowned B2C and B2B eCommerce platform that boasts endorsements from market research companies like Forrester, Gartner, and IDC.

It’s a SaaS solution that empowers B2B businesses to take charge of their digital storefronts through API-driven flexibility. BigCommerce’s dual approach allows them to serve both B2B and B2C brands.

**Features:**

* **Multi-storefront:** Design unique storefronts for different regions and customer segments via pre-integrated apps and flexible, open architecture design.

* **Wholesale B2B eCommerce:** Offer wholesale B2B customers individualized user experiences, price lists, and a shopping cart with multiple payment options.

* **Omnichannel capabilities:** Use Codisto and Feedonomics to market your products through 150+ channels spanning social media platforms, search engines, and digital marketplaces.

* **API flexibility:** Adapt to changing customer needs and business growth requirements by using the platform’s powerful APIs to connect your CRM, ERP, PIM, and other software to accommodate new customers, product catalogs, and workflows.

* **Pricing:** Starts at $29.95 for the “Essentials” plan and custom pricing for the “Enterprise” plan.

* **Best for:** Small eCommerce businesses and large-scale merchants.


### 3. Swell

![Swell website](https://cdn.sanity.io/images/kqgmf0g2/production/f33ed866f30f6d292b153cedd9fbf4114c2a61b6-2560x1866.webp?fit=clip)

Next up in our B2B eCommerce solution rolodex is Swell, a headless eCommerce platform that provides B2B-specific functionality to cover a wide range of use cases.

With its open and extensible API, Swell is a good middle ground between the flexibility of open-source platforms and the convenience of SaaS platforms. It’s a good option if your brand has complex needs that require custom development, and you’re not afraid to get your hands dirty by coding your own storefront.

**Features:**

* **Flexible pricing:** Swell has a powerful pricing system that allows you to specify customer groups, volume-based discounts, and personalized promotions, all of which are table stakes for B2B brands.

* **Highly customizable:** Swell allows you to extend the core data models with your own attributes and concepts, enabling your dev team to customize your eCommerce experience in ways that wouldn’t be possible with the competition.

* **B2B-friendly payments:** With support for invoicing, multipart, and offline payments, Swell provides all the features you need to support payments for your B2B business.

* **Headless storefront:** Swell is a fully headless B2B platform, which gives you full control over your storefront experience. This allows you to freely and quickly iterate on the UX of your B2B shopping experience, with very few limitations.

* **Pricing:** Community plan starts at 2% of sales.

* **Best for:** Tech-savvy B2B brands with custom needs.


### 4. NetSuite SuiteCommerce

![NetSuite SuiteCommerce website](https://cdn.sanity.io/images/kqgmf0g2/production/a365f03b97983c072c8b620a0de26a48293bdb95-2560x2126.webp?fit=clip)

[NetSuite SuiteCommerce](https://www.netsuite.com/portal/products/ecommerce/products/ecommerce/b2b.shtml) is the cloud-based eCommerce solution by NetSuite, one of the leading providers of ERP software.

With NetSuite SuiteCommerce, you can manage all aspects of your business-to-business eCommerce brand, including quote management, reordering, invoicing, segment-based pricing and product catalogs.

Furthermore, NetSuite’s eCommerce solution natively integrates with NetSuite’s CRM, ERP and inventory management solutions, allowing you to manage large-scale eCommerce operations.

**Features:**

* **Scalability:** With NetSuite’s integrated ecosystem, you will get access to a suite of tools that will help you run your B2B eCommerce business by following industry-proven workflows.

* **Powerful analytics:** NetSuite SuiteCommerce offers powerful analytics capabilities, allowing you to build and save custom reports that help you drive your business forward.

* **Built-in CMS:** NetSuite SuiteCommerce’s built-in, drag-and-drop CMS allows you to make changes to your eCommerce site without development work and even schedule them to be published at a later stage.

* **Self-service account management:** The platform provides self-service account management capabilities: Customers will be able to manage returns themselves or contact your helpdesk if they need assistance with an order.

* **Pricing:** $999 licensing fee and $99 per user

* **Best for:** Mid- to large-size brands making the jump to enterprise.


### 5. Solidus

![Solidus website](https://cdn.sanity.io/images/kqgmf0g2/production/b4a8e4277a65c71ae24b0d363a33a432a4601f53-2560x2126.webp?fit=clip)

[Solidus](https://solidus.io) is an open-source eCommerce platform used by world-class B2C and B2B brands.

Based on the Ruby on Rails framework, Solidus offers eCommerce brands all the flexibility they need to build innovative customer experiences for their business-to-business brand, and provides a robust and scalable architecture that has stood the test of time.

Offering the ability to customize every single aspect of the storefront, admin panel and core business logic, Solidus is the perfect fit for B2B brands that want to offer engaging shopping experiences or need to integrate with an in-house/exotic PIM, ERP system, or other service.

**Features:**

* **Monolithic or headless:** Solidus natively supports monolithic and headless architectural models. Start quickly with a monolithic build, then transition to headless as your brand grows and you need more flexibility on the frontend.

* **Completely customizable:** Solidus offers native customization hooks for every single aspect of the customer and admin experience, as well as its internal business logic. You will be able to customize every bit of your 
eCommerce website however you like.

* **Scalability:** This is a platform that has stood the test of time, and is used by some of the world’s largest B2B and B2C eCommerce brands.

* **Vibrant community:** Solidus has a vibrant and active community of agencies, brands and contributors, all sharing their experience and know-how to help each other achieve their goals.

* **Pricing:** Free.

* **Best for:** Brands that want full control over their digital presence, to innovate and scale intentionally.

## Discover the best B2B eCommerce platform for your brand

There you have it — a curated list of the best B2B eCommerce platforms available on the market today!

To find the right eCommerce solution, look for one that has:

* The eCommerce features you want for your store(s).

* The flexibility to meet your unique business model.

* Good scalability to accommodate future growth and business needs.

Finding the right B2b eCommerce platform is one thing. Developing a seamless user experience that fits your brand is equally important. Nebulab can help you with everything from eCommerce migrations and storefront development to digital commerce strategy. No matter where you are in your brand’s journey, [we have the right service for you.](https://nebulab.com/#services)

[Get in touch today](/contact-us) to see how Nebulab can take your brand to the next level.

Top 5 B2B eCommerce Platforms for Growth-driven Brands

As funding for headless commerce platforms reached a staggering [$1.6 billion](https://www.forbes.com/sites/forbestechcouncil/2021/05/11/why-is-headless-commerce-getting-16-billion-in-funding/?sh=5322b28f513a) in 2021, these systems aren’t to be ignored. But how exactly do they compare to the so-called traditional “monolithic” eCommerce platforms, and when should you pick one over the other?

This guide will explore the headless commerce model, its benefits, how it differs from the all-in-one monolithic commerce system, and when it’s a good option for your brand.

## What is headless commerce and how does it work?

Headless commerce is an eCommerce architecture where the frontend layer, or presentation layer, is decoupled from the backend commerce functionality.

Before we continue, let’s review the key differences between the frontend and backend:

* **Frontend:** This is the user interface. Customers see and interact with the frontend, whether they’re accessing your eCommerce site, shopping app, digital kiosk or other shopping channels.

* **Backend:** The backend is the behind-the-scenes, technical side of an eCommerce store the customer doesn’t see. The backend includes the technologies and tools that run in the background to ensure customers can shop and [have smooth checkouts](/blog/one-page-checkout-with-spree).

In headless commerce, the frontend and backend systems communicate via Application Programming Interfaces (APIs). This approach allows you to update the frontend, the customer-facing part of your site, independently of the backend and even use different development frameworks. This separation of concerns offers several benefits which we’ll explore below.

Examples of headless eCommerce solutions are Commerce Layer, Swell, and Nacelle.


## 4 benefits of headless commerce

![Woman lying on a couch and using a laptop](https://cdn.sanity.io/images/kqgmf0g2/production/96998b94bc1edf8908d27f5af24b1a34e88c56a8-1200x797.jpg?fit=clip)

Platforms that adopt a headless architecture offer several benefits compared to monolithic, or so-called traditional eCommerce platforms. Here are the top four advantages.

### 1. Omnichannel capabilities

In an omnichannel eCommerce experience, customers can start shopping on one channel or device and transition seamlessly to a different channel while the brand retains key information: common examples are a customer completing their purchase online, but selecting in-store pickup, or a customer buying something in-store and having the order show up their online order history.

Headless commerce makes it easy to serve the [74% of shoppers](https://www.salesforce.com/content/dam/web/en_us/www/documents/research/salesforce-state-of-the-connected-customer-4th-ed.pdf) who use multiple channels to shop: because the same backend system can serve multiple storefronts, you can easily adapt customer touchpoints and shopping experiences to serve your eCommerce website, your mobile app, social media pages, and even physical locations. All will be completely integrated and feel seamless for your customers to interact with.

### 2. Technical flexibility

By decoupling backend and frontend, headless platforms allow your development team to pick the frontend stack, including third-party providers, that they’re most productive with. A headless architecture allows you to adopt your favorite content management system (CMS) to create rich editorial experiences, or elevate your storefront through progressive web apps (PWAs). This enables you to create engaging digital experiences that don’t face the limitations of traditional monolithic frontends.

When done right, headless architectures even allow you to refactor or completely replace entire parts of your backend with little to no impact on your frontend experience(s), which allows you to move and experiment much more quickly.

### 3. Superior personalization

Most monolithic eCommerce platforms severely limit your ability to personalize the customer experience by forcing you to work with proprietary templating language and preventing you from accessing customer data. With [80% of customers](https://www.epsilon.com/us/about-us/pressroom/new-epsilon-research-indicates-80-of-consumers-are-more-likely-to-make-a-purchase-when-brands-offer-personalized-experiences) indicating they prefer brands that offer tailored experiences, eCommerce personalization is now table stakes for modern brands.

Headless platforms allow you to not only leverage basic eCommerce data, such as a customer’s profile and order history, but even augment it with brand-specific data points of your own. This allows you to create shopping experiences that feel built for your customer, boosting customer engagement, conversion rates and AOV.

### 4. Blazing fast performance

Storefronts that leverage a headless eCommerce platform can typically be deployed as static sites and put behind a global content delivery network (CDN) such as Cloudflare. In the hands of a capable development team, this can lead to incredible performance that would be hard to achieve with a monolithic platform.

A 2019 study by Portent has found that improving your loading speeds can boost your conversion rates [anywhere from 1.5X to 2.5X](https://www.portent.com/blog/analytics/research-site-speed-hurting-everyones-revenue.htm)! If your eCommerce site loads slowly, you are leaving lots of money on the table—literally.

## 3 drawbacks of going headless

![Four programmers working at same office's table](https://cdn.sanity.io/images/kqgmf0g2/production/0afcfb4759febba635d79b5004c9a4cf4c8c2242-1200x800.jpg?fit=clip)

In some cases, a headless build can lead to an unnecessarily complex architecture that causes more problems than it solves. Evaluating which eCommerce platform to use for your business needs is a complex process that should take into account both short-term and long-term factors as well as your budget and internal capabilities.

Here are three drawbacks of headless eCommerce platforms.

### 1. Technical capabilities

Launching a headless storefront requires you to create an in-house engineering team or hire an eCommerce agency for the long term. Headless sites require more ongoing maintenance to keep the lights on: Dependencies need to be updated, infrastructure needs to be maintained, and the site needs to be continuously monitored for bugs and performance issues.

In our experience, this additional effort has its upsides: It forces brand operators to get into a continuous optimization mindset, where they’re constantly identifying and capitalizing on new technology and other opportunities that can improve the shopping experience. Monolithic platforms, on the other hand, encourage a less intentional set-and-forget approach, which is definitely easier to execute, but also worse positioned for long-term scalability.

### 2. Time-to-market (and cost!)

Headless builds are typically associated with slightly higher timelines than monolithic builds. Adopting a headless architecture requires a significant investment in an agency or an in-house development team that will build your storefront, and this process can take anywhere between 2 and 4 months, depending on the complexity of the build.

Conversely, launching a store on a monolithic platform can be a much faster process with more competitive pricing, if you’re willing to settle for a more standardized look and purchase experience. This can be an acceptable compromise for smaller mom-and-pop businesses, but certainly not for a direct-to-consumer (DTC) brand with large long-term aspirations.

### 3. Integration effort

Headless eCommerce platforms are very flexible because you have full freedom to implement your storefront however you want. Unfortunately, this also means that many of the integrations and plugins that you can use out of the box with a monolithic platform will require a bit more work to be integrated in a headless architecture.

If you want to add reviews to your headless eCommerce website, for instance, you’ll need to work with your designers and engineers to figure out what the experience should look like, where to place the reviews, when to ask for them etc., and then implement and test the new functionality.

Ultimately, this extra effort is a good thing: A headless system asks you to be more disciplined and intentional in how you modify your storefront. This will force you to approach all initiatives with a critical eye rather than jumping from trend to trend, but it can be frustrating if you’re used to installing a plugin and forgetting about it.


## The verdict: headless or monolithic?

![Woman holding a credit card and using a phone](https://cdn.sanity.io/images/kqgmf0g2/production/cb3e8d957a2c46acdf1eda32e9cecd9c5173bf13-1200x800.jpg?fit=clip)

The answer is: It depends on the use case. There’s no right or wrong answer.

While a headless commerce architecture has myriad benefits over monolithic architectures, it’s not ideal in all contexts. In certain scenarios, a headless commerce approach is the best way to build your vision and drive superior brand performance, while in others, you’re better off with a monolithic architecture that saves you time and money.

Headless commerce solutions might be right for:

1. **Brands that want to offer a consistent customer experience across channels:** Any brand that wants to deliver consistent customer experiences regardless of channels or devices should consider adopting this architecture.

2. **Brands that feel their current platform is too rigid and restrictive:** If you’ve ever felt your platform is limiting on the backend or frontend, it’s time to switch to a flexible headless setup.

3. **Brands that put personalization front and center:** If personalizing the shopping experience is critical for your brand’s strategy, then you should explore the capabilities that a headless build will unlock for your development team.

4. **Online stores that have slow-loading pages:** If sluggish pages have been a pain point for your eCommerce store, a headless architecture may be able to help by allowing you to leverage a more robust frontend ecosystem.

On the other hand, monolithic builds are a good solution for:

1. **Brands with limited technical know-how:** Headless commerce requires stronger technical capabilities which might not be everyone’s cup of tea. If you want to launch a commerce website without dealing with the underlying technicalities, headless is not for you.

2. **Brands with time-to-market or financial constraints:** If you’re on a tight timeline or a limited budget, a monolithic build will very often prove cheaper and quicker to launch than a headless counterpart.

3. **Brands that want ready-made functionality:** If you want to leverage ready-made features and integrations without thinking too deeply about how to integrate them in your shopping experience, a monolithic platform will give you more peace of mind.


## Need help picking the right platform?

![Entrepreneur using his phone and laptop](https://cdn.sanity.io/images/kqgmf0g2/production/97e367e0de824649a05070d381052e44e0ca20e4-1200x801.jpg?fit=clip)

Headless architectures allow teams to move faster, address changing consumer needs, improve the user experience, and capitalize on omnichannel opportunities, but they’re not ideal for all brands.

Nebulab can help your new digital brand pick the right eCommerce platform for a greenfield build, or help your established brand design the right tech stack for its next growth spurt. We offer full-service consulting throughout all stages of your eCommerce project.

[Reach out](/contact-us) to see how we can help you create a vision for your eCommerce experience.

Headless Commerce: The Good, the Bad and the Ugly

One of the most important decisions you will make when launching your digital brand is which eCommerce platform you build your store with. Typically, there are three categories to choose from:

* **SaaS platforms** are online software solutions that handle all the complexity of building and running a store. In exchange for a recurring license fee, these tools provide a storefront your customers can access as well as a backend to to manage your store. They are by far the quickest and easiest solution to get started. Popular examples in this category are [Shopify](https://www.shopify.com/) and [BigCommerce](https://www.bigcommerce.com/).

* **Open-source platforms** are ready-made software packages that provide similar functionality to what you could get with a SaaS platform. Because they are open-source, these platforms can be customized, although many of them are not built for that. Furthermore, you have to host them in your own infrastructure. Popular examples are [WooCommerce](http://woocommerce.com/) and [Prestashop](https://www.prestashop.com/).

* **Open-source frameworks** are software solutions that provide the basic functionality you need to build your store. They vary in functionality and underlying technology, but most of them are built to create extremely custom experiences and provide a very high degree of flexibility, at the cost of a steeper learning curve and a larger upfront investment. Popular examples are [Solidus](https://solidus.io/) and [Saleor](https://saleor.io/).
The main difference between SaaS platforms and open-source platforms is the pricing model: SaaS platforms require paying a recurring license fees, while most open-source platforms are free. In terms of functionality, however, they are pretty similar, so we will instead focus on the differences between SaaS platforms and open-source frameworks.

## Cost of ownership

SaaS platforms have two main pricing models: you either pay a fixed fee every month/year, or a percentage of your store’s sales volume. This results in a pricing model that scales with your store, but **it also means you are paying money just to keep your store online instead of investing in its continuous evolution.**

Most open-source frameworks, on the other hand, are entirely free to use, but you need to hire a development team that will build, launch and maintain your store. While this model requires a larger upfront investment, **it’s also a better fit for those entrepreneurs who are serious about investing in the technology that powers their business.**

If you can afford a larger upfront investment and you expect your brand to scale seriously, going with an open-source framework will reduce your total cost of ownership while creating more opportunities than you could get with an off-the-shelf solution.

## Customization possibilities

SaaS platforms offer a great starting experience with no customization work needed. This is really helpful for people who are just getting their feet wet in the eCommerce industry: **if you don’t know how to create a good UX and just want to start selling, a SaaS solution will help you.** This kind of simplicity doesn’t come for free, though: **SaaS platforms are not always easy to customize, and in certain cases you are stuck with the default experience they provide.**

Going with an open-source framework means you’ll have to figure out more stuff by yourself, but **it also affords you the flexibility to customize each and every aspect of your store however you see fit,** allowing you to truly innovate the buying experience rather than being one more droplet in a sea of digital brands.

The most prominent online brands became memorable not just because of their products, but because of the experience they created around all brand interactions. **If eCommerce is an important channel for you, you need to start seeing yourself as an experience company,** and treat technology as a first-class citizen.

## Data ownership

**SaaS platforms, unfortunately, act by their very nature as middlemen between you and your customers.** Because you are not hosting your infrastructure when you adopt a SaaS solution, you lose direct access to a lot of potentially useful information. These platforms try to make up for the lack of data ownership by providing out-of-the-box reporting tools, but they often fall short of brand expectations.

**With an open-source framework, you will always have complete access to all the data generated by your store.** This data can be used in any way you see fit: you can either customize your platform to generate advanced reports internally, or connect an external business intelligence tool that will help you take full advantage of all the information at your disposal.

Being a digital brands allows you to use data to your advantage: by accessing information that is not always available to traditional brick-and-mortar retailers, you can make smarter decisions, which reduces your costs and helps you stay competitive. The paradox here is that **data ownership is even more important for smaller brands, which don’t have access to economies of scale and can afford fewer mistakes.**

## Time to market

Because most SaaS solutions provide all the tools you need to start an online business out of the box, it will always be quicker to get your brand started with a SaaS platform than with an open-source framework, at least for a basic store. **If you’re in a hurry to get started and cannot afford to wait, you should definitely look into SaaS.**

With that said, one aspect to keep in consideration is the velocity of your team when evolving your store in response to market conditions. **In the hands of a skilled engineering team, an eCommerce framework will be not only quicker to adapt, but because it’s built to be customized, it will also allow you to make optimizations that stand the test of time.** SaaS platforms, on the other hand, often require ugly hacks that cost you more time in ongoing maintenance than for their initial development.

For most brands, time to market for the initial launch is not a relevant factor. On the other hand, time to market in capitalizing new opportunities and evolving your eCommerce experience can make or break a digital brand.

## So… which one is it?

As you have seen, there are different factors to take into consideration when choosing the best eCommerce platform for your needs. Most of them boil down to two key aspects: experience and vision.

**If you are only getting started in eCommerce, or think of your brand mainly as a product company, you should probably consider SaaS options.** They will make selling online a no-brainer, at the cost of technical limitations and a higher total cost of ownership.

**If you are an eCommerce veteran, or consider customer experience to be paramount in building your brand, you should instead going with an open-source framework**, making a larger upfront investment in order to have a flexible platform that will allow you to deliver a completely custom experience.

What Can Open Source Do for eCommerce?

As an eCommerce consulting firm, we know the value behind a custom store implementation: **not going
with a SaaS solution affords you maximum flexibility and endless innovation opportunities** —
there's nothing a good development team can't do.

For digital brands, this can be powerful: **when your platform doesn't limit you, you can implement
whatever you have in mind,** and create even stronger bonds with your customers.

However, there are also downsides:

* Having a solid development workflow is good for new features and invasive modifications, but it
  becomes a bottleneck when you only need to change an email template, or the arrangement of
  elements on a page. Relying on developers for these tasks can slow you down.
* **Your developers' time is important and, most likely, expensive.** Having them make trivial
  adjustments to your content or campaigns may not be the best use of their expertise. Instead, you
  should do whatever you can to free them up for more important work.

Luckily, a lot of tools have emerged over the last years that allow you to make changes to almost
every customer-facing aspect of your store without necessarily involving your developers. These are
SaaS tools that only have to be integrated with your store once, and then provide you with an admin
panel you can access and use autonomously.

There are a lot of options for different categories, and over the years we've used many of them for
our customers. Here's a round-up of the best one in each category, along with a few alternatives
you may also want to try!

## 1. Manage your content yourself

Content management is one of those areas where self-serve tools have been available for a long time,
but are not always used (the right way). Headless CMS solutions are all the rage now, and the
philosophy behind them is fairly simple.

Unlike a traditional CMS, that allows editors to enter whatever they want in the page, with the risk
of creating un-optimized or even broken layouts, **headless CMSs require your developers to specify
the possible structure of the content upfront.** Content editors can then manage the content through
the headless CMS. Finally, this content is pulled by your store and displayed to your customers when
they visit the corresponding page(s).

While they may seem limiting to someone accustomed to old-style content management tools, **headless
CMSs are extremely powerful if used the right way**, and they can be just as flexible, if not more,
than traditional solutions, while sparing your developers a lot of tedious work.

### The best headless CMS: Prismic

[VIDEO](https://drive.google.com/file/d/181Oppz0QeRmrr11ShCrQ4DXC4jwpTNQT/view?usp=share_link)

Out of all the headless CMSs we have tried, [Prismic](https://prismic.io) definitely comes out on
top. **It's an extremely modern tool with a powerful API and development toolkits for the most
popular languages, and it can be easily integrated in any application.**

Its pricing is also [very competitive](https://prismic.io/pricing), with a free basic plan and
attractive options for organizations of all shapes and sizes.

There are a couple of alternatives also worth considering:

* [Alchemy CMS](https://alchemy-cms.com/about) is an open-source, self-hosted headless CMS for Ruby
  on Rails applications. It's a good option if you don't want to pay a third-party to host your
  content, but may be more complex for your development team to configure and maintain, especially
  if they don't have experience with Ruby.
* [Contentful](https://www.contentful.com) is Prismic's main competitor. While it's a solid option
  trusted by large companies such as Spotify, Lyft and Twilio, we have found it to be less reliable
  than Prismic, and a bit behind the curve when it comes to its technical capabilities. The pricing
  is also [much steeper](https://www.contentful.com/pricing) than Prismic's, going from $39/mo to
  $879/mo.

## 2. Build 360-degree marketing campaigns

**For digital brands, creating a loyal customer-base that identifies with your values and mission is
a matter of life or death**, and how, when and where you communicate with your users is key to
creating a successful and engaged community of brand _aficionados_.

Unfortunately, very often these touchpoints are hardcoded by developers into the application, which
means every experiment and every change need to go through the development team before customers can
benefit from them. **This can be especially critical for time-sensitive marketing campaigns,** where
getting the timing right can mean the difference between a customer and a lost sale.

Luckily, there are a few tools out there that can help you take back control. The integration flow
is usually straightforward: you ask your developers to send customer information to the marketing
automation service, which you then use to communicate with customers autonomously.

### The best marketing tool: Klaviyo

![The Klaviyo email marketing UI.](https://cdn.sanity.io/images/kqgmf0g2/production/34c56d7e6b8d6bda3f2dfaf44a6668137211eab0-1395x762.png?fit=clip)

A relatively recent product, [Klaviyo](https://www.klaviyo.com/) won our hearts when we first used
it, thanks to its flexibility and ease of customization for the end-user.

It allows you to run email, SMS and social media marketing campaigns all from the same interface
and leveraging the same dataset, and (obviously) supports A/B testing of your campaigns so that you
can test small changes and tweak your campaigns accordingly.

But where Klaviyo really shines is in its event-based architecture: by integrating with your store,
**Klaviyo knows when your customers take certain actions and allows you to build complex automated
campaigns** such as abandoned cart flows, all without having to involve your devs!

The most prominent alternative to Klaviyo is [Mailchimp](https://mailchimp.com), a giant in this
industry. While it provides many of Klaviyo's features, Mailchimp lacks SMS marketing capabilities
and has other features, such as landing pages and postcards, that may not be needed by the average
brand.

## 3. A/B test to your heart's desire

A/B testing can be a complex feat to pull off properly. Not only do you have to implement the
testing logic, but you also need a solid framework in place to validate the results of your
experiments and ensure you're not jumping to conclusions.

From a technical standpoint, implementing experiments is not fun either: each experiment needs to
be implemented manually, and failed experiments often linger unused in your codebase because no one
has time to remove them. **Over time, this accumulation of failed experiments can create huge
amounts of technical debt and slow down development.**

The complexity behind running a reliable A/B test often puts off companies who'd like to start with
the technique. When done right though, **A/B testing can be a powerful tool to optimize your
conversion rates and get a better sense of your customers' taste**, and there are a few tools you
can use to make this process a breeze.

### The best A/B testing tool: Optimizely

![The Optimizely A/B testing UI.](https://cdn.sanity.io/images/kqgmf0g2/production/1c7ac7dc278e63f43c8fd68b6f1cf66dd6f6101b-1849x1278.png?fit=clip)

[Optimizely](https://www.optimizely.com/) is an all-in-one platform for A/B testing all aspects of
your website, trusted by the most prominent startups and enterprises. A full-stack implementation
consists of two components:

* A frontend plugin that allows you to **run customer-facing A/B tests without involving your
  development team**, e.g. testing two versions of your landing page.
* A backend integration that allows your development team to implement A/B tests for more complex
  aspects, such as testing different promotions or shipping options.

You can manage experiments directly from Optimizely's UI, **which will also determine the winner
with its proprietary algorithms** — no Excel spreadsheet needed.

A popular alternative to Optimizely is [LaunchDarkly](https://launchdarkly.com), although you should
know LaunchDarkly is more focused on feature flags and does not provide a visual editor that allows
you to run customer-facing experiments without asking your developers.

## 4. Up your data collection game

Data is the stepping stone in the journey from online store to digitally-native vertical brand. As
Andy Dunn, one of Bonobos' co-founders and
[the man who coined the term _DNVB_](https://medium.com/@dunn/digitally-native-vertical-brands-b26a26f2cf83),
says:

> Deeper data on the consumer drives enables the DNVB to stay closer to the customer than its brick
> and mortar driven peers, and the ownership of the brand end-to-end fuels more affinity for a
> vertical commerce brand than even the best e-commerce experiences.
Being able to do more with your data unlocks new possibilities for your business. In turn, **your
ability to analyze data in a meaningful way is a function of how much data you collect and where.**

Traditionally, adding a new analytics service to your toolbelt has been very dependent on
development work. Developers would have to write a custom integration for the new service and then
test it to make sure data was being collected consistently and reliably. This could result in slow
integration times and lost opportunities.

But in the last few years, a new category tools was born that promise to solve this problem once
and for all. This new breed of services acts as a gateway between your application and all of your
tracking and analytics tools. They provides a unified programming interface that **drastically
simplifies the integration work for your development team,** as they only have to integrate with one
service and not ten. Store owners can then manage all of their tracking integrations from the
gateway's control panel. Adding new services is as simple as clicking a button — no dev needed!

### The best data platform: Segment

![The Segment data collection UI.](https://cdn.sanity.io/images/kqgmf0g2/production/0f94ab549ae2c13cf121a0c26936e899aa9f079d-1121x519.svg?fit=clip)

[Segment](https://segment.com) touts itself as a customer data platform (CDP). In other words, they
provide a centralized data collection service and give you the tools you need to manage and act on
your data.

Trusted by tens of startups and large organizations, Segment lives up to its promise of dramatically
simplifying data collection: **developers only have to integrate Segment in your application once.**
You can then enable and test new tracking and analytics services in a blink of an eye, freeing up
your engineering team's time for other initiatives.

In our experience, **Segment is incredibly reliable and provides an amazing user experience.** It
reduces development spend and implementation time.

A popular alternative is [Google Tag Manager](https://tagmanager.google.com/), which allows you to
manage all of your tracking snippets from one interface. However, GTM is much more limited than
Segment, because it simply acts as a central repository for different tracking codes, and doesn't
know anything about the data you are collecting. On the upside, it's free, so it may be a good
starting point if you just want to dip your toes in this water, or if you don't need a full-fledged
data collection platform.

## 5. ...and access new business insights!

Now that customer data is flowing in the right direction(s), it's time to use it to make informed
decisions about your business. In order to do that, many stores develop their internal reporting
tools, which take a lot of time away from core business priorities, or turn to Excel spreadsheets,
which often fall short of business requirements.

Instead, **companies that use data to drive important decisions, such as digitally-native vertical
brands, can and should rely on battle-tested Business Intelligence (BI) platforms.** These are tools
that plug directly into your data sources and can generate reports about all aspects of your
company's operations and sales.

Using a BI platform instead of in-house solutions allows you to access richer insights into your
data and let your developers focusing on core business capabilities rather than internal software.

### The best BI platform: Looker

![The Looker business intelligence UI.](https://cdn.sanity.io/images/kqgmf0g2/production/ad302d86b3f6a04f0641560e3f0bcdc04966649d-942x571.png?fit=clip)

There's no shortage of BI platforms, as these tools have always been used by companies of all sizes
to better understand the market and drive strategic decisions. Among all the options,
[Looker](https://looker.com) stands apart for its modern take on business intelligence.

By combining BI, data visualization and reporting capabilities, **Looker allows you to create very
flexible experiences:** for instance, you can embed data visualizations directly in your store's
dashboard, or send a sales report every month to your key decision-makers, so that everyone's always
in the loop and can make the right decisions.

**Looker allows you to access the data you need, wherever you need it,** making sure that reports
are being put to good use rather than just sitting there and gathering dust.

[Tableau](https://www.tableau.com) is also worth looking into, although it takes a more traditional
approach to business intelligence, centralizing all your data and reports under the same roof.

## Flexibility + automation FTW

Most of these tools have plugins to integrate with the most popular SaaS eCommerce platforms.
Unfortunately, **these plugins often offer a shallow integration** that doesn't cover all customer
touchpoints or doesn't capture all the data you could leverage.

In some cases, the fault lies on the plugin developer for not doing a good job. In others, it's due
to the sandboxed nature of SaaS solutions, that don't expose all the hooks and information the
services need to show their full potential.

**By adopting a flexible, open-source eCommerce framework such as [Solidus](https://solidus.io), you
are getting the best of both worlds:** on one hand, you can create deep integrations that let you
leverage all the features of these awesome services; on the other, you are not limited by your
platform, and can implement all those features that make your brand stand apart from its
competitors.

5 No-Code eCommerce Management Tools

[Event programming][event_programming] (also known as the pub/sub pattern) has
been gaining lot of traction in recent times, not without reason. Events allow
to easily add custom behavior to a process that the developer may not own
directly or know in detail: you just need to subscribe to a known event and
then, when it happens, your code will run.

In the past, a few attempts were made to add an events system to
[Solidus][solidus], and finally events became a reality in version 2.9 after
this [PR][solidus_events_pr].

## Solidus events: the basics

How do events work in Solidus? They're actually rather simple, let's start the
Solidus sandbox console and get our hands dirty. First, we need to subscribe to
the event we're insterested in:

```ruby
Spree::Event.subscribe 'foo' do |event|
  puts "Event with name '#{event.name}' just fired!"
end
```

then, we can manually fire it:

```ruby
Spree::Event.fire :foo
```

and the text `Event with name 'foo' just fired!` will appear on your screen...
that was easy 🍰

## Introducing event subscribers

Let's now consider a more ‘real life’ scenario. We want to deliver
[transactional emails][transactional_emails] to customers in a centralized way.

The first step is to patch the state machines of some Solidus models in order
to fire events when the shipment or order state changes. These two modules will
do the trick:


```ruby
module OrderDecorator
  def self.prepended(base)
    base.state_machine do
      after_transition do |order, transition|
        Spree::Event.fire "order_#{transition.to_name}", order: order
      end
    end
  end
  Spree::Order.prepend(self)
end
module ShipmentDecorator
  def self.prepended(base)
    base.state_machine do
      after_transition do |shipment, transition|
        Spree::Event.fire "shipment_#{transition.to_name}", shipment: shipment
      end
    end
  end
  Spree::Shipment.prepend(self)
end
```

Then, we add a subscriber module that will deliver mails when orders and
shipments change to the right state:

```ruby
module TransactionalEmailsSubscriber
  include Spree::Event::Subscriber
  event_action :order_complete
  event_action :order_canceled
  event_action :shipment_shipped
  def order_complete(event)
    TransactionalMailer.notify_order(event.payload[:order])
  end
  def order_canceled(event)
    TransactionalMailer.notify_order(event.payload[:order])
  end
  def shipment_shipped(event)
    TransactionalMailer.notify_shipment(event.payload[:shipment])
  end
  subscribe!
end
```

The module includes `Spree::Event::Subscriber`, which simplifies events
subscriptions by sparing you to write some tedious boilerplate.

You need to define which event you want to subscribe to with the `event_action`
macro and then define a corresponding method that will be called when the event
is triggered.

If the module is loaded late enough in the initialization process of the app,
then it can be subscribed to directly from within its definition (see last
line), otherwise it needs to be explicitly subscribed to, for example in an
initializer:

```ruby
TransactionalEmailsSubscriber.subscribe!
```


The last and optional step, if you want to actually see the examples work, is
to define the fake `TransactionalMailer` class:

```ruby
module TransactionalMailer
  extend self
  def notify_order(order)
    puts "Dear #{customer(order)}, your order #{order.number} is now #{order.state}."
  end
  def notify_shipment(shipment)
    order = shipment.order
    puts "Dear #{customer(order)}, shipment with tracking #{shipment.tracking} for order #{order.number} is now #{shipment.state}."
  end
  private
  def customer(order)
    order.bill_address.firstname
  end
end
```

Everything is now in place, so you just need to complete, cancel or ship some
shipments. One quick way is to copy all the code above in the Solidus core
specs for the order or shipment model, run them and watch the text appear on
screen:


<img
  src="/assets/blog/img/posts/solidus-events/tests.png"
  alt="Solidus shipments test run in console"
  />

## Subscribe to multiple events

Recently Solidus gained the ability to subscribe to multiple events by using
regular expressions. This is a feature made possible by the fact that
ActiveSupportNotifications supports regexps — though other event adapters, when
they will become available, may not offer this feature as well.

Using regular expressions may help, for example, when you want to subscribe
to all order's events, or during debugging. You can use this code if you want
to be notified each time an event is fired:

```ruby
Spree::Event.subscribe /.*\.spree/ do |event|
  puts "#{event.name} => #{event.payload.inspect}"
end
```

Please note that you need to explicitly include the `spree` namespace in the
regexp, or you will subscribe to all ActiveSupport notifications, including
the ones from Rails internals.


## How Solidus events work

Solidus events are based on [Rails][rails]'
[ActiveSupportNotifications][ASNotifications], but the actual event backend is
configurable, so new event adapters may be added by the core team in the future
(or you can create your own, of course).

ActiveSupportNotifications seemed to be the most reasonable choice for
implementing the default event adapter for the following reasons:

* it's default Rails
* it's battle tested since Rails 3.x
* it doesn't require any external events library
* it's widely used in Rails internals
* it's simple and easy to use

Solidus events are a relatively new feature, so they still need to become widely
used in the Solidus codebase, but developers can start using them anywhere for
their convenience by adding custom events and subscribing to them. And if you
think you found a good use case, then please consider sharing it with the
community by opening an issue or a PR in Solidus... thank you!

A Guide to Solidus Events: Everyone's Invited!

Recently one of our customers informed us that they were getting weird numbers from
Facebook and Google in regards to order purchase amounts on their [Solidus][solidus] based
eCommerce.

Facebook and Google reported multiple order confirmations with the same order number, the actual
order total amounts were from 2 to 6 times lower than what was reported by them.

These numbers looked very nice on paper 📈 and could boost some distracted egos (people are
buying plenty of stuff, we're doing much better than expected!!! 💵🤑💰) but unfortunately they were so
inaccurate to be pretty useless. Houston, we have a problem 👨‍🚀.

The first step was to check how Google and Facebook get that data: some JavaScript code that
is supposed to be executed only once sends all tracking information when the customer is
redirected to the order page after completing the checkout.

How do we inject the JS code only once? By leveraging a feature in Solidus frontend
codebase: a convenient `flash` message is set after the order is finalized, and it can
be used as a flag in order to trigger the tracking libraries.

What follows is the [relevant code][checkoutcontroller] in Solidus codebase. Everything starts
in `#update`, then `#finalize_order` is called and eventually the message is set in
`#set_successful_flash_notice`:


```ruby
  # solidus/frontend/controllers/spree/checkout_controller.rb
  def update
    if update_order
      assign_temp_address
      unless transition_forward
        redirect_on_failure
        return
      end
      if @order.completed?
        finalize_order
      else
        send_to_next_state
      end
    else
      render :edit
    end
  end
  private
  def finalize_order
    @current_order = nil
    set_successful_flash_notice
    redirect_to completion_route
  end
  def set_successful_flash_notice
    flash.notice = t('spree.order_processed_successfully')
    flash['order_completed'] = true
  end
```

And this is the code in our customer's eCommerce that uses the `flash` message:

```erb
   <% if flash['order_completed'] %>
      <%= render "facebook_tracking" %>
      <%= render "google_remarketing" %>
      <%= render "adwords" %>
    <% end %>
```

The usual suspect for such issues is __caching__. If the page is cached (either on
the server or the client) then the HTML (JS code included) is not fresh and
will trigger the tracking events multiple times, one time for each page
view.

Testing locally and on the staging environment (which happens to mirror production
in regards to cache settings and such) confirmed that events are
correctly triggered only once: the expected JS code is present on the first page load
but is not on subsequent visits.

Soon we were able to confirm the issue with Safari on iOS. If you complete the
order and close the browser/restart the device then, when you reopen Safari, the
page is reloaded from the cache, not from the web.

The next step was to check the page HTTP headers. This can be done easily and
quickly from the command line using `curl -I <page-url>`.

The response included these results:

```
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/html
```

Let's get some help from [MDN][mdn] website in regards to the `Cache-Control: private`
directive:


>[private] Indicates that the response is intended for a single user and must not be stored
>by a shared cache. A private cache may store the response.
So, this directive does not completely exclude caching.

The fix was easy: customize the HTTP headers to completely avoid caching. This was
done with regular [Ruby on Rails][rails] code by extending the [controller][orderscontroller]
`OrdersController` in Solidus frontend with a decorator:

```ruby
  module OrdersController
    module EditActionCacheHeaders
      def self.prepended(base)
        base.before_action :set_no_cache_headers, only: :show
      end
      private
      def set_no_cache_headers
        response.headers['Cache-Control'] = 'no-cache, no-store'
        response.headers['Pragma'] = 'no-cache'
        response.headers['Expires'] = "Fri, 01 Jan 1990 00:00:00 GMT"
      end
      Spree::OrdersController.prepend self
    end
  end
```

When changing Solidus default behavior, it's better to do it in a decorator that extends the
default functionality with `prepend` rather than reopening and patching its methods directly.
This solution allows for easier maintenance, more clarity of purpose and composition.

The order page is managed by `OrdersController#show` action, which we don't need to modify
at all as adding a new `before_action` suffices to achieve the goal.

The first line of `#set_no_cache_headers` method is the most relevant, as it instructs all
recent browsers (HTTP/1.1) to __absolutely not__ cache and store the page for any reason.<br>
The second line `response.headers['Pragma'] = 'no-cache'` targets older browsers (HTTP/1.0)
that can accept only the `Pragma` header, while the third line set the `Expires` header well in
the past, as an extra safeguard just in case the previous headers failed their purpose.


before saying goodbye let me share a much cited quote from [Phil Karlton][quote-source]:

> There are only two hard things in Computer Science: cache invalidation and naming things.
Have a good one!


[solidus]: https://solidus.io
[mdn]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
[checkoutcontroller]: https://github.com/solidusio/solidus/blob/master/frontend/app/controllers/spree/checkout_controller.rb
[orderscontroller]: https://github.com/solidusio/solidus/blob/master/frontend/app/controllers/spree/orders_controller.rb
[rails]: https://rubyonrails.org/
[quote-source]: https://skeptics.stackexchange.com/questions/19836/has-phil-karlton-ever-said-there-are-only-two-hard-things-in-computer-science

Boosting sales with browser cache!?!

Ensuring privacy of customer data is undoubtedly a matter of great importance
for any reputable retail business going online. Setting up an online presence
entails global access to business resources including goods, services and
personal information collected during interaction with customers. It is,
therefore, necessary that adequate mechanisms are put in place to guarantee
confidentiality and integrity of business data made available online.

Access control is a primary security concern. Generally, there are two main
ingredients to the access control equation:

- **Authentication**. To grant access, the system must first establish the
identity of the subject initiating the request to the server. The
identification process is called authentication and can be performed by
either a human or by yet another system;
- **Authorization**. With the obtained identity the system can proceed to
reason about the actions available to the current user within the system.
Restricting access to resources based on the given identity, or the absence of
one (e.g. guest user), is called authorization.

Both authentication and authorization are off the shelf features of [Solidus](https://solidus.io/).
This article delves into authorization and how it can be set up within Solidus
to align with your business needs.

## Built on CanCan(Can)

Authorization in Solidus is built upon the [CanCan(Can)](https://github.com/CanCanCommunity/cancancan)
gem, which offers an expressive DSL to [define](https://github.com/CanCanCommunity/cancancan/wiki/defining-abilities)
and [verify](https://github.com/CanCanCommunity/cancancan/wiki/checking-abilities) user permissions against application resources.
CanCan allows one to avoid access control logic being scattered throughout the
application source code. Instead, it enables one to define all user permissions
in Ability classes. For instance, here is a simplified Ability class for an
eCommerce application:

```ruby
class Ability
  include CanCan::Ability
  def initialize(user)
    user ||= User.new
    if user.admin?
      can :manage, :all
    else
      can :display, Product
      can :display, Taxon
      can :display, Taxonomy
      can :display, Variant
    end
  end
end
```

With the growth of the application, ability files like the one above tend to
quickly become massive and hence hard to maintain. With that in mind, Solidus
augments CanCan interface to facilitate implementation and maintenance of
complex ability specifications.

Let's go through the steps required to set up a custom permission system within
Solidus by examining the configuration of those permissions that already ship
with the eCommerce platform.

## Roles

Solidus comes with two preconfigured roles: *admin* and *default*. User that
`has_spree_role?(:admin)` has access to the admin panel and can manage all
resources. User that `has_spree_role?(:default)` resembles a client or a website
visitor, that can view certain resources, manage their shopping carts, etc.
Here are two main options to create a new `Spree::Role`:

- Manually add a row in the `spree_roles` table by executing
`Spree::Role.create(name: 'role_name')` in the rails console;
- In one of the configuration files (`config/intializers/spree.rb`, `config/application.rb`,
`db/migrations`, `db/seeds`) add a line `Spree::Role.find_or_create_by(name: 'role_name')`
for each role you wish to create.

With the user roles identified and created, we can proceed with assigning them
permissions sets.

## Permission sets

Addition of each new role to your application (e.g. `:blog_editor`,
`:promotion_manager`, `:retail_admin`, etc) increases the overall authorization
logic complexity. Solidus enhances the permission management process by solving
three issues:

- Enable one to split the Ability class into smaller chunks of related
permissions;
- Enable reuse by allowing one to mix and match various user roles with
various permission sets;
- Enable one to extend abilities (think pushing roles and permissions to an
array), rather than directly overriding or decorating the Ability class;

For example, by extending `PermissionSet::Base` it is now possible to decouple
the admin role permissions from the rest of the access control logic:

```ruby
# lib/spree/permission_sets/super_user.rb
module Spree
  module PermissionSets
    class SuperUser < PermissionSets::Base
      def activate!
        can :manage, :all
      end
    end
  end
end
```

The same decoupling is then applied to the default user role permissions:

```ruby
# lib/spree/permission_sets/default_customer.rb
module Spree
  module PermissionSets
    class DefaultCustomer < PermissionSets::Base
      def activate!
        can :display, Product
        can :display, Taxon
        can :display, Taxonomy
        can :display, Variant
      end
    end
  end
end
```

New permission sets should be created in their dedicated classes that extend
`Spree::PermissionSets::Base`. Permission rules defined with the CanCan DSL
should be created in the `activate!` method. Following the examples above,
place your custom permission sets under the `lib/spree/permission_sets` folder.
Finally, remember to load Solidus lib files in your application configuration:

```ruby
# config/application.rb
config.before_initialize do
  Dir.glob(File.join(File.dirname(__FILE__), "../lib/spree/**/*.rb")) do |c|
    require_dependency(c)
  end
end
```

## Role configuration

Permission sets organize related permissions without binding them to any user
role. A role can be associated with a list of permission sets through a call
to `assign_permissions` in the Solidus initializer:

```ruby
# config/initializers/spree.rb
Spree.config do |config|
  config.roles.assign_permissions :admin, ['Spree::PermissionSets::SuperUser']
  config.roles.assign_permissions :default, ['Spree::PermissionSets::DefaultCustomer']
  ...
end
```

## Conclusion

An authorization system is an integral part of any modern application that
assumes user interaction. Both development and maintenance of authorization
logic quickly become non-trivial with the growth of the application.
Specifically, adding new roles and permission logic contributes to the
increasing complexity of the system.

Solidus provides a built-in solution for user permission management. Extending the CanCan interface, the proposed approach allows one to group related permissions into separate sets and later assign them to different roles. Defining role permissions from smaller permission sets, or "componentization", allows to reduce the perceived complexity of the overall system while preserving a modular and easily maintainable system.

Your eCommerce Needs Authorization: Enter Solidus

for extracting data from each schema. This approach is cheaper than
multi-db because it requires less hardware, time and resources to
manage a large number of customers.

### Shared schema

In this implementation the tenants' records share the same tables within the same database, using an ad-hoc column in each table to discriminate among all tenats' records.

There is no data isolation and no fault tolerance: every problem with our
persistent layer affects on all tenants; all backups, restores, extraction
operations for a single tenant do not come for free: you should implement all these mechanisms by yourself at the application level because you could have different policies for different customers.

Just like the multi-schema approach we'll face less costs in terms of hardware in the long period but considerable development costs of a shared-architecture.

### Which approach should I use?

The answer is always the same: it depends. When you choose a solution you have to face several trade-offs. [This article][msdn-multi-tenant-data-architecture] provides some interesting considerations.

As a rule of thumb it's better avoid a multi-db approach if you don't know for
sure how many tenants you're about to manage. Avoid a shared approach if you expect a huge amount of data per tenant or when particular capabilities are required for each tenant.

> Choose the right tool for the right job.
## Within Rails

Now back to the topic of this blogpost: how to migrate our newly created Solidus eCommerce to multi-tenant?

First of all, Solidus is a Rails app and achieving multi-tenancy within Ruby on
Rails is quite easy due to the highly flexible and extendible
nature of the Ruby language and Rails' engine-based architecture. After all, that's one of the main reason [we work with Solidus!][nebulab-blogpost-why-solidus]

I recommend this *old-but-gold* [Railscast][ryan-bates-railscast-multi-tenant] that shows how to implement a shared-schema multi-tenant architecture by yourself using ActiveRecord scopes.

However there are already a bunch of gems implementing all types of
multi-tenancy.

### Apartment

There is an amazing, mature - and veeery well documented - gem made by
[**Influitive Corp.**][influitive-homepage] called [Apartment][apartment-gh]
that will implement both multi-db and multi-schema architectures pretty well and
almost *out-of-the-box*. This gem basically introduces a [Rack][rack-homepage]
middleware (called *Elevator*) that is responsible of intercepting the
requests, selecting the target tenant according to some criteria
(like the domain/subdomain name or, for example, the authenticated user) and
preparing ActiveRecord queries with all the stuff needed to switch to the
correct database or schema.

There are a lot of articles on how to migrate your RoR application to
multi-tenant using the Apartment gem. We really appreciated [Troy
Anderson's Zero to Multi-Tenant in 15 Minutes – A Rails
Walkthrough][zero-to-multi-tenant], and [this blogpost by Brad Robertson][influitive-blogpost-multi-tenant-journey-with-apartment].
There are also some useful screencasts (see *Credits*).

## Within Solidus

As mentioned above Apartment basically interacts with ActiveRecord and the Rack middleware system on which Rails relies on, so should work pretty well together with Solidus. And so it is! However, there are some known issues we have to keep in mind when switching a Solidus app to multi-tenant.

In fact, as the application complexity and dependencies grow, we could face
some conflicts or issues, expecially when we use some specific or intrusive
gems. Here I'll summarize the most common I found around the web. I've created [this tutorial project][multi-tenant_shop] that aims to serve two different online stores: `www.pescara-shop.com` and `www.latina-shop.com`. The project relies on the Apartment gem and adopts a multi-schema implementation. This project has a good README and a list of self-explaining commit messages you can follow as step-by-step instructions. Here you can find more details about the encountered issues and some advice on how to make Solidus and Apartment work.

#### Preferences

Since Solidus preferences could be persisted in the database
(`legacy_db_preferences` mode), we could store the preferences for each tenant when the application starts and retrieve the correct preferences with each request, depending on tenant. Unfortunately, saving preferences on database is currently deprecated and it might be removed:

> Replace the default legacy preference store, which stores preferences in the
> spree_preferences table, with a plain in-memory hash. This is faster and less
> error-prone.
But using a plain in-memory hash requires [some
workarounds][multi-tenant-shop-preferences-ext] to properly store the preferences.

#### Testing

Since Solidus uses [RSpec][rspec-homepage], I've focused my analysis on how this testing suite works with the Apartment gem.  Let's start by looking at the [Apartment wiki page][apartment-testing]. Here we can find most of the instructions and the best practices we need:

> The number one thing that has helped us in testing is to create a single
> tenant before the whole test suite runs and switch to that tenant for the run
> of your tests.
In fact, using feature specs is almost impossible, and as far as I know, the
reason is the same why we cannot use __transactional tests__ with Capybara:

> Transactional fixtures do not work with Selenium tests, because Capybara uses
> a separate server thread, which the transactions would be hidden from. We
> hence use DatabaseCleaner to truncate our test database.
See [this issue][apartment-capybara-issue444] for more details.

The combination of the mandatory use of [DatabaseCleaner][dbcleaner-gh] and the need to test against a single test-tenant, produces a quite standard
configuration like this:

```ruby
# spec/rails_helper.rb
RSpec.configure do |config|
  config.use_transactional_fixtures = false
  config.before(:suite) do
    # Clean all tables to start
    DatabaseCleaner.clean_with :truncation
    # Use transactions for tests
    DatabaseCleaner.strategy = :transaction
    # Truncating doesn't drop schemas, ensure we're clean here, app *may not* exist
    Apartment::Tenant.drop('test_app') rescue nil
    # Create the default tenant for our tests
    Apartment::Tenant.create('test_app')
  end
  config.before(:each) do
    # Start transaction for this test
    DatabaseCleaner.start
    # Switch into the default tenant
    Apartment::Tenant.switch! 'test_app'
  end
  config.after(:each) do
    # Reset tentant back to `public`
    Apartment::Tenant.reset
    # Rollback transaction
    DatabaseCleaner.clean
  end
end
```

#### Seeding

I reccomend using Rails' plain-old seeds mechanism instead of external gems. One of the most famous is [Seedbank][seedbank-gh], but it doesn't seem to be working with Apartment (and lacks support for Rails 5). A little code has to be written in order to setup a very basic tenant-based seed loading mechanism. Something like:

```ruby
# config/db/seeds.rb
NebulabShop::Stores.each do |tenant, domain|
  Apartment::Tenant.switch(tenant) do
    Rails.root.join("db/seeds/#{tenant}").each_child do |seed_file|
      puts "Loading seed file: #{seed_file}"
      load seed_file
    end
  rescue Errno::ENOENT => e
    puts "there was an error while accessing #{e.message}"
  end
end
```

#### Asynchronous jobs

[Sidekiq][sidekiq-homepage] is probably the best known background processor for Ruby and Rails. Although it's not a gem included in Solidus there's plenty of situations where you probably need asynchronous jobs. Luckily, as mentioned in the Sidekiq wiki

> You can use client middleware to add job metadata to the job before pushing it
> to Redis. The same job data will be available to the server middleware before
> the job is executed, if you need to set up some global state, e.g. current
> locale, current tenant in a multi-tenant app, etc
it's possible to exploit the middleware architecture of Sidekiq to inject
tenant-switching logic into the Sidekiq workflow. Moreover, there's no need to
implement this by yourself! Influitive developed an Apartment adapter
for Sikdekiq called [apartment-sidekiq][apartment-sidekiq-gh].

## Conclusions

In this blogpost I've briefly introduced the concept of multi-tenancy and
investigated on how the adoption of this architecture could impact our Solidus
application, giving a sum up of some useful resources I've found along the way.
I've highlighted the amazing extendable architecture of the framework which allows us to highly customize our business logic and behaviors - and so multi-tenancy - by simply decorating Solidus objects. If you're interested in a more
deep dive into implementation or configuration details, you can refer to the
[*Multi-tenant shop*][multi-tenant_shop] project. Hope this helped you! Feel free to comment or ask for any questions.

## References and Credits

#### Articles

+ [Ruminations on multi-tenant][ruminations-on-multi-tenant]
+ [Multi-tenant ecommerce platform][multi-tenant-ecommerce]
+ [Multi-Tenant Data Architecture][msdn-multi-tenant-data-architecture]
+ [Zero to Multi-Tenant in 15 Minutes – A Rails Walkthrough by Troy Anderson][zero-to-multi-tenant]
+ [Our Multi-tenancy Journey with Postgres Schemas and Apartment by Brad Robertson][influitive-blogpost-multi-tenant-journey-with-apartment]
+ [Building a multi-tenant app is easy…if you have an apartment! by Igor Petrov][credits-apartment-freecodecamp]

#### Screencasts

+ [Railscasts PRO #388: Multi-Tenancy with Scopes by Ryan Bates][ryan-bates-railscast-multi-tenant]
+ [Rails Pacific 2014 Multi-Tenancy with Rails by Ryan Bigg][ryan-bigg-railspacific-rails-multi-tenancy]
+ [GoRails: Multi-Tenancy in Rails with the Apartment gem][gorails-railscast-apartment]

#### Books

+ [Multitenancy with Rails][ryan-bigg-book-multi-tenancy-with-rails]

[ruminations-on-multi-tenant]: http://www.db.in.tum.de/research/publications/conferences/BTW2007-mtd.pdf
[multi-tenant-ecommerce]: https://medium.com/@riyajohn9495/multi-tenant-ecommerce-platform-979da8c5554c
[postgresql-multi-schema]: https://www.postgresql.org/docs/9.1/static/ddl-schemas.html
[spof-wiki]: https://en.wikipedia.org/wiki/Single_point_of_failure
[msdn-multi-tenant-data-architecture]: http://ramblingsofraju.com/wp-content/uploads/2016/08/Multi-Tenant-Data-Architecture.pdf
[ryan-bates-railscast-multi-tenant]: https://www.youtube.com/watch?v=jwILy2GB7XE
[ryan-bigg-railspacific-rails-multi-tenancy]: https://www.youtube.com/watch?v=uwWBuqmQb0o
[ryan-bigg-book-multi-tenancy-with-rails]: https://leanpub.com/multi-tenancy-rails-2
[influitive-homepage]: https://influitive.com
[apartment-gh]: https://github.com/influitive/apartment
[rack-homepage]: http://rack.github.io/
[rspec-homepage]: http://rspec.info/
[dbcleaner-gh]: https://github.com/DatabaseCleaner/database_cleaner
[gorails-railscast-apartment]: https://youtu.be/L5y72hfIT_M
[zero-to-multi-tenant]: https://www.alliedcode.com/zero-to-multitenant-in-15-minutes-a-rails-walkthrough/
[influitive-blogpost-multi-tenant-journey-with-apartment]: https://influitive.io/our-multi-tenancy-journey-with-postgres-schemas-and-apartment-6ecda151a21f
[nebulab-blogpost-why-solidus]: /blog/why-solidus
[multi-tenant_shop]: https://github.com/nebulab/multitenant_shop
[multi-tenant-shop-preferences-ext]: https://github.com/nebulab/multitenant_shop/blob/master/lib/multitenant/
[seedbank-gh]: https://github.com/james2m/seedbank
[sidekiq-homepage]: https://sidekiq.org/
[apartment-sidekiq-gh]: https://github.com/influitive/apartment-sidekiq
[apartment-capybara-issue444]: https://github.com/influitive/apartment/issues/444
[apartment-testing]: https://github.com/influitive/apartment/wiki/Testing-Your-Application
[credits-apartment-freecodecamp]: https://medium.freecodecamp.org/building-a-multitenant-app-is-easy-if-you-have-an-apartment-3465f6eda85b

How to switch a Solidus eCommerce to Multi-tenant

Over the last few years, many online retailers decided to go responsive with
their eCommerce websites. That’s because they probably found out that most of the traffic on their online store is coming from mobile devices, and here at
Nebulab we have seen this trend emerge dramatically also with our clients’
stores.

However many eCommerce owners still tend to focus on the desktop shopping
experience instead of the mobile one. Maybe because they didn’t adopt a [Mobile First](https://responsivedesign.is/strategy/page-layout/mobile-first/)
approach at early stages, or maybe because they’re not aware where their traffic comes from.

Making the mobile experience enjoyable and intuitive is crucial to engage your
customers so that they will not leave the website quickly.

Here are a few simple tweaks that could improve the mobile shopping experience of your eCommerce.

## Horizontal Touch Carousel
![Horizontal Touch Carousel](https://cdn.sanity.io/images/kqgmf0g2/production/6c695dcf702d51aabcb09e19b7fe01a6b2c6494b-480x854.gif?fit=clip)

Make sure you’re using an image gallery that supports horizontal swipe gestures, since it’s simpler for a mobile user to navigate through images.
Also, to make the user understand that it is a slideshow and not a single image,
remember to provide a visible way to navigate the gallery, like [bullet navigation](https://tympanus.net/Development/DotNavigationStyles/).

## High quality images
In a web page, people usually look at images before content. This happens
particularly in eCommerce websites where product images should provide as much information as possible in order to convince customers to buy the product. So make sure you use high-quality images for your products so the they will not look pixelated or lose quality when zooming.
And remember that most smartphones, and also some desktop computers such as recent MacBooks, have high pixel density display, which means that your images need to be optimized for such devices. However high-quality images could mean large file size which cause slow website performance. Tools like [Compressor.io](https://compressor.io/) let you reduce the size of your images without noticeable loss in quality.
In addition, I suggest to use vector images ([SVG](https://css-tricks.com/using-svg/)) wherever possible for elements like logos and icons.

## Sticky Add to Cart button
![Sticky CTA](https://cdn.sanity.io/images/kqgmf0g2/production/f73dc2c5450a0cc547575fabb95bcb652eb66bae-480x852.gif?fit=clip)

The Add to Cart button is the most important call-to-action of your eCommerce
and in order to make it always visible as the user scrolls down the product page,
I suggest you to make it fixed at the bottom or at the top of the screen.

![Sticky CTA Desktop](https://cdn.sanity.io/images/kqgmf0g2/production/32dd586b692d6f022a3be7e0d16c1c574ad69e8a-1951x1071.png?fit=clip)

As you can see in the image above, this solution could also be helpful on desktop
when there’s a lot of information on the product page and you want to improve
your add-to-cart rate.

## Fixed header
![Sticky header](https://cdn.sanity.io/images/kqgmf0g2/production/44ee7c9d00c37c5098fe42bae7d48e5d181d0bd6-480x851.gif?fit=clip)

Web pages could be very long especially on mobile, where content is often
“compressed” in order to fit the window width, and sometimes this turns to be
annoying for users who want to find essential elements like the website menu or
the cart icon. For example, if you reach the bottom of the page and you want to
go back to the top and continue to navigate through the website, you have to
scroll the whole page again.
To avoid this and to speed up the navigation of your website, add an always
visible sticky header that follows the user as they scroll the page.

## Don’t hide useful information
![Accordion](https://cdn.sanity.io/images/kqgmf0g2/production/39f79d6c243a42af971a44c667bf7846a7033fe4-480x854.gif?fit=clip)

Sometimes useful information for the user like “Shipping & Returns” or “Size guide”
aren’t easy to find in the product page because they are hidden somewhere or only
linked in the footer of the website. It’s important to show these info in order to
reassure the user and encourage them to purchase. Accordion tabs could be a great
solution if you don’t want to increase the length of the page.

Of course these tweaks are not meant to be for everyone, since every website has
its own user base and its own market, but they should work for most online shops.

In conclusion, my advice is to put mobile at the center of your eCommerce strategy:
considering that more and more people use their smartphone as the only device to
browse the web, purchases from mobile will inevitably increase in the future.

5 cool tweaks to improve your eCommerce mobile shopping experience

Spree or Solidus? Which OSS project Nebulab, as an agency involved in
Ruby on Rails eCommerce development, should invest on? This blog post
tells the story about what's happening inside our agency in choosing
where to put more effort.

## Spree and Nebulab

Nebulab has proudly been one of the first company that adopted Spree. In fact
we are using it since version 0.30. We always did our best contributing
actively to the project and its extensions, attending almost all SpreeConf
around the world and supporting the community via the Spree Mailing List.

We strongly believed in this project that we used for 100% of our eCommerce
customers, often recommending them to migrate to Spree from other platform,
like Magento or custom Ruby on Rails eCommerce applications.

We have also been one the first company that applied to be a
[Spree Solution Partner][spree solution partners]. This partnership allowed us
to give something back to the project and take a lot of contacts with clients
all over the world.

On October 28th Spree announced that [they will no longer
maintain the OSS project](https://spreecommerce.com/blog/future-of-spree-oss).
The main reason is that the Spree company has been acquired by another
bigger company, First Data.

It's easy to imagine our feelings hearing that our favorite OSS project
would have a so drastic change in its maintenance and community management.

Bad news never come alone. **[Wombat][wombat]**, an
integration platform built from Spree company that we were using for some
of our clients, would be discontinued soon. Fortunately, according with one of
our cool customers which was extensively using that service, we developed
[Cangaroo][cangaroo], an Open Source alternative to Wombat, that we are
currently using successfully in production.

## Solidus

Months before this event, a group of developers from
[Bonobos][bonobos], one of the
[biggest online retail store][bonobos ipo] in the United States and
[Stembolt][stembolt], a Canadian web development firm, forked
Spree because they started to diverge from the direction Spree was taking.
They called the project [Solidus][solidus], naming it after an
[old Roman coin][solidus coin] and the
[SOLID principles of Object Oriented Design][solid principles].

Having more activity we naturally started taking a look at this fork,
understanding its principles and its different approach that we started
to appreciate and share.

If you are interested in differences between the two platforms
[this article][spree vs solidus] is a great resource.

Here's a list of stuff that we like about Solidus:

### A Solid Roadmap

Solidus guys decided to put focus on fixing and improving current codebase
instead of adding new features that are probably unnecessary for many stores.

Here you can find the full
[Solidus Future Plans][solidus future plans].

We trust developers involved in the Solidus project, we can see on the
[Solidus GitHub Repository][solidus github] that they are great in what they do
and lately they also have emerged for their attention for security issues.

### Top Priority to Code Integrity

Solidus is trying to get rid of stuff that doesn't look clean like the
improper use of `class_eval`. This is not only a question of code
style but ensure it's easier to customize your stores, your extensions and
to update Solidus from one version to the next one.

But why **class_eval** is not a good practice?

Of course it depends by the situation but in general using class_eval you
are re-opening the general class definition; technically this is not
an inheritance and this means that into the re-opened class you cannot use
`super` to replicate a previously defined method behavior. For the
sake of better understanding this concept, let's make a simplified example:


**Spree::Stock::ShippingRateSorter** is a class defined into the solidus
core that defines how to sort shipping rates.

```ruby
# Solidus Core

# app/models/spree/stock/shipping_rate_sorter.rb
module Spree
  module Stock
    class ShippingRateSorter
      attr_reader :shipping_rates

      def initialize(shipping_rates)
        @shipping_rates = shipping_rates
      end

      def sort
        shipping_rates.sort_by(&:cost)
      end
    end
  end
end
```
Now, in your store or extension, suppose you want to change how to sort
those elements. Specifically we want to reverse the order of shipping rates.
We used to write in our stores something like:

```ruby
# Our App or Extension

# app/models/spree/stock/shipping_rate_sorter_decorator.rb
module Spree
  module Stock
    ShippingRateSorter.class_eval do
      def sort
        shipping_rates.sort_by(&:cost).reverse
      end
    end
  end
end
```

This is not terrible, at least until the default way shipping rates are sorted
changes into core, and our code is no more compliant with it making it a mess
to update solidus to more recent versions.

Often, the solution to this kind of problem is using **super** to inherit the
behavior of core code in order to make our extensions less dependant to that
code.

Solidus is proposing to change this `class_eval` over-usage, moving to a more
clean way to extend stuff.

```ruby
# Our App or Extension

# app/models/spree/stock/custom_shipping_rate_sorter.rb
module Spree
  module Stock
    class CustomShippingRateSorter < ShippingRateSorter
      def sort
        super.reverse
      end
    end
  end
end

# config/initializers/spree.rb
Spree::Config.shipping_rate_sorter_class = Spree::Stock::MyShippingRateSorter
```

Awesome, isn't it?

### Forked from Spree 2.4

Solidus has been forked from Spree 2.4, and now Spree is at 3.0. The main change
between these versions is the introduction of **Twitter Boostrap** into both
frontend and backend. That wasn't a good idea in our opinion for several
reasons:

- updating would mean changing frontend code of all stores we were working on;
- 90% of our clients are not interested in bootstrap themes but a
custom frontend style, so often it would probably be more work to
remove it than to adapt the spree frontend to that specific store needs;
- in our vision the frontend HTML should not include front-end framework class
names but semantic ones that represents what's inside that specific element.

### Active Community

Lot of friends and contributors that we did know on the Spree community have
already joined the Solidus community. In fact, in the
[Solidus Slack channel][solidus slack] there are already 400+ developers
that discuss, support each other and design together the future Solidus moves.

We also love conferences, and we look forward to attend
[Solidus Conf 2016][solidus conf] in Toronto, an opportunity for us
to learn, to better understand the Solidus goals and to meet community members
and clients in person.

## Our choice

Our plan is to start all new stores using Solidus but to stay with Spree for
the majority of those already developed. We think that this is the decision
that makes more sense, also because Spree has new maintainers now and this
should ensure quick response to any security issue that could come out.

Even if Spree seems to be reborn with a
[new core team and roadmap][new spree core team],
we think that there's still a lot to do for Spree to recapture our interest
and we currently feel comfortable with the Solidus approach, which we hope to
contribute to as much as we can.


[bonobos]: https://bonobos.com/
[bonobos ipo]: https://pando.com/2014/07/06/bonobos-raises-another-55-million-and-aims-for-an-ipo-all-in-spite-of-being-ecommerce/
[cangaroo]: https://github.com/nebulab/cangaroo
[new spree core team]: https://spreecommerce.com/blog/spree-roadmap-announcement
[solid principles]: https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
[solidus]: http://solidus.io/
[solidus coin]: https://en.wikipedia.org/wiki/Solidus_(coin)
[solidus conf]: http://conf.solidus.io/
[solidus future plans]: https://github.com/solidusio/solidus/milestones
[solidus slack]: http://slack.solidus.io/
[solidus github]: http://github.com/solidusio/solidus
[spree solution partners]: https://spreecommerce.com/solution_partners
[spree vs solidus]: http://bluestout.com/blog/spree-vs-solidus-ecommerce-platforms/
[stembolt]: https://stembolt.com/
[wombat]: https://github.com/wombat

Why Solidus?

The purpose of this post is to show **one way** to implement one page checkout
with Spree. The goal here is to build a solution which is clean and elegant,
especially taking into account the ability of the app to be easily updated
when a new version of Spree comes out.

## How Spree Checkout works

It’s basically a state machine which runs validations and callbacks when trying
to go from a step into the next one. It's really flexible thanks to its own
[DSL](http://guides.spreecommerce.com/developer/checkout.html#the-checkout-flow-dsl),
built to allow checkout flow customization. Default steps are **address**,
**delivery**, **payment** and **confirm** (optional, depending on the payment
method used or if the
[related preference](https://github.com/spree/spree/blob/master/core/app/models/spree/app_configuration.rb#L35)
is set).

## The strategy

What we are going to do is to just display **all steps into a single page**
changing the steps submit buttons so that they are going to make **anynchronous
requests** each time we hit continue on the current step. This ajax `update`
request will be automatically handled by `Spree::CheckoutController`.
Creating a **js view** for this action we can easily update the right step:
in case of successful responses the next step will be updated otherwise
the current step will be updated and validation errors will be displayed.

Also, we are going to implement some UX improvement since it will be
better to **disable inactive steps** hiding outdated summary and preventing
form elements from being used.

### Confirm step is required

We need the last step to skip the ajax request. This is needed because in
case of success it will redirect us to the `completion_route` which uses a
separate controller and view (usually `Spree::OrdersController.show`).

## All steps in one page

Our first goal will be to show all the steps in a single page. We can easily
do it by overloading the `checkout/edit.html.erb` view of our application:

```erb


<div id="checkout" data-hook>
  <% @order.checkout_steps[0...-1].each do |state| %>
    <div class="row checkout_content <%= 'disabled-step' if state != @order.state %>" data-step="<%= state %>"data-hook="checkout_content" id="checkout_<%= state %>">
      <%= render :partial => 'form_wrapper', :locals => { :order => @order, :state => state } %>
    </div>
  <% end %>
</div>

# ...

```

On a side note, this is the **only view we are overloading** to have this
approach working. To disable one step checkout we can just remove (or rename)
this file and the default behavior will be restored.

We are basically cycling on every checkout step. For each step we render
a new `_form_wrapper` partial wich will be responsible to display the step
correctly. Here is the code of this new partial:

```erb


<div class="columns <%= if state != 'confirm' then 'alpha twelve' else 'alpha omega sixteen' end %>" data-hook="checkout_form_wrapper">

  <%= render :partial => 'spree/shared/error_messages', :locals => { :target => order } %>

  <%= form_for order, :url => update_checkout_path(state), :remote => (state != 'confirm'), :html => { :id => "checkout_form_#{state}" } do |form| %>
    <% unless order.email? %>
      <p class="field" style='clear: both'>
        <%= form.label :email %><br />
        <%= form.text_field :email %>
      </p>
    <% end %>

    <%= render state, :form => form %>
  <% end %>
</div>
<% if state != 'confirm' %>
  <div id="checkout-summary" data-hook="checkout_summary_box" class="columns omega four">
    <%= render :partial => 'summary', :locals => { :order => order } %>
  </div>
<% end %>
```

The code is quite similar to the original `edit.html.erb` Spree view. We added

```ruby
:remote => (state != 'confirm'),
```

to the `form_for` tag in order to make ajax requests unless the current state
is the `confirm` one.

At this point we’ll have all our steps into a single page:

![All steps in a singe page](https://cdn.sanity.io/images/kqgmf0g2/production/de2e9d876c6ef15856814f39dd80702084d811ef-996x2287.png?fit=clip)

As you can see, since we still don't know what the user's address is, the
**delivery step is empty**; it will be filled with the shipping method once
we know what shipping method is available for a user within a certain zone.

## Advance through the steps with Ajax

So, what happens when we hit "Save and Continue"? An asynchronous request is
made and the `Spree::CheckoutController#update` method is called.
Rails responds with a js file since that's exactly the default way
Spree responds to a `remote` request. We just need to create a js file (we'll
go with coffeescript) which will be executed at each `update` response:

```coffee
# app/views/spree/checkout/edit.js.coffee

partial = "<%=j render :partial => 'form_wrapper', :format => :html, :locals => { :state => @order.state, :order => @order } %>"
step = ($ '#checkout_<%= @order.state %>')
error = "<%= flash[:error] %>"

replace_checkout_step(step, partial, error)
```

* `partial` variable will contain the html of the step we need to render
  (the next one unless there
are errors that prevent to go to the next step);
* `step` variable will contain the element we are going to update;
* `error` variable will contain potential errors we want to render;
* `replace_checkout_step` method is defined in the assets directory into a
proper one-page-checkout support file which will also contain other
convenience methods:

```coffee
# app/assets/javascripts/spree/frontend/one_page_checkout.js.coffee

window.replace_checkout_step = (step, partial, error) ->
  disable_steps true
  step.html(partial) if partial?
  step.find('form.edit_order').prepend("<p class='checkout-error'>#{error}</p>") if !!error
  enable_step step

enable_step = (element) ->
  element.removeClass("disabled-step")
  element.find("form input").removeAttr("disabled")
  element.find("#checkout-summary, .errorExplanation").show()
  # Call Spree step specific javascript
  Spree.onAddress() if element.data('step') == 'address'
  Spree.onPayment() if element.data('step') == 'payment'

disable_steps = (all) ->
  elements = if all? then ($ ".checkout_content") else ($ ".checkout_content.disabled-step")
  elements.addClass("disabled-step")
  elements.find("form input").attr("disabled", "disabled")
  elements.find("#checkout-summary, .errorExplanation").hide()

Spree.ready ($) ->
  if ($ '#checkout').is('*')
    disable_steps()
```

The code is quite self-explanatory; anyway, this is what happens everytime
`replace_checkout_step` is called:

* all steps are disabled (a `.disabled-step` class is added to all steps,
  form elements are disabled, summary and errors are hidden);
* the html code of the right step is updated;
* eventual flash messages are prepended to the current step's div;
* form elements are enabled and summary is shown only into the current step;
* `.disabled-step` class is removed from the current step;
* if the current step is address or payment step, default Spree js is called
  in order to attach default Spree handlers to the just created DOM elements.

Just as a UI improvement we can set an opacity layer via CSS to all disabled
steps:

```css
/* app/assets/stylesheets/spree/frontend/one_page_checkout.css.scss */

.disabled-step {
  opacity: .5;
}
```

This is the result:

![Steps with opacity](https://cdn.sanity.io/images/kqgmf0g2/production/6386197dc71778f8c494035d38529075447327f0-770x640.gif?fit=clip)

## Further Developments

As said at the beginning of the post, this is just a basic solution you could
extend to add more features and custom style; for example you could just show
the step title if it's a disabled step. Other useful features are
**enabling popstate** to let URLs update reflecting the current step and
**automatic and animated scroll** while a new step is reached.

If you want to give it a try, here is the [source code](https://github.com/nebulab/spree-one-page-checkout)
of what has been done here.

The Nebulab