How do you sell one Shopify product to different customers on different pages?

Why can’t one product page sell to everyone?

Because different customers buy the same product for different reasons. Each avatar has different problems and needs a different transformation. When one page tries to talk to four types of customer at once, it ends up talking to none of them properly. The headline is vague, the images are generic, and half the objections it answers belong to somebody else.

Meanwhile your ads keep getting more specific. We break audiences down into really specific sets of people, with hooks written for each one. Then every one of those ads sends the click to the same generic product page. The person who stopped scrolling because the ad spoke to their exact problem lands on a page that doesn’t.

What should the main product page do then?

Keep it generic, but lean it toward whoever buys the most. Look at your best-buying group and dial the product page toward them. That page stays in your menu and collections, so anyone browsing the store finds the standard version.

The avatar pages are for ad traffic. The ad goes to the matching landing page, and the menu keeps pointing at the main product page.

How do you put one product on several pages in Shopify?

Shopify ties a product to one template, so you can’t easily run five versions of the same product page. We build the avatar pages under /pages/ instead of /products/.

The way we do it is installing the product card above a regular page template. As I explained it to one client, you can have the product componentry of any product you want on an infinite number of landing pages themed to different avatars. The gallery, the buy box, add to cart and subscription options all sit at the top of the landing page, drawing from the same product and the same inventory. Below that, the page is free to tell the story that avatar needs to hear.

That’s why we now build every section so it works on both product pages and landing pages. A reviews block, an FAQ, a comparison table. If it’s modular, you can drop it anywhere. Spinning up a new avatar page becomes assembling blocks you already have, and the same approach works for a page per country.

How do you stop it becoming a maintenance nightmare?

Metafields. On the pages we build, everything is a metafield, so anything on the page can either be unique to that one page or updated across the whole website in one place.

Say your shipping promise changes. That’s a sitewide field, and you change it once. The headline and pain points for one avatar are page-specific fields, and they only live on that page. You get the flexibility of separate pages without updating every one of them each time something changes.

Our team is the right kind of lazy. If we’d have to make the same change 20 times, we’d rather work out how to make it once. When a test lifts conversion rate, you want that change rolled out everywhere in one go.

When is it worth building avatar pages, and for how many?

When you’ve already got an avatar-specific ad that’s working. If you’ve got one that’s working at the moment and you’re looking for an edge, worth doing. If you don’t, not worth doing.

A landing page amplifies an angle that’s already proven in the ads. It won’t rescue an angle that isn’t. Find the winner in your ad account first, then give it a page that matches.

Timing matters too. Don’t start a big rebuild of your page templates right before a sales season like Black Friday. Keep the budget on small tests then, and do the restructure afterwards.

As for how many, about three. Ideally you wouldn’t have more than three on the go at once. Every page needs its own ads, its own creative and someone watching the numbers. Spread that across eight avatars and none of them get the attention they need to win.

Start with the avatar behind your best ad. Build that page, run the ads to it, and compare it against sending the same ads to your main product page. Add the next avatar once you know what the first one is telling you.

Can you track which avatar actually bought?

A landing page tells you where someone came from. When one physical product serves lots of use cases, it can be worth going further.

We’ve built what we call phantom products for this. Each use case gets its own listing with a suffix on the SKU, which the 3PL amends and skips when it picks the order. The customer gets exactly the same item. You get data on what they bought and what they bought it for.

That data earns its keep. You can show it in Klaviyo emails, trigger flows from it, and retarget on Meta with the message that matches the use case. Inventory is the part to get right. If ten listings draw on one base unit, manage that stock in your ERP with a bill of materials, so every listing goes out of stock together when the warehouse hits zero. Don’t try to fake it with a bundles app on the storefront.