# UGC programs (/docs/concepts/ugc) A UGC program rewards members for the content they create about you, and for how well it does. For example: * **100 XP for a launch post on X**, once your team approves it. * **A bonus once a video reaches 1,000 views.** * **One point for every ten likes**, credited each day the post keeps growing. A program is three pieces you combine: * **A [tracker](/docs/concepts/trackers)** collects the posts. * **A content quest** checks each post and rewards it once. * **An engagement rule**, if you want one, credits points every day as the post's likes or views grow. ```mermaid flowchart LR T["Tracker"] --> A["Admission"] A --> Q["Qualification"] Q --> P["Performance gate (optional)"] P --> R["One-time reward"] P --> E["Engagement rule"] E --> L["Daily points"] ``` | Term | Meaning | | ---------------------- | -------------------------------------------------------------------------------------------- | | Content item | A creator's identified post, independent of which tracker found it or which program uses it. | | Admission | Letting a collected post into one quest, for the member who owns it. | | Content qualification | One quest's decision about a post and its evidence. | | Performance stage | An optional threshold, such as 100 likes, that must also pass before the one-time reward. | | Engagement reward rule | A formula that turns growth in a qualifying post's likes or views into points. | | Credit watermark | The highest count already paid for, so the same growth is never paid twice. | > [!IMPORTANT] Reward X posts only for approved creators > X does not allow apps that reward users for posting. A content quest on an X tracker that pays, through its own rewards or an engagement rule, needs an `inGroup(group)` prerequisite naming a [group](/docs/concepts/groups) of creators the operator approves; posts by anyone else are not admitted. A deployment that publishes one without it warns with `x-post-rewards-ungated`. ## Admission [#admission] A content quest completes once per post. X search supplies each post's text and counters, [YouTube Shorts](/docs/build/trackers#reward-youtube-shorts) each Short's title, description, tags, length and views, likes and comments, from the channels members linked, and [TikTok videos](/docs/build/trackers#reward-tiktok-videos) each video's title, caption, length, size, link and views, likes, comments and shares, from the accounts members linked. Your own source can feed in videos, posts or other creator content in the same way, with its own fields and metrics. > [!NOTE] YouTube view counts changed twice > YouTube counts every play of a Short as a view from 2025-03-31, and counts every format's view when playback starts from 2026-08-24. View counts from either side of those dates are not comparable, so set view thresholds and engagement formulas for content published after them. Each newly collected post waits until all of these hold: * **Ownership.** The post's author account belongs to one member of your project, through an account they linked. * **Enrollment.** The member joined the quest, when the quest requires it. * **Dates.** The post was published within the tracker's window, and by default after the quest was published. * **Historical policy.** A post published before the member linked their account, or before they enrolled, is historical. Depending on the quest, it's let in automatically, when the member claims it, or when a reviewer retries it. * **Prerequisites and pause.** The quest's prerequisites are met and the quest is active. Posts collected before a content quest is published are not backfilled. > [!DEV] > A content quest uses `content({ tracker, ...policy })` and needs no separate completion policy. A custom source declares its own body schema and metrics. Ownership resolves through the source's declared identity kinds. `since: "activation"` is the default; `"window"` counts from the tracker window, while `"enrollment"` counts from each member's enrollment and requires enrollment. See [automatic content admission](/docs/reference/trackers#automatic-content-admission). ## Qualification follows the content item [#qualification-follows-the-content-item] * **Edits are checked again.** If the creator changes the post's text, the quest checks it again under the rules it was let in with, for the same member. New like counts or profile changes don't trigger a recheck. * **Out-of-date decisions can't pay.** Domino checks the current post and owner before applying any decision. * **One reward per quest and post.** The first accepted check pays. Later qualifying edits don't pay again, and different quests can reward the same post separately. ## Performance gates the one-time reward [#performance-gates-the-one-time-reward] A content quest can wait for the post to perform, such as 100 likes or 1,000 views, before it pays. The post has to be approved and hit the threshold. * **Fresh numbers only.** Each check reads one fresh, complete sample. Missing or old counters wait for a refresh; a real zero counts. * **It can pass later.** A post rejected at 20 likes can pass at a later sample of 150. * **Paid stays paid.** A later drop below the threshold doesn't take the reward back. > [!DEV] > Declare a `performance` stage over the source's declared metrics, such as `likes` or `views`. Content qualification and performance must both accept before the reward resolves. See [content performance gates](/docs/reference/trackers#content-performance-gates). ## Engagement credits growth [#engagement-credits-growth] An engagement rule pays points as a post keeps growing, on top of the quest's one-time reward. It reads a qualifying quest and credits a point ledger directly. When the quest has a performance threshold, a post earns engagement points only while it is approved and above the threshold. | Behavior | What happens | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Formula | A running total over the post's counters, such as one point per ten likes. | | Settlement | At most once per [project calendar](/docs/concepts/calendar) day, starting at the next midnight after the first eligible sample. | | Watermark | Counters of 100, 130, 120, then 135 likes pay for at most 135. A drop and recovery never pays twice. | | Budgets | Optional limits per project or per member, for each day, week, or month of the project calendar, or for the rule's lifetime. Growth over a limit never carries into the next period. | | Scope | Posts first found after the rule was published. Earlier posts are not backfilled. | | Formula change | Applies from an observed boundary forward. Past engagement is never repriced. | Pausing the quest, a pending review, lost approval, a removed post, or a change of owner stops further points until it is resolved. > [!DEV] > The formula is a cumulative target over the declared counters. It runs without network, clock, or member access. See [daily engagement points](/docs/reference/trackers#daily-engagement-points) for authoring, budgets and settlement timing. > [!IMPORTANT] Awards are not reversed automatically > Rejection, deletion, or a lower count stops future rewards and accrual. Points and rewards already credited remain. ## Current scope [#current-scope] * **Operator view.** Console shows each post's admission, qualification, performance, and engagement outcomes under **Community → Trackers**, and reviewers can retry historical admission there. Enrollment and member claims use the API. * **Publication.** The CLI publishes content quests and engagement rules to test environments. ## Where next [#where-next] - [Track content and events](/docs/build/trackers) — Build a UGC program with content quests and engagement rules. - [Trackers](/docs/concepts/trackers) — How posts are collected, revised, and observed. - [Points](/docs/concepts/points) — Where engagement points are credited.