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 users1 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.
  • Aggregation requirements. Aggregation requirements ensure that every row contains a large enough number of users to protect end-user privacy.

  • Differential requirements. Differential requirements 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. Differential requirement violations can be triggered by changes to your underlying data between two jobs.

When a result doesn’t pass privacy checks, Ads Data Hub omits the results without notifying you. This can be any row that was deemed risky, or an entire results set. However, the filtered row summary feature can be used to summarize the dropped rows, unless prevented by privacy restrictions, such as when the users in a filtered row summary don’t meet aggregation requirements.

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

Differential requirements

Differential 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 differential 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 differential 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 results 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 pick up data that was filtered due to privacy checks. Data from filtered rows is summed and added to a catch-all row. While the data isn’t useful for analysis, it provides a summary of how much data was filtered from the results.

In the example below, the rows containing campaigns 124 and 125 would be filtered, as they don’t meet the 50-user aggregation requirement.

Campaign ID Users
123 400
124 45
125 6

However, using a filtered row summary, the filtered data can be combined to meet the 50-user aggregation requirement.

Campaign ID Users
null 51
123 400

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