Shopify personalisation without a platform subscription

Shopify personalisation usually means installing a recommendations app, placing its widgets, and paying a monthly fee that scales with traffic or revenue. It works, up to a point, and then two things happen: the fee becomes a line the finance team questions, and nobody can say with confidence how much of the reported revenue the app actually caused. This article describes the alternative: a personalisation service you own, built on your Shopify event data and catalogue, served through your theme or headless storefront, with lift measured against a holdout. It covers the architecture, what Shopify gives you and what it does not, the controlled test, and the cost.

What Shopify personalisation is and why ownership matters

Personalisation on a Shopify store is four surfaces: recommendation blocks on product, cart and post-purchase pages; personalised collection ordering; personalised search results; and next-best-offer in email and WhatsApp. All four depend on the same inputs: a stream of view, add-to-cart, checkout, purchase and return events per customer or session, and a catalogue with clean attributes. An app subscription takes those inputs into the vendor's system and returns widgets. An owned system keeps the data, the models and the serving logic with you, which matters when you want to use the same models in messaging, when you go headless, or when the subscription cost passes the cost of building. The broader retail work is on the retail industry page.

App subscription vs owned personalisation service

What Shopify gives you, and what it does not

Shopify exposes what a personalisation service needs. The Storefront and Admin APIs and webhooks provide orders, customers, products, variants and collections; the Web Pixels API captures storefront behaviour events; Shopify Functions and theme app extensions let a service render into the theme without editing it by hand. The Shopify developer documentation is the reference for each and for the rate limits and versioning that shape the integration. What Shopify does not give you is a ready model, a clean event history, or a way to run a holdout across your own recommendations; those are the build. Where a store has never captured events beyond orders, the first weeks are spent installing the pixel and letting history accumulate, and the models start from purchase history and catalogue similarity until behavioural data exists.

Architecture of an owned personalisation service

Event pipeline

A pixel or theme script sends storefront events to a collector; webhooks deliver orders and returns; a nightly job syncs the catalogue. Events land in a warehouse or Postgres, keyed by customer where known and session otherwise, joined to product IDs that match the catalogue. This is the unglamorous foundation and the part most stores get wrong first; it is described in event pipelines: the unglamorous foundation of personalisation.

Models

Three models cover most stores. Item-to-item similarity from co-views and co-purchases answers "customers who viewed this also bought". A per-customer model ranks the catalogue for the logged-in or recognised visitor. A session model re-ranks within the current visit for anonymous traffic. Catalogue attributes and embeddings handle new products with no history. None of these need a large team or a large model; they need the pipeline to be right. Which models fit which store is covered in recommendation engines explained for e-commerce leaders.

Serving

A small API returns ranked product IDs for a surface, a customer or session, and a context (this product, this cart). The theme calls it from a theme app extension block; a headless front end calls it from its components; the email and WhatsApp systems call it when composing. Responses are cached briefly and fall back to bestsellers or curated collections if the service is slow, so a personalisation outage never blanks a page. Headless personalisation is the same API with a different consumer.

The controlled test, or it did not happen

The service assigns each visitor to a variant at first sight and holds the assignment. The control group sees the store's default blocks, bestsellers or manual picks. Both groups' revenue per visitor, conversion and average order value are measured over a period long enough to be trusted and across at least one full weekly cycle. Lift is reported with a confidence interval, not as a point. Vendor-attributed revenue counts every purchase that touched a widget and cannot answer whether the customer would have bought anyway. The method is in personalisation lift: why you must run a controlled test. Run it before cancelling the app, and run it again after every model change.

Privacy and consent on the storefront

Event capture is personal data. The pixel should respect the store's consent settings, so visitors who decline tracking are served non-personalised blocks and no session events are stored. Customer identifiers stay in your systems; if a warehouse is used, it is yours. Retention is decided, not defaulted: raw events for a defined period, aggregates for longer. For stores serving India, the Digital Personal Data Protection Act's rules on purpose and consent apply; for EU visitors, GDPR. Building these in is a few days of work at the start and a project if retrofitted after a complaint. The DPDP Act and AI post covers the Indian obligations.

When the subscription is still the right answer

A store with modest traffic, a small catalogue and no plans for messaging or headless is better served by an app, at least until the monthly fee approaches what a build would cost. The build makes sense when the subscription is a visible monthly line, when the same recommendations are wanted in WhatsApp or email, when the store is going headless, or when nobody can explain the vendor's reported lift. A ten-day discovery sprint looks at traffic, catalogue and current spend and gives a straight answer.

A worked example

A fashion D2C brand on Shopify ran two recommendation apps and an email tool with its own "AI picks", each reporting influenced revenue that, added together, exceeded a plausible share of sales. The event pipeline was built first: pixel events, order and return webhooks, catalogue sync, all into Postgres. Item-to-item and per-customer models followed, served through a theme app extension on product and cart pages and through the brand's WhatsApp agent for post-purchase suggestions. A holdout of visitors saw the store's default blocks for the test period. The lift was real but smaller than the apps had claimed, which the founder found more useful than the earlier numbers. The apps were cancelled, the brand owns the service, and the same models now feed replenishment prompts. The D2C personalisation and WhatsApp agent case study describes a similar shape.

Team and timeline

An owned Shopify personalisation service is a personalisation engine build: a data engineer for the pipeline, an ML engineer for the models, and a Shopify-experienced full-stack engineer for the theme extension and serving API, over six to ten weeks. The first two weeks build the pipeline and install the pixel; the middle weeks train and evaluate models offline; the last weeks serve, run the holdout and report. Starting price is $21,000 / ₹13.6L; the Essential Care Plan at $1,000 / ₹68,000 per month covers retraining, catalogue changes and Shopify API version updates. Hosting is small. Full figures are on the pricing page, and if the store's data readiness is unknown, a Sprint Zero at $3,250 / ₹2,00,000 is credited to the build.

Before you start: a checklist

• Check what events the store captures today beyond orders, and for how long
• List every app currently serving recommendations and its monthly cost
• Audit catalogue attributes: categories, tags, sizes, colours, images
• Decide the surfaces for the first release: product page, cart, post-purchase, messaging
• Agree the holdout share and test duration with whoever reads the results
• Confirm whether the store is headless or planning to be
• Name an owner for the weekly lift report
• Plan the fallback content for every surface if the service is unavailable

Questions clients ask

• Will this slow the storefront? No; the API responds in tens of milliseconds and every block has a cached fallback.
• Do we need a data warehouse? Not to start; Postgres handles most stores. A warehouse helps when marketing wants the same data.
• Can we keep one app and test against it? Yes; the holdout can compare the owned service against the app before you cancel.
• How often are models retrained? Weekly for most stores, nightly for fast-moving catalogues, and after any large sale.
• Does it work for anonymous visitors? Yes, through session models and item-to-item similarity; recognised customers get the per-customer model.

Related reading

Real-time ranking: personalising within a single session covers the session model; cold-start personalisation for new users and new products covers catalogue launches; AI for D2C brands places personalisation alongside support and forecasting.

Own the pipeline, own the models, and measure the lift yourself; the subscription was renting you a number you could not check.