Targeting keys and bid-modifier keys are different lists
This seat's targeting catalog has 50 keys. Bid modifiers have 66, including both clocks. Treating them as one list is how we concluded dayparting did not exist for three months.
Published 2026-09-09 · Search job: bid modifiers vs targeting
Bid modifiers and targeting are different lists on this seat. Confusing them is how we spent three months believing dayparting did not exist.
Targeting decides eligibility: can this request even be in the auction for this line item. Bid modifiers decide what happens to the bid when a term matches. An unmatched request keeps its bid unmodified. Those are different jobs, so they have different vocabularies. We treated the targeting catalog as the only vocabulary.
The two counts
/rest/v2/ref/targeting-keys returns 50 keys across six modules: app_site, content, environment, exchange, geo, and platform. There is no clock on that list. user_time_of_week is absent. That fact is still true.
OPTIONS /rest/v2/bid-modifiers returns actions.POST with 66 targeting_key choices. That list includes both time_of_week and user_time_of_week, plus segment, user_id, ad_size, delivery, feed, and ip_address. Those keys are not in the 50. They are not "secret targeting." They are modifier keys.
FreeWheel's own bidding-agent notes already said this: a separate vocabulary from Buzz targeting-expression modules, including time-of-week ranges. We had the sentence in a research file and still concluded from the targeting catalog that the capability was missing.
Why the mix-up lasted
A targeting-key probe is the obvious first check. If you want to daypart a campaign, you look for a clock in targeting. When the clock is missing, the honest-sounding conclusion is "this seat cannot daypart." That is the same single-endpoint move as checking one API surface and calling the capability absent.
Dayparting lives on bid modifiers. The verified term shape is { targeting_key: 'user_time_of_week', comparator: 'in_range', value: [startMinute, endMinute], multiplier }. Minutes from Sunday midnight, 0 to 10079. Attach the modifier with line_items.bid_modifier_id. Every current line item on the live portfolio had that field null when we looked, which is a product gap, not a seat gap.
A bid modifier only applies where a term matches. A daypart that wants to suppress hours must enumerate the hours to suppress, usually with multiplier: 0, rather than listing the hours to allow and hoping the rest go away. That is a different mental model from targeting, where you state who is eligible.
What each list is for
Use targeting when the question is eligibility. Inventory source allowlists, geo, environment, ads.txt, placement, and site live there. Use bid modifiers when the question is bid scaling or a clock the targeting catalog does not have. Delivery modifiers are a third object: they weight budget across segments with ranks and a required fallback weight. They are not wired into the product yet. They are also not the targeting catalog.
The practical rule is boring. Before you say a control is missing, read both lists. OPTIONS, not /fields is how you read the modifier list. The targeting-key catalog is how you read eligibility. They will not agree, and that disagreement is the design.