Recommendation Engines: How They Work and What to Define Before Adoption
Published:
Last Updated:
Category: MarTech
Authors: Shusaku Yosa
A recommendation engine selects products, articles or other items that may suit a visitor or the content being viewed. Adding an “items you may like” panel is not the business objective by itself. Start with the difficulty you want to solve: finding relevant items, comparing choices or discovering content.
This guide helps ecommerce and publishing teams define requirements before choosing an existing feature, a SaaS service or custom development. The important decision is not simply which algorithm to use, but what data, interface, evaluation and operational work the project requires.
How a recommendation system works
A system may generate candidates, score them and adjust the final order. Google's recommendation systems overview describes this common architecture as candidate generation, scoring and re-ranking.
A site does not necessarily need a large machine-learning system. Rules based on categories, availability or editorial choices may be a reasonable starting point. Match the approach to the available items, update frequency, customer problem and team that will maintain it.
Content-based and collaborative approaches
Content-based recommendations use similarities between items. Collaborative filtering uses similarities in relationships between users and items. Google's candidate generation guide introduces these concepts. The name alone does not tell you which approach is suitable; inspect the data it would need.
New products and first-time visitors may have little history. Define what will appear in those situations. Also consider business constraints such as unavailable products, repeated recommendations or an excessive concentration on popular items. A model is only part of the overall experience.
Six requirements to define
Requirement | What to document |
|---|---|
Items | Products, articles or other objects eligible for recommendation |
Use case | The page, cart, email or other location where recommendations appear |
Item data | Identifiers, categories, availability and sources of updates |
Behavior data | Recommendation impressions, clicks and relevant later actions |
Integration | Existing systems, update frequency, response requirements and fallback |
Operation | Owners, exclusions, evaluation and incident handling |
Identifier consistency deserves particular attention. If the website and data feed use different product identifiers, matching displays with outcomes becomes difficult. When the data owner and site developer are different people, prepare a requirement document both can validate.
For behavior linked to individuals, confirm the purpose, allowed uses, access and retention with the relevant internal owners. Define necessary data before expanding collection. A recommendation project should be designed around the information that can actually be used.
Compare adoption routes using the same cost categories
Features in an existing platform
Check what your ecommerce or content system already supports. Assess display locations, rule controls and data access. An existing feature may reduce some integration work, but it still needs configuration, verification and a person responsible for operation.
An external SaaS service
Separate setup and integration from recurring charges. Review usage allowances, additional charges, data retention, export, connection methods and termination. Ask what happens when data is missing or the external service is unavailable. A subscription price does not describe the complete implementation cost.
Custom development
Define requirements, data processing, recommendation logic, presentation and testing. Then include infrastructure, monitoring, maintenance and improvements after release. Custom development does not eliminate recurring costs, and a particular number of years does not guarantee that it becomes cheaper than a service.
Compare the likely operating period, changes in usage and item volume, maintenance responsibility and future modification needs. Record assumptions explicitly so that a total-cost comparison can be revised when conditions change.
Evaluate the experience and the business outcome separately
A recommendation impression, a click and a purchasing customer are different units. Establish whether the display and click can be recorded correctly before interpreting later outcomes. If purchases increase after launch, seasonality or other promotions may also have contributed.
Write down the question being tested, comparison conditions and exclusions for tests or unsuitable traffic. Consider the quality of the result, not only the number of clicks. For a shop, availability and returns may matter; for a publication, the usefulness of the next article may matter. When data is sparse, report actual counts and uncertainty instead of emphasizing a large percentage change.
The data and measurement guide helps define tracking and reporting work. It is not a quotation for developing an entire recommendation system.
Two hypothetical project briefs
Brief A: improve an existing ecommerce recommendation panel. Review the current feature and rules, item availability data, display and measurement. Check whether configuration and interface changes can address the problem before commissioning a new engine.
Brief B: explore a custom recommendation approach. Document the eligible items, usable data, response requirements, evaluation and maintenance. Begin by confirming feasibility and delivery responsibility. A quote for visual changes or tag configuration cannot represent the whole system.
These are examples of project boundaries. They do not establish that Ficilcom offers every stage as a standard service or can accept a custom recommendation development request.
Prepare this information for a discussion
- The website, existing platform and any current recommendation feature.
- Item volume, identifiers, update process and usable behavior data.
- Intended display locations, exclusions and fallback content.
- Candidate tools, contractual restrictions and the internal development owner.
- The desired outcome, measurement readiness and comparison plan.
- Ownership of operation, maintenance, changes and data management.
Frequently asked questions
Can we start with limited data?
Consider rules or existing features as well as personalized approaches. Define what happens without a history. Data volume alone does not prove that a personalized system will be useful.
Do more recommendation clicks mean success?
Only if that supports the intended objective. A focus on clicks can miss usefulness, satisfaction or later business outcomes. Decide what improvement you want before selecting the indicator.
Can a data or UI/UX estimate cover the engine?
Tracking and interface changes are different from engine development and maintenance. Use the UI/UX scope guide to define screen and evaluation work, rather than treating it as a system-development price.
Discuss the work you need separately
Identify whether your question concerns an existing feature, data preparation, interface improvements or custom development. Use the estimate service list to review the relevant work categories.
The standard estimators do not establish the price or availability of a complete recommendation system. For custom or combined work, send the requirements through the contact form to confirm the possible scope. The MarTech planning guide can also help map the relationship between tools, data and operations.
