Configurations de préciblage
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Les enchérisseurs peuvent utiliser la ressource pretargetingConfigs pour ne recevoir que les demandes d'enchères pour les impressions qui correspondent à leurs critères de ciblage.Vous pouvez avoir jusqu'à 10 configurations de préciblage à la fois.
Chaque configuration de préciblage répartit les demandes d'enchères sur tous les points de terminaison.
Les demandes d'enchères ne sont pas toujours réparties uniformément entre tous les points de terminaison. Par exemple, une configuration de préciblage pour des ID géographiques spécifiques dans une région donnée peut générer moins de correspondances dans les zones d'échange les plus éloignées de cette région. Les points de terminaison situés à proximité de ces zones d'échange peuvent recevoir moins de demandes d'enchères.
Bonnes pratiques
Pour recevoir des demandes d'enchères, vous devez créer au moins une configuration de préciblage. Voici quelques conseils pour gérer vos configurations de préciblage:
- Définition du champ d'application
Le préciblage est semblable au filtrage. Vous devez utiliser des critères de préciblage pour filtrer les demandes d'enchères en fonction de celles qui sont pertinentes pour votre cas d'utilisation. Si vous ne définissez aucun critère de préciblage, vous pouvez recevoir des demandes d'enchères pour toutes les impressions.
Si vous ne recevez pas suffisamment de demandes d'enchères associées à une configuration de préciblage donnée, vous pouvez élargir vos critères de préciblage.
- Logique
Les valeurs des champs de ciblage de premier niveau sont traitées selon la logique OR. Cela signifie que vous pouvez recevoir des demandes d'enchères comportant au moins l'une des valeurs que vous spécifiez dans le champ de premier niveau. Par exemple, si votre configuration de préciblage comporte les valeurs languageCodes en, de et sv, vous pouvez recevoir des demandes d'enchères dont la langue détectée est en, de ou sv.
Différents champs sont traités avec la logique AND. Vous ne recevez que les demandes d'enchères avec une correspondance pour au moins une valeur dans chaque champ de préciblage que vous avez défini. Par exemple, si votre configuration comporte les valeurs languageCodes en, de et sv, et la valeur includedPlatforms PERSONAL_COMPUTER, vous ne recevrez que les demandes d'enchères dont la langue détectée est en, de ou sv, et le type d'appareil PERSONAL_COMPUTER.
En raison de la logique AND des champs de préciblage, vous ne pouvez pas inclure de critères contradictoires. Par exemple, si vous incluez la même valeur dans includedIds et excludedIds dans un critère NumericTargetingDimensions, cela génère une erreur.
- Chevauchement
Les demandes d'enchères peuvent être éligibles pour plusieurs configurations de préciblage.
Vous pouvez créer jusqu'à 10 configurations de préciblage pour cibler différents types d'inventaires. Les configurations de préciblage peuvent se chevaucher. Une même demande d'enchère peut donc être éligible pour plusieurs configurations de préciblage. Dans ce cas, le champ billing_id de la demande d'enchère contient l'identifiant billingId de chaque configuration applicable. Si plusieurs n° compte facturation sont détectés dans la demande d'enchère, vous devez spécifier celui sur lequel vous enchérissez dans le champ billing_id de la réponse à l'enchère.
ID géographiques
Certains ID géographiques ne peuvent pas être ciblés pour des raisons de non-respect des règles. Par exemple, certaines régions comptant une petite population ne peuvent pas être ciblées, car cela enfreindrait nos règles de confidentialité. Nos règles sont susceptibles d'être modifiées. Si vous spécifiez un ID géographique dans le geoTargeting de votre configuration de préciblage qui n'est plus valide par la suite, l'ID apparaît alors dans le champ invalidGeoIds. Les ID géographiques inférieurs à invalidGeoIds n'ont aucune incidence sur le ciblage. Si un ID goegraphic dans invalidGeoIds devient valide, il est ajouté au champ geoTargeting de votre configuration de préciblage.
Le fichier geo-table.csv répertorie les ID géographiques pouvant être ciblés. Il est mis à jour régulièrement à mesure que des ID sont ajoutés ou supprimés.
Nombre de demandes d'enchères
Vous devez configurer le nombre maximal de RPS pour les points de terminaison de votre système d'enchères et autoriser le système de quotas d'appel à gérer le trafic envoyé à vos points de terminaison pour chacune de vos configurations de préciblage.
Voici les cas particuliers dans lesquels la gestion du nombre maximal de RPS au niveau de la configuration de préciblage avec maximumQps peut s'avérer utile:
- Réception d'un trop grand nombre de requêtes
- Si le système de quota d'appels envoie un nombre anormalement élevé de demandes d'enchères aux points de terminaison du système d'enchères pour une configuration de préciblage donnée, vous pouvez ajuster manuellement le nombre de demandes à l'aide de
maximumQps.
- Tester une configuration pour un nouvel inventaire
- Si vous essayez d'accepter un nouvel inventaire, comme un nouveau format de création, vous pouvez implémenter une configuration de préciblage ciblant uniquement cet inventaire avec un faible
maximumQps.
Pour l'inventaire ciblé par plusieurs configurations de préciblage, les demandes d'enchères sont envoyées aux points de terminaison de l'enchérisseur, y compris le billingId pour chaque configuration, à condition qu'au moins une des configurations n'ait pas atteint sa limite maximumQps.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/25 (UTC).
[null,null,["Dernière mise à jour le 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."]]
