Our Feed Features Explained
Here we give an overview of all feed features you will find on the Feed Builder page in 'mbd console.
Feed Types
3 types of feeds are configurable through Feed Builder.
For-you
For-you feed is a personalized feed, meaning that it recommends different feed content to different users (specified by the user_id input passed when calling the API), based on the user's previous interactions with different content. Our engine is trained on a wide range of interaction data available on chain, and predicts and recommends content that each individual user is most likely to interact with. Once a user interacts with a piece of content, our system picks up the new interaction in near real time, and updates the recommendations to the user accordingly.
For-you is the best feed to use for providing content relevant to individual users, thereby increasing your APP's engagement.
Trending
Trending is a content discovery feed, which uses recent user-content interaction data to predict what contetn is soon to receive a lot of attention and engagement across the system.
The trending content universe itself is not personalized for each user, but to keep the relevancy to individual users, our system has the ability to remember what content the user has already seen (through an impression_count
parameter) and avoid showing the same content to the user again. We also provide a configurable option (through show_interacted_items
) to hide content the user has already interacted with.
Popular
Popular is another type of content discovery feed, which returns a list of content that is already popular (ie receiving a lot of attention and interaction from users) in the system.
As with the trending feed, the popular feed can stop showing content that the user has seen or interacted with.
Feed Freshness
The feed freshness section contains parameters that that can keep the feed "fresh". This is very important as a stale feed affects the perceived quality of the feed as seen by the users.

Time Period
Time period allows you to specify to return only content created within the last n
days.
Since our system is trained to predict what a particular user is likely to interact with or what content in the system will receive a lot of interactions, the recommended content can be created longer in the past if the models think they are the best. Time period can be used if you would only want more recent content to be shown in your feed.
impression_count
Impression count allows you to specify the number of items returned by the API call to be considered "seen" by the current viewing user (specified by the user_id
in API call). For example, if impression_count is set to 5 when calling the API, the first 5 items in the returned list is considered seen by the user, and the items will not be included in future API responses.
Show / Hide Interacted Items
If a user has already interacted with an item, this means the user has already seen the item. However, whether the item should be included in the feed is not clear cut.
We took the opinion that interacted items should not be shown to the same user, and so by default interacted items are not returned in the API response for the user.
However, there is also a case to be made that users might like seeing the same content again, both because the user likely is interested in the content in the first place and doesn't mind seeing it again, or any new conversations surrounding the content might be of interest to the user. Show interacted items can be used as an option to allow the content to still be included in the feeds.
Filters
Filters narrows down the entire universe of recommendable content to exclude content with certain attributes. Use filters to make content more relevant to your users and the nature of your APP.
Inclusions
Inclusion type filters tells the system to include the content only if they are tagged with the specific labels or attributes.

Channels
Specify a list of channels (channel urls), so that only content from these channels will be returned
Author IDs
Specify to return only content from a specific list of Author IDs.
Author IDs can be specified in 3 ways. (only one type at a time is supported at the moment)
- Specify a list of specific author IDs, so that only content from these channels will be returned
- Specify
following
, so only content created by users followed by theuser_id
is returned - Specify the following list of a specific user, so content created by users followed by that specific user is returned
AI Labels
Specify a list of AI labels, so that only content tagged with these AI labels will be returned. When you select an AI label, there is an option to tweak the threshold score, such that only content with label score above the threshold will be returned. This can be used to fine tune the behaviour of the feed. 'mbd system default will be used if a threshold is not specified.
Embed Domains
Specify a list of domains, so that only content with embeded objects from the specific domains will be returned. For example, you can add mint.fun
or zora.co
to the domain list to make a feed of content with nft related objects embedded, or use drakula.app
to make a video feed.
Publication Types
Specify to only return content of specific types. For example, you may want a feed with only images
, videos
, nft
s or music
, etc.
Exclusions
Exclusion type filters tells the system to not include the content if they are tagged with the specific labels or attributes.

Author IDs
Specify to exclude content if they are from specific Author IDs. This is useful if you know authors that mainly create content not relevant to your users but might otherwise deem to be trending or recommended by for-you.
Like Author IDs in inclusion filters, Author IDs can be specified in 3 ways. (only one type at a time is supported at the moment)
- Specify a list of specific author IDs, so that only content from these channels will be returned
- Specify
following
, so only content created by users followed by theuser_id
is returned - Specify the following list of a specific user, so content created by users followed by that specific user is returned
AI Labels
Specify to exclude content if they are tagged with specific AI labels. This is useful if you want to exclude topics (for example web3-related content) not relevant to your users but might otherwise deem to be trending or recommended by for-you.
Like inclusion AI labels filters, these AI labels can be specified with a custom threshold to fine tune the behaviour of the feed.
Promotions
Promotions are power ways of adding variability in your feed. With promotion feeds, you can mix in a different feed (saved as a feed_id with different set of filters and parameters) at a specific percentage, or insert specific items at specific positions in the feed.
Currently, we only support 1 type of promotion (feed or item) in each API call.
Feed Promotion Guide
A concise reference for using feed promotions in the embed
Feed API.
Contents
- What Are Feed Promotions?
promotion_filters
Object- Promotion Types
- Example Request & Response
- Mixing Algorithm (Pseudo Code)
- Tips, Limits & Best Practices
- Frequently Asked Questions
- Changelog & References
1 What Are Feed Promotions?
A feed promotion is a controlled way to inject extra content into a user’s main feed. Each promotion can either:
- Blend an entire feed (
promotion_type = "feed"
) at a specified percentage, or - Insert specific items (
promotion_type = "items"
) at fixed ranks.
Promoted content is mixed toward the top of each page, boosting visibility without completely overriding the user’s core experience.
2 promotion_filters
Object
promotion_filters
Objectpromotion_filters
is an array—one element per promotion (only one is supported today).
Field | Type | Required | Description |
---|---|---|---|
promotion_type | string | ✓ | "feed" or "items" |
promotion_name | string | ✓ | Label surfaces in source_feed of response items |
percent | integer | feed‑type | Target percentage of the final result that should be promotional |
feed_id | string | feed‑type | ID of an existing feed whose items will be promoted |
filters | object | feed‑type | Optional extra filters to refine the promotion feed |
promoted_items | array<object> | items‑type | Hand‑picked items with optional 1‑based rank |
UI note: The form shown in the product mirrors this schema, revealing required and conditional fields.
3 Promotion Types
3.1 feed
(most common)
feed
(most common)- Pulls items from another feed (
feed_id
). - Uses
percent
to determine the target blend. - Items appear at random, skew‑to‑top positions.
3.2 items
items
- Promotes an explicit list of items.
- Provide a
rank
to pin an item to an exact slot; otherwise the system distributes items evenly.
4 Example Request & Response
curl --request POST \
--url https://api.mbd.xyz/v2/farcaster/casts/feed/for-you \
--header 'HTTP-Referer: https://docs.mbd.xyz/' \
--header 'X-Title: mbd_docs' \
--header 'accept: application/json' \
--header 'authorization: Bearer <YOUR TOKEN>' \
--header 'content-type: application/json' \
--data '{
"promotion_filters": [
{
"promotion_type": "feed",
"promotion_name": "video_content",
"percent": 35,
"feed_id": "feed_180"
}
],
"user_id": "3",
"feed_id": "feed_214"
}'
Highlights
- The main feed is
feed_214
(for user3
). feed_180
(curated videos) is promoted at ~35 %.
Partial response:
{
"item_id": "0x757a…9048",
"source_feed": "promotion:feed_180" // promoted
},
{
"item_id": "0xfd6c…6832",
"source_feed": "main:feed_214" // main
source_feed prefixes clearly distinguish promoted versus main items.
5 Mixing Algorithm (Pseudo Code)
5.1 Flow Diagram
Main Feed ─────────┐
│ (deduplicate)
Promotion Feed ───┘
│
▼
[Generate skew‑biased positions] ←─────────┐
│ │
└───► [Interleave lists] ────────────┘
Goal: roughly promoPercent % of the first top‑k items come from the promotion feed and are biased toward early ranks.
5.2 Core Pseudo Code
CONST OVERFETCH = 2.0
function mix(main, promo, percent, topK):
# 1 — Deduplicate
main, promo ← removeOverlap(main, promo)
# 2 — Over-fetch so ratios survive later trimming
desired ← topK × OVERFETCH
promoN ← ceil(desired × percent / 100)
mainN ← desired − promoN
promo ← first(promo, promoN)
main ← first(main, mainN)
# 3 — Choose insertion slots (skewed toward lower numbers)
slots ← skewedPositions(count = promoN, max = promoN + mainN)
# 4 — Interleave
out ← []
for i in 1…(promoN + mainN):
if i in slots: out.append(pop(promo))
else: out.append(pop(main))
# 5 — Return final page
return first(out, topK)
5.3 Skewed Position Helper
function skewedPositions(count, max):
assert count ≤ max
universe ← [1 … max]
weight(n) = 1 / n^0.35 # lower n ⇒ higher weight
slots ← weightedUniqueSample(universe, weight, count)
return sort(slots)
Intuition: Think of drawing numbered tickets—tickets 1–10 are heavier than 90–100. Selected slots therefore cluster near the top without always landing at position 1.
6 Tips, Limits & Best Practices
- Single promotion per request — chain multiple calls client‑side if you need more.
- Set reasonable percent values (10–30 % is typical). Values over 50 % may feel spammy.
- Track source_feed in analytics to verify the real-world blend meets expectations.
- Quality matters. The algorithm does not re-rank promotion items, so start with a well-ranked feed.
- Tweak OVERFETCH (default 2.0) if heavy deduplication causes percentage drift.
7 Frequently Asked Questions
Q — Can I promote using filters only (no saved feed)?
A — Yes. Omit feed_id
, supply filters
, and set promotion_type = "feed"
. The system treats it as an ad-hoc feed.
Q — Is insertion deterministic?
A — Slots are freshly generated per request, but once chosen, the order remains stable throughout the page.
Q — What if the promotion feed is exhausted?
A — The engine silently back-fills with main-feed items, so the actual percentage may be lower than requested.
Cold Start Configurations
What's Considered Cold Start?
If a user is new to the system and has no interaction history, or if the user has not been actively interacting with content for a long period of time, there is not enough signals to recommend a "good" feed to the user.
Specifying a Cold Start Feed
In cases the user is considered under "cold start", it is recommended that you configure a "cold start feed" to be shown to the user in those cases. This basically means that our APIs uses the feed_id
specified by the cold_start_feed
when we detect that a user is under "cold start".
Cold start feed should be carefully crafted to make the feed interesting to "cold" users. This can be done by using a combination of the strategies below:
- use
ai_labels
infilters
to select content topics that represent the topics the users on your platform are more likely to be interested in - use
author_ids
infilters
, and curate a "good" list of content creators. Good content creators should be those who are regular users and actively create content that are interesting to other users - use
author_ids
and specifyfollowing
, to include content created by the users followed by the current user, if the user is a returning user - use
channels
infilters
to select a list of quality channels that users on your platform are more likely to be interested in - depending on the nature of your platform, it might be beneficial to also use
publication_type
infilters
to return only certain types of publications (only videos, for example) - depending on the nature of your platform, it might be beneficial to use exclude
ai_labels
to avoid content that might not be relevant to your users. You can, for example, choose to exclude web3-specific content by specifying web3ai_labels
in exclusion list
Finally, it is recommended to include a promotion filter in the cold start feed_id, to mix in different strategies mentioned above. For example, the feed can be configured to include ai_labels, author_ids, channels, to ensure the content is of specific types, and then use a promotion filter of following
in author_ids
, to achieve something like 70% of content from "interesting" labels and sources, and 30% of content from users followed by the viewing user_id
.
Updated 11 days ago