Skip to content

TCO and effort model

This page explains TCO and effort model and how it fits into the RecSys suite.

Who this is for

  • Buyers and stakeholders planning time, roles, and risk.
  • Developers estimating integration effort.

What you will get

  • A decomposition of effort into concrete work packages
  • What changes effort up/down (so you can plan realistically)
  • A checklist you can use in procurement and planning

The effort buckets

1) Integration effort

What you do:

  • Implement POST /v1/recommend integration
  • Send tenant scope and request IDs correctly
  • Emit exposure logs (minimum viable spec)

Docs:

Effort drivers:

  • Number of surfaces and item types
  • How clean your existing event/identity model is
  • Whether you already log “what was shown” consistently

2) Data readiness effort

What you do:

  • Provide item metadata (IDs, tags, price, availability, …)
  • Provide outcome signals (click, add-to-cart, purchase) if available

Docs:

Effort drivers:

  • Are event schemas consistent across clients/platforms?
  • Can you produce join keys reliably? (request IDs, user/session IDs)

3) Ops readiness effort

What you do:

  • Define deployment shape (pilot vs production-like)
  • Decide DB-only vs artifact/manifest mode
  • Put runbooks and rollback in place

Docs:

Effort drivers:

  • Existing platform maturity (observability, deployment, on-call)
  • Need for strict SLOs and rollback windows

4) Optimization effort (ongoing)

What you do:

  • Tune weights, rules, and constraints per tenant/surface
  • Add or improve signals via pipelines (optional)
  • Evaluate changes and decide ship/hold/rollback

Docs:

Effort drivers:

  • How many stakeholders need to sign off on changes
  • How fast you need to iterate vs how risk-averse you are

A simple planning template

Use this as a procurement-ready checklist:

  • Surfaces in scope (list them)
  • Item ID and item metadata source confirmed
  • Exposure logging confirmed (format, storage, access)
  • Outcome logging confirmed (optional but recommended)
  • Tenant model confirmed (one tenant vs many)
  • Data mode chosen (DB-only vs artifact/manifest)
  • Pilot environment defined (local / staging / prod-like)
  • Success metrics agreed (business + offline/online)