Внесение шума — это метод защиты конфиденциальности пользователя при выполнении запросов к базе данных. Он работает путём добавления случайного шума к агрегирующему предложению SELECT запроса. Этот шум защищает конфиденциальность пользователя, обеспечивая при этом достаточно точные результаты, устраняя необходимость в проверке различий и снижая требуемый порог агрегации для выходных данных. Большинство существующих запросов можно выполнять в режиме шума, но с некоторыми ограничениями .
Узнайте о преимуществах использования шумоподавления
Проверка различий не применяется: при выполнении запросов с добавлением шума Ads Data Hub не фильтрует строки по признаку сходства с предыдущими наборами результатов. Это означает, что вы по-прежнему можете получить целостное представление данных, сохраняя при этом конфиденциальность пользователей.
Упрощено устранение неполадок: строки опускаются только из-за требований агрегации, что упрощает устранение неполадок и адаптацию запросов.
Не нужно изучать новый синтаксис: вам не нужно изучать какой-либо новый синтаксис запроса или разбираться в концепциях конфиденциальности, чтобы использовать шум вместо проверок различий.
Точность результатов очевидна: успешное задание показывает общий процент данных с ожидаемым количеством шума.
Узнайте, как шум влияет на требования к конфиденциальности
Проверка различий: Вставка шума не использует существующие проверки различий в Ads Data Hub. При использовании вставки шума проверки различий отключаются.
Требование к агрегации: Вставка шума выводит данные о показах, представленные приблизительно 20 или более уникальными пользователями, и данные о кликах или конверсиях, представленные приблизительно 10 или более уникальными пользователями.
Статические проверки: нет воздействия.
Бюджеты и ограничения запросов: запросы, выполняемые с использованием шума, используют тот же бюджет доступа к данным, что и проверки различий. Как и в случае с проверками различий, если вы выполняете один и тот же запрос к одному и тому же набору данных много раз, вы можете потерять доступ к часто запрашиваемым датам в наборе данных. Это может произойти при выполнении запросов со скользящим окном или при многократном выполнении одного и того же запроса.
Режим шума накладывает дополнительные, более строгие ограничения на повторное вычисление тех же агрегированных результатов в рамках запросов или между ними. Как и в случае с бюджетом доступа к данным, вы можете потерять доступ к часто запрашиваемым датам в наборе данных; но ограничения, связанные с повторным вычислением тех же агрегированных результатов, будут ограничивать только запросы в режиме шума, но не запросы в режиме проверки различий. Подробнее см. в разделе Повторные результаты .
Узнайте больше о проверках конфиденциальности .
Понять, как введение шума влияет на результаты
Ads Data Hub вводит шум, чтобы снизить риск раскрытия информации — риск того, что кто-то узнает информацию об отдельном пользователе. Это позволяет найти баланс между конфиденциальностью и полезностью.
Вставка шума в Ads Data Hub преобразует результаты запроса следующим образом:
- Он ограничивает вклад пользователей, выпадающих из общего списка, в агрегированные результаты. Он суммирует вклад каждого пользователя в каждой агрегации, а затем ограничивает каждый вклад минимальными и максимальными границами ограничения.
- Он объединяет фиксированные вклады каждого пользователя.
- Он добавляет шум к каждому агрегированному результату — результату каждого вызова агрегирующей функции в каждой строке. Масштаб этого случайного шума пропорционален установленным границам.
- Он вычисляет количество пользователей с шумом для каждой строки и исключает строки со слишком малым их числом. Это похоже на k-анонимность в режиме проверки различий, но из-за шума задания, работающие с одним и тем же набором данных, могут удалять разные строки. Кроме того, в режиме шума удаляется меньше строк, поскольку требования к агрегации ниже (примерно 20 против ровно 50).
Конечный результат представляет собой набор данных, в котором каждая строка содержит зашумлённые агрегированные результаты, а небольшие группы данных были исключены. Это скрывает влияние отдельных пользователей на возвращаемые результаты.
О фиксации агрегации
В Ads Data Hub для вставки шума используется явное или неявное ограничение агрегации для ограничения влияния выбросов. Вы можете выбрать тип ограничения в зависимости от вашего варианта использования.
Неявное зажатие
При неявном ограничении границы определяются автоматически. Для использования неявного ограничения не требуется специальный синтаксис SQL. Если диапазон значений одной строки шире, чем у другой, неявное ограничение находит разные границы для этих строк. Обычно это обеспечивает меньшую погрешность для каждого результата. С другой стороны, каждая агрегация получает разные границы ограничения и уровни шума, что может затруднить их сравнение.
Неявное ограничение может привести к сбою, если агрегация получает данные от слишком малого числа пользователей, например, при вызове функции COUNTIF() с редким условием. В таких случаях возвращается NULL . Также обратите внимание, что COUNT(DISTINCT user_id) автоматически использует явное ограничение с границами 0 и 1 .
Явное зажатие
Явное ограничение ограничивает общий вклад каждого пользователя заданным диапазоном. Явные границы применяются ко всем строкам одинаково и должны быть литеральными значениями . Даже если в некоторых строках диапазон вклада каждого пользователя шире, чем в других, ко всем ним применяются одни и те же границы. Это делает результаты для разных строк более сопоставимыми, хотя в некоторых строках уровень шума выше, чем при неявном ограничении.
Явное ограничение создаёт вдвое меньше шума, чем неявное, при заданном наборе границ ограничения. Поэтому, если вы можете оценить разумные границы, вы получите лучшие результаты, задав их явно.
Чтобы использовать явное ограничение, установите границы для каждой поддерживаемой агрегатной функции, добавив целые числа, представляющие нижнюю и верхнюю границы. Например:
SELECT
campaign_name,
-- Set lower and upper bounds to 0 and 1, respectively
ADH.ANON_COUNT(*, contribution_bounds_per_group => (0,1))
FROM data
GROUP BY 1
Выполнить запрос с использованием инъекции шума
- Откройте отчет.
- Установите переключатель настроек конфиденциальности шума в положение «Использовать шум» .
- Выполнить запрос .
- Оцените воздействие дополнительного шума.
- Дополнительно: адаптируйте запрос , чтобы снизить влияние шума.
Оценить воздействие шума
После успешного завершения задания Ads Data Hub отображает надёжность результата в сводке конфиденциальности. Надёжность рассчитывается на основе процента ячеек в выходных данных, на которые сильно повлиял шум. Значение в таблице результатов считается сильно затронутым, если масштаб добавленного шума превышает 5% от результата в ячейке.
Для затронутых выходных наборов данных в сводке по конфиденциальности перечислены десять наиболее шумных столбцов от наибольшего к наименьшему уровню воздействия и их соответствующий вклад в шум. Это разбивка ожидаемого уровня шума.
| Результаты с уровнем шума >5% | Цвет индикатора | Влияние |
|---|---|---|
| <5% | Зеленый | Низкое воздействие |
| 5%-15% | Желтый | Средний удар |
| 15%-25% | Апельсин | Большое влияние |
| >25% | Красный | Очень сильное воздействие |
Вы также можете просмотреть сводку по конфиденциальности для недавних заданий по отчётам на главной странице. Чтобы просмотреть сведения о конфиденциальности для конкретного задания, наведите указатель мыши на значок совета по конфиденциальности privacy_tip на карточке задания в разделе «Недавние действия» .
Адаптировать запросы
Агрегированные результаты с большей вероятностью будут содержать непредвиденный уровень шума, если на них влияет мало пользователей. Это может произойти, когда в строках мало пользователей или когда некоторые пользователи не влияют на результаты, например, при использовании функции COUNTIF . Исходя из данных о шуме, вы можете скорректировать запрос, чтобы увеличить процент данных с ожидаемым уровнем шума.
Ниже приведены общие рекомендации:
- Расширьте диапазон дат.
- Перепишите запрос, чтобы уменьшить детализацию данных, например, сгруппировав их по меньшему числу параметров или заменив
COUNTIFнаCOUNT. - Удалите шумные столбцы.
- Используйте явное ограничение .
Поддерживаемые агрегатные функции
Следующие агрегатные функции поддерживаются с шумом:
-
SUM(...) -
COUNT(*) -
COUNT(...) -
COUNTIF(...) -
COUNT(DISTINCT user_id) -
APPROX_COUNT_DISTINCT(user_id) -
AVG(...)
Ключевое слово DISTINCT поддерживается только с функцией COUNT и только при использовании с прямой ссылкой на столбец user_id из таблицы Ads Data Hub или выражением, которое возвращает user_id или NULL , например COUNT(DISTINCT IF(..., user_id, NULL)) .
О целочисленных результатах
Хотя Ads Data Hub автоматически добавляет шум для этих функций агрегации, сигнатуры функций не меняются. Поскольку функции, такие как COUNT или SUM от INT64 , возвращают INT64 , любая десятичная часть зашумленного результата округляется. Обычно это пренебрежимо мало по сравнению с размером результата и шумом.
Если вам нужна точность десятичной дроби в результате, избегайте написания функций, возвращающих INT64 , например, используйте SUM с преобразованием ее входных данных в FLOAT64 .
Об отрицательных результатах
В принципе, шум с очень малыми значениями может привести к отрицательным числам, даже если это семантически невозможно для запроса. Для поддержания ожидаемого поведения все формы COUNT и COUNTIF автоматически ограничиваются нулем, поэтому они никогда не дают отрицательных результатов. Если вы хотите получить такое же поведение с другой функцией, например, SUM , вы можете ограничить результаты вручную, используя GREATEST(0, SUM(...)) .
Это изменение обычно незначительно, но оно вносит небольшое положительное смещение в общие результаты. Если вам нужно этого избежать, попробуйте использовать ADH.ANON_COUNT вместо COUNT или GROUP BY ROLLUP для вычисления общего количества элементов по строкам.
Поддерживаемые шаблоны запросов
Важно : большинство стандартных рекомендаций Ads Data Hub по-прежнему применимы к запросам, использующим шумовые данные. В частности, мы рекомендуем вам ознакомиться с рекомендациями по повторным запросам одних и тех же данных .
В этом разделе описываются шаблоны запросов, которые поддерживаются при выполнении запросов с использованием внедрения шума.
Агрегаты на уровне пользователя
Неограниченные агрегации на уровне пользователя поддерживаются так же, как и в режиме проверки различий. Шум добавляется только в агрегации, объединяющие данные нескольких пользователей. Агрегации, явно группирующие по user_id , или аналитические функции, разделяющие данные по user_id , не получают никакого шума, и разрешены любые функции. Агрегации на уровне пользователя, которые явно не группируют данные по user_id , например, GROUP BY impression_id , рассматриваются как кросс-пользовательские агрегации, поэтому шум добавляется.
Группировки по external_cookie недостаточно. Хотя external_cookie можно использовать для объединения таблиц *_match с таблицами, принадлежащими клиентам, любые агрегации для одного пользователя должны явно группироваться по столбцу user_id, а не только по столбцу external_cookie.
Пример агрегатной функции:
WITH user_paths AS (
# Grouping by user_id, no noise needed, all functions allowed
SELECT user_id, STRING_AGG(campaign_id, ">" ORDER BY query_id.time_usec) AS path
FROM adh.google_ads_impressions
GROUP BY 1
)
# Noise applied here to num_users
SELECT path, COUNT(*) AS num_users
FROM user_paths
GROUP BY 1;
Пример аналитической функции:
WITH events AS (
# Partitioning by user_id, no noise needed, all functions allowed
SELECT
campaign_id,
ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY query_id.time_usec) AS index
FROM adh.google_ads_impressions
)
# Noise applied here to first_impressions
SELECT campaign_id, COUNT(*) AS first_impressions
FROM events
WHERE index = 1
GROUP BY 1;
Параллельные агрегаты
Каждая межпользовательская агрегация получает шум независимо. Вы можете запустить несколько таких агрегаций в одном операторе, объединяя результаты в одну таблицу с помощью JOIN или UNION .
Пример:
WITH result_1 AS (
# Noise applied here to num_impressions
SELECT campaign_id, COUNT(*) AS num_impressions
FROM adh.google_ads_impressions
GROUP BY 1
), result_2 AS (
# Noise applied here to num_clicks
SELECT campaign_id, COUNT(*) AS num_clicks
FROM adh.google_ads_clicks
GROUP BY 1
)
SELECT * FROM result_1 JOIN result_2 USING(campaign_id)
Обратите внимание, что это поддерживается, но этого следует избегать в режиме проверки разностей. Эта практика не создаёт проблем с шумом, поскольку каждый параллельный агрегат подвергается шуму и фильтруется независимо.
Агрегированные данные, объединенные с неагрегированными данными
Поскольку Ads Data Hub поддерживает только аналитические окна, сепарируемые по user_id , распространённым решением является раздельное агрегирование этих результатов и их самообъединение перед повторным агрегированием. Такие запросы поддерживаются в режиме шума и часто работают лучше, чем в режиме проверки различий, благодаря более раннему выполнению требований конфиденциальности.
Пример:
WITH campaign_totals AS (
# Noise applied here to campaign_imps
SELECT campaign_id, COUNT(*) AS campaign_imps
FROM adh.google_ads_impressions
GROUP BY 1
)
# Noise applied here to imps
SELECT campaign_id, demographics, campaign_imps, COUNT(*) AS imps
FROM adh.google_ads_impressions JOIN campaign_totals USING(campaign_id)
GROUP BY 1,2,3
Режим шума препятствует повторному агрегированию совокупных результатов, таких как AVG(campaign_imps) .
Неподдерживаемые шаблоны запросов
В этом разделе описываются шаблоны запросов, которые не поддерживаются при выполнении запросов с использованием внедрения шума.
Запросы, включающие сегодня
Запросы в режиме шума не поддерживают запросы к данным за текущий день. (Это не рекомендуется делать в режиме проверки различий.) Текущая дата не может быть выбрана для запросов, использующих внедрение шума.
Повторные результаты
В режиме шума Ads Data Hub ограничивает частоту повторения одной и той же агрегации. При достижении этих ограничений запросы в режиме шума потеряют доступ к часто запрашиваемым датам в наборе данных. Ниже приведены примеры того, как это может произойти.
Повторение запроса происходит, когда один и тот же запрос выполняется несколько раз с одинаковыми или очень похожими параметрами, например, с перекрывающимися диапазонами дат. Этого можно избежать, используя данные, уже экспортированные в ваш проект BigQuery.
Обратите внимание, что если два задания запрашивают данные из перекрывающихся диапазонов дат, они могут создавать повторения при выполнении одних и тех же вычислений для одних и тех же пользователей. Например, следующий запрос, выполняемый для перекрывающихся диапазонов дат, создаёт повторения, поскольку он разбивает данные по дате:
SELECT DATE(TIMESTAMP_MICROS(event.event_time)) AS date,
COUNT(*) AS cnt
FROM adh.cm_dt_clicks
GROUP BY 1
В этом случае вам следует выполнить запрос по непересекающимся сегментам дат.
Другой пример повторения возникает, когда данные в какой-то степени независимы от даты. Следующий запрос создаёт повторения при выполнении в перекрывающиеся даты, когда оба задания охватывают весь жизненный цикл кампании:
SELECT campaign_id, COUNT(*) AS cnt
FROM adh.google_ads_impressions
GROUP BY 1
В этом случае вам следует выполнить этот запрос только один раз, поскольку результат не изменится.
Повторение агрегации происходит, когда одна и та же агрегация повторяется несколько раз в запросе:
SELECT COUNT(*) AS cnt1, COUNT(*) AS cnt2
FROM table
В этом случае следует удалить один из повторов.
Обратите внимание, что даже если агрегации синтаксически различны, но вычисляют одно и то же значение, это будет считаться повторением. Другими словами, если значения condition1 и condition2 одинаковы для всех пользователей с каким-либо значением key , следующий запрос будет содержать повторение:
SELECT key, COUNTIF(condition1) AS cnt1, COUNTIF(condition2) AS cnt2
FROM table
GROUP BY key
Если у вас есть условия, которые очень похожи для некоторых групп пользователей, вы можете рассмотреть возможность переписывания запроса так, чтобы в нем был только один COUNT .
Дублирование строк происходит при объединении таблицы Ads Data Hub с таблицей BigQuery таким образом, что каждая строка из таблицы Ads Data Hub соответствует нескольким строкам в таблице BigQuery. Например, следующий запрос создаст повторение, если в таблице bq_table есть несколько строк с одинаковым идентификатором кампании:
SELECT r.campaign_id, COUNT(*) AS cnt
FROM adh_table
INNER JOIN bq_table ON l.campaign_id = r.campaign_id
В этом случае следует реструктурировать запрос так, чтобы bq_table имела только одну строку на каждое значение ключа соединения (в данном случае campaign_id ).
Обратите внимание, что извлечение массива из таблицы Ads Data Hub может привести к тому же эффекту, если у большинства пользователей одинаковые массивы значений:
SELECT in_market_id, COUNT(*)
FROM adh.dv360_youtube_impressions,
UNNEST(in_market) AS in_market_id
GROUP BY 1
Узнайте о других передовых методах выполнения запросов .
Прямая реагрегация
Шум применяется к первому уровню кросс-пользовательской агрегации в запросе. Запросы с несколькими уровнями агрегации объединяют зашумленные результаты, поэтому итоговые агрегированные данные могут содержать гораздо больше шума. Такие запросы получают предупреждение при проверке:
WITH layer_1 AS (
# Noise applied here to partial_result
SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
FROM adh.google_ads_impressions
GROUP BY 1,2,3
HAVING partial_result > 5
)
# Reaggregation of partial_result with no user-level data, will be rejected
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1
Чтобы получить наилучшие результаты при использовании шума, вычисляйте все межпользовательские операции в рамках одной агрегации. Например, используйте SUM событий, а не SUM промежуточных значений.
Если многоуровневая агрегация неизбежна, вы можете устранить предупреждение, экспортировав результаты непосредственно из первого уровня. Чтобы сделать это в рамках одного задания, не изменяя результаты скрипта, создайте временную таблицу (или таблицу, экспортированную в ваш проект BigQuery) с синтаксисом OPTIONS(privacy_checked_export=true) . Например:
CREATE TEMP TABLE layer_1 OPTIONS(privacy_checked_export=true) AS (
# Noise applied here to partial_result
SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
FROM adh.google_ads_impressions
GROUP BY 1,2,3
HAVING partial_result > 5
);
# Reaggregation of privacy checked data, no noise needed
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1
Узнайте больше о временных таблицах .
Если первый уровень агрегации слишком детализирован для проверки конфиденциальности, рассмотрите возможность переписывания запроса с использованием агрегации на уровне пользователя . Если это невозможно, то запрос не поддерживается в режиме шума.
Неприсоединенные идентификаторы пользователей
Запросы в режиме шума не должны объединять данные отдельных пользователей в одну строку, за исключением случаев агрегации с шумом. Поэтому объединения неагрегированных данных Ads Data Hub должны явно объединяться по столбцу user_id .
Этот запрос явно не присоединяется к столбцу user_id , что приводит к предупреждению проверки:
SELECT …
FROM adh.google_ads_impressions
JOIN adh.google_ads_clicks USING(impression_id)
Подобные объединения могут вести себя не так, как ожидается, поскольку будут совпадать только строки с одинаковым значением user_id . Это можно исправить, указав в предложении USING явное значение user_id , например, USING(impression_id, user_id) .
Обратите внимание, что это ограничение применяется только к соединениям таблиц Ads Data Hub (за исключением таблиц измерений). Оно не распространяется на таблицы, принадлежащие клиентам. Например, разрешено следующее:
SELECT …
FROM adh.google_ads_impressions
JOIN bigquery_project.dataset.table USING(any_column)
Ads Data Hub-BigQuery правые соединения
Внешние соединения с данными, принадлежащими клиентам, могут привести к появлению строк с отсутствующими идентификаторами пользователей, что помешает корректной работе шума.
Оба этих запроса приводят к предупреждениям проверки, поскольку они допускают наличие несоответствующих строк с отсутствующими идентификаторами пользователей на стороне Ads Data Hub:
SELECT …
FROM adh.google_ads_impressions
RIGHT JOIN bigquery_project.dataset.table USING(column)
SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions USING(column)
Обратите внимание, что любое из этих объединений будет работать, если порядок таблиц обратен. Существует также исключение для таблиц RDID, которые объединяются непосредственно по device_id_md5 . Например, следующий запрос будет работать без предупреждений:
SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions_rdid USING(device_id_md5)
Сводка отфильтрованных строк
Спецификация сводки отфильтрованных строк не поддерживается в режиме шума. В шумовом режиме эта функция зачастую не нужна из-за низких скоростей фильтрации и отсутствия фильтрации при проверке разностей.
Если вы наблюдаете значительную фильтрацию данных в шумовом результате, увеличьте объём агрегированных данных. Вы можете выполнить параллельное агрегирование по всему набору данных, чтобы сравнить общую оценку, например:
SELECT campaign_name, COUNT(*)
FROM data
GROUP BY 1
UNION ALL
SELECT 'Total', COUNT(*)
FROM data
GROUP BY 1
Обратите внимание, что общее количество подвергается независимому шуму, и общие значения могут не суммироваться, но общее количество часто точнее, чем сумма зашумленных строк.
Таблицы, созданные в кросс-режиме
Неэкспортированные таблицы в Ads Data Hub можно использовать только в том же режиме конфиденциальности, в котором они были созданы. Нельзя создать таблицу в обычном режиме агрегации и использовать её в режиме шума, и наоборот (если только эта таблица предварительно не экспортирована в BigQuery).