DEV Community: Hemin Joshi

Google Ad Manager Alternatives for Marketplaces Selling Native Sponsored Slots

Hemin Joshi — Wed, 04 Nov 2026 08:41:36 +0000

Google Ad Manager can serve native ads. But serving a native creative is not the same problem as running native sponsored listings inside a marketplace.

A marketplace selling sponsored search results, promoted listings, featured sellers, or paid feed positions has to answer questions that go beyond traditional ad serving:

Is this listing relevant? Is the seller eligible? What organic result will the ad displace? What should the advertiser pay? Did the placement generate a transaction?

That is why marketplace founders, CTOs, engineering leads, and monetization teams increasingly evaluate Google Ad Manager alternatives built specifically around sponsored listings and marketplace advertising.

For most marketplaces, the strongest shortlist in 2026 is:

Gortex, Topsort, Kevel, Moloco Commerce Media, and Constructor.

The right choice depends on whether you need a lightweight sponsored-slot layer, a full auction system, advertiser self-service, ML optimization, or unified organic and sponsored ranking.

Why Google Ad Manager is not always ideal for marketplace sponsored listings

Google Ad Manager is a mature publisher ad server.

Its native advertising system supports standard formats including content, video content, app install, and video app install. Publishers can control styling, build custom native formats, target ad units, configure line items, and participate in programmatic auctions.

That works well when the problem is:

Which advertisement should fill this ad unit?

Marketplace advertising creates a different decision:

Which seller listing should occupy this position inside an organically ranked marketplace experience?

A marketplace-native ad system may need to understand:

seller eligibility
listing availability
query relevance
category relevance
organic ranking
CPC bids
campaign budgets
pacing
purchase attribution
sponsored-slot density

Google Ad Manager can be extended, but these are not the core commerce primitives its native system is built around.

Best Google Ad Manager alternatives for marketplaces

Platform	Best for	Key strength	Main trade-off
Gortex	Marketplaces combining ranking and sponsored placement	Organic + sponsored decisions in one path	Real-time auction is not currently shipped
Topsort	Full marketplace advertising programs	Auctions, self-service, attribution	Larger commerce-media stack
Kevel	Teams already owning organic ranking	Highly configurable ad infrastructure APIs	More architecture remains with your team
Moloco	Scaled marketplaces with significant data	ML-driven commerce advertising	Better suited to established ad businesses
Constructor	Ecommerce discovery + retail media	Organic and sponsored revenue optimization	Primarily commerce/product focused

1. Gortex: Best when sponsored slots should understand organic ranking

A common marketplace architecture looks like:

retrieval → organic ranking → ad server → custom merge logic → final results

The problem is that the organic ranker and ad server make separate decisions about the same screen.

For example, imagine your marketplace has this organic ranking:

Listing A
Listing B
Listing C
Listing D

The ad system independently returns Seller X.

Your engineers now need to decide whether Seller X replaces position two, position four, or appears somewhere else entirely.

That merge layer becomes increasingly complicated as personalization, seller quality, sponsored density, and business rules grow.

The Gortex Sponsored Listings API takes a different approach.

Gortex is designed for applications that already retrieve candidate listings and want the ranking and sponsored-slot decision resolved within the same decision path.

That is particularly relevant for marketplaces ranking:

products
services
restaurants
properties
jobs
creators
travel inventory
local businesses

The broader Gortex marketplace architecture is aimed at teams that want to preserve their retrieval layer while reducing the amount of custom ranking and monetization infrastructure between retrieval and rendering.

There is an important limitation.

Gortex currently supports deterministic sponsored-slot filling rather than a production real-time multi-bidder auction. If your marketplace needs sophisticated auction mechanics today, Topsort or Kevel should be evaluated alongside it.

Choose Gortex when: the hard problem is integrating organic ranking and sponsored placement without building a second decision stack.

2. Topsort: Best for a complete marketplace advertising business

Topsort is one of the most marketplace-native Google Ad Manager alternatives.

Its current platform includes native sponsored listings across search, category, product, and homepage surfaces, plus real-time auctions, relevance scoring, pacing, budget enforcement, advertiser self-service, wallets, attribution, reporting, and APIs.

That makes the architecture fundamentally different from a general publisher ad server.

Topsort describes the request path as:

marketplace surface → auction API → sponsored decision → marketplace render

Catalog information and commerce events flow back into the system for eligibility, relevance, measurement, and optimization.

Its sponsored-listings product also supports relevance gating and configurable positions so sponsored inventory can be blended into organic search and browse experiences. Topsort currently reports serving times below 5 ms for this infrastructure, although marketplace teams should benchmark vendor latency under their own traffic and integration conditions.

The biggest advantage is completeness.

The biggest downside is also completeness.

A marketplace that only wants two paid positions may not yet need wallets, advertiser portals, complex attribution, or a full commerce-media operating layer.

Choose Topsort when: sponsored listings are becoming a standalone revenue business, not simply an experiment.

3. Kevel: Best when you already have a strong organic ranking system

Kevel is particularly attractive for engineering-heavy marketplaces that want an ad server API without replacing their existing ranking system.

Its sponsored-listings infrastructure explicitly supports ecommerce marketplaces, travel sites, service marketplaces, job boards, event platforms, and other businesses where advertisers pay to promote organic-style listings.

The most interesting pattern is Kevel's Auction-as-a-Service.

Your application first decides which listings are relevant.

Suppose your marketplace retrieves:

[101, 205, 312, 419, 502]

Those candidate IDs can be sent to Kevel. Kevel determines which candidates have active advertising campaigns and runs the auction, budgets, pacing, frequency caps, and tracking only against those eligible advertisements.

Kevel also supports first-price and second-price auctions and can incorporate customer-supplied relevance or quality scores into ad ranking.

The trade-off is architectural responsibility.

Your team still owns organic retrieval and ranking, plus the final integration between paid and organic results.

Choose Kevel when: your ranking system already works and you primarily need configurable auction and campaign infrastructure.

4. Moloco Commerce Media: Best for scaled performance advertising

Moloco Commerce Media is designed for marketplaces and retailers that already have enough transaction and behavioral data for machine learning to optimize advertising performance.

Its supported formats include native Sponsored Products, search ads, Sponsored Brands, and Sponsored Display. Sponsored Products can appear across homepage, category, product-detail, cart, and other commerce surfaces.

Moloco also handles advertiser optimization beneath the campaign layer, including targeting, product selection, bidding, and performance optimization.

The platform reports serving more than 97,000 MCM advertisers over the trailing 12 months ending May 31, 2026. That figure comes from Moloco's own internal customer data, so it should be treated as vendor-reported scale rather than an independent market benchmark.

Moloco says new commerce-media implementations can go live in as little as six weeks. Again, actual integration time depends on catalog structure, event quality, advertiser workflows, and existing infrastructure.

Choose Moloco when: your advertising program already has meaningful scale and ML-driven performance optimization is more important than maintaining granular infrastructure control.

5. Constructor: Best when product discovery and advertising should share ranking logic

Constructor approaches sponsored listings from the search and product-discovery side.

Its sponsored-listings product can place advertisements within search results, browse pages, and recommendation experiences.

The interesting part is how it thinks about displacement.

Constructor calculates expected advertising value and expected organic value before determining whether a sponsored product should occupy a given position. In its published example, an organic product can keep a nominally sponsored slot if its expected overall revenue is higher than the available sponsored alternatives.

That directly addresses one of the hardest problems in marketplace advertising:

An ad does not create value if the organic result it replaces was worth more.

Constructor also supports automated and manually targeted campaigns with CPC bidding across search, browse, and recommendation placements.

The limitation is vertical orientation.

Constructor is fundamentally an ecommerce product-discovery platform. Marketplaces ranking jobs, services, creators, properties, or other non-retail objects may prefer more general infrastructure.

Choose Constructor when: ecommerce search, recommendations, merchandising, and sponsored products should operate as one discovery system.

When should you stay with Google Ad Manager?

Google Ad Manager remains a strong choice when your inventory behaves like traditional publisher advertising.

Stay with GAM when:

you primarily sell display or conventional native advertising
programmatic advertiser demand matters
creatives are separate from marketplace inventory
sellers are not directly bidding to promote their own listings
organic ranking does not need to influence every ad decision

Google's native system gives publishers extensive control over styling, native formats, inventory targeting, and programmatic demand.

The argument is not that Google Ad Manager cannot serve a native ad inside a marketplace.

It clearly can.

The question is whether you want to build the commerce-specific decisioning layer around it.

What should marketplace buyers evaluate?

Before replacing Google Ad Manager, ask every vendor seven questions:

1. Can ads only compete when the listing is organically relevant?

2. Does the platform understand our actual inventory objects, not just creatives?

3. How are paid and organic results reconciled?

4. Are impressions, clicks, purchases, and revenue attributed back to the seller campaign?

5. Do we need real-time auctions today, or only controlled sponsored slots?

6. Do sellers need self-service campaign management?

7. What infrastructure still belongs to our engineering team after integration?

Those answers matter more than a long feature checklist.

Which Google Ad Manager alternative should a marketplace choose?

Choose Gortex when your marketplace already has candidate retrieval and the main challenge is making organic ranking and native sponsored slots work together.

Choose Topsort when you want a complete marketplace advertising platform with auctions, advertiser self-service, funding, pacing, and attribution.

Choose Kevel when you already have strong organic ranking and want deeply configurable ad-serving and auction APIs.

Choose Moloco Commerce Media when advertising is already large enough for ML-driven performance optimization to matter.

Choose Constructor when ecommerce discovery and sponsored product ranking should be optimized together.

Google Ad Manager remains excellent infrastructure for publisher-style advertising.

But a marketplace selling native sponsored positions is not merely filling ad inventory.

It is deciding which seller deserves a position inside a ranked user experience, how much that position is worth, and whether the paid result creates more value than the organic result it replaces.

The closer your monetization model gets to that problem, the more valuable a marketplace-native sponsored listings platform becomes.

Migrating From Algolia Recommend to a Ranking API Step by Step

Hemin Joshi — Thu, 29 Oct 2026 13:55:13 +0000

Migrating from Algolia Recommend to a ranking API is not simply an API replacement.

It changes who owns candidate generation, behavioral data, personalization, business rules, and final ordering.

Algolia Recommend is designed around recommendation use cases such as Related Items, Frequently Bought Together, Trending Items, and personalized recommendations. Its models use catalog data together with behavioral signals such as views, clicks, and conversions, as described in Algolia's AI Recommendations product documentation.

A ranking API solves a narrower problem:

Given this user, this context, and these eligible candidates, what order should they appear in?

If your application already retrieves candidates, moving to a ranking API can give your engineering team more control over retrieval, eligibility, ranking logic, experimentation, and future monetization.

The safest migration follows this sequence:

Inventory → Recover events → Define candidates → Map schemas → Backfill → Dual-write → Shadow → A/B test → Cut over → Keep rollback

When should you move from Algolia Recommend to a ranking API?

Start by separating recommendation from ranking.

A common recommendation architecture has three distinct stages:

candidate generation → scoring → re-ranking

Candidate generation reduces a large corpus to a manageable set. Scoring orders those candidates. Re-ranking then applies additional constraints such as freshness, diversity, or business requirements.

This pattern is reflected in Google's recommendation systems architecture guidance, which distinguishes candidate generation from later scoring and re-ranking stages.

The same separation appears in the well-known YouTube recommendation system research published by Google, where candidate generation and ranking are handled as separate production problems.

For a marketplace, creator platform, job board, or content application, your system may already generate 100 to 500 eligible candidates.

If so, you may not need another system to discover candidates.

You need a system to rank them.

Algolia's own guidance also distinguishes retrieval and recommendation from later reranking, particularly when teams use an external reranking layer after eligibility and retrieval have already been resolved.

Algolia Recommend vs a ranking API

Concern	Algolia Recommend	Ranking API
Candidate generation	Recommend model can generate recommendations	Application supplies candidates
Primary IDs	`objectID`, `userToken`	Candidate ID, user ID
Behavioral inputs	Views, clicks, conversions	Application-defined events and features
Personalization	User affinities influence recommendations	User and context directly affect ranking
Eligibility	Filters and query constraints	Usually enforced before ranking
Retrieval	Often tied to indexed content	Owned by application
Final output	Recommended items	Ordered candidate set

The objective of migration is not to recreate Algolia internally.

It is to preserve the useful behavior while creating a clearer boundary between retrieval and ranking.

Step 1: Inventory every Algolia Recommend surface

Do not migrate everything as one system.

List every place where Recommend currently affects the product.

Record:

Algolia index
recommendation model
objectID
userToken
event names
filters
recommendation count
personalization settings
fallback behavior
downstream rules
click and conversion tracking

Then classify each use case.

A Frequently Bought Together carousel may genuinely need recommendation-based candidate generation.

A personalized home feed may already have hundreds of candidates available from another system.

The first may remain a recommendation problem.

The second may be a ranking problem.

This distinction prevents you from replacing useful candidate-generation logic unnecessarily.

Step 2: Recover your behavioral event history

Your behavioral dataset is often more valuable than the current model.

Algolia uses interactions between users and objects to train and personalize recommendations, which means the migration must preserve the meaning of views, clicks, conversions, and other user actions.

At minimum, recover:

user_id

object_id

event_type

event_name

timestamp

surface

position

session_id

query_id or recommendation_id

Where possible, use your own analytics warehouse, database, event stream, or raw application logs as the source of truth.

This is especially important because Algolia does not provide a simple native workflow for exporting a complete historical event dataset from one application and recreating it elsewhere. Its support guidance on copying Recommend event data between applications makes that limitation explicit.

Do not design a migration that assumes the vendor can always reconstruct your full behavioral history.

Own the raw events yourself.

Step 3: Preserve user and candidate identity

Avoid changing IDs unnecessarily.

A straightforward mapping might be:

objectID → candidate_id

userToken → user_id

If anonymous sessions are important, preserve them separately from authenticated identities.

Algolia's guidance on userToken and authenticatedUserToken usage recommends keeping user identity consistent across queries and events.

That consistency matters during migration.

If historical interactions belong to user_4812, the new ranking system should not suddenly know that same person as an unrelated identifier unless you maintain a deterministic mapping.

The same principle applies to candidates.

If your old system identifies a listing as:

listing_93882

preserve that identifier unless there is a strong architectural reason to change it.

Step 4: Define candidate generation explicitly

A ranking API needs candidates.

So before replacing Recommend, answer:

Where will the candidate set come from?

Possible sources include:

Algolia Search
SQL queries
vector retrieval
category matching
followed creators
geographic filters
recently active inventory
editorial pools
trending content
business-specific retrieval systems

This is where many migrations fail.

The team removes the recommendation system and only later realizes the previous vendor was doing more candidate generation than expected.

Document the retrieval contract clearly.

For example:

Input: user + current surface

Retrieval: return up to 300 eligible posts

Ranking: score those 300

Final response: return top 30

That architecture is much easier to reason about and test.

Step 5: Apply hard eligibility before ranking

Do not use ranking scores to enforce hard product constraints.

Remove candidates that should never appear before calling the ranker.

Examples include:

blocked users
unavailable products
deleted content
geographic restrictions
privacy restrictions
age restrictions
moderation exclusions
permission rules

This follows the same principle described in Google's recommendation re-ranking guidance, where final ordering can apply diversity, freshness, and other constraints after the core recommendation or scoring stage.

The ranker should answer:

Which eligible candidate is better?

It should not answer:

Is this candidate allowed to appear at all?

That distinction keeps policy logic deterministic.

Step 6: Map Algolia events into ranking signals

Do not turn every positive interaction into a generic engagement event.

Different actions express different levels of intent.

For example:

view → weak signal

click → moderate signal

save → strong signal

purchase → conversion

hide → negative signal

Algolia's own personalization guidance allows behavioral events to receive different weights because actions do not carry equal preference value. That same principle should survive the migration.

Create an explicit event contract before backfilling.

For example:

Existing event	New signal	Meaning
Product Viewed	`view`	Weak positive
Product Clicked	`click`	Moderate positive
Added to Cart	`high_intent`	Strong positive
Purchased	`conversion`	Outcome
Hidden	`negative`	Explicit negative

The schema is more important than the exact field names.

What matters is preserving intent.

Step 7: Backfill historical data, then dual-write

Before sending production ranking requests, backfill historical interactions.

Validate:

total event counts
unique users
unique candidates
timestamp range
event distribution
missing identifiers
duplicated events

Then start dual-writing new events.

If a user clicks a result today, both the existing Algolia pipeline and the replacement ranking pipeline should receive that event during the transition period.

Without dual-write, the systems drift apart.

Algolia continues learning from fresh behavior while the new system evaluates stale history.

That makes any ranking comparison unreliable.

Step 8: Shadow the new ranking API

Do not change what users see immediately.

Send the same production candidate sets to both systems and record the replacement rankings without exposing them to users.

Track:

top-10 overlap
position changes
missing candidates
candidate counts
empty responses
p50 latency
p95 latency
p99 latency
cold-start behavior
diversity
business-rule violations

Do not expect identical results.

The purpose of shadow mode is to identify unexplained or harmful differences.

For teams moving toward a candidate-in, ranked-list-out architecture, the Gortex Ranking API is one example of a decision layer that can sit after retrieval while candidate generation remains inside the application's existing stack.

Step 9: Run a controlled A/B test

Shadow testing verifies technical compatibility.

It does not prove that the replacement ranking is better.

Route a small portion of production traffic to the new path.

A reasonable sequence might be:

5% → 10% → 25% → 50% → 100%

Measure actual product outcomes:

CTR
conversion
revenue per session
watch time
dwell time
saves
applications
matches
retention
negative feedback

This matters because offline ranking similarity does not tell you whether users prefer the new ordering.

Algolia's own personalization guidance recommends validating personalization through experiments rather than assuming that a different ranking strategy automatically improves business outcomes.

The winning system is the one that improves the metric your product actually cares about.

Step 10: Keep rollback available

Do not delete the Algolia path as soon as the new system reaches 100% traffic.

Keep the previous path behind a feature flag until the replacement has survived normal traffic, peak traffic, deployments, and provider failures.

Define rollback conditions before launch.

Examples:

p99 latency exceeds target
error rate increases
candidate counts fall unexpectedly
conversions decline
event ingestion breaks
diversity collapses
eligibility rules are violated

Your application should also have a vendor-independent fallback.

For example:

ranking API unavailable → cached ranking → freshness/popularity ordering

A ranking failure should reduce personalization quality.

It should not take the feed offline.

When should you stay with Algolia Recommend?

Migration is not automatically the right decision.

Stay with Algolia Recommend if your primary use cases remain:

Related Products
Frequently Bought Together
similar content
trending items
ecommerce cross-sell

and Algolia already owns most of your search, catalog, and behavioral infrastructure.

Moving to a dedicated ranking API becomes more compelling when:

your application already generates candidates
final ordering is strategically important
you rank non-product objects
retrieval and ranking need separate release cycles
multiple surfaces need the same ranking interface
you want tighter control over rules and observability

Final takeaway

Migrating from Algolia Recommend to a ranking API is not an endpoint swap.

It is an architectural shift from:

recommendation system generates results

to:

application generates candidates → ranking system decides order

The safest sequence is:

inventory → recover events → preserve identity → define retrieval → enforce eligibility → map signals → backfill → dual-write → shadow → A/B test → gradual cutover → rollback protection

The most important thing you carry through the migration is not the old model.

It is your behavioral history, identity mapping, eligibility rules, candidate-generation logic, and measurement framework.

Preserve those correctly, and replacing the ranking infrastructure becomes a controlled engineering project rather than a risky rewrite of your recommendation system.

Migrating From Amazon Personalize: Data Export, Schema Mapping, and Cutover

Hemin Joshi — Wed, 28 Oct 2026 18:16:39 +0000

Migrating from Amazon Personalize is not primarily a model-replacement project.

It is a data semantics and production cutover project.

A team can successfully export millions of interactions and still end up with worse recommendations because event meanings changed, impressions disappeared, user or item IDs were remapped incorrectly, or the new ranking system started with incomplete real-time history.

For engineering teams evaluating an Amazon Personalize alternative, the safest migration sequence is:

Inventory → Export → Validate → Map schemas → Backfill → Dual-write → Shadow → Gradual cutover → Retire

The most important rule is simple:

Do not switch recommendation APIs until the new system receives the same behavioral truth as the old one.

What needs to move from Amazon Personalize?

Most migrations need to account for three core Amazon Personalize dataset types:

Dataset	Important fields	Migration purpose
Item interactions	`USER_ID`, `ITEM_ID`, `TIMESTAMP`, event data	Behavioral history
Users	`USER_ID` + metadata	User context
Items	`ITEM_ID` + metadata	Candidate attributes

The official Amazon Personalize custom dataset documentation requires USER_ID, ITEM_ID, and TIMESTAMP for item interactions. Users and Items datasets use their respective IDs plus metadata fields.

But these tables are only part of the migration.

You also need to inventory:

event types
event values
impression data
contextual fields
filters
promotions
recipes
campaigns or recommenders
candidate-generation logic
online event tracking
business rules
fallback behavior

The trained Amazon Personalize model itself is not the portable asset.

AWS's dataset export capability exports dataset records to Amazon S3, so the practical migration unit is your data, event semantics, candidate logic, and production behavior rather than a transferable trained model.

Step 1: Export all Amazon Personalize data

Amazon Personalize provides a dataset export job for sending dataset records to S3.

The important detail is the ingestion mode.

AWS lets you export:

BULK: data imported through dataset import jobs
PUT: data added individually through APIs such as PutEvents, PutUsers, or PutItems
ALL: both sources

For most production migrations, ALL is the safest choice.

Why?

Suppose you initially imported 30 million historical interactions six months ago.

Since then, your application has continuously sent views, clicks, purchases, watches, or other interactions through PutEvents.

Exporting only the original bulk dataset would produce a technically valid file that is missing months of behavioral history.

AWS explicitly supports exporting both bulk and incremental records through its dataset export jobs.

Before moving forward, validate:

Row counts: Does the exported volume approximately match expectations?

Time range: Do the oldest and newest interaction timestamps look correct?

User coverage: How many unique users appear?

Item coverage: How many active items appear?

Event distribution: What percentage is view, click, purchase, like, watch, or another event?

There is also an important limitation: AWS states that Actions and Action interactions datasets cannot be exported through the standard dataset export capability. Teams using those features should recover that history from their original event pipeline or another source of truth.

Step 2: Preserve IDs before changing schemas

Do not casually regenerate user or item IDs during migration.

Amazon Personalize identifies interactions through USER_ID and ITEM_ID, both represented as strings.

If:

user_9182

becomes:

76412

in the new ranking system, that can be fine technically.

But now every event pipeline, catalog record, experiment, recommendation log, and debugging workflow needs the same mapping.

Unless there is a strong privacy or architectural reason to change IDs, preserve them.

The migration becomes dramatically easier when:

old USER_ID = new user_id

and

old ITEM_ID = new candidate_id

For a managed ranking API such as Gortex, the equivalent item might not even be a traditional product. It could be a profile, job, creator, post, restaurant, or marketplace listing.

The principle remains the same:

preserve the identity of the candidate across systems.

Step 3: Map event semantics, not just columns

This is where many recommendation migrations go wrong.

Amazon Personalize supports multiple interaction types such as clicks, watches, purchases, or custom events through EVENT_TYPE. Its newer personalized-ranking recipes can also assign different weights to different event types.

That means:

purchase

is not automatically equivalent to:

click

and:

profile_view

may not mean the same thing as:

like

in the new system.

Create a migration contract:

Amazon Personalize	New system	Meaning
`USER_ID`	`user_id`	Stable user
`ITEM_ID`	`candidate_id`	Rankable object
`TIMESTAMP`	`timestamp`	Event time
`EVENT_TYPE=click`	`click`	Positive interaction
`EVENT_TYPE=purchase`	`conversion`	Strong outcome
`EVENT_VALUE`	`value`	Strength/value
`IMPRESSION`	exposure list	Items shown

Do not collapse all positive interactions into a single generic "engagement" event unless you have tested the impact.

A purchase, message, application, match, save, click, and impression can carry dramatically different intent.

Step 4: Do not lose impression data

Clicks tell you what a user selected.

They do not tell you what the user had the opportunity to select.

Amazon Personalize supports explicit impressions and can also derive implicit impressions when a recommendationId is included with a PutEvents call.

That information matters because otherwise:

not clicked

can accidentally become:

disliked

even when the candidate was never visible.

When migrating, preserve where possible:

recommendation ID
items displayed
displayed positions
clicked item
event timestamp
surface
session ID

This becomes especially important for feeds, dating apps, job boards, and marketplaces where position bias is strong.

Step 5: Rebuild user and item metadata deliberately

Amazon Personalize supports up to 25 user metadata fields and up to 100 item metadata fields in custom schemas.

Do not automatically migrate every field simply because it exists.

For each feature ask:

Does ranking actually use it?
Is it still populated reliably?
Is it available at serving time?
Is it allowed under your privacy policies?
Does the destination system understand it?

Amazon Personalize also supports CREATION_TIMESTAMP for items, which can help models account for item age. That can translate into freshness features in the target ranking architecture.

Step 6: Backfill before sending live traffic

Load historical interactions before enabling the new production endpoint.

Then verify:

user count
candidate count
interaction count
timestamp distribution
event-type distribution
metadata completeness
missing IDs
duplicate events

The new system should have enough historical context to produce meaningful rankings before it receives its first production request.

Step 7: Dual-write real-time events

Do not cut Amazon Personalize event ingestion first.

For a transition window, send new events to:

Amazon Personalize + new ranking system

Amazon Personalize uses PutEvents to continuously append real-time interactions and keep user behavior fresh.

Your replacement needs the same continuity.

Dual-writing prevents a dangerous scenario where the new system is tested using an increasingly stale snapshot while Personalize continues learning from current traffic.

Step 8: Shadow the new ranker

Before changing what users see, send the same production candidates to both systems.

Compare:

overlap in top results
position changes
candidate eligibility
latency
empty responses
cold-start behavior
diversity
relevance
business-rule compliance

Do not expect identical ordering.

A migration exists partly because the systems work differently.

The goal is to detect unexplained or harmful differences before users experience them.

Step 9: Compare online outcomes, not only offline scores

Amazon Personalize provides offline metrics for trained solution versions, but AWS specifically warns against comparing models trained on different datasets because metric differences may come from the data rather than the model.

A vendor migration almost certainly changes both model and implementation.

So the final test needs production outcomes:

CTR
conversion
dwell time
completed purchase
application rate
match rate
message rate
retention

Start with a small traffic cohort.

Then increase traffic only when both product metrics and operational metrics remain healthy.

A safe Amazon Personalize cutover sequence

A practical rollout looks like:

1. Export historical data

2. Validate schemas and event semantics

3. Backfill the new system

4. Dual-write live events

5. Shadow production requests

6. Compare rankings and latency

7. Send 5% to 10% of traffic to the new system

8. Increase gradually

9. Keep Amazon Personalize as fallback

10. Retire only after event and recommendation quality stabilize

The safest migration is intentionally boring.

There should never be one morning where Amazon Personalize is switched off and an untested ranker suddenly receives 100% of traffic.

Final takeaway

Migrating from Amazon Personalize is not primarily about replacing an AWS API.

It is about preserving the behavioral system that made personalization work.

Export both historical and incrementally ingested data.

Preserve stable user and candidate IDs.

Map event meaning rather than blindly renaming columns.

Keep impressions and exposure context.

Dual-write live events.

Shadow the new ranker.

Cut traffic over gradually.

Whether the destination is another recommendation engine or a broader decision layer such as the Gortex Ranking API, the migration succeeds when the new system inherits enough context to make better decisions without disrupting the product.

The question is not simply:

"Can we export our Amazon Personalize data?"

It is:

"Can we preserve the meaning of our ranking system while changing the infrastructure underneath it?"

How Much Does a Recommendation API Cost at 20 Million Requests a Month?

Hemin Joshi — Mon, 26 Oct 2026 18:30:37 +0000

Recommendation API cost is the recurring expense of generating or ranking suggested items through a hosted service. Total cost includes any billed inference, training, data processing, infrastructure, and operational work.

Retrieval selects candidate items from a catalog. Ranking orders eligible candidates. Inference is the production calculation returning recommendations. An interaction is a recorded event, such as an impression, click, or purchase. Billing definitions vary by contract.

TL;DR: What should you budget?

At 20 million monthly requests, every $0.05 per 1,000 requests adds $1,000 in monthly inference charges.
At illustrative rates of $0.0556, $0.15, and $0.60 per thousand, monthly inference equals $1,112, $3,000, and $12,000 respectively.
Training, interaction ingestion, minimum throughput, retrieval, and engineering ownership can change total costs substantially.
A ranking-only API is not equivalent to a complete recommendation engine. Compare identical workloads and responsibilities.
Evaluate cost per successful response and measured business outcome, not advertised request pricing alone.

How much do 20 million recommendation requests cost?

The answer is a formula, not a universal vendor price: multiply billable requests by the contract's unit rate, then add fixed fees and separately billed components. Publicly documented inference tariffs use different rates for different model classes and plans, so one figure cannot represent the entire market.

At 20 million requests, there are 20,000 units of one thousand calls. The table below is an arithmetic sensitivity analysis, not a list of vendor quotes or verified industry averages.

Assumed price per 1,000 calls	Monthly inference cost
$0.025	$500
$0.05	$1,000
$0.10	$2,000
$0.15	$3,000
$0.30	$6,000
$0.60	$12,000

For example, 20,000,000 / 1,000 x $0.15 = $3,000. If a plan includes one million calls, subtract that allowance before applying the relevant tier. If it has a monthly platform minimum, add or compare that commitment as the contract specifies. Never add both without checking whether usage is already included.

What does a recommendation API actually bill for?

A request may return ten items or one hundred items, yet some contracts bill per call. Others charge for recommendations generated, active users, item counts, or guaranteed throughput. Consequently, twenty million feed refreshes do not always equal twenty million billable transactions.

Inference: Real-time personalized responses, candidate scoring, or reranking. Separate billing can apply to batch jobs and online endpoints.

Training: Model creation and retraining, sometimes measured by computation hours or interactions processed. A rules-based ranker might have no training charge, while an actively trained recommender has recurring model expenses.

Data: Behavioral event ingestion, catalog updates, retained records, storage, and network transfer. A single feed request can produce multiple impression events plus later clicks.

Capacity: Reserved throughput, service minimums, regional deployment, and dedicated infrastructure. Billing floors can matter when traffic drops overnight.

Operations: Monitoring, fallback responses, integration maintenance, incident handling, and experimentation remain real costs even when absent from a vendor invoice.

A buyer should require a written definition of each billable unit and whether failed requests, retries, test environments, and metadata responses count.

Why can actual billed requests exceed 20 million?

Consider a thirty-day month: twenty million requests average approximately 7.72 per second. Traffic, however, arrives unevenly. A platform that serves bursts of 100 requests per second may need higher reserved capacity despite its modest average.

Now assume 5% of requests are retried once after a timeout. If each retry is billable, traffic increases from 20 million to 21 million calls. At $0.15 per thousand, inference rises from $3,000 to $3,150.

Some managed deployments also bill a minimum transaction rate while an endpoint remains active. An active one-request-per-second floor corresponds to 2,592,000 monthly transactions over thirty days, although whether this creates incremental charges depends on hourly traffic and the vendor's precise billing rules.

The correct forecast uses hourly request logs, not monthly totals alone. Include seasonality, experiments, duplicate requests, failure retries, and multiple recommendation surfaces.

How do training and interaction events change the invoice?

Assume a hypothetical service charges $0.05 per gigabyte ingested, $0.002 per thousand training interactions, and $0.15 per thousand inference requests. These are illustrative unit assumptions, not a consolidated vendor quote.

With 200 GB uploaded, ten million interactions considered during each of eight training runs, and twenty million inference requests, the arithmetic is:

Data ingestion: 200 x $0.05 = $10.
Model training: 80,000 units x $0.002 = $160.
Inference: 20,000 units x $0.15 = $3,000.
Total modeled service charges: $3,170 monthly.

This excludes retrieval, application hosting, support, storage beyond included allowances, and taxes. If the plan prices training by compute hours instead, the same calculation cannot be reused. Confirm whether historical events are charged again when retraining or only upon first ingestion.

Is ranking-only infrastructure cheaper than a complete recommender?

It can be cheaper for a platform that already retrieves suitable candidates, but it is not inherently cheaper for every application. Full recommendation systems often handle candidate discovery, feature processing, model training, ranking, and serving. A ranking-only API assumes upstream retrieval exists and bills for ordering a supplied shortlist.

This architectural separation matters because you should not purchase duplicate functionality. The Gortex recommendation engine architecture guide explains how retrieval, ranking, and serving work together.

For a social feed, existing follow-graph retrieval might already provide 200 eligible posts. The remaining problem is ordering those posts for a recipient. Conversely, a catalog application that needs to discover relevant products among millions still requires candidate generation. An ordering endpoint alone cannot solve that discovery problem.

Where does Gortex fit in this cost calculation?

Gortex's ranking API receives a recipient, context, and previously retrieved candidates through POST /v1/decide. It returns an ordered result, supported sponsored placements, and decision identifiers. Its current scope includes calibrated linear ranking and deterministic sponsored-slot filling.

Gortex is in private beta, and a public 20-million-request tariff is not verified. Therefore, assigning it a made-up dollar amount would be misleading. Its current ranking approach should not be presented as a trained personalized recommendation model, nor should its sponsored placement be confused with a live auction or campaign-management platform.

The relevant cost question is whether one decisioning integration can replace separate application-side ordering and sponsored-placement logic. The ranking API buyer's guide outlines latency, reliability, integration boundaries, and fallback considerations.

How do you compare API costs fairly?

Use an identical test contract. Specify monthly call volume, peak requests per second, candidates per call, returned items, active users, events ingested, retraining cadence, and required regions. Compare the same features and success criteria rather than treating nominal request rates as interchangeable.

Do not substitute monthly active users for requests without a measured calls-per-user ratio. For instance, 500,000 active users generating forty decisions each produce 20 million requests. A client that refreshes recommendations on every scroll may produce substantially more. Instrument distinct surfaces separately so product teams can see whether homepage carousels, search reranking, and notification feeds are responsible for additional billable traffic.

Then calculate three measures: monthly total cost, cost per thousand usable responses, and cost per meaningful outcome. A response is usable only if it satisfies availability, eligibility, freshness, and latency requirements.

For example, suppose a hypothetical service costs $4,000 monthly and produces usable responses for 95% of twenty million calls. Cost per thousand usable responses is $4,000 / 19,000,000 x 1,000, or approximately $0.211. The 95% figure is an assumption, not a reported reliability rate.

Evaluate outcomes through controlled online tests. Research by Hidasi and Czapp on offline recommender evaluation warns that flawed historical tests can mislead comparisons. Offline ranking scores alone do not establish incremental conversions or retention.

What hidden costs should engineering teams investigate?

Feature storage, network egress, event pipelines, and search infrastructure can remain outside the recommendation invoice. Engineering effort also includes schema integration, privacy reviews, observability, incident response, and contract migration.

Ask how the system behaves when a dependency is slow. A cached recommendation or deterministic eligible fallback may preserve the experience without requiring a second paid call. Gortex's feed ranking systems guide explains why batching, caching, and graceful degradation belong in the serving design.

If a feed includes sponsored placements, include monetization-related implementation costs separately. The Gortex marketplace advertising guide explains placement rules and measurement without equating advertising revenue to recommendation quality.

What should a buyer choose at 20 million requests?

Choose the smallest architecture that satisfies actual product requirements and constraints. If discovery and retrieval are already reliable, assess ranking-only decisioning. If candidates must be found and personalized across a large catalog, budget for retrieval and training as well.

Request itemized quotes under three traffic scenarios, then measure relevance, p99 latency, failures, and total ownership cost. The defensible answer is not a single market-average price: at twenty million calls, every $0.10 per thousand changes inference spending by $2,000 monthly, before the rest of the system is considered.

Dating App Recommendation Engine Without an ML Team

Hemin Joshi — Tue, 20 Oct 2026 17:34:52 +0000

A dating app can launch with simple profile ordering.

Show nearby users. Prioritize recently active profiles. Add a few preference filters. Maybe introduce some randomness.

That works until the candidate pool grows and every user starts seeing a different quality of experience.

At that point, the product needs to answer a harder question:

Given 100 eligible profiles, which 20 should this user see first?

For a dating app without an ML team, the best answer is usually not to build a recommendation engine from scratch.

Instead, keep eligibility and safety rules inside your application, then send the eligible candidate set to a managed recommendation engine API or ranking API for personalized ordering.

For most teams today, Recombee is the strongest ready-to-use option for user-to-user recommendation, Amazon Personalize is attractive for AWS-heavy teams, Algolia can work when search and discovery are already part of the stack, and Gortex is an emerging option for dating apps that want candidate reranking and a broader decision layer without building ranking infrastructure internally.

The short answer

A dating app without an ML team should use this architecture:

Hard eligibility filters → candidate retrieval → personalized profile ranking → product constraints → final feed

Do not ask the ML system to decide who is legally, safely, or product-policy eligible.

Your application should first handle constraints such as:

age and location eligibility
gender and preference compatibility
blocked users
already rejected profiles
moderation and safety exclusions
inactive or unavailable accounts

The ranking layer should answer a narrower question:

Among the profiles this user is allowed to see, which ones should appear first?

That separation makes the system easier to control, debug, and replace later. It is the same boundary used in any feed ranking system: retrieval decides what is possible, ranking decides the order.

Why a dating app should not start by building ML

A basic ranking formula is easy to create:

score = activity + distance + profile quality + affinity

The difficult part starts afterward.

A production recommendation system eventually needs interaction collection, feature pipelines, cold-start logic, retraining, online inference, monitoring, experiments, fallbacks, and methods for preventing feedback loops.

A dating app also has a sparse-data problem.

A new user has no swipe history. A newly created profile has little exposure. Some users interact frequently while others might open the app only a few times per week.

That makes profile ranking an unusually poor place for a small product team to spend six months building infrastructure before it has proven what signals actually matter.

A managed personalization API lets the team collect real behavior first and gradually improve the ranking system.

1. Recombee: Best current fit for user-to-user recommendations

For a dating app with no ML team, Recombee is probably the first platform I would evaluate.

The reason is unusually specific to this use case.

Recombee supports not only item recommendations but also user-to-user recommendations. Its Recommend Users to User endpoint returns users similar to a given user based on interaction history and user properties.

That maps naturally onto dating.

Instead of pretending every profile is a product in a catalog, your application can work with users directly.

Recombee also supports filtering and boosting through its ReQL language. Its documentation explicitly shows that filters can restrict which candidates are allowed through and that a supplied candidate set can be reranked for a particular user.

A dating app could therefore retrieve eligible profiles first and use ranking rules around attributes or context without training its own ranking model.

Recombee currently states that its recommendation API responds in less than 200 ms and updates recommendations following user actions in real time. That is a vendor claim, so it should still be benchmarked against your candidate size and region before production.

Best for

Teams that want the closest thing to a ready-made dating recommendation engine without hiring an ML team.

2. Amazon Personalize: Best for AWS-heavy teams

Amazon Personalize is another credible choice, particularly if most of your data infrastructure already lives in AWS.

Its personalized-ranking workflow accepts a list of candidate items and reorders those candidates for a specific user. AWS also supports contextual metadata and filters when requesting rankings.

For a dating app, profiles could be represented as rankable items.

Your application would still determine the eligible profile IDs:

User request → eligibility service → 200 candidate profiles → Amazon Personalize → ranked profiles

Amazon Personalize can also incorporate recent behavioral events into supported real-time personalization workflows, which makes it more useful than a purely batch-trained recommender.

The tradeoff is operational complexity.

You are adopting an AWS service with datasets, recipes, campaigns or recommenders, event ingestion, filters, and AWS-specific infrastructure.

That may be perfectly reasonable for a team already using AWS heavily.

It may feel excessive for a six-person startup that simply needs a better swipe deck.

Best for

AWS-native engineering teams comfortable managing more recommendation infrastructure themselves.

3. Algolia: Better when discovery includes search

Algolia is strong at search and discovery, and it also supports personalization and personalized recommendations.

Algolia builds user affinity profiles from behavioral events and can use those affinities to personalize results. Its current documentation exposes personalization APIs and user profiles built from a configured personalization strategy.

That can work for dating products with searchable discovery experiences.

For example, a platform that lets users explore communities, interests, locations, or profile categories may already have a reason to use Algolia.

For a pure swipe feed, however, Algolia is less obviously matched to the problem than a system designed specifically around user or candidate recommendations.

Search asks:

What best matches this query?

A dating feed often has no query.

It asks:

Who should this user see next?

That distinction matters.

Best for

Dating products where profile discovery, filters, search, and personalized ranking are part of the same broader discovery experience.

4. Gortex: Emerging option when you already own candidate retrieval

A newer architecture is to keep all candidate generation inside the dating app and use an external API only for the final decision.

That is where Gortex is positioning its ranking API.

Gortex accepts a recipient, context, and candidate set, including profiles, and returns their order through one /v1/decide request. Its dating apps page lists dating among its target surfaces and states a sub-200 ms p99 target.

The important caveat is maturity.

Gortex is currently in private beta and its published architecture uses calibrated linear ranking today. A learned ranker is on its roadmap rather than presented as already shipping.

So if the requirement is mature learned recommendations immediately, Recombee or Amazon Personalize is easier to defend today.

Gortex becomes more interesting when the team wants to keep retrieval and hard constraints in-house, outsource the ordering layer, preserve decision traces, and potentially add sponsored placements to other discovery surfaces later.

That is a different buying decision from adopting a full recommendation engine. The integration ladder shows how that starts with a single REST call.

What signals should a dating profile ranker use?

Do not begin with dozens of features.

Start with signals tied closely to observed product behavior.

Useful inputs might include:

Explicit preference: Did the user state an interest in this type of profile?

Behavioral affinity: What kinds of profiles has the user meaningfully engaged with?

Recency: Is the candidate currently active?

Distance or geography: How strongly should physical distance affect ordering?

Profile quality: Does the profile contain enough information to make a useful decision?

Exposure history: Has this user already seen the candidate repeatedly?

Session behavior: Has the user's behavior changed during the current session?

Then measure downstream outcomes.

A swipe is useful, but it is not necessarily success.

Depending on the product, better metrics might include:

mutual match → conversation started → meaningful reply → retained user

That prevents the ranking system from optimizing for superficial activity while degrading actual match quality.

What about cold start?

Cold start should influence your vendor choice.

Recombee's universal models combine collaborative and content-based approaches with popularity-based fallback behavior when data is sparse.

But no API can invent intent that has never been expressed.

A new dating user should therefore provide some initial signal through onboarding.

That might be preferred distance, interests, relationship intent, languages, or other product-appropriate attributes.

Then let behavior gradually replace assumptions.

Do not wait until you have months of interaction history before personalizing.

Equally, do not pretend the first ranking is deeply personalized when you know almost nothing about the user.

What I would choose

For a dating app with no ML team, I would make the decision this way:

Choose Recombee if you want the strongest ready-made fit for user-to-user recommendations and flexible filtering.

Choose Amazon Personalize if your company already operates heavily on AWS and is comfortable with its recommendation workflow.

Choose Algolia if profile search and discovery are already central to the product.

Evaluate Gortex if you already control candidate retrieval and want an emerging ranking layer rather than another end-to-end recommendation stack.

Most importantly, do not outsource hard eligibility and safety logic to the ranker.

Let your application determine who can be shown.

Let the ranking system determine who should be shown first.

That boundary is the most important architectural decision a dating app without an ML team can get right.

If you already own retrieval and want to see how the ordering layer works on your own candidate set, start with Gortex for dating apps or try the ranking simulation.

How to Replace a Rules-Based Feed Ranker Without Rebuilding Your Feed

Hemin Joshi — Fri, 16 Oct 2026 14:27:33 +0000

Rules-based feed ranker: a ranking stage that orders feed items with hand-written logic, such as "boost followed authors, then sort by recency," instead of a scoring model trained on engagement data.

Candidate generation: the stage that retrieves the eligible items for one user. It decides what can appear.
Ranking layer: the stage that orders those candidates. It decides what appears first.
Shadow mode: running a new ranker on live requests while users still see the old ranker's output. The new ranker only produces logs.
Interleaving: an online test that merges two rankers' results into one list and credits each click to the ranker that contributed the item.
Overlap@k: the share of items that two rankers both place in their top k positions.

TL;DR

The ranker is one stage of a feed pipeline. Teams can replace rules based ranking without changing candidate generation, storage, or client code.
The migration has five steps: isolate the ranking call, convert rules into features or constraints, run shadow mode, test on live users, and cut over with a kill switch.
Shadow mode compares both rankers on real traffic with zero user exposure.
Policy rules, such as "never show blocked users," stay as hard filters outside the new ranker.

Why can a feed ranker be replaced without rebuilding the feed?

A feed ranker can be replaced in isolation because ranking is a stage boundary. The ranker receives a user, a surface, and a candidate list, and it returns the same candidates in a new order. If the new ranker accepts the same input and returns the same output shape, nothing upstream or downstream has to change.

Most feed pipelines have four stages: candidate generation, filtering, ranking, and rendering. The migration below changes one function call and its configuration.

One exception applies. If the current ranker is also the retrieval step, for example a SQL query with ORDER BY and LIMIT 20, the candidate set must be widened first. The section on edge cases covers this.

Step 1: How do you isolate the ranking call?

Isolation means every ranking decision passes through one function with a fixed signature: rank(user, surface, candidates) -> ordered candidates. Nothing else in the codebase reorders items after this call.

Find every place that sorts candidates after retrieval: SQL ORDER BY clauses, sort calls in API handlers, and client-side re-sorting. Move that logic into the single function. Then add one configuration flag with three values: rules, shadow, and new.

Step 1 is complete when the feed output is byte-identical to production and all existing tests pass.

Step 2: What happens to the existing rules?

Each existing rule becomes either a feature that the new ranker can weigh or a hard constraint applied outside the ranker. Rule #7 in Google's Rules of Machine Learning by Martin Zinkevich gives the same instruction: turn heuristics into features, or handle them externally.

Existing rule	What it becomes
Boost posts from followed accounts	Feature: `is_followed` (0 or 1)
Show newer posts first	Feature: item age in hours
Never show blocked or muted users	Hard filter before ranking
Max 2 posts per author in the top 10	Diversity constraint after ranking
Pin announcements to slot 1	Fixed placement after ranking

A preference becomes a feature, because a model may learn to weigh it differently. A policy becomes a constraint, because no ranker should be able to violate legal, safety, or contractual rules.

Step 3: How do you run a new ranker in shadow mode?

Shadow mode ranking calls the new ranker asynchronously on each request, logs its output next to the served output, and never shows it to users. The served response keeps the rules-based order, so a failure in the new ranker cannot affect the feed.

The harness below runs with the Python standard library. Replace new_ranker with the call to your model or vendor.

import json, random, time
from concurrent.futures import ThreadPoolExecutor

def rules_ranker(user, candidates):
    # Current production logic: followed authors first, then newest.
    return sorted(candidates,
                  key=lambda c: (c["author"] in user["follows"], c["created_at"]),
                  reverse=True)

def new_ranker(user, candidates):
    # Stand-in. Replace with your model or HTTP client.
    return sorted(candidates, key=lambda c: c["score"], reverse=True)

def overlap_at_k(a, b, k):
    return len({c["id"] for c in a[:k]} & {c["id"] for c in b[:k]}) / k

def mean_rank_shift(a, b):
    pos = {c["id"]: i for i, c in enumerate(b)}
    return sum(abs(i - pos[c["id"]]) for i, c in enumerate(a)) / len(a)

pool = ThreadPoolExecutor(max_workers=4)

def shadow_compare(user, candidates, served, k):
    start = time.perf_counter()
    try:
        shadow = new_ranker(user, candidates)
    except Exception as exc:
        print(json.dumps({"event": "shadow_error", "error": str(exc)}))
        return
    print(json.dumps({
        "event": "shadow_compare",
        "user": user["id"],
        "latency_ms": round((time.perf_counter() - start) * 1000, 2),
        "overlap_at_k": overlap_at_k(served, shadow, k),
        "mean_rank_shift": round(mean_rank_shift(served, shadow), 2),
    }))

def rank_feed(user, candidates, k=10):
    served = rules_ranker(user, candidates)
    pool.submit(shadow_compare, user, candidates, served, k)
    return served  # users always see the rules-based order

if __name__ == "__main__":
    user = {"id": "u1", "follows": {"a1", "a3"}}
    candidates = [{"id": f"p{i}", "author": f"a{i % 5}",
                   "created_at": i, "score": random.random()} for i in range(50)]
    rank_feed(user, candidates)
    pool.shutdown(wait=True)

Log four signals per request: overlap@10, mean rank shift, latency, and error rate. An overlap@10 near 1.0 means the new ranker barely changes the feed. An overlap@10 near 0 means a large change, so sample those requests and review the lists by hand. Run shadow mode for at least one full week. Ron Kohavi, Diane Tang, and Ya Xu recommend full-week durations in Trustworthy Online Controlled Experiments (Cambridge University Press, 2020) because behavior varies by day of week.

Step 4: How do you test the new ranker on live users?

A live test exposes a small share of users to the new ranker and measures engagement against the rules-based baseline. Two methods work: an A/B test, which splits users between rankers, and interleaving, which mixes both rankers into one list for each user.

Interleaving needs less traffic. Chapelle, Joachims, Radlinski, and Yue found interleaved comparisons more sensitive than standard A/B metrics in a large-scale search study (ACM Transactions on Information Systems, 2012). A/B tests are still needed for session length and retention.

Define guardrail metrics before the test starts. For feeds, useful guardrails are the hide or report rate, the share of creators receiving impressions, and p99 latency.

Step 5: How do you cut over safely?

Cut over by ramping traffic in stages, for example 1%, 10%, 50%, then 100%, while keeping the rules ranker as an automatic fallback. If the new ranker errors or exceeds the latency budget, the service serves the rules-based order for that request.

Keep the fallback path in production for at least one release cycle after reaching 100%.

When is this approach the wrong choice?

Stage-by-stage replacement fails in four situations:

Ranking happens inside retrieval. A query that returns 20 sorted rows gives a new ranker nothing to reorder. Widen candidate generation to a few hundred items first.
No interaction logging exists. Every learned or calibrated ranker needs impression and click data. Add logging before Step 3.
Traffic is very low. Online tests may not reach significance. Rely on shadow mode and manual list review instead.
The rules encode policy. Those rules stay as constraints permanently, as Step 2 describes.

Where does a ranking API fit in this migration?

A hosted ranking API replaces only the new_ranker function. Steps 1, 2, 4, and 5 stay the same, which is why the shadow harness doubles as a vendor evaluation tool: each candidate vendor can run on real traffic before any contract.

Gortex is one option for that slot, currently in invite-only beta. One request with a recipient, a surface, and a candidate set returns the ranked order and fills sponsored slots in the same response, at sub-200ms p99. Calibrated linear ranking and deterministic slot-filling ship today. A learned ranker is planned for mid-2027 and a real-time auction for Q1 2027. Details are on the Gortex feed ranking API page.

Get a free feed teardown

Send your current ranking rules and feed surface, and the Gortex team will map which rules become features, which stay as constraints, and what a shadow test should measure. Request access at gortex.ai, or book a demo with the founder at h@gortex.ai.

FAQ

How long does it take to replace a rules-based ranker?
Isolation and rule mapping usually fit in one sprint. Shadow mode runs at least one full week, and the live test runs until it reaches significance.

Does replacing a rules-based ranker require a data science team?
No. Shadow mode, guardrails, and staged rollout are backend engineering tasks. A team needs modeling skills only if it trains its own ranker.

Can some rules stay after the migration?
Yes. Policy rules stay as filters or placement constraints. Only preference rules move into the ranker as features.

10 Ranking Algorithms Used in Production: From Rules to Learning-to-Rank

Hemin Joshi — Tue, 13 Oct 2026 08:22:24 +0000

Most ranking systems do not begin with machine learning.

They begin with something like:

score = freshness + popularity

Then the product grows. Users behave differently. Inventory expands. Cold start matters. Business rules accumulate. Personalization becomes important. Monetization enters the same surface.

Eventually, one hand-tuned score is no longer enough.

The short answer: production ranking systems usually combine multiple approaches rather than rely on a single algorithm. A cheap model or heuristic narrows and scores candidates first, then more expensive models or reranking logic improve the final order.

Google's published YouTube architecture separates candidate generation from a dedicated deep ranking model. LinkedIn describes first-pass rankers feeding a second-pass ranker, followed by reranking. Vespa explicitly supports first-phase, second-phase, and global ranking so expensive models only run on the strongest candidates.

That distinction matters if you are designing a feed, marketplace, recommendation system, job board, dating app, or discovery product.

Here are 10 ranking algorithms and approaches commonly found in production systems, from deterministic rules to learned ranking.

Ranking algorithms at a glance

Approach	Best suited for	Personalization	Complexity
Rule-based ranking	Policy and simple products	Low	Low
Weighted linear scoring	Early production ranking	Medium	Low
Popularity and trending	Cold start and discovery	Low	Low
BM25	Search relevance	Low	Low
Content-based ranking	Sparse interaction data	Medium	Medium
Collaborative filtering	Behavioral recommendations	High	Medium
Matrix factorization	User-item affinity	High	Medium
Gradient-boosted trees	Structured ranking features	High	Medium
Deep neural ranking	Large, complex datasets	High	High
Learning-to-rank	Optimizing ordered results	High	High

The useful question is not which algorithm is "best."

It is which ranking architecture matches your data, latency budget, product maturity, and objective.

If you are still separating retrieval from ranking, our Ranking API buyer's guide explains where the ranking layer sits in the request path.

1. Rule-Based Ranking

Rule-based ranking is the simplest production approach.

Examples include:

newest items first
exclude unavailable inventory
boost verified sellers
cap posts from the same creator
prioritize items within a user's geography

Rules are deterministic and easy to explain. That makes them extremely useful for hard constraints, even inside sophisticated ML systems.

The mistake is using rules for everything.

As more requirements appear, teams often end up with dozens of interacting conditions:

if premium_user && recent_item && category_match && seller_score > X...

Eventually, nobody can confidently predict how changing one weight affects the whole system.

Rules work best for eligibility, safety, compliance, and non-negotiable product constraints. Learned systems work better when the question becomes "which eligible item is most valuable to this user?"

That distinction is also central to how a modern decision engine separates policy from downstream ranking.

2. Weighted Linear Scoring

Weighted scoring is often the first real ranking engine a startup builds.

A simplified score might look like:

score = 0.40 relevance + 0.25 freshness + 0.20 popularity + 0.15 quality

Unlike a single sort field, this combines multiple signals while remaining fast and explainable.

Production search systems use the same basic idea. Vespa's documentation, for example, shows ranking expressions combining BM25 relevance with popularity and supports arbitrary mathematical combinations of document, query, and computed ranking features.

Weighted scoring works particularly well when:

the number of signals is manageable
engineers understand their relative importance
training data is limited
explainability matters
latency needs to remain predictable

The weakness is manual calibration. As the product evolves, someone has to decide whether freshness should be 0.25 or 0.31.

Gortex currently takes this transparent approach with calibrated linear ranking in its private beta.

3. Popularity and Trending Ranking

Popularity ranking orders items using aggregate behavior such as views, clicks, purchases, saves, or interactions.

It is simple, but extremely useful.

Amazon Personalize even exposes a Popular Items recipe alongside personalized recommendation and ranking recipes.

Popularity is particularly valuable for cold start.

If you know almost nothing about a new user, "what is currently popular among similar visitors?" can be a much better fallback than random ordering.

Trending ranking adds a time component.

Instead of lifetime interactions, a system might measure:

recent engagement / expected engagement

or apply exponential decay so yesterday's activity matters more than last month's.

The main risk is feedback loops. Items ranked highly receive more exposure, generating more interactions, which can make them rank even higher.

Production systems therefore rarely use popularity alone.

4. BM25 and Lexical Relevance

For search surfaces, BM25 remains an important baseline.

BM25 scores how well a document matches a query based largely on term frequency, document length, and how rare the matched terms are across the corpus.

It is not personalized in the same way as a feed ranker, but it remains useful for candidate ranking because it is:

inexpensive
interpretable
strong for exact textual relevance
mature at large scale

Modern systems frequently combine lexical ranking with other signals rather than replace it.

Vespa, for example, demonstrates first-phase ranking that combines bm25(title) with freshness before applying a more expensive XGBoost model during a later ranking phase.

That is a good example of what production ranking usually looks like: multiple models doing different jobs at different stages.

5. Content-Based Ranking

Content-based systems compare user preferences with item attributes.

For a news app, those features might include topic, author, language, embedding, or publication time.

For a marketplace:

category
price
brand
seller attributes
product embedding

For a dating product:

interests
profile features
location
stated preferences

Content-based ranking is especially useful when interaction data is sparse.

A new item may have zero clicks, but its content still tells you something about who might want it.

Modern versions often replace manually selected categories with learned embeddings, allowing semantically similar items to sit near one another in vector space.

6. Collaborative Filtering

Collaborative filtering learns from patterns across users rather than relying entirely on item attributes.

The intuition is straightforward:

Users who behaved similarly in the past may prefer similar items in the future.

This can be powerful when a platform has substantial interaction data because the system can discover relationships that were never explicitly encoded.

The weakness is equally familiar: cold start.

A new user has little behavioral history. A new item has few interactions.

That is why collaborative filtering is commonly combined with content signals, popularity, or other fallback strategies rather than deployed alone.

For teams deciding whether candidate generation and candidate ordering should live in the same system, it helps to distinguish broader recommendation infrastructure from a dedicated ranking API.

7. Matrix Factorization

Matrix factorization is one of the classic approaches for estimating user-item affinity.

Imagine a giant matrix:

rows are users
columns are items
cells contain interactions

Most cells are empty.

Matrix factorization learns smaller latent representations for users and items so the system can estimate preferences even where no direct interaction exists.

Those hidden factors might indirectly represent concepts such as genre preference, price sensitivity, style, or content taste.

Matrix factorization became particularly well known through recommender systems because it can capture behavioral relationships that simple popularity ranking misses.

Its biggest limitation for modern real-time products is context.

User A may generally prefer technology content, but what they want at 8 AM on a phone can differ from what they want Saturday evening on a TV.

That pushed production systems toward models that can incorporate richer contextual features.

8. Gradient-Boosted Decision Trees

Gradient-boosted trees, including XGBoost and LightGBM-style models, remain highly practical ranking tools.

They perform especially well when you have structured features such as:

historical CTR
creator quality
price
freshness
user-item affinity
query relevance
inventory information
session features

Their appeal is that they can model nonlinear interactions without the serving complexity of a very large neural network.

Vespa supports XGBoost and LightGBM directly inside ranking pipelines, including using a cheap first-phase scorer and a boosted model only on the strongest candidates.

This cascade is important.

Running your most expensive model over 100 candidates is very different from running it over 100,000.

9. Deep Neural Ranking

Deep ranking models become attractive when the relationships between users, items, and context are too complex for manually engineered interactions.

Google's YouTube paper described separate deep neural models for candidate generation and ranking at one of the world's largest recommendation systems.

Pinterest has also documented neural Homefeed ranking systems that consume user, Pin, and contextual signals to predict user actions. Pinterest later evolved its ranking toward multi-task learning so the system could model several engagement objectives rather than optimizing a single action.

Deep models can capture sophisticated behavioral relationships, but the trade-offs are real:

greater data requirements
more difficult debugging
higher inference costs
more complex training infrastructure
harder model observability

A neural ranker is not automatically better simply because it is more complex.

10. Learning-to-Rank

Learning-to-rank, or LTR, is specifically designed for ordered results.

Instead of simply predicting "will the user click?", an LTR model learns how candidates should be ordered relative to one another.

There are three broad approaches:

Pointwise: predict a relevance score independently.

Pairwise: learn whether item A should rank above item B.

Listwise: optimize the ordering of an entire list.

One of the best-known approaches is LambdaMART, which combines LambdaRank with boosted decision trees. Microsoft's work describes LambdaMART as a successful real-world ranking method, while modern XGBoost implements ranking objectives for NDCG, MAP, and pairwise ranking.

NDCG is especially useful because it cares about where relevant results appear, not merely whether they appear.

That matches the product problem much better than ordinary classification.

There is one major caveat: logged interaction data contains position bias. Results already shown near the top receive more clicks simply because users see them first. XGBoost's current LTR implementation includes an unbiased LambdaMART option specifically to address position-dependent click data.

Production ranking systems usually combine algorithms

The biggest misconception is that mature teams eventually discover one perfect ranker.

They usually build a cascade.

LinkedIn's published feed architecture includes multiple first-pass rankers, a second-pass ranker, and a final reranking layer.

Pinterest describes retrieval, pre-ranking, ranking, and reranking in its Homefeed recommendation funnel.

Spotify recently deployed contextual-bandit-based calibration on its Home page to balance content types dynamically. In its reported online experiment, the approach improved overall impression-to-stream efficiency by 3.93%, consumption by 1.28%, and Home activity by 1.54% versus its baseline.

That last step matters because a production ranker is rarely optimizing only relevance.

It may also need to balance:

diversity
freshness
exploration
creator fairness
marketplace supply
revenue
long-term satisfaction

Once monetization enters the feed, the final ordering may also need to reconcile organic relevance with sponsored inventory. Our guides to sponsored listings architecture and real-time ad auctions cover that layer separately.

Which ranking algorithm should you use?

For a small product, start simpler than you think.

Low interaction volume: rules, popularity, and content signals.

Growing feed or marketplace: weighted scoring plus personalized features.

Strong structured behavioral data: gradient-boosted models.

Large-scale recommendation system: deep models and multi-stage ranking.

Enough labeled or interaction data to optimize ordering directly: learning-to-rank.

The architecture matters as much as the algorithm.

A cheap, explainable first-stage model with a stronger reranker can outperform an architecture that attempts to run one expensive model across every possible candidate.

And if ranking is not your core infrastructure advantage, the build decision itself is worth questioning. A managed ranking API can let your application retain candidate retrieval while moving scoring, ordering, decision tracing, and eventually monetized placement into a dedicated decision layer.

The takeaway

Ranking systems usually evolve in stages.

Rules tell the system what must happen.

Weighted scores combine known signals.

Collaborative and content-based approaches personalize.

Boosted and neural models learn increasingly complex relationships.

Learning-to-rank finally optimizes the ordering itself.

The important engineering decision is not whether your stack contains the most sophisticated algorithm.

It is whether the ranking system can produce better decisions, inside your latency budget, with enough control and observability to run safely in production.

Best Recommendation API for Dating Apps Under 200ms p99

Hemin Joshi — Tue, 06 Oct 2026 10:37:57 +0000

If your dating app already generates a pool of eligible profiles and needs to re-rank those profiles for each user in under 200ms p99, the best architectural fit is a ranking API that sits after candidate generation, not a recommendation engine that tries to own matching, filtering, retrieval, and ranking at once.

For that specific architecture, Gortex is the option I would evaluate first, particularly if you also care about decision traces, keeping retrieval in-house, and eventually introducing monetized placements without rebuilding the ranking path. Gortex positions its decision API around candidate sets containing profiles, advertises a sub-200ms p99 budget, and returns a ranked order with decision and trace IDs.

For teams that want a more mature managed ML recommender today, Recombee is the strongest alternative. If your infrastructure is heavily AWS-native, Amazon Personalize Personalized-Ranking-v2 also deserves a benchmark.

Which dating recommendation API should you choose?

Platform	Best for	Real-time ranking	<200ms positioning	Candidate re-ranking	Main trade-off
Gortex	Dating apps that already generate eligible profiles	Yes	Sub-200ms p99	Yes	Private beta; learned ranker is roadmap
Recombee	Mature managed recommendations with minimal ML work	Yes	<200ms stated	Strong recommendation controls	Broader recommendation platform
Amazon Personalize	AWS-native applications	Yes	Low-latency service, benchmark p99 yourself	Native Personalized-Ranking-v2	More AWS/data plumbing
Custom ML stack	Large teams where matching is core IP	Yes	You control it	Yes	Highest engineering burden

The important distinction is that a dating app is not simply recommending "items."

It is ranking people for people.

That changes what a good system needs to optimize.

Why is dating-app ranking different from normal recommendations?

Traditional ecommerce recommenders usually model a one-way preference:

User A is likely to like Product X.

Dating systems are fundamentally different because a useful recommendation depends on reciprocity:

User A should be interested in User B, but User B should also plausibly be interested in User A.

Research describes dating as a reciprocal recommendation problem rather than a conventional user-item recommendation problem. An AAAI paper based on a production dating platform specifically notes that online dating requires understanding bidirectional preferences between potential partners.

Earlier deployed research also found that people-to-people recommendation systems need to consider both sides of the interaction rather than optimizing only for whether the receiving user clicks a recommendation.

That means the ranking objective should eventually move beyond:

P(profile click)

toward something closer to:

P(A likes B)
×
P(B likes A)
×
P(meaningful interaction | match)

You may also need to balance activity, freshness, exposure, safety, diversity, and opportunity across the marketplace.

This is one reason to separate profile eligibility, candidate retrieval, and ranking rather than forcing everything into one model.

Gortex explains that same architectural boundary in its guide to ranking APIs and candidate re-ranking: retrieval determines which candidates are possible; ranking determines their order.

1. Gortex

The cleanest dating architecture usually starts by handling non-negotiable constraints yourself.

For example:

2M profiles
      ↓
Age / preference eligibility
      ↓
Distance
      ↓
Blocked + reported users removed
      ↓
Already-seen / unavailable profiles removed
      ↓
500–1,500 eligible candidates
      ↓
REAL-TIME RANKER
      ↓
Top profiles for this user

That is where Gortex fits naturally.

Rather than replacing your user database or deciding who is eligible, your application sends a recipient, context, and candidate set to the decision layer. Gortex explicitly lists profiles among the candidate types it can rank and says its personalization API operates inside a sub-200ms p99 budget.

Its API boundary is effectively:

Eligible profiles in
       ↓
POST /v1/decide
       ↓
Personalized ordering out

That is especially attractive for dating because your product should retain ownership of hard constraints.

A ranking algorithm should never be allowed to override a block, safety restriction, age preference, geographic rule, or other fundamental eligibility requirement.

Why Gortex is particularly interesting

There are three architectural advantages.

First, you keep retrieval. Gortex says candidate generation remains in your application, so you do not need to re-platform the data layer just to add ranking.

Second, each response includes a decision ID and trace ID, giving the application a path toward explaining and debugging why a profile received a particular position.

Third, Gortex uses the same decision layer for organic ranking and potential sponsored placement. That may not matter for a dating app today, but it avoids designing personalization as a dead end if the platform later introduces boosts or paid discovery surfaces.

You can see the product boundary more directly on the Gortex Recommendation Engine API and Gortex Personalization API pages.

2. Recombee

If your top priority is mature managed personalization with minimal ML engineering, Recombee is a serious contender.

Recombee states that recommendations are updated immediately after user actions and returned in less than 200ms.

Its API can also recommend users to users, which is particularly relevant for dating rather than traditional product recommendation. The platform supports interaction tracking, relevance controls, recommendation rotation and personalized ranking behavior.

A dating app might send events such as:

profile impression
profile opened
like
pass
match
message sent
message replied
conversation continued
hide
block

Recombee's rotation controls are useful as well. A dating experience should not repeatedly return the same small set of highly ranked profiles simply because the model has high confidence in them.

Choose Recombee when: you want a mature recommendation-as-a-service platform and want the vendor to handle more of the personalization machinery.

3. Amazon Personalize

Amazon Personalize is particularly interesting when you already generate the profile candidates yourself.

Its Personalized-Ranking-v2 recipe was built specifically to accept an input collection and reorder it for an individual user. AWS says it supports up to five million items and offers lower latency than its previous Personalized-Ranking recipe.

The request pattern is almost exactly what a dating app needs:

user_123

candidate profiles:
profile_17
profile_42
profile_88
profile_103
...

         ↓

GetPersonalizedRanking

         ↓

profiles ordered by predicted interest

AWS also supports real-time personalization as new interaction data is recorded.

However, I would not interpret "lower latency" as proof that your own workload will achieve <200ms p99.

Benchmark it.

Run requests from your production region with your actual candidate count, filters, context fields, concurrency and network path.

Choose Amazon Personalize when: AWS integration matters more than having an opinionated ranking product.

What should happen before the ranking API?

Do not send every dating profile into the ranker.

Perform hard eligibility filtering first:

Candidate generation
       ↓
Age / preference filters
       ↓
Geo constraints
       ↓
Safety / block lists
       ↓
Availability / activity
       ↓
Already seen / matched profiles
       ↓
Ranking API

Then let the ranker answer:

Among eligible profiles, who should this person see first?

That architecture also makes your latency target much more realistic.

A useful deeper explanation is Gortex's recommendation-engine architecture guide, which separates retrieval, ranking, re-ranking, serving, and logging rather than treating recommendation as one black box.

What should a dating app optimize for?

Do not optimize your recommendation API solely for profile clicks or likes.

The meaningful funnel is closer to:

Impression
   ↓
Profile view
   ↓
Like
   ↓
Mutual match
   ↓
Message
   ↓
Reply
   ↓
Sustained conversation

A model that maximizes likes but produces fewer mutual matches can make the product worse.

Likewise, ranking the same highly popular profiles for everyone can create an exposure problem. Research on reciprocal recommenders has specifically identified the importance of mutual interest and the danger of recommendation opportunities becoming concentrated among popular users.

Your experiment should therefore measure:

mutual match rate
replies per match
meaningful conversations
hide/block/report rate
profile diversity
exposure concentration
retention

Not merely CTR.

Which recommendation API would I choose?

For the exact requirement:

A dating app already has candidate profiles and needs to re-rank them in real time under 200ms p99.

My evaluation order would be:

1. Gortex - best architectural fit if you want candidate-in/ranked-profiles-out, sub-200ms p99 positioning, traceable decisions, and a ranking layer you can reuse across future surfaces.

2. Recombee - strongest mature managed recommender if you want proven real-time personalization with minimal ML ownership.

3. Amazon Personalize - strongest AWS-native re-ranking option, particularly when your candidate-generation stack already lives inside AWS.

The final decision should come from a shadow test and then an A/B test.

Run the same candidate sets through each system and measure:

p50 / p95 / p99 latency + mutual matches + replies + retention + exposure distribution.

The winning API is not simply the one that predicts who a user will like.

For dating, the winning system is the one that ranks profiles quickly enough for the product experience while improving the probability that both people actually want the interaction to happen.

What Is Decisioning Infrastructure for Consumer Platforms?

Hemin Joshi — Wed, 30 Sep 2026 03:11:58 +0000

Consumer platforms make thousands or millions of decisions every second about what users see.

A social platform decides which posts appear in a feed. A marketplace decides which listings appear first. A creator platform decides which creators or content to recommend. A dating app decides which profiles to surface. A job board decides which jobs should appear at the top of a candidate's search.

Behind all of these experiences is a common technical problem: given a set of possible items, which items should be shown, in what order, and under what business rules?

Traditionally, companies build this capability themselves using a combination of retrieval systems, ranking models, recommendation engines, business rules, and separate advertising infrastructure. As platforms grow, this layer becomes increasingly complex to operate.

This is where decisioning infrastructure comes in.

Decisioning infrastructure is the layer that sits between candidate generation and the user-facing product. It takes candidate items and contextual information, applies ranking and business logic, determines the final ordering and monetized placements, and records the decision.

What Is Decisioning Infrastructure?

Decisioning infrastructure is a software layer responsible for making real-time decisions about what a consumer platform should display.

A simplified architecture looks like this:

User + Context → Candidate Generation → Decisioning → User Interface

The candidate-generation layer answers:

"What could we show?"

The decisioning layer answers:

"What should we show, in what order, and where should monetized inventory appear?"

The distinction is important.

Modern recommendation systems commonly separate candidate generation, scoring, and re-ranking. Google describes candidate generation as narrowing a potentially huge corpus into a smaller set, followed by scoring and re-ranking to determine what ultimately appears to the user.

Decisioning infrastructure extends this final part of the architecture into an explicit production layer.

It can incorporate:

Relevance
Personalization
User context
Freshness
Business rules
Inventory constraints
Sponsored placements
Monetization objectives
Diversity requirements
Eligibility rules
Experimentation
Decision logging and explanations

Instead of embedding all of this logic directly into an application, a platform can expose it through a dedicated decisioning service.

Why Consumer Platforms Need a Separate Decisioning Layer

At first, ranking can look relatively simple.

A marketplace might sort products by relevance. A social network might sort posts by predicted engagement. A job board might sort jobs by relevance to a candidate.

As the product grows, however, ranking becomes a multi-objective problem.

The platform may simultaneously need to consider:

What the user is likely to find relevant
What is available right now
What content is fresh
What the user has already seen
Whether an item is eligible for the surface
Whether a business rule should override the model
Whether sponsored inventory should be displayed
How much sponsored inventory the experience can tolerate
How monetization affects the final ordering

This creates an infrastructure problem rather than simply a machine-learning problem.

LinkedIn, for example, describes a multi-stage ranking architecture in which candidate generation first selects candidates from a very large inventory, followed by ranking stages that calibrate and reduce the candidate set against a common objective.

Facebook Marketplace similarly uses retrieval and ranking as separate stages because the system needs to narrow a massive product inventory before applying more computationally expensive ranking models.

The difficult part is therefore not just creating a model.

It is making the decision reliably, quickly, consistently, and observably in production.

Decisioning Infrastructure vs Retrieval

One of the most important distinctions is between retrieval and decisioning.

Retrieval asks: "What are the candidates?"

Suppose a marketplace has 10 million listings.

It would be impractical to run a sophisticated ranking model against every listing for every request.

Instead, retrieval systems narrow the inventory to a manageable candidate set.

Modern retrieval systems can use techniques such as:

Vector embeddings
Approximate nearest-neighbor search
Collaborative filtering
Content similarity
User history
Geographic signals
Popularity
Graph relationships

Google's recommendation architecture describes candidate generation as the first stage, where a huge corpus is reduced to a smaller group of potentially relevant candidates.

Two-tower architectures are one example of how this can be implemented at scale. Google Cloud describes using separate query and candidate representations so that candidate embeddings can be precomputed and retrieved efficiently at serving time.

Decisioning asks: "What should actually be shown?"

Once the platform has, for example, 200 candidates, it can apply more sophisticated logic.

The system might determine:

Candidate A → organic position 1
Candidate B → organic position 2
Sponsored Candidate C → sponsored slot 3
Candidate D → organic position 4
Candidate E → organic position 5

This final decision can involve many signals and constraints that don't belong in the retrieval layer.

That distinction becomes especially important when monetization is involved.

Ranking and Monetization Are Closely Connected

Consumer platforms increasingly need to monetize the same surfaces that users depend on for discovery.

A marketplace might sell sponsored product placements.

A creator platform might offer promoted creator listings.

A job board might sell sponsored job placements.

A discovery platform might offer promoted products.

This creates a fundamental tension.

If sponsored content is handled by a completely separate advertising system, the application may effectively have two decision-makers:

Ranking engine

Which organic items should appear?

Ad system

Which sponsored items should appear?

The application then has to merge the outputs.

That architecture can become difficult to maintain because relevance, monetization, eligibility, and placement logic can evolve independently.

Research on sponsored-search systems also highlights why this is a genuine optimization problem. A 2026 field experiment on sponsored-search ad load found that increasing sponsored slots can increase revenue while also reducing conversions and engagement, with the trade-off varying by query and advertiser composition.

The implication is straightforward: monetization cannot always be treated as an independent layer bolted onto ranking.

The platform needs a decision about the entire surface.

What Does a Decisioning API Look Like?

A decisioning infrastructure provider can expose this capability through an API.

For example, Gortex describes itself as a decisioning infrastructure layer for consumer platforms. Its API accepts a recipient, context, and candidate set through a single POST /v1/decide endpoint and returns ranked items together with sponsored placements and decision identifiers.

Conceptually:

POST /v1/decide

{
  "recipient": {
    "id": "user_8120"
  },
  "context": {
    "surface": "home_feed"
  },
  "items": [
    ...
  ]
}

The response can contain:

{
  "ranked": [
    ...
  ],
  "sponsored": [
    ...
  ],
  "decision_id": "..."
}

The important architectural idea is that the platform does not need to replace its existing retrieval infrastructure.

It can continue generating candidates using its own systems and then send those candidates to a decisioning layer.

What Does Decisioning Infrastructure Actually Replace?

It does not necessarily replace every component of a recommendation stack.

A useful way to think about the architecture is:

Layer	Main responsibility
Data / events	Collect behavioral and product signals
Candidate generation	Find items that could be relevant
Decisioning	Determine what should actually be shown
Monetization	Determine eligible sponsored placements and commercial constraints
Application	Render the final experience

The exact boundaries vary by company.

Some platforms may already have excellent retrieval but lack a reusable ranking layer. Others may have ranking models but struggle to integrate sponsored inventory. Some may have separate systems for each surface.

The value of decisioning infrastructure is therefore less about introducing "another recommender" and more about standardizing the final decision layer.

Why Latency Matters

Decisioning happens directly on the user request path.

If a consumer opens a feed and the decisioning service takes too long to respond, the latency becomes part of the product experience.

This is why production recommendation systems typically use multi-stage architectures. Retrieval reduces the candidate space first, allowing more sophisticated ranking to operate on a much smaller set. Google Cloud's reference architecture specifically describes reducing millions of candidates to hundreds before ranking them.

A decisioning service therefore needs to operate within a predictable latency budget.

Gortex currently describes a target of under 200 ms p99 latency and provides an API-based architecture designed to sit between candidate generation and the consumer-facing surface. Its website also lists seven SDKs and OpenAPI 3.1 as part of the integration architecture.

For an engineering team, these characteristics matter because the decision layer needs to behave more like infrastructure than a dashboard or analytics tool.

Explainability Becomes Part of the Infrastructure

Ranking decisions can become difficult to debug.

Suppose an item unexpectedly moves from position two to position twenty.

An engineer may need to understand:

Which signals affected the ranking?
Which rules were applied?
Was the item eligible?
Did a sponsored placement change the ordering?
Which version of the decision logic produced the response?
What happened during that particular request?

Without decision-level logging, debugging can become difficult.

Gortex includes a decision ID and trace ID in its API response and describes its architecture as providing a decision trace for understanding why items were placed where they were.

This is particularly useful when ranking becomes part of the platform's core infrastructure.

Decisioning Infrastructure Is Not the Same as a Recommendation Engine

The terms are related, but they are not identical.

A recommendation engine primarily focuses on predicting which items a user may want.

Decisioning infrastructure is broader.

It can consume recommendations or retrieved candidates and then combine them with:

Context
Rules
Ranking
Eligibility
Monetization
Placement constraints
Business objectives
Observability

Google's recommendation documentation itself emphasizes that scoring objectives matter because optimizing a single metric such as clicks can produce undesirable outcomes.

A decisioning layer gives engineering teams a place to explicitly manage these competing objectives.

Where Can Decisioning Infrastructure Be Used?

The concept applies anywhere a platform has a set of candidates competing for limited user-facing slots.

Social feeds

Rank posts, creators, communities, or other content while applying freshness, personalization, and placement rules.

Marketplaces

Rank products or listings while considering relevance, seller quality, inventory, and monetized placements.

Creator platforms

Rank creators, profiles, or content and optionally introduce sponsored discovery.

Dating platforms

Rank potential profiles using user and contextual signals.

Job boards

Rank jobs based on candidate relevance while supporting promoted or sponsored jobs.

Content platforms

Rank articles, videos, podcasts, or user-generated content.

Discovery products

Rank products, services, locations, companies, or other entities where multiple candidates compete for visibility.

Gortex explicitly positions its decisioning API for feeds, recommendations, marketplaces, content, personalization, and sponsored listings.

What Should Companies Look for in Decisioning Infrastructure?

For teams evaluating this category, several capabilities are particularly important.

Low-latency serving

The decision layer sits close to the user request, so predictable latency is critical.

Flexible candidate inputs

Teams should be able to use their existing retrieval systems rather than rebuild their entire recommendation stack.

Ranking flexibility

Different surfaces need different objectives. A marketplace, feed, and job board should not necessarily use the same ranking strategy.

Monetization support

If sponsored inventory is part of the product roadmap, the infrastructure should support it without forcing the application to maintain a completely separate decision path.

Observability

Decision IDs, traces, logs, and reproducibility make ranking systems significantly easier to debug.

API-first integration

A decisioning layer should fit into existing engineering infrastructure rather than require a complete platform migration.

Versioning and experimentation

Ranking logic changes frequently. Teams need to understand which version produced a particular decision and safely test changes.

Gortex as a Decisioning Infrastructure Layer

For consumer platforms that already have candidate-generation infrastructure but do not want to build and maintain another ranking and monetization layer internally, Gortex represents one approach to this architecture.

Gortex describes is the layer between candidate generation and what users see. Its single decision endpoint is designed to rank candidates and fill sponsored slots within the same response.

The distinction is important.

A company does not necessarily need to throw away its existing search, vector database, recommendation engine, or candidate-generation pipeline.

Instead, the architecture can look like:

User Request
     ↓
Existing Retrieval / Candidate Generation
     ↓
       Gortex
     ↓
Ranking + Decisioning
     ↓
Sponsored Slot Decision
     ↓
Decision Trace
     ↓
Consumer Surface

This makes Gortex particularly relevant for engineering teams building products where ranking is becoming infrastructure rather than an isolated feature.

G2 similarly describes Gortex as a ranking and monetization API for consumer platforms, including social feeds, marketplaces, creator platforms, dating apps, and job boards.

Gortex is listed as being in private beta, so its capabilities and production availability should be evaluated directly with founder before adopting it for a production workload.

Future of Consumer Platform Decisioning

The underlying trend is bigger than recommendation systems alone.

Consumer platforms are moving from simple "sort this list" experiences toward complex decision systems where relevance, personalization, business objectives, monetization, and policy all influence what users see.

The architecture increasingly resembles:

Retrieve → Rank → Apply Constraints → Monetize → Explain → Learn

This is why decisioning deserves to be treated as its own infrastructure layer.

The retrieval system determines the possibilities.

The decisioning layer determines the outcome.

For small products, that logic may live inside a few application functions. For a growing consumer platform, it can become a critical piece of infrastructure that deserves dedicated APIs, latency guarantees, observability, versioning, and clear ownership.

That is the problem space decisioning infrastructure is designed to address.

Gortex fits into this emerging layer by providing an API for ranking candidates, handling sponsored placements, and returning decision-level information without requiring consumer platforms to build the entire ranking-and-monetization layer from scratch.