How to Add Frequently Bought Together Offers on Shopify

Frequently bought together can mean several things: products selected by a merchant, suggestions derived from historical orders or a grouped offer that a shopper accepts in one action. A store should know which experience it is buying. The label alone does not establish the recommendation source or the shopper controls.

FairRev currently provides evidence for manually selected catalogue add-ons and code for grouped cart additions. A complete grouped related-product journey has not yet been verified for FairRev. This guide therefore provides a selection and testing workflow you can use to evaluate an app. It distinguishes that workflow from the narrower FairRev accessory demonstration and explains what to request before choosing a grouped offer.

Understand the grouped offer experience

A grouped offer should make its contents understandable before acceptance. The shopper needs to know which products and variants are included, how many units are being added and the amount they will pay. If components can be excluded, the interface must make that choice and its price effect clear.

Consider a hypothetical case and cleaning cloth offered alongside a camera. A fixed pair that is accepted together is different from two independent accessory suggestions. It is also different from a native bundle product with its own catalogue and inventory behavior. Choose according to the experience your store needs, and ask a provider to show that exact journey rather than relying on a shared feature label.

Use the Shopify frequently bought together app evaluation guide to compare selection, pricing and the shopper controls. The current FairRev code can join offered product names and submit multiple variants, but that is implementation evidence only. It does not show that the shopper sees the expected group, can make the expected choices or receives the promised checkout total.

Evaluate a real demonstration of the intended group. The existing snowboard and ski wax screenshot shows a single accessory offer. It cannot demonstrate a grouped related-product decision simply because the products can be described as related.

Check how recommended products are selected

Ask what determines the products shown. Manual curation uses the merchant's judgement and chosen triggers. A purchase-history system uses observed order relationships. Personalization can introduce another layer of shopper-specific selection. These sources have different maintenance and explanation requirements.

The verified FairRev builder selects catalogue variants manually. Internal product-pair work does not prove that historical pairs automatically populate the live grouped widget. Until that connection is demonstrated, describe selected products as merchant-chosen related items. Do not imply they are commonly purchased together by real customers.

Manual selection can still be useful. A merchant can choose an accessory known to fit the main product and explain the relationship accurately. The weakness is maintenance: a changed variant, discontinued component or compatibility update can make the group wrong. Assign a routine review of those relationships rather than assuming a recommendation label keeps them current.

When assessing another product, ask for the same clarity. A claim about recommendations should identify the source, merchant controls and limits. Do not infer superior personalization from an app's use of artificial intelligence, and do not describe FairRev as better at recommendations when the relevant live behavior remains unverified.

Select products for a useful grouped offer

Start with a task the main product does not complete alone. Identify compatible accessories or consumables and check whether the shopper already receives them in the ordinary package. An extra item is not useful if it duplicates what is included or fits only another variant.

Choose a small coherent group and specify exact variants and quantities. The customer should be able to understand why the items belong together. Keep fulfillment practical: components must be available, pickable and correctly described on the order. Consider the effect on shipping and packaging as well as the catalogue subtotal.

Set a margin constraint before offering a discount. Include the cost of all components, variable fulfillment and returns. A group can raise order value and still reduce contribution. A percentage saving is not enough information to judge the promotion's economics.

For a single companion product, a Shopify cross sell app workflow may answer the need more simply. Do not build a group just because a keyword suggests one. Use the smallest offer that helps the shopper make a useful decision and that the store can support with a verified journey.

Configure and evaluate a grouped workflow

Begin with the products, quantities and placement you selected. In the tool being evaluated, check how those choices are represented and how a shopper accepts them. FairRev's manually selected offered variants and grouped cart-addition implementation are a starting point for a demonstration, not a completed frequently bought together tutorial. Ask support to show the exact grouped configuration before using it.

To evaluate the requirement, record a real configuration. Capture the actual offer type, selected products, variants, quantities, discounts, headline and placement. Save the draft and record the version. Then publish through the normal product controls and confirm the live result rather than stopping at a successful save.

Walk the shopper experience from the published page. Record what is displayed, what can be changed and what acceptance adds. Inspect cart lines, final checkout prices and the resulting order. The same saved offer version should explain all of those artifacts. If the product cannot deliver the expected grouped experience, choose a narrower accessory offer or continue evaluating a tool that demonstrates the group you need.

This evidence requirement is specific. A code path, a configuration type and a single-item screenshot are useful clues, but they do not replace the real walkthrough. Keep a short evaluation record: the exact products, which components can be removed, the quantity added, the ordinary total, the discount and the checkout total. This makes two demonstrations comparable even when their marketing uses the same phrase for different interfaces. Ask which behavior depends on a theme or another cart app. Record unanswered questions beside the test result so that a promising preview does not become an assumed production capability.

Test placements and shopper behavior

Use the actual theme and cart implementation that will be named in the documentation. Product and cart blocks need suitable sections. A drawer needs an adapter and a working refresh journey. A placement option in the builder does not verify grouped behavior in that context.

Test a component already in the cart, repeated acceptance, a changed main-product variant and unavailable inventory. Remove one component after acceptance and inspect the remaining prices. If components can be selected individually, test every selection boundary that changes qualification or discount. Do not assume such selection exists until the real interface demonstrates it.

Check narrow screens, keyboard use and the route to checkout. A group of products can become hard to understand when names wrap or prices lose their association with components. The shopper should not have to infer whether the displayed total covers the group or just one item.

Retain screenshots of the actual setup, grouped display, cart and checkout. Label development data clearly and record limitations by theme and placement. Do not claim universal compatibility from a single success. The purpose is a repeatable instruction a merchant can follow, not a convincing-looking screenshot detached from the product.

Understand limitations and billing

Revisit the evidence after catalogue or theme changes. A recorded group can become inaccurate when a selected component is discontinued, so documentation needs the same maintenance as the offer itself.

Current evidence does not establish purchase-history personalization, automatic group selection, a mix-and-match builder or a native bundle SKU. It also does not establish every drawer implementation. These limits should remain visible in evaluation materials so a merchant with a different requirement can choose another product.

FairRev pricing covers the conditional free allowance, recurring minimum and fixed maximum. Every available feature is included, but a feature's appearance in a code enum is not proof that its complete shopper workflow is ready. Public installation has not been verified, so no installation link is supplied here.

FairRev attribution explains the order-item matching rule, quantities, exclusions, refunds and settlement. Accepting a group does not automatically make the entire basket attributable. A zero-priced component contributes no discounted item revenue itself. Attributed revenue remains different from experimentally measured additional sales and from profit.

Before selecting FairRev for this requirement, request a functioning grouped demonstration, an explanation of product selection, actual setup and shopper screenshots, and the complete acceptance-to-order result. Those checks remain unresolved. A merchant can still use the demonstrated single-item accessory workflow when that narrower experience fits, or select another tool with a verified group. The useful next step is a reproducible test with the intended catalogue and theme, followed by a fee comparison using the documented billing rule.