Оптимизируйте свои подборки
Сохраняйте и классифицируйте контент в соответствии со своими настройками.
Участники торгов могут использовать ресурс pretargetingConfigs , чтобы получать запросы ставок только для показов, соответствующих их критериям таргетинга. Одновременно можно иметь до 10 конфигураций предварительного таргетинга.
Каждая конфигурация предварительного таргетинга распределяет запросы ставок по всем конечным точкам. Запросы ставок не всегда распределяются равномерно по всем конечным точкам. Например, конфигурация предварительного таргетинга для определенных географических идентификаторов в определенном регионе может иметь меньше совпадений в торговых точках , находящихся дальше от этого региона. Конечные точки рядом с этими удаленными торговыми точками могут получать меньше запросов ставок.
Лучшие практики
Чтобы получать запросы ставок, необходимо создать хотя бы одну конфигурацию предварительного таргетинга. Вот несколько советов по управлению конфигурациями предварительного таргетинга:
Объем
Предварительный таргетинг похож на фильтрацию. Вам следует использовать критерии предварительного таргетинга, чтобы отфильтровать запросы ставок по тем, которые имеют отношение к вашему варианту использования. Если вы не зададите никаких критериев предварительного таргетинга, вы сможете получать запросы ставок для всех показов.
Если вы получаете недостаточно запросов ставок, связанных с определенной конфигурацией предварительного таргетинга, возможно, вам захочется расширить критерии предварительного таргетинга.
Логика
Значения в полях таргетинга верхнего уровня обрабатываются с помощью логического OR . Это означает, что вы можете получать запросы ставок, которые имеют хотя бы одно из значений, указанных вами в поле верхнего уровня. Например, если в вашей конфигурации предварительного таргетинга указаны значения languageCodesen , de и sv , вы можете получать запросы ставок с en , de или sv в качестве обнаруженного языка.
Различные поля обрабатываются логическим AND Вы получаете только те запросы ставок, которые соответствуют хотя бы одному значению в каждом заданном вами поле предварительного таргетинга. Например, если в вашей конфигурации указаны значения languageCodesen , de и sv и значение PERSONAL_COMPUTERincludedPlatforms , вы получаете только запросы ставок, в которых обнаружен язык en , de или sv и тип устройства PERSONAL_COMPUTER .
Благодаря логическому AND в полях предварительного таргетинга нельзя включать противоречивые критерии. Например, включение одного и того же значения в includedIds и excludedIds в критерии NumericTargetingDimensions приводит к ошибке.
Перекрывать
В запросах ставок можно использовать несколько конфигураций предварительного таргетинга.
Вы можете создать до 10 конфигураций предварительного таргетинга для таргетинга на различные виды инвентаря. Конфигурации предварительного таргетинга могут перекрываться, поэтому для одного запроса ставки можно использовать несколько конфигураций предварительного таргетинга. В этом случае поле billing_id запроса ставки содержит billingId каждой применимой конфигурации. Если в запросе ставки обнаружено несколько идентификаторов выставления счетов, необходимо указать, по какому идентификатору выставлены ставки, в поле billing_id ответа на заявку.
Географические идентификаторы
Некоторые географические идентификаторы недоступны по соображениям политики. Например, некоторые регионы с небольшим населением не могут быть выбраны в качестве таргетинга, поскольку это нарушает нашу политику конфиденциальности. Наша политика может быть изменена. Если вы укажете географический идентификатор в geoTargeting конфигурации предварительного таргетинга, который впоследствии станет недействительным, в этот момент этот идентификатор появится в поле invalidGeoIds . Географические идентификаторы в списке invalidGeoIds не влияют на таргетинг. Если географический идентификатор в invalidGeoIds становится действительным, он добавляется в поле geoTargeting вашей конфигурации предварительного таргетинга.
В файле geo-table.csv перечислены целевые географические идентификаторы, и он периодически обновляется по мере добавления и удаления идентификаторов.
Количество запросов ставок
Вам следует настроить максимальное количество запросов в секунду для конечных точек системы назначения ставок и разрешить системе квотирования вызовов управлять трафиком, отправляемым на ваши конечные точки для каждой из ваших конфигураций предварительного таргетинга.
Вот крайние случаи, когда управление максимальным количеством запросов в секунду на уровне конфигурации предварительного таргетинга с помощью maximumQps может оказаться полезным:
Получение слишком большого количества запросов
Если система квотирования вызовов отправляет необычно большое количество запросов ставок конечным точкам системы назначения ставок для данной конфигурации предварительного таргетинга, вы можете использовать maximumQps , чтобы вручную настроить количество запросов.
Тестирование конфигурации для нового инвентаря
Если вы пытаетесь поддерживать новый инвентарь, например новый формат объявлений, вы можете реализовать конфигурацию предварительного таргетинга, ориентированную только на этот инвентарь с низким значением maximumQps .
Для инвентаря, на который настроено несколько конфигураций предварительного таргетинга, запросы ставок отправляются конечным точкам системы назначения ставок, включая billingId для каждой конфигурации, если хотя бы одна из конфигураций не достигла maximumQps количества запросов в секунду.
[[["Прост для понимания","easyToUnderstand","thumb-up"],["Помог мне решить мою проблему","solvedMyProblem","thumb-up"],["Другое","otherUp","thumb-up"]],[["Отсутствует нужная мне информация","missingTheInformationINeed","thumb-down"],["Слишком сложен/слишком много шагов","tooComplicatedTooManySteps","thumb-down"],["Устарел","outOfDate","thumb-down"],["Проблема с переводом текста","translationIssue","thumb-down"],["Проблемы образцов/кода","samplesCodeIssue","thumb-down"],["Другое","otherDown","thumb-down"]],["Последнее обновление: 2025-07-24 UTC."],[[["\u003cp\u003eUse pretargeting configurations to filter bid requests and receive only relevant impressions, with the ability to create up to 10 configurations.\u003c/p\u003e\n"],["\u003cp\u003ePretargeting criteria use logical \u003ccode\u003eOR\u003c/code\u003e within fields and logical \u003ccode\u003eAND\u003c/code\u003e across fields, allowing for flexible but specific targeting.\u003c/p\u003e\n"],["\u003cp\u003eBid requests can match multiple pretargeting configurations, requiring bidders to specify the desired billing ID in their bid response.\u003c/p\u003e\n"],["\u003cp\u003eSome geographic IDs may be untargetable for policy reasons, and the \u003ccode\u003egeo-table.csv\u003c/code\u003e file provides a list of valid targetable IDs.\u003c/p\u003e\n"],["\u003cp\u003eManage bid request traffic using the Callout Quota System and \u003ccode\u003emaximumQps\u003c/code\u003e for specific pretargeting configurations when necessary.\u003c/p\u003e\n"]]],["Bidders use `pretargetingConfigs` to filter bid requests, receiving only those matching their criteria; up to 10 configurations are allowed. These configurations filter requests using logical `OR` within fields and logical `AND` across fields. Bid requests can match multiple configurations, identified by `billingId` in the request. Geographic targeting may have restrictions and invalid IDs are listed under `invalidGeoIds`. You can set `maximumQps` per configuration to manage traffic volume. At least one configuration is required to receive bid requests.\n"],null,["# Pretargeting configurations\n\nBidders can use the `pretargetingConfigs` resource to receive only bid\nrequests for impressions that match their targeting criteria.You can have up to\n10 pretargeting configurations at once.\n\nEach pretargeting configuration distributes bid requests across all endpoints.\nBid requests aren't always distributed evenly across all endpoints. For example,\na pretargeting configuration for specific geographic IDs in a given region might\nhave fewer matches in [trading\nlocations](/authorized-buyers/rtb/peer-guide#trading-locations) that are farther\nfrom that region. Endpoints near those farther trading locations might receive\nfewer bid requests.\n\nBest practices\n--------------\n\nIn order to receive bid requests, you must create at least one\npretargeting configuration. Here are some tips for managing your pretargeting\nconfigurations:\n\nScope\n\n: Pretargeting is like filtering. You should use pretargeting criteria to filter\n bid requests to those that are relevant to your use case. If you don't set any\n pretargeting criteria, you can receive bid requests for all impressions.\n\n If you aren't receiving enough bid requests related to a given pretargeting\n configuration, you might want to broaden your pretargeting criteria.\n\nLogic\n\n: Values in top-level targeting fields are processed with logical `OR`. This\n means you can receive bid requests that have at least one of the values you\n specify in the top-level field. For example, if your pretargeting\n configuration has `languageCodes` values `en`, `de`, and `sv`, you might receive\n bid requests with `en`, `de`, or `sv` as the detected language.\n\n Different fields are processed with logical `AND`. You only receive bid\n requests that have a match for at least one value in every pretargeting field\n you set. For example, if your configuration has `languageCodes` values `en`,\n `de`, and `sv`, and `includedPlatforms` value `PERSONAL_COMPUTER`, you receive\n only bid requests that have a detected language of `en`, `de`, or `sv` and a\n device type of `PERSONAL_COMPUTER`.\n\n Due to the logical `AND` across pretargeting fields, you can't include\n contradictory criteria. For example, including the same value in `includedIds`\n and `excludedIds` in a `NumericTargetingDimensions` criteria results in an\n error.\n\nOverlap\n\n: Bid requests can be eligible for multiple pretargeting configurations.\n\n You can create up to 10 pretargeting configurations to target different\n kinds of inventory. Pretargeting configurations can overlap, so a single bid\n request might be eligible for multiple pretargeting configurations. In this\n case, the bid request's `billing_id` field contains the `billingId` of\n each applicable configuration. If multiple billing IDs are found in the bid\n request, you must specify which billing ID you're bidding on in the bid\n response's `billing_id` field.\n\nGeographic IDs\n--------------\n\nSome geographic IDs aren't targetable for policy reasons. For example, some\nregions with small populations can't be targeted because it would violate our\nprivacy policy. Our policies are subject to change. If you specify\na geographic ID in your pretargeting configuration's `geoTargeting` that becomes\ninvalid at a later date, the ID appears under the `invalidGeoIds` field at that\ntime. Geographic IDs under `invalidGeoIds` have no impact on targeting. If a\ngoegraphic ID in `invalidGeoIds` becomes valid, it's added to your pretargeting\nconfiguration's `geoTargeting` field.\n\nThe\n[geo-table.csv](//storage.googleapis.com/adx-rtb-dictionaries/geo-table.csv)\nfile lists targetable geographic IDs, and is updated periodically as IDs are\nadded and removed.\n\nBid request count\n-----------------\n\nYou should configure the maximum QPS for your bidder endpoints,\nand allow the [Callout Quota System](/authorized-buyers/rtb/callout-quota-system)\nto manage the traffic sent to your endpoints for each of your pretargeting\nconfigurations.\n\nHere are edge cases where managing maximum QPS at the\npretargeting configuration level with `maximumQps` might be useful:\n\nReceiving too many requests\n: If the Callout Quota System is sending an unusually large number of bid\n requests to bidder endpoints for a given pretargeting configuration, you can\n use `maximumQps` to manually adjust the number of requests.\n\nTesting a configuration for new inventory\n: If you're trying to support new inventory, like a new creative format,\n you can implement a pretargeting configuration targeting only that inventory\n with a low `maximumQps`.\n\nFor inventory that's targeted by multiple pretargeting configurations,\nbid requests are sent to the bidder's endpoints, including the `billingId`\nfor each configuration, as long as at least one of the configurations hasn't\nreached its `maximumQps` limit."]]