Build a TikTok-Style Short-Form Video Feed Algorithm with NeuronSearchLab

If you are building a TikTok-style feed, a Reels-style surface, a Shorts-style experience, or any personalized For You feed, the core loop is the same: ingest video interactions, learn a representation of each user, re-rank a candidate pool, repeat. NeuronSearchLab gives you that loop end-to-end: contexts, events, ranking pipelines, rules, training, model promotion, analytics, and explainability, so you can ship a short-form video recommendation algorithm without building the plumbing yourself.

This guide walks through a TikTok-style short-form feed setup step by step.

The setup flow happens in the NSL admin console. Where the console has an admin API equivalent, the route is listed in the collapsible block at the end of the section. Serving traffic is separate: clients use the Core API or SDK for recommendations and event tracking.

1. Define a context

A context is a surface where recommendations are served: your TikTok-style For You feed, a "you may also like" rail, a profile page. Each context can have its own ranking pipeline and its own rules, so the same catalogue powers very different experiences without you forking your data.

Open Context in the console and create a new context for the short-form video feed. Most teams start with one For You feed context and add more surfaces, such as comments rails, related-content shelves, or group feeds, as the product grows.

In the context editor, set:

• Context Name: a human-readable name, such as "Short-form home feed".
• Context Key: the stable key your app will use.
• Context Type: the product surface, such as a homepage feed.
• Recommendation Type: the model family for this surface.
• Retrieval Architecture: the retrieval approach, such as Content Embedding, Two-Tower, Sequential (gSASRec), or Generative (Semantic IDs).

API equivalents

• POST /api/context/create: create a context
• GET /api/context: list contexts
• PATCH /api/context/:id: update a context

2. Configure your event types

Events are the signal your model learns from. Open the Events section of the console and define the interactions you care about, giving each one a weight from 0 to 100. The weight tells the platform how much that signal should move the user's representation.

A useful starter set for a short-form feed:

• impression: low weight, fires when an item is shown.
• watch: medium weight, fires when the user begins watching.
• complete: high weight, fires when the user watches to the end or loops.
• like: high weight, explicit positive signal.
• share: very high weight, the strongest positive signal you'll get.
• skip or swipe_away: low or zero-value signal, useful for a TikTok-style ranking algorithm that needs to learn what not to keep showing.

You can tune these later. Saved values are read when a new training or fine-tuning run starts, so completed jobs are not rewritten, but future runs use the latest values.

Events also owns the training templates used to start runs. Build or select a template, check that the required signals meet the template threshold, then start training from the same page.

API equivalents

• GET /api/events/event-types: list event types with counts
• POST /api/events/event-types: create an event type
• PUT /api/events/event-types/:id: update an event type
• DELETE /api/events/event-types/:id: delete an event type
• POST /api/events/save-values: bulk save event names and weights
• GET /api/events/templates: list training templates
• POST /api/events/templates: create a training template
• PUT /api/events/templates/:id: update a training template
• DELETE /api/events/templates/:id: delete a training template

3. Load your catalogue

Catalogue feed sources are managed in Catalogue Ingest. Add a source pointing at your vertical video catalogue, then either run it on demand or let the scheduler pick it up. The console supports Video/MRSS, RSS/Atom, Google Shopping, Shopify, JSON endpoint, and custom XML sources.

Each item carries descriptive text that drives its embedding, so make those descriptions rich: titles, captions, transcripts, tags, topics. The more semantically loaded the text, the better the personalization downstream.

Use Catalogue Ingest for source setup, schedule, status, and manual runs. Use Items when you need item search and item-detail views to confirm what is in the catalogue or inspect a single record.

API equivalents

• GET /api/catalogue-ingest: list ingest configs
• POST /api/catalogue-ingest: create an ingest config
• PATCH /api/catalogue-ingest/:id: update an ingest config
• DELETE /api/catalogue-ingest/:id: delete an ingest config
• POST /api/catalogue-ingest/:id/trigger: run an ingest on demand
• GET /api/items/search or POST /api/items/search: search the catalogue
• GET /api/items/:itemId: inspect a single item

4. Build a ranking pipeline

A pipeline is the sequence of stages that turns a pool of candidates into a ranked For You feed. For a TikTok-style feed algorithm, this is where broad retrieval, model scoring, business rules, and final output shaping come together. The platform's pipeline stages are:

1. Candidate generation: pull a broad set of relevant items for the user.
2. Signals: enrich candidates with user, item, and interaction features.
3. Scoring: rank candidates using the trained model and item/user features.
4. Learned Reranker: apply an optional learned second-pass ranker.
5. Catalog Signals: add catalogue intelligence where configured.
6. LLM Reranker: apply an optional intelligence layer.
7. Rules Engine: apply business logic, including filters, boosts, and hard constraints.
8. Final Sort: produce the final ordering.
9. Output Shaping: trim or reshape the returned feed.

From Pipeline Config, create a pipeline, attach it to your context, and mark it active. Active context-specific pipelines take precedence; a global active pipeline acts as fallback.

Add rules where you need them

The Rules Engine section lets you express things the model should not have to learn: boosts, buries, filters, pins, caps, diversity constraints, deduplication, randomization, reorder rules, guaranteed top items, grouping, and weighted topic logic. For suppression-style behavior, use Filter to remove items or Bury to down-weight them. Rules are toggleable from the console, scoped to a context when needed, and ordered by priority.

Tune rerank controls

Rerank Controls is a separate per-context page. Click a context row, then set the global default or surface presets for search, results, and recommendations. Modes include off, balanced, and aggressive, with a configurable depth for how many candidates are re-scored.

API equivalents

• GET /api/pipelines: list pipelines
• POST /api/pipelines: create a pipeline
• GET /api/pipelines/:id: inspect a pipeline
• PATCH /api/pipelines/:id: update a pipeline
• DELETE /api/pipelines/:id: delete a pipeline
• GET /api/rules: list rules
• POST /api/rules: create a rule
• GET /api/rules/:id: inspect a rule
• PATCH /api/rules/:id: update a rule
• DELETE /api/rules/:id: delete a rule
• GET /api/rerank-controls?contextId=...: inspect rerank controls
• GET /api/rerank-controls: list rerank controls for all contexts
• PUT /api/rerank-controls: save rerank controls

5. Train and promote a model

Training is template-driven. In Events, pick or create a template, confirm the run target, then start a training job. If you are fine-tuning an existing model, start from Models, choose the model family or base version, and the console will take you back to Events with the fine-tune target preselected.

Use Model Training to track jobs, logs, metrics, and stop controls. Once a job produces a model package you like, use Models to approve and promote it:

• Approve marks the package ready.
• Promote deploys it to the serving endpoint.

Models also shows model families, versions, serving targets, active models, and registered models. If you are bringing your own model, register and manage it there.

API equivalents

• POST /api/training/start: start a training job
• POST /api/tenant-models/fine-tune: start a fine-tune
• GET /api/training-jobs: list training jobs
• POST /api/training-jobs/stop: stop a running job
• GET /api/training-jobs/logs/:jobName: fetch recent logs
• GET /api/training-jobs/metrics/:jobName: fetch final metrics
• POST /api/training-jobs/approve: approve a model package
• POST /api/training-jobs/promote: promote to the endpoint
• GET /api/training-jobs/endpoint: inspect the live endpoint
• GET /api/models: list registered models
• POST /api/models: register a model

6. Serve recommendations and close the attribution loop

Your client calls the recommendations endpoint through the SDK or Core API. Every TikTok-style For You feed response includes a request_id. The SDK captures that ID and attaches it to later trackEvent calls by default; if you are calling the API directly, pass the same request_id with every event you track from that response.

That ID is how the platform attributes a watch, click, or share to the ranking that produced it. Without it, your model still sees events, but analytics and training exports lose the clean join back to the served recommendation set.

1. client requests a feed for the user and context
2. response -> items + request_id
3. user watches an item to completion
4. client sends a `complete` event with the same request_id

Events are processed asynchronously, and the user's representation updates shortly after, so personalization compounds as the session continues.

API equivalents

• GET /v1/recommendations: request recommendations for a user and context
• POST /v1/events: track events, including request_id or requestId

7. Measure and explain

The console gives you several ways to inspect how the system is performing:

• Dashboard: headline numbers, summary cards, and top items at a glance.
• Analytics workbench: when the data analytics add-on is enabled, aggregate engagement, coverage, served requests, events, and breakdowns by preset, context, request, user, item, session, placement, model version, and pipeline version.
• Items: search the catalogue and drill into per-item analytics.
• Users: inspect a user's activity and recommendation journey.
• Top items: leaderboards by configured event.
• Item comparison: compare two items head-to-head.

And when a stakeholder asks "why did this item rank where it did?", Explainability returns the score breakdown for an item, with optional user and context inputs for the specific feed decision.

API equivalents

• GET /api/dashboard?period=7d: dashboard summary
• GET /api/analytics?preset=7d&context=...: aggregate analytics
• POST /api/analytics/query: run analytics workbench queries
• GET /api/analytics/items/:itemId: per-item analytics
• GET /api/analytics/users/:userId: per-user analytics
• GET /api/analytics/top-items?metric=events&event_id=...: top items
• GET /api/analytics/items/compare?item_a=...&item_b=...: head-to-head comparison
• GET /api/explain?item_id=...&user_id=...&context_id=...: score breakdown

Putting it together

That's the whole TikTok-style feed algorithm loop:

1. Context defines the surfaces.
2. Event types define the signals.
3. Catalogue Ingest brings in your content; Items lets you inspect it.
4. Pipeline Config, Rules Engine, and Rerank Controls define the ranking behavior.
5. Events starts training; Model Training tracks it; Models approves and promotes it.
6. The Core API or SDK returns recommendations with a request_id that events carry back.
7. Dashboard, Analytics, Items, Users, and Explainability make the system legible.

Start with one For You context, one pipeline, and the short-form video events that matter most. Once the loop is closing, with recommendations in, events back with their request_id, model retrained, and metrics moving, you can layer on additional contexts, sharper rules, and richer training templates with confidence that the foundation is sound.

Ready to build? Spin up a context, define your events, point an ingest at your catalogue, and let the loop do the rest.