Configurações de pré-segmentação
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Os bidders podem usar o recurso pretargetingConfigs para receber somente solicitações de lance de impressões que correspondam aos critérios de segmentação.É possível ter até 10 configurações de pré-segmentação ao mesmo tempo.
Cada configuração de pré-segmentação distribui solicitações de lance por todos os endpoints.
As solicitações de lance nem sempre são distribuídas de maneira uniforme entre todos os endpoints. Por exemplo, uma configuração de pré-segmentação para IDs geográficos específicos em uma determinada região pode ter menos correspondências em locais de negociação que estão mais distantes dessa região. Os endpoints próximos aos locais de operação mais distantes podem receber menos solicitações de lance.
Práticas recomendadas
Para receber solicitações de lance, é preciso criar pelo menos uma configuração de pré-segmentação. Confira algumas dicas para gerenciar as configurações de pré-segmentação:
- Escopo
A pré-segmentação é como a filtragem. Use critérios de pré-segmentação para filtrar solicitações de lance àquelas relevantes para seu caso de uso. Se você não definir critérios de pré-segmentação, será possível receber solicitações de lance para todas as impressões.
Se você não estiver recebendo solicitações de lance suficientes relacionadas a uma determinada configuração de pré-segmentação, convém ampliar seus critérios de pré-segmentação.
- Lógica
Os valores nos campos de segmentação de nível superior são processados com um OR lógico. Isso significa que você pode receber solicitações de lance que tenham pelo menos um dos valores especificados no campo de nível superior. Por exemplo, se a configuração de pré-segmentação tiver os valores de languageCodes en, de e sv, você poderá receber solicitações de lance com en, de ou sv como o idioma detectado.
Campos diferentes são processados com AND lógico. Você só recebe solicitações de lance que correspondem a pelo menos um valor em cada campo de pré-segmentação definido. Por exemplo, se a configuração tiver os valores de languageCodes en, de e sv e o valor de includedPlatforms PERSONAL_COMPUTER, você só vai receber solicitações de lance com o idioma en, de ou sv detectado e o tipo de dispositivo PERSONAL_COMPUTER.
Devido ao AND lógico nos campos de pré-segmentação, não é possível incluir
critérios contraditórios. Por exemplo, incluir o mesmo valor em includedIds
e excludedIds em um critério NumericTargetingDimensions resulta em
erro.
- Sobreposição
As solicitações de lance podem ser qualificadas para várias configurações de pré-segmentação.
É possível criar até 10 configurações de pré-segmentação para segmentar diferentes tipos de inventário. As configurações de pré-segmentação podem se sobrepor. Assim, uma única solicitação de lance pode ser qualificada para várias configurações de pré-segmentação. Nesse caso, o campo billing_id da solicitação de lance contém o billingId de cada configuração aplicável. Se vários IDs de faturamento forem encontrados na solicitação de lance, especifique para qual ID você está fazendo um lance no campo billing_id da resposta do lance.
IDs de áreas geográficas
Alguns IDs geográficos não podem ser segmentados por motivos relacionados à política. Por exemplo, algumas
regiões com populações pequenas não podem ser segmentadas porque violariam nossa
política de privacidade. Nossas políticas estão sujeitas a alterações. Se você especificar um ID geográfico no geoTargeting da configuração de pré-segmentação que se tornar inválido posteriormente, o ID aparecerá no campo invalidGeoIds. Os IDs geográficos abaixo de invalidGeoIds não afetam a segmentação. Se um ID goegráfico em invalidGeoIds se tornar válido, ele será adicionado ao campo geoTargeting da configuração de pré-segmentação.
O arquivo geo-table.csv lista os IDs de áreas geográficas segmentáveis e é atualizado periodicamente à medida que os IDs são adicionados e removidos.
Contagem de solicitações de lance
Você precisa configurar o QPS máximo para seus endpoints do bidder e permitir que o callout System gerencie o tráfego enviado aos endpoints para cada uma das configurações de pré-segmentação.
Veja alguns casos extremos em que o gerenciamento de QPS máximo no
nível da configuração de pré-segmentação com maximumQps pode ser útil:
- Recebimento de muitas solicitações
- Se o sistema de cota de chamadas estiver enviando um número excepcionalmente grande de solicitações de lance para endpoints do bidder para uma determinada configuração de pré-segmentação, é possível usar
maximumQps para ajustar manualmente o número de solicitações.
- Como testar uma configuração para o novo inventário
- Se você quiser oferecer suporte ao novo inventário, como um novo formato do criativo, implemente uma configuração de pré-segmentação apenas para esse inventário com um baixo
maximumQps.
No caso de inventários segmentados por várias configurações de pré-segmentação,
as solicitações de lance são enviadas aos endpoints do bidder, incluindo o billingId
de cada configuração, desde que pelo menos uma das configurações não
tenha atingido o limite de maximumQps.
Exceto em caso de indicação contrária, o conteúdo desta página é licenciado de acordo com a Licença de atribuição 4.0 do Creative Commons, e as amostras de código são licenciadas de acordo com a Licença Apache 2.0. Para mais detalhes, consulte as políticas do site do Google Developers. Java é uma marca registrada da Oracle e/ou afiliadas.
Última atualização 2025-07-25 UTC.
[null,null,["Última atualização 2025-07-25 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."]]
