Privacy checks in Ads Data Hub

End-user privacy is at the core of everything that Ads Data Hub does; it's the foundation that our platform is built upon. In order to help maintain that privacy and help our customers with regulatory compliance, we impose certain checks and restrictions, designed to help prevent the transmission of data about individual users¹ in the data that you get out of the platform. Here is an overview of the checks, with more detail in the sections below:

• Static checks. Static checks examine the statements in your queries to look for obvious and immediate privacy concerns, such as:
  • Exporting user identifiers, or any function of user identifiers.
  • Using blocklisted functions over fields that contain user-level data.
• Data access budget. Your data access budget limits the total number of times that you can access a given piece of data. Users approaching the end of their budget will be notified via a privacy message with type DATA_ACCESS_BUDGET_IS_NEARLY_EXHAUSTED. You may monitor the budget using the data access budget entry point or by observing budget notifications in the UI.
• Aggregation requirements. Aggregation requirements ensure that every row contains a large enough number of users to protect end-user privacy.

• Difference checks. Difference checks compare results from the job that you're running to your previous results, as well as rows from the same result set. This is designed to help prevent you from gathering information about individual users by comparing data from multiple sets of users that meet our aggregation requirements. Difference check violations can be triggered by changes to your underlying data between two jobs.

When a result doesn't pass privacy checks, Ads Data Hub will display or return a privacy message informing you that a row was filtered. This can be anything from a single row, to an entire result set. To ensure that your reporting totals remain accurate, use a filtered row summary to count data from dropped rows².

Note: Whenever possible, use sandbox data to iterate on and test queries. Jobs using sandbox data won't contribute to difference check violations.

Aggregation requirements

At the core of Ads Data Hub's privacy checks is the user aggregation threshold. For most queries, you can only receive reporting data on 50 or more users. However, queries that only access clicks and conversions can be used to report on 10 or more users. (Users with null IDs don't count towards this aggregation threshold.)

In the example below, the row containing campaign 125 would be filtered from the final results, because it aggregates results from 48 users, which is below the 50-user minimum. Filtered rows are those omitted from the results due to privacy restrictions.

Campaign	Users	Impressions
123	314	928
124	2718	5772
125	48	353

Note: Events with zeroed user IDs count as a single user toward the 50-user minimum, no matter how many actual users created these events.

Note: Configure a filtered row summary to report on data that was omitted. This helps to maintain a consistent baseline in your reports.

Difference checks

Warning: As per the Ads Data Hub policies, do not attempt to disaggregate data in an attempt to disambiguate sets of users that don't meet our aggregation requirements.

Difference checks help ensure that users can't be identified through the comparison of multiple sufficiently aggregated results. When comparing a job's results to previous results, Ads Data Hub looks for vulnerabilities on the level of individual users. Because of this, even results from different campaigns, or results that report the same number of users, can be filtered if they have a large number of overlapping users.

On the other hand, two aggregated result sets may have the same number of users--appearing identical--but not share individual users, and therefore be privacy-safe, in which case they wouldn't be filtered.

Ads Data Hub uses data from your historical results when considering the vulnerability of a new result. This means that running the same query over and over again creates more data for difference checks to use when considering a new result's vulnerability. Additionally, the underlying data can change, leading to privacy check violations on queries thought to be stable.

Tip: Whenever possible, use sandbox data to iterate on and test queries. Jobs using sandbox data won't contribute to difference check violations.

When your job-level results differ adequately, but an individual row is similar to a row in a previous job, Ads Data Hub will filter the similar row. In the example below, the row containing campaign 123 in the second result will be filtered, because it differs from the previous result by a single user.

Job 1			Job 2
Campaign ID	Users		Campaign ID	Users
123	400		123	401
124	569		224	1325

If the sum of the users in all rows in a result set is similar to that from a previous job, Ads Data Hub will filter the entire result set. In the example below, all results from the second job will be filtered.

Job 1			Job 2
Campaign ID	Users		Campaign ID	Users
123	400		123	402
124	1367		124	1367

Filtered row summary

Filtered row summaries tally data that was filtered due to privacy checks. Data from filtered rows is summed and added to a catch-all row. While the filtered data can't be further analyzed, it provides a summary of how much data was filtered from the results.

Note: Aggregation requirements apply to filtered row summaries themselves. If the resulting filtered row summary falls below aggregation requirements, the filtered row summary itself will be filtered.

Query advisor

If your SQL is valid but might trigger excessive filtering, the query advisor surfaces actionable advice during the query development process, to help you avoid undesirable results.

Triggers include the following patterns:

• Joining aggregated subqueries
• Joining unaggregated data with potentially different users
• Recursively defined temp tables

To use the query advisor:

• UI. Recommendations will be surfaced in the query editor, above the query text.
• API. Use the customers.analysisQueries.validate method.

---

1. Other than data they have consented to share, such as in the case of panelists. ↩

2. Unless prevented by privacy restrictions, such as when the users in a filtered row summary don't meet aggregation requirements. ↩