The direct answer: do not start with an advanced engine or an ambition to personalize every visitor. Define which products may compete, at which moment, and for which outcome. Use rules for availability, compatibility, price, contribution margin, consent, and commercial pressure. Compare the platform's native feature with a model only when volume and variety justify it. Measure incremental revenue and contribution per session or order—not carousel clicks alone.
Poor recommendations look like an algorithm problem, but they often begin upstream: inconsistent catalogs, stale inventory, duplicate variants, the wrong objective, missing exclusions, and no commercial owner. The system learns that an item receives clicks and keeps promoting it even when the right size is unavailable, returns rise, or margin falls. More personalization on bad operational data simply accelerates the wrong decision.
Write the Commerce Recommendation Contract
- Moment — product page, search, cart, post-purchase, CRM, or service interaction.
- Customer job — compare, complete, substitute, discover, replenish, or progress.
- Candidates — the product set allowed to compete at that moment.
- Exclusions — unavailable, incompatible, restricted, low-confidence, overexposed, or inappropriate items.
- Objective — conversion, revenue, contribution, basket size, discovery, or retention, in an explicit order.
- Diversity — limits on repeated brand, category, price band, and already-seen items.
- Context — session, location, channel, device, history, and permitted signals.
- Reason — why an item qualified, what evidence supports it, and when that reason expires.
- Outcome — exposure, click, add, purchase, contribution, return, cancellation, and satisfaction.
- Owner — who owns catalog, policy, model, experience, and scale decisions.
The Contract separates selection from persuasion. A model may rank candidates; it must not invent compatibility, availability, or benefits. Furniture needs dimensions and room context. Beauty needs routine and restrictions. B2B distribution needs specifications, stock, and lead time. Commercial taxonomy comes before AI.
Choose rules, a native feature, or a custom layer
- Rules — best for smaller catalogs, stable relationships, and costly compatibility errors.
- Native feature — appropriate when catalog, events, and storefront already share one platform and the team needs straightforward control.
- Managed model — useful when interaction volume, multiple placements, and recent behavior support continuous learning.
- Custom layer — justified only when several channels, objectives, providers, and constraints must share one decision.
Shopify lets merchants edit related and complementary products and inspect reports; that may solve the first scope without another platform. AWS recommends at least 50,000 interactions from 1,000 users with two or more interactions for quality Amazon Personalize recommendations. That is product guidance, not a universal rule, but it exposes a practical truth: a store with sparse history should use curated relationships, contextual popularity, and transparent rules as honest comparators.
Protect eligibility before optimizing relevance
Google Cloud documents recommendation filters for availability and attributes and notes that availability is updated in real time. The operating order matters: remove what cannot be sold, then rank what remains. Price, geography, lead time, variant, policy, compatibility, and suppression should be structured controls rather than prose left for a model to interpret.
- New visitor — use session context, content, category, and trends with a confidence boundary.
- New product — use attributes, curation, and controlled exploration; do not bury it because history is absent.
- Known customer — use history only when identity, permission, and purpose are clear.
- Volatile stock — require real-time eligibility and a safe fallback.
- Unequal margins — use contribution as an objective or counter-metric without turning discovery into a hidden clearance aisle.
- High returns — penalize the recommendation and investigate fit, content, or product quality.
An eight-week implementation pilot
- Weeks 1–2 — choose one decision point; map candidates, exclusions, baseline, and unit economics.
- Week 3 — repair essential IDs, variants, inventory, price, margin, and events.
- Week 4 — create three comparable policies: current rule, native feature, and one AI-assisted alternative.
- Week 5 — run in shadow mode; test eligibility, latency, coverage, and reason codes.
- Weeks 6–7 — release limited traffic with a comparator, fallback, and exposure caps.
- Week 8 — evaluate outcome, contribution, returns, experience, cost, and operations; scale, simplify, or stop.
Measure what happens after the click
- Coverage — eligible sessions receiving a valid recommendation.
- Relevance — click and add-to-cart, treated as diagnostics rather than final outcomes.
- Business — incremental conversion, revenue, and contribution per session or order.
- Quality — unavailable, incompatible, repetitive, or unexplained recommendations.
- Experience — abandonment, return, cancellation, complaint, and item removal.
- Operations — latency, errors, fallback use, curation time, and incidents.
- Cost — platform, inference, integration, data, experimentation, monitoring, and people.
- Counter-metrics — catalog concentration, discounting, lost discovery, and cannibalization.
Google Cloud supports objectives such as conversion rate and revenue per session. Panel optimization still does not prove incremental enterprise value. Compare policies in the same context and preserve a holdout or reference period where feasible. Revenue may rise because the system shifted a purchase that would have happened anyway; contribution may fall when promotional items dominate.
Cost and accountability
Cost rises with SKUs, variants, inventory and price frequency, placements, channels, identity, latency, markets, and experiments. Commerce owns catalog and policy; marketing owns the customer task and experience; CRM governs identity and pressure; data instruments events; technology integrates and operates; finance defines contribution; service returns reasons for exchanges and returns. An implementation partner can build the system but should not choose the economic objective alone.
Bring one real recommendation surface
Connect the work to the minimum data loop at https://makinai.co/insights/en/cdp-ai-marketing-minimum-customer-data-loop-revenue, next best action at https://makinai.co/insights/en/ai-next-best-action-crm-personalization, incentive incrementality at https://makinai.co/insights/en/crm-discount-incrementality-ai-protect-margin, and first-value onboarding at https://makinai.co/insights/en/ai-customer-onboarding-first-value-crm. MAKINAI implements CRM and commerce at https://makinai.co/services/en/crm-ecommerce-commerce-transformation. Bring one placement, its candidate catalog, and four weeks of events; we can define the smallest useful pilot.
Better recommendations do not guarantee incremental demand. Price, media, availability, product, content, and seasonality may dominate the result. Small samples limit inference, and historical behavior requires appropriate permission and purpose. The sources document platform capabilities and requirements; the Contract, pilot, and economic criteria are MAKINAI editorial recommendations to validate in the real operation.