Personalisation without a personalisation platform

The word covers two products with almost nothing in common, and scoping conversations go badly because nobody separates them first.

The first is known-customer personalisation: this person has bought from you, you know what and when, and the site should behave accordingly. Show the trade price to a wholesale account. Suppress the first-order discount banner from someone on their fourth order. Put the consumable they bought eleven weeks ago at the top of the home page. All of this is deterministic — there is no model, no inference, just a fact about a customer and a rule about what to do with it.

The second is anonymous behavioural personalisation: someone arrived from a paid ad four minutes ago, has viewed three products in one collection, and the page should adapt within the session. This is the thing that needs a vendor, because it needs an identity graph, an in-session event stream and, if the recommendations are to be any good, a model trained on more traffic than most stores have.

Nearly every store asking about personalisation wants the first and is being quoted for the second. The first is built into the platform you already pay for.

Five mechanisms, all native, all free with the plan you are on.

The `customer` object in Liquid. When a shopper is signed in, the theme can read customer.tags, customer.orders_count, customer.total_spent, customer.last_order, customer.metafields, customer.b2b?, customer.tax_exempt, customer.store_credit_account and the address list. That is enough for the large majority of rules a merchandiser will ever ask for, and it renders server-side, so there is no flash of the wrong content and no script to load.

Customer segments. Segments are written in ShopifyQL — the help documentation is explicit that a segment requires the FROM customers and SHOW clauses and that you customise the WHERE clause. The value is not the segment screen; it is that the segment becomes an addressable thing the rest of the admin can use. An automatic discount can be restricted to it. Flow can act on membership. Email can send to it. Build the segment once and it is available to every channel that asks.

Flow, as the thing that writes the tag. The gap between a segment and a theme rule is a customer tag, and Flow closes it without code: on an order paid or a segment joined, apply a tag the theme already knows how to read.

The Product Recommendations API. GET /{locale}/recommendations/products.json takes a required product_id, an optional limit where "the value can range from 1 to 10, and the default is 10", and an optional intent of related or complementary. Two intents, two jobs: related products are substitutes, complementary products are the things bought alongside. Most themes ship one recommendations section using the default and never touch the second intent, which is free upside sitting in the theme already.

Search & Discovery for the manual override. The app lets a merchandiser pick up to ten complementary and up to ten related products per item by hand, which matters most for the products where the automated answer is wrong — a new SKU with no purchase history, or a product whose obvious accessory is not obvious to an algorithm. Note the eligibility rules before you promise coverage: recommended products need active status, a price above zero and publication to the Online Store channel, and complementary products require inventory above zero.

The `localization` object. localization.country, localization.language, localization.market and the available lists give the theme market context without a geolocation script. Showing a UK visitor UK delivery language is personalisation, it converts, and it costs nothing.

Here is where native personalisation stops. Shopify documents that outside customers/account, customers/addresses, customers/order and the checkout and gift card contexts, "if the customer isn't logged into their account, the customer object returns nil". No sign-in, no personalisation in Liquid.

That is a bigger hole than it sounds, because on most direct-to-consumer stores the majority of sessions are not signed in. It also interacts with caching: a page that varies per visitor is a page that cannot be served identically to everyone, and the cheapest, fastest version of your storefront is the one that can be.

The Section Rendering API is the documented way to have both. You render the page once, cached and identical for everybody, then fetch the personalised part separately: append a sections parameter to any page URL to "render up to five sections, identified by their section IDs", and you get back JSON keyed by section ID with the rendered HTML as the value. Swap the markup in. The page arrives fast, the personalised block arrives a beat later, and you have not shipped a rendering framework to do it.

Two documented caveats decide whether this is a good idea for a given block. You cannot specify section setting values through the API, so the section has to derive everything from the request and the Liquid context. And sections that fail to render come back as null — "a response might have an HTTP 200 status, but still include one or more sections that failed to render" — so the client code needs a real empty state, not an assumption.

Which gives a simple rule. Server-render anything a signed-in customer should see; it is faster, it cannot flicker, and it degrades to the generic version by itself. Put a recommendation strip behind a client-side swap if you like. Never put a price, a stock message or a legal statement there, because the moment the request fails the page is lying. And if the personalised block is above the fold, it is not a personalised block, it is a layout shift.

Three things a dedicated personalisation product does that the above does not, worth naming precisely rather than dismissing. Anonymous identity and in-session behaviour — stitching sessions together and acting on what someone looked at four minutes ago, none of which Liquid can see. A model you did not train, sometimes over a vendor's wider network rather than just your store, which can beat Shopify's own recommendations on a sparse catalogue. And a measurement harness: holdout groups and per-variant reporting, genuinely the hardest part to build and the part teams skip when they do this themselves.

And here is the cost nobody itemises: every one of these works by injecting a script into your theme. That script is on the critical path of every page, it will show up in your Core Web Vitals, and it is the thing that makes personalised content arrive after the page. You are trading measured speed for hypothetical relevance, and on a mobile product page that trade is not automatically a win.

We would talk most stores out of a personalisation platform, and the reason is arithmetic rather than principle.

Personalisation is an optimisation, which means you have to be able to tell whether it worked. A test that splits traffic between a personalised and a control experience needs enough conversions in each arm to separate a real effect from noise, and the effects on offer here are small. A store doing a few hundred orders a month will not read a five per cent difference in any useful timeframe. It will read the invoice.

So the order we would actually run is: fix the things that are wrong for everybody first. The product page that does not say when the item arrives. The mobile cart. The four scripts adding a second to the first paint. Those are not personalisation, they are the baseline, and they are worth more than a personalised hero to every visitor including the ones a platform would target. Our [conversion rate optimisation work](/services/optimize/shopify-conversion-rate-optimization) starts there for exactly this reason — the personalised version of a page that does not convert converts slightly better and still does not convert.

Then build the native rules, because they are free and deterministic: trade pricing for B2B accounts, a suppressed acquisition banner for repeat buyers, a replenishment prompt driven by last_order, curated complementary products on your top hundred SKUs. Measure that. If you are running enough volume to read a test and the native rules are all in place, a platform becomes a reasonable next question. Before that, it is a subscription with a script tag attached.

• Conversion rate optimisation
• Customer segments that are worth building
• Upsell and cross-sell without slowing the page