> ## Documentation Index > Fetch the complete documentation index at: https://docs.apostra.com/llms.txt > Use this file to discover all available pages before exploring further. # The seller-history co-op > What a buyer account shares and gets by joining the seller-history co-op, how the pooled figures are protected, and how leaving works. A seller's record shows how often it kept the commitments it made on goals. On your own buys, you always see your own record with a seller. The **seller-history co-op** adds something you cannot get alone: other buyers' results with that seller, pooled. It is a co-op because you get the pooled history only by contributing to it. Joining is your choice, and it starts off. For what a record cell holds and how a buy is judged, see [The seller's record](/v2/concepts/goal-seeking-campaigns#the-sellers-record). ## In short * Joining shares the judged results of this account's completed buys, only as aggregates that never name a buyer, campaign or media buy, and never price. In return the account gets other members' pooled seller history. Pooled reading and ranking open only when the pilot read is enabled for the account. * Leaving withdraws every published figure this account's buys stood behind, at once, and the account stops reading pooled history. Pooled reading and ranking open only when the pilot read is enabled for the account. The sections below give the detail. ## Who decides The administrators of a buyer account decide whether the account joins. An account that never joined is not a member. Members and non-members are set per buyer account. | To do this | Use | | - | - | | Join or leave | `save_buyer_operator` on `/mcp/v3` with `sellerHistoryCoop: true` or `false`, or `PATCH /api/v2/buyer/readiness/operator` with the same field | | Read whether the account is a member | `operatorIdentity.sellerHistoryCoop` from `get_status`, or `identity.sellerHistoryCoop` from `GET /api/v2/buyer/readiness` | The setting sits with the account's operator identity because the operator that owns the account decides. Changing it takes the same administrator permission as the operator identity. The field is sent with the identity, so to change only the co-op setting, send the saved identity again unchanged. On `/mcp/v3`, a change goes through the preview and confirmation that identity changes use: preview first, show the person what a member shares and gets, and confirm with the token the preview returns. ## What a member shares A member shares the judged results of its completed buys, and only as aggregates. A pooled figure never names a buyer, a campaign or a media buy, and never says how many buyers or operators stand behind it. * **Which buys count.** Completed buys that carry a goal commitment and were judged, as described in [Judging delivery](/v2/concepts/goal-seeking-campaigns#judging-delivery). Sandbox buys do not count, and neither do buys last delivered more than 180 days ago. * **Price is never shared.** The co-op pools delivery, performance and quality. What a seller charged you stays with you. * **The operator behind the account counts, not the account.** The co-op counts operators by the operator domain an account confirmed. A buy from an account with no confirmed operator identity is left out, so confirm your [operator identity](/v2/buyer/account/setup) first. ## What a member gets A member reads other members' pooled history of a seller, as the seller's record, in place of its own record. It is the same kind of figure: one per goal objective and commitment kind for each seller. * **A figure is shown only with enough behind it.** At least 3 distinct operators and 5 judged buys must stand behind it, and no single operator may supply more than half of the judged buys. A figure that fails either is not shown. Without these limits, a member could work out another member's results from a thin figure. * **Nothing exact is shown, and smaller records show less.** A record built from fewer than 40 judged buys is small. It shows a size band (`size: "under_40_judged"`) and a hit rate and median distance from target rounded to the nearest 0.25, which is quarters. It shows no number of buys, no number judged and no split into beat, met and missed: with so few buys, one buy can move a rounded share by a whole step, so a split could be worked back into individual results. Several different results round to the same quarter, so the quarter cannot be worked back into one. A record built from 40 or more judged buys (`size: "40_or_more_judged"`) shows the rounded split. The number of buys and the number judged are rounded to the nearest 5. The share of judged buys that beat, met or missed their target (`beatShare`, `metShare`, `missedShare`) is given in steps of 0.05, which is 5 percentage points, and the three always add up to exactly 1: each share takes the step at or below it, and any step left over goes to the shares closest to the next step up. The hit rate is rounded to the nearest 0.05, and the median distance from target is rounded to the nearest 0.05, which is 5 percent of the target. At 40 judged buys one buy moves a share by 2.5 points at most, which is less than half of that rounding step, so no single buy can be read out of a figure. * **It is a snapshot, not a live figure.** Pooled history is published on a fixed schedule, monthly to start. A live figure leaks through subtraction: if you read a pooled hit rate before and after one other buyer's buy completes, you could recover that buy's result. A published value changes only when at least 5 judged buys from at least 3 distinct operators have been added since it was published. Otherwise the previous value stands. * **Automatic selection uses it too.** For a member with pooled reading open, automatic product selection ranks sellers with the published snapshot. For anyone else it ranks with the account's own completed buys with each seller. ## Leaving Leaving takes effect at once. Every published figure that the account's buys stood behind is withdrawn in the same moment, and the account stops reading pooled history. A withdrawn figure is not republished from the same remaining buys, because publishing it again without the leaver would reveal the leaver's results as the difference between the two values. It returns only when buys added by the remaining members meet the change threshold above and it passes the minimum. Leaving does not delete your own record with a seller. You keep reading that. ## If you are not a member You read your own record with a seller: only your own completed buys, judged the same way. They are your own buys, so the counts are exact and no minimum applies. You do not read any other buyer's results, and no other buyer's results change how automatic selection ranks sellers for you. ## What a seller sees A seller reads its own record across all its buyers, as before. That record is built from evidence the seller holds or was sent, so no buyer's consent is involved. A seller never sees which buyers are members. **Pilot.** Reading pooled history is in a pilot, and the pilot widens after sellers have been told what buyers see. Until pooled reading is open for your account, joining only means your own completed buys will count toward the pool once it opens. You do not read pooled history yet: automatic selection ranks with your own buys, and an account outside the pilot that asks for `include: ["commitmentRecord"]` is refused with `FEATURE_NOT_ENABLED`. ## Not part of the co-op The market benchmarks that product scoring uses for cost per action, cost per click, click-through and conversion rates by objective, country and channel are a separate, market-wide computation. They name no seller, buyer or buy and do not depend on membership. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.