Collection Merchandising: Rails, Tiles and In-Grid Promotion on Shopify

Definition

Merchandiser-configured product carousels, tabbed collection shelves, category tile rows and block-scoped rails on landing pages, plus promo tiles placed at chosen positions inside a collection or search grid without breaking pagination — including tiles that appear only when a given facet is active. One product-card renderer reused everywhere so behavior stays consistent.

The Evidence

• Evidence strength: 24 live, Deploi-attributed builds across 3 Shopify storefronts.
• Split by storefront: Nudestix 12, Three Ships 7, LUS Brands 5.
• Split by attribution: 19 Deploi-authored, 5 modifications of vendor theme code — named as such on each build page.
• Evidence quality: nine carry code plus client working records. Fifteen are documented from the code; no client-side record of the decision survives.
• Confidence: 7 strong, 17 moderate.
• Surfaces: homepage and collection pages lead (12 builds each), then landing pages, blog, search, the PDP and the mega menu.
• Status: Live, verified 2026-09-06. Buy-vs-build verdict: build or configure in the theme.

How It's Actually Built

The mechanism at the centre of this capability is a loop rewrite, and it exists because Shopify paginates products, not grid slots. Drop a promo tile inside {% for product in collection.products %} and it either eats a product slot or shifts every product after it, and the count the shopper sees stops matching the grid. So the loop becomes a slot loop: it walks grid positions while a separate product cursor advances only when a product is actually emitted. A promo block claims its position first; otherwise the next product renders. The paginate object is never touched, so pagination keeps counting products and the tile is additive rather than substitutive.

The tile itself is a theme block: position, width (one grid item, two, or full bleed), image, aspect ratio, heading, body, button and its colours, all theme-editor settings. Tiles are scoped by collection handle so one section can carry a season's worth and only the right one renders, and a section that renders its grid twice accumulates the ids it has already emitted so a tile can't appear twice. On the search side the same block trades position-matching for facet-matching: it renders only when a chosen facet is active. And because a tile sits in a product grid, its markup mirrors the grid's own column arithmetic at every breakpoint — a hand-built srcset and a sizes string derived from page width, gutters and column count — or the row reflows around it.

Rails follow one rule: render the theme's own card. card-product on the Dawn storefronts, product-grid-item and product-card.liquid on the premium theme. That's what keeps price, badges, ratings, wishlist and quick-add identical whether a product appears on a collection page, a homepage carousel, a landing page or an article. Where Dawn's featured-collection section couldn't be stacked — every id and Swiper selector keys off section.id — we re-keyed the whole thing to block.id so one events page can hold several independently configured rails. Where merchandisers needed a category row, the card resolves through a fallback chain: link from the block, else the collection's URL; label from the block, else the collection's title; image from the block, else collection.featured_image, else Shopify's placeholder. Adding a category is picking a collection.

The Buy-vs-Build Position

The corpus's own verdict:

Always built or configured in the theme; in-grid promo tiles in particular are trivial to own and are a standard line item in merchandising apps.

That's the least fashionable verdict we publish and the one we're most confident about. A merchandising app's value is scheduling, rules and reporting. The tile is the cheap part — it's a block with settings and a rewritten loop — and buying the tile means renting a second card renderer that has to be re-taught your badges, your ratings and your quick-add every time either side changes. Our reasoning on which half is worth paying for is in the merchandising rules decision.

The Builds

Eleven of the 24 have published pages. Of the rest — the gift and category tile sections with their own desktop and mobile layout modes, the tabbed collection browser and the block-scoped event rails among them — twelve are documented and will follow. One won't get a page of its own — editorial review didn't clear it.

LUS Brands

• Merchandisable homepage product carousel with a tag-driven badge engine and inline add-to-bag — 42 section settings, a badge engine resolved at render time from tags and compare-at price, and add-to-bag through the theme's own cart. High complexity, home and collection.
• Shop-by-category carousel with collection-aware card fallbacks — each card falls back to the linked collection's own image, URL and title, so a merchandiser adds a category by picking one. Medium complexity, home.
• Kids featured collection: a custom element that builds its Swiper on approach and wraps the theme's own product cards — a sub-brand rail that takes its type, accent and slides-per-view from CSS custom properties scoped to the section id, while the slides stay Dawn's own card-product, so the rail can't drift from the collection grid. Medium complexity, home and listing.

Nudestix

• Main collection grid: merchandisable promo tiles, load-more and a filter blocklist — Dawn's grid extended with in-grid tiles, section-rendered load more and a merchandiser-editable list of filter values to hide. High complexity, collection.
• Featured tutorial with an adjacent shoppable product rail — merchandising by collection picker: the first three products of whichever collection is chosen render as full theme cards beside a deferred video, quick view and in-card add included. Medium complexity, landing.
• Homepage exclusive-offers rail with caption heights equalized in idle time — a campaign tile row where every tile is a merchandiser block carrying an image, three lines of free-length copy and a link, and the grid's column classes are chosen in Liquid from how many blocks exist rather than from a select somebody has to remember to change. Desktop and mobile layout are independent settings, so the same row can be a shelf on one and a peeking rail on the other, and the uneven caption blocks that free-length copy produces are levelled through one custom property the stylesheet was already reading. High complexity, home.
• Mega-menu product rail (v2): a library-free slider in a theme asset, constructed per panel when the panel is seen — the merchandised rail put somewhere a rail normally can't go, with a merchandiser title, a shop-all link and a track that measures its own slide width at the moment of a move rather than at load. Medium complexity, global.

Three Ships

• Collection page: three filter modes, in-grid promo blocks and infinite scroll — a premium vendor theme's collection section, configured and extended, with promo blocks serialised into the paginated loop. High complexity, collection.
• Tabbed collection product slider and the shared merchandising card — every tab server-rendered so switching is instant, sharing one card snippet across home, landing and article surfaces. Medium complexity, home and landing.
• Size-pill variant picker and quick add-to-cart inside product grids — a capture-phase delegated handler that turns a grid card into a size selector and blocks add-to-cart until a size is chosen. Medium complexity, collection and home.
• Filter-triggered promo cards inside the search results grid — a tile that appears only when a chosen facet is active, placed by grid slot. Medium complexity, search and collection.

What This Rests On

• Liquid section schema and settings — 22 of the 24 builds. Every control described on this page is a section setting.
• Theme blocks — 8 builds; the promo tile, the category tile and the per-rail configuration are all blocks.
• Cart AJAX API — 6 builds; add-to-cart from a card, without a product-page round trip.
• Section Rendering API — 5 builds; how a grid re-renders after a filter or a load-more, and how the cart drawer catches up.
• Metafields — 4 builds; card imagery, badge copy and the attributes rails sort and label by.
• Custom elements and CSS custom properties — lazily-initialised rails and per-section theming emitted from block settings.
• Storefront filtering, Liquid pagination and collection tag permalinks — the facet state a tile can trigger on, and the page ladder a tile must not disturb.
• Swiper — 6 builds; the carousel runtime on both Dawn storefronts, loaded globally by the theme rather than per section.

What Varies by Storefront

Theme base sets the ceiling. LUS Brands runs Dawn 15.4.1, Nudestix runs Dawn 6.0.2 — the same lineage nine major versions apart — and Three Ships runs Palo Alto 5.8.0 by Presidio Creative, a paid premium theme, so its merchandising sections are vendor code we extended and have to keep upgrading. The Dawn gap shows up directly: the newer store gets a block model and a card that already supports quick add, while the older one hand-rolls behaviour Dawn's own slider markup can't express and can't simply swap in a library without abandoning the theme's CSS.

Catalog cadence decides the shape. A haircare catalog with a separate kids audience wants rails that carry their own theming per audience, so colour and type scale arrive as CSS custom properties emitted per section. A cosmetics catalog on a campaign calendar wants tiles authored per breakpoint and layout modes chosen per section, because a campaign changes the arrangement, not just the artwork. A skincare catalog with a small SKU count and multiple sizes has a different merchandising problem entirely — the decision to move onto the card isn't which product, it's which size, which is why that storefront's grid work is a variant picker rather than a tile.

Installed apps set the last constraint. Review widgets, wishlist buttons, an analytics loader and a recommendation widget all live in the DOM these grids replace or inject into, so each storefront's re-render puts back a different set of things — and on one of them, cards arrive after load from a recommendation widget, which is why its quick-add is delegated from document.

Where This Gets Hard

The dual-render pattern is the cost people don't expect. Shopify renders Liquid once, on the server, with no knowledge of the viewport, so "grid on desktop, carousel on mobile" has exactly two honest answers: build a carousel that CSS can neutralise, or render the tile set twice and let a scoped {% style %} block reveal one. Several sections here take the second route because a merchandiser can rearrange it without breaking it. It is also markup you pay for on every request, on the pages that can least afford it.

Section settings are an API, and they behave like one. The theme editor keys a section's saved values to its section type, so changing a live section's schema in place risks the configuration a merchandising team spent months tuning — which is why one of these sections lives as a deliberate fork published alongside the original rather than as an in-place rewrite. The fork is a second file to maintain. That's the trade the settings model forces, and it is still a trade.

And a tile is only easy until the grid moves. A filter change replaces the container wholesale, so slot arithmetic runs again on the server and everything bound inside the old grid is gone. A section that renders its grid twice has to ensure a tile isn't emitted twice. A tile has to reproduce the grid's column maths at every breakpoint or the row reflows. None of that is hard. All of it is somebody's Tuesday, forever.

So: if what you need is six chosen products on the homepage, both Dawn and Palo Alto already ship that section and a custom rail buys you a maintenance liability, not a capability. If your tiles change weekly and nobody will re-check them, an app's scheduling and reporting are worth more than our slot loop — that's the half of the category we'd tell you to buy. And we push back hard on a new section per campaign. A rail a merchandiser can re-point at a different collection outlives three bespoke ones.

Related Capabilities

• Filters, faceted navigation and progressive grid loading — the pipeline these tiles have to survive, and the closest sibling to this page.
• On-site search, predictive search and external search services — the same tile vocabulary applied to a search grid, triggered by a facet instead of a position.
• Mega menu and mobile navigation — product rails inside the header, merchandised from the same theme editor by the same team.
• Fixed bundles and kit merchandising — collection templates whose cards are kits, rendered through the same card contract.

Answers to Help You Make Smart Decisions

Can I put a promotional tile inside a Shopify collection grid without breaking pagination? Yes, and it's the standard move here. The trick is to stop looping products and start looping grid slots, advancing a separate product cursor only when a product is actually rendered. The paginate object stays untouched, so page counts and the "showing N of M" line remain honest while the tile occupies a real position in the layout.

Do I need a merchandising app to curate collections and rails? For the rail itself, no — it's a theme section with settings, and building it keeps one card renderer across your whole storefront. What an app genuinely sells you is scheduling, rules and reporting on merchandising decisions. If your team changes tiles weekly and wants campaigns to start at midnight without a deploy, that is a real reason to buy.

Why do themes render a grid and a carousel twice? Because Liquid renders on the server and has no idea how wide the screen is. If a merchandiser can choose grid on desktop and carousel on mobile, the section either ships a carousel CSS can flatten or ships both layouts and hides one. Both are legitimate; the second survives merchandiser editing better and costs you duplicated markup.

Can shoppers add to cart straight from a collection card? Yes, through the Cart AJAX API and the theme's own cart drawer. The complication is variants: a card with one button either adds an arbitrary default or sends the shopper to the product page. On one storefront here the card carries size pills, and the first tap on add-to-cart reveals them rather than adding anything.

Ready to Merchandise Your Collection Pages on Purpose?

Your merchandising team knows what should be in slot three this week. The only question is whether they need you to deploy it. Contact us today and we'll show you which of your rails should be a setting instead of a ticket.