Processor features

Troubleshoot secure signals

Next: How Google processes secure signals

Find out why secure signals aren't delivering. #securesignals

To ensure secure signals are being included in all eligible RTB ad requests, there are a number of troubleshooting steps possible.

Identify missing secure signal providers on requests

In Ad Manager reporting, use the appropriate "Demand channel" filter (Ad Exchange, Open Bidding, or SDK Bidding) and combine it with the "Secure signal name (presented)" or "Secure signal name (delivered)" dimensions to see which secure signal providers are being sent on ad requests. You can also use the "Date" and "Inventory types (expanded)" dimensions to help limit the focus of your report to a specific time period or environment.

Ensure secure signal delivery

Review your secure signals controls in Demand channel settings and ensure that any default settings or override groups align with your preferences. If default settings are toggled on for some or all demand channels, ensure there isn't a conflicting setting in an override group that may prevent some or all bidders from receiving the signal.

In demand channel settings, you can also control whether Authorized Buyers can use bid request data to build user profiles for uses such as interest-based ads and remarketing.

For SDK Bidding specifically, learn how to ensure bidders can send their own signals by verifying your SDK Bidding setup.

Secure signals are present but not sent to winner

When reporting on secure signals, there are a number of cases when a secure signal is present on an ad request but is not sent to the winning bidder, such as when:

The bidder did not subscribe to receive the signal.
The signal was filtered in the bidder’s pretargeting on some inventory, such as browser, environment, or mobile OS.
The signal is deprioritized by the bidder in preference for third-party cookies or device IDs (EEA only)
The secure signal has been generated, but is empty.

Note: Google doesn't have visibility into why a certain signal might not be generated correctly. Work directly with the signal provider to troubleshoot why this is happening or to ensure your configuration is correct.

Learn more about Authorized Buyer secure signal troubleshooting and pretargeting.

Secure signals are not present

When reporting on secure signals, there are a number of cases when a secure signal may not be present on an ad request to bidders:

The publisher hasn’t allowed secure signals sharing, or secure signal sharing with bidders, or has yet to complete any required integration work as specified by certain secure signal providers.
The signal hasn’t been generated. Work with your signal provider if the signal collection script requires information or integration.
The ad request might be non-personalized and you are not sharing secure signals on non-personalized (NPA) ad requests. To enable non-personalized ad requests, go to "Secure signals settings", and select "Share" to share secure signals on NPA ad requests.

In general, not all users have an ID from every provider. For example, a user might visit your site for the first time, but an ID hasn't been generated yet. Users that clear their cookies can delete IDs stored locally. Users may also have privacy or browser settings that prevent IDs from being created or shared.

Caching

The content of the secure signal that is passed to a Google publisher tag (GPT) is cached to reduce latency on subsequent requests. Any script fetch and execution that blocks sending the ad request introduces a delay to all demand causing a reduction in viewability and revenue.

To eliminate this cost, especially considering secure signals might apply only to some demand despite latency potentially impacting all demand, GPT caches the generated, obfuscated signals in first-party local storage with a stale-while-revalidate mechanism as follows:

GPT looks in local storage for the presence of a previously generated signal and timestamp of when it occurred.
If not in cache, trigger signal generation and send ad request. There is no guarantee that the signal is included in this request.
If in cache but the time since generation exceeds expiration time, trigger signal generation and send the ad request. There is no guarantee that the signal is included in this request.
If in cache, the time since generation is outside of stale window, but within expiration time, trigger signal generation but include cached signal in current request.
Any flow that causes signal generation results in its storage within cache so that it can be used for later requests on the page, such as refresh, additional slots, and subsequent page views given local storage domain siloing.

Use delivery tools or ad inspector

In mobile app environments, you can verify signals are being passed using either Delivery tools or Ad inspector. If secure signals are missing, make sure that the ad units coded into the map exactly match the ad units in Google Ad Manager, because they are case sensitive. You can learn more about troubleshooting secure signals delivery in mobile app environments by reviewing the Verify your SDK Bidding setup and Inspect mobile app ad delivery articles.

Use developer tools

In web environments, you can inspect a browser’s local storage to find if signals are present.

In Chrome, click , then More tools, and then < > Developer tools.
Click the "Application" tab.
Under the "Storage' pane and "Local storage," click the URL (such as https://example.com). The site's local storage data displays.
Identify the "Key" corresponding to the signal provider.

It may be in the form of _GESPSK-<signal-provider.com>.
If you see the desired signal(s) in the corresponding entry, the signal has been cached in the browser’s local storage and is being sent.

Consult with your secure signal provider

We recommend that publishers work with their secure signal provider(s) to ensure their implementation is healthy. Additionally, go through previous steps to manage errors and misconfigurations. Working with your secure signal provider directly ensures the script is loading and operating as expected.

Was this helpful?

How can we improve it?