Cấu hình nhắm mục tiêu trước
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Bên đặt giá thầu có thể sử dụng tài nguyên pretargetingConfigs để chỉ nhận yêu cầu giá thầu cho các lượt hiển thị khớp với tiêu chí nhắm mục tiêu của họ.Bạn có thể có tối đa 10 cấu hình nhắm mục tiêu trước cùng một lúc.
Mỗi cấu hình nhắm mục tiêu trước sẽ phân phối các yêu cầu giá thầu trên tất cả các điểm cuối.
Yêu cầu giá thầu không phải lúc nào cũng được phân phối đồng đều trên tất cả các điểm cuối. Ví dụ: cấu hình nhắm mục tiêu trước cho các mã nhận dạng địa lý cụ thể trong một khu vực nhất định có thể có ít kết quả khớp hơn ở các vị trí giao dịch cách xa khu vực đó hơn. Các điểm cuối gần các vị trí giao dịch ở xa đó có thể nhận được ít yêu cầu giá thầu hơn.
Các phương pháp hay nhất
Để nhận yêu cầu giá thầu, bạn phải tạo ít nhất một
cấu hình nhắm mục tiêu trước. Dưới đây là một số mẹo để quản lý các cấu hình nhắm mục tiêu trước của bạn:
- Phạm vi
Tiêu chí nhắm mục tiêu trước giống như tính năng lọc. Bạn nên sử dụng tiêu chí nhắm mục tiêu trước để lọc các yêu cầu giá thầu ra những yêu cầu có liên quan đến trường hợp sử dụng của mình. Nếu không đặt tiêu chí nhắm mục tiêu trước nào, bạn có thể nhận được yêu cầu giá thầu cho mọi lượt hiển thị.
Nếu không nhận được đủ số yêu cầu giá thầu liên quan đến một cấu hình nhắm mục tiêu trước nhất định, bạn nên mở rộng tiêu chí nhắm mục tiêu trước của mình.
- Logic
Giá trị trong các trường nhắm mục tiêu cấp cao nhất được xử lý bằng logic OR. Điều này có nghĩa là bạn có thể nhận các yêu cầu giá thầu có ít nhất một trong các giá trị mà bạn chỉ định trong trường cấp cao nhất. Ví dụ: nếu cấu hình nhắm mục tiêu trước của bạn có các giá trị languageCodes en, de và sv, thì bạn có thể nhận được các yêu cầu giá thầu có en, de hoặc sv dưới dạng ngôn ngữ phát hiện được.
Các trường khác nhau được xử lý bằng AND logic. Bạn chỉ nhận được các yêu cầu giá thầu khớp với ít nhất một giá trị trong mỗi trường nhắm mục tiêu trước mà bạn đã đặt. Ví dụ: nếu cấu hình của bạn có các giá trị languageCodes là en, de và sv, cùng với giá trị includedPlatforms là PERSONAL_COMPUTER, thì bạn sẽ chỉ nhận được các yêu cầu giá thầu có ngôn ngữ phát hiện là en, de hoặc sv và loại thiết bị là PERSONAL_COMPUTER.
Do AND logic trên các trường nhắm mục tiêu trước, nên bạn không thể đưa vào các tiêu chí mâu thuẫn. Ví dụ: việc đưa cùng một giá trị vào includedIds và excludedIds trong tiêu chí NumericTargetingDimensions sẽ dẫn đến lỗi.
- Trùng lặp
Các yêu cầu giá thầu có thể đủ điều kiện cho nhiều cấu hình nhắm mục tiêu trước.
Bạn có thể tạo tối đa 10 cấu hình nhắm mục tiêu trước để nhắm mục tiêu các loại khoảng không quảng cáo khác nhau. Các cấu hình nhắm mục tiêu trước có thể trùng lặp, vì vậy, một yêu cầu giá thầu có thể đủ điều kiện cho nhiều cấu hình nhắm mục tiêu trước. Trong trường hợp này, trường billing_id của yêu cầu giá thầu chứa billingId của từng cấu hình áp dụng. Nếu tìm thấy nhiều mã thanh toán trong yêu cầu giá thầu, bạn phải chỉ định mã thanh toán mà bạn đang đặt giá thầu trong trường billing_id của phản hồi giá thầu.
Mã địa lý
Một số mã nhận dạng địa lý không thể nhắm mục tiêu vì lý do chính sách. Ví dụ: chúng tôi không thể nhắm mục tiêu một số
khu vực có dân số nhỏ vì điều đó vi phạm chính sách quyền riêng tư của chúng tôi. Các chính sách của chúng tôi có thể thay đổi. Nếu bạn chỉ định một mã nhận dạng địa lý trong geoTargeting của cấu hình nhắm mục tiêu trước nhưng sau này lại không còn hợp lệ, thì mã nhận dạng đó sẽ xuất hiện trong trường invalidGeoIds vào thời điểm đó. Các mã địa lý trong invalidGeoIds không ảnh hưởng đến việc nhắm mục tiêu. Nếu một mã đo lường trong invalidGeoIds hợp lệ, thì mã đó sẽ được thêm vào trường geoTargeting của cấu hình nhắm mục tiêu trước.
Tệp geo-table.csv
liệt kê các mã địa lý có thể nhắm mục tiêu và được cập nhật định kỳ khi
thêm và xoá các mã nhận dạng.
Số yêu cầu giá thầu
Bạn nên định cấu hình QPS tối đa cho các điểm cuối của người đặt giá thầu và cho phép Hệ thống hạn mức chú thích quản lý lưu lượng truy cập gửi đến các điểm cuối của bạn cho mỗi cấu hình nhắm mục tiêu trước.
Dưới đây là các trường hợp đặc biệt mà việc quản lý QPS tối đa ở cấp cấu hình nhắm mục tiêu trước bằng maximumQps có thể hữu ích:
- Nhận quá nhiều yêu cầu
- Nếu Hệ thống hạn mức chú thích đang gửi một số lượng yêu cầu giá thầu lớn bất thường đến điểm cuối của bên đặt giá thầu cho một cấu hình nhắm mục tiêu trước nhất định, thì bạn có thể sử dụng
maximumQps để điều chỉnh số lượng yêu cầu theo cách thủ công.
- Kiểm tra cấu hình cho khoảng không quảng cáo mới
- Nếu đang cố gắng hỗ trợ khoảng không quảng cáo mới, chẳng hạn như định dạng mẫu quảng cáo mới, bạn có thể triển khai tiêu chí nhắm mục tiêu trước chỉ nhắm mục tiêu khoảng không quảng cáo đó với
maximumQps thấp.
Đối với khoảng không quảng cáo được nhiều cấu hình nhắm mục tiêu trước nhắm đến, các yêu cầu giá thầu sẽ được gửi đến điểm cuối của bên đặt giá thầu, bao gồm cả billingId cho mỗi cấu hình, miễn là ít nhất một trong các cấu hình chưa đạt đến giới hạn maximumQps.
Trừ phi có lưu ý khác, nội dung của trang này được cấp phép theo Giấy phép ghi nhận tác giả 4.0 của Creative Commons và các mẫu mã lập trình được cấp phép theo Giấy phép Apache 2.0. Để biết thông tin chi tiết, vui lòng tham khảo Chính sách trang web của Google Developers. Java là nhãn hiệu đã đăng ký của Oracle và/hoặc các đơn vị liên kết với Oracle.
Cập nhật lần gần đây nhất: 2025-07-25 UTC.
[null,null,["Cập nhật lần gần đây nhất: 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."]]
