Добавление случайных данных

Введение шума — это метод, используемый для защиты конфиденциальности пользователей при запросах к базе данных. Он работает путем добавления случайного шума к агрегирующему предложению SELECT запроса. Этот шум защищает конфиденциальность пользователей, обеспечивая при этом достаточно точные результаты, устраняя необходимость в проверках различий и снижая требуемый порог агрегации для вывода. Большинство существующих запросов могут быть выполнены в режиме шума, с некоторыми ограничениями .

Важно: аккредитация MRC от Ads Data Hub не распространяется на запросы, выполняемые в режиме шумовых помех.

Узнайте о преимуществах использования шумоподавления.

Проверки на различия не применяются: при выполнении запросов с добавлением шума Ads Data Hub не фильтрует строки по признаку сходства с предыдущими наборами результатов. Это означает, что вы по-прежнему можете получить целостное представление о данных, защищая при этом конфиденциальность пользователей.

Процесс устранения неполадок упрощен: строки исключаются только в связи с требованиями агрегирования, что упрощает поиск и адаптацию запросов.

Нет необходимости изучать новый синтаксис: вам не нужно осваивать новый синтаксис запросов или разбираться в концепциях конфиденциальности, чтобы использовать шум вместо проверок на различия.

Сообщается о точности результатов: в случае успешного выполнения задания отображается общий процент данных, которые могли быть искажены шумом.

Узнайте, как шум влияет на требования к обеспечению конфиденциальности.

Проверка различий: Вставка шума не зависит от существующих проверок различий в Ads Data Hub. При использовании вставки шума проверки различий отключаются.

Требование к агрегации: для вывода данных о показах используются данные примерно от 20 или более уникальных пользователей, а для данных о кликах или конверсиях — данные примерно от 10 или более уникальных пользователей.

Статические проверки: не оказывают влияния.

Бюджеты и ограничения запросов: Запросы, выполняемые с использованием шума, используют тот же бюджет доступа к данным, что и проверки различий. Как и в случае с проверками различий, если вы выполняете один и тот же запрос к одному и тому же набору данных много раз, вы можете потерять доступ к часто запрашиваемым датам в наборе данных. Это может произойти, если вы используете запросы со скользящим окном или если вы делаете один и тот же запрос несколько раз.

Режим «Шум» накладывает дополнительные, более строгие ограничения на повторное вычисление одних и тех же агрегированных результатов внутри или между запросами. Как и в случае с ограничением доступа к данным, вы можете потерять доступ к часто запрашиваемым датам в наборе данных; однако ограничения, связанные с повторным вычислением одних и тех же агрегированных результатов, будут ограничивать запросы только в режиме «Шум», а не запросы в режиме проверки различий. Для получения дополнительной информации см. раздел «Повторяющиеся результаты» .

Узнайте больше о проверках конфиденциальности .

Поймите, как введение шума влияет на результаты.

Ads Data Hub добавляет шум, чтобы снизить риск раскрытия информации — риск того, что кто-то сможет узнать информацию об отдельном пользователе. Он уравновешивает конфиденциальность и полезность.

Вставка шумовых данных в Ads Data Hub преобразует результаты запроса следующим образом:

• Он ограничивает вклад пользователей, выходящих за рамки допустимых значений, в агрегированных результатах. Он суммирует вклад каждого пользователя в каждой агрегации, а затем ограничивает каждый вклад минимальным и максимальным значениями.
• Она суммирует ограниченные взносы каждого пользователя.
• Это добавляет шум к каждому результату агрегирования — результату каждого вызова функции агрегирования в каждой строке. Масштаб этого случайного шума пропорционален установленным границам.
• Он вычисляет количество пользователей с шумом для каждой строки и удаляет строки со слишком малым количеством пользователей. Это похоже на k-анонимность в режиме проверки различий, но из-за шума задания, работающие с одним и тем же набором данных, могут отбрасывать разные строки. Кроме того, в режиме проверки шума отбрасывается меньше строк, поскольку требования к агрегации ниже (приблизительно 20 против ровно 50).

В итоге получается набор данных, в каждой строке которого содержатся зашумленные агрегированные результаты, а небольшие группы исключены. Это маскирует влияние отдельного пользователя на возвращаемые результаты.

О блокировке агрегации

В Ads Data Hub для добавления шума используется неявное или явное ограничение агрегации, чтобы ограничить влияние выбросов. Вы можете выбрать тип ограничения в зависимости от ваших задач.

Неявное ограничение

Для использования неявного ограничения значений не требуется специальный синтаксис SQL, оно применяется по умолчанию. Неявные границы выводятся из самих данных и определяются для каждой агрегации. Если некоторые агрегации имеют более широкий диапазон значений, чем другие, неявное ограничение может определять разные границы для разных агрегаций в зависимости от ситуации. Это обычно приводит к уменьшению количества ошибок. Обратите внимание, что COUNT(DISTINCT user_id) автоматически ограничивает вклад каждого пользователя до 1 .

Явное ограничение

Явное ограничение суммарного вклада каждого пользователя ограничивает его заданным диапазоном. Явные границы применяются единообразно ко всем агрегациям и должны быть литеральными значениями . Явное ограничение может давать лучшие результаты, когда границы, как правило, известны. Например, ограничение возраста от 0 до 100 отражает общедоступную информацию, поскольку возраст большинства людей обычно находится в этом диапазоне.

Ads Data Hub предоставляет дополнительные агрегатные функции ADH.ANON для явного ограничения значений. Для использования явного ограничения значений установите границы для каждой поддерживаемой агрегатной функции, сложив целые числа, представляющие нижнюю и верхнюю границы. Например:

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

Выполните запрос с использованием внедрения шума.

1. Откройте отчёт.
2. Переведите переключатель настроек шума в разделе «Конфиденциальность» в положение «Использовать шум» .
3. Выполните запрос .
4. Проанализируйте влияние дополнительного шума.
5. Дополнительно: адаптируйте запрос для уменьшения влияния шума.

Проанализируйте воздействие шума.

После успешного завершения задачи Ads Data Hub отображает достоверность результата в сводке конфиденциальности. Достоверность определяется на основе процента ячеек в выходных данных, которые могут быть сильно подвержены влиянию шума. Значение в таблице результатов считается подверженным влиянию шума, если масштаб добавленного шума превышает 5% от результата в ячейке.

Для затронутых наборов выходных данных в сводке по вопросам конфиденциальности перечислены десять наиболее зашумленных столбцов в порядке убывания степени влияния и их соответствующий вклад в уровень шума. Это разбивка меток влияния шума.

% затронутых результатов	Цвет индикатора	Влияние
<5%	Зеленый	Низкий уровень воздействия
5%-15%	Желтый	Среднее воздействие
15%-25%	Апельсин	Высокое воздействие
>25%	Красный	Очень сильное воздействие

Вы также можете предварительно просмотреть сводку конфиденциальности для последних заданий отчетов на главной странице. Чтобы просмотреть конфиденциальность для конкретного задания, наведите указатель мыши на значок подсказки по конфиденциальности privacy_tip в карточке задания в разделе «Последняя активность» .

Адаптируйте запросы

При небольшом количестве пользователей, влияющих на результат, агрегирование данных с большей вероятностью будет подвержено влиянию шума. Это может произойти, когда агрегирование выполняется на основе небольших групп пользователей или когда некоторые пользователи не влияют на результаты, что может случиться, например, с функцией COUNTIF . На основе отчета о шуме вы можете скорректировать свой запрос, чтобы уменьшить процент результатов, подверженных влиянию шума.

Ниже приведены общие рекомендации:

• Расширьте диапазон дат.
• Перепишите запрос, чтобы уменьшить детализацию данных, например, сгруппировав данные по меньшему количеству параметров или заменив COUNTIF на COUNT .
• Удалите шумные колонки.
• В тех случаях, когда можно выбрать разумные границы, рекомендуется явное ограничение значений .

---

Поддерживаемые агрегатные функции

Следующие агрегатные функции поддерживаются с учетом шума:

• SUM(...)
• COUNT(*)
• COUNT(...)
• COUNTIF(...)
• COUNT(DISTINCT ...)
• APPROX_COUNT_DISTINCT(...)
• AVG(...)

Ключевое слово DISTINCT поддерживается только с функцией COUNT . При использовании с прямой ссылкой на столбец user_id из таблицы Ads Data Hub или выражением, возвращающим либо user_id , либо NULL , например COUNT(DISTINCT IF(..., user_id, NULL)) , функции COUNT DISTINCT и APPROX_COUNT_DISTINCT(...) вычисляются с ограничением вклада каждого пользователя до 1 Когда COUNT DISTINCT ссылается на столбец, отличный от user_id , он аппроксимируется с помощью APPROX_COUNT_DISTINCT с неявным ограничением.

Дополнительные агрегатные функции

В дополнение к поддержке обычных агрегаторов, Ads Data Hub представляет дополнительные агрегатные функции ADH.ANON , поддерживающие явное ограничение значений. Эти агрегаторы имеют тот же синтаксис, что и агрегатные функции BigQuery с дифференциальной приватностью , однако для их работы не требуется предложение WITH DIFFERENTIAL_PRIVACY :

• ADH.ANON_SUM( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_COUNT( *, [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_COUNT( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_AVG( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_PERCENTILE_CONT( ..., percentile, contribution_bounds_per_row => (lower_bound, upper_bound) )

• ADH.ANON_COUNT_DISTINCT( ..., [ max_contributions_per_group => upper_bound ] )

Параметры ADH.ANON_SUM , ADH.ANON_COUNT и ADH.ANON_AVG :

• contribution_bounds_per_group : Взносы на пользователя ограничиваются для каждого раздела, определенного ключами GROUP BY . Верхняя и нижняя границы применяются к значениям для каждой группы после агрегирования значений для каждого пользователя.
• lower_bound : Числовой литерал, представляющий наименьшее значение, которое следует включить в агрегацию.
• upper_bound : Числовой литерал, представляющий наибольшее значение, которое следует включить в агрегацию.

Параметры ADH.ANON_PERCENTILE_CONT :

• percentile : Процентиль для вычисления, литерал в диапазоне [0, 1] .
• contribution_bounds_per_row : Взносы каждого пользователя ограничиваются для каждой строки (для каждой записи). Обратите внимание, что для процентиля требуются явные ограничения, поэтому он поддерживается только как дополнительная функция.
• lower_bound : Числовой литерал, представляющий наименьшее значение, которое следует включить в агрегацию.
• upper_bound : Числовой литерал, представляющий наибольшее значение, которое следует включить в агрегацию.

Параметры ADH.ANON_COUNT_DISTINCT :

• max_contributions_per_group : Взносы на пользователя ограничиваются для каждого раздела, определенного ключами GROUP BY . Верхняя граница ограничивает максимальный взнос пользователя в группу после агрегирования значений по каждому пользователю.
• upper_bound : Числовой литерал, представляющий наибольшее значение, которое следует включить в агрегацию.

Вычислите MIN и MAX

Функции MIN и MAX напрямую не поддерживаются при агрегировании шума, но часто существуют альтернативные методы вычисления этих результатов.

Если у вас есть MIN или MAX значение, которое можно использовать в качестве ключей группировки, например, дата события, вы можете сначала сгруппировать данные по этому значению, а затем вычислить MIN / MAX . Это вернет минимальное или максимальное значение, которое проходит пороговое значение агрегации.

Пример:

WITH campaign_date_ranges AS (
  SELECT campaign_id, MIN(event_date) AS min_date, MAX(event_date) AS max_date
  FROM (
    # Aggregation thresholding will be applied here
    SELECT DISTINCT
      campaign_id,
      DATE(query_id.time_usec, @time_zone) AS event_date
    FROM adh.google_ads_impressions
  )
)
SELECT campaign_id, num_impressions, min_date, max_date
FROM (
  # Noise and aggregation thresholding will be applied here
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
)
JOIN campaign_date_ranges USING(campaign_id)

В качестве альтернативы, если у вас есть минимальное или максимальное значение с известными границами, вы можете использовать PERCENTILE_CONT с явно указанными границами для получения приблизительного результата.

Пример:

SELECT
  campaign_id,
  COUNT(*) AS num_impressions,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 0,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS min_timestamp,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 1,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS max_timestamp
FROM adh.google_ads_impressions

О результатах, содержащих целые числа

Хотя Ads Data Hub автоматически добавляет шум для этих агрегатных функций, сигнатуры функций не меняются. Поскольку такие функции, как COUNT или SUM of INT64 , возвращают INT64 , любая десятичная часть результата с шумом округляется. Обычно это незначительно по сравнению с размером результата и шума.

Если вам необходима точность до десятичных знаков в результате, избегайте написания функций, возвращающих INT64 — например, используйте SUM с преобразованием входных данных в FLOAT64 .

О негативных результатах

В принципе, шум с очень малыми значениями может приводить к отрицательным числам, даже если это семантически невозможно для запроса. Для обеспечения ожидаемого поведения все формы COUNT и COUNTIF автоматически ограничиваются нулем, поэтому они никогда не дают отрицательных результатов. Если вам нужно такое же поведение с другой функцией, например SUM , вы можете ограничить результаты вручную, используя GREATEST(0, SUM(...)) .

Это изменение обычно незначительно, но оно вносит небольшой положительный сдвиг в общие результаты.

Общественные группы

В предложении GROUP BY анонимизированные результаты запроса агрегируются по группам. Для обеспечения достаточного количества пользователей в группе и защиты индивидуальных данных применяется пороговое значение агрегации. Процесс определения того, какие группы могут быть освобождены, называется «выбором разделов».

Во многих случаях информация о группах может быть общедоступной. Например, группировка по версии браузера, дню недели или географическому региону не зависит от данных пользователя, если значения ключей группировки известны заранее. В этом случае выбор раздела можно опустить, поскольку наличие или отсутствие группы в выходных данных не предоставляет никакой новой информации о пользователях.

Ads Data Hub определяет запросы, подходящие для публичных групп, и не применяет к ним пороговые значения агрегации. Это означает, что никакие выходные строки не отфильтровываются. Следует отметить, что результаты, полученные на основе небольшого количества пользователей, могут быть сильно искажены из-за шума.

Для того чтобы запрос соответствовал требованиям общедоступных групп, его структура должна обеспечивать предварительное знание всех ключей группировки. Столбцы группировки должны удовлетворять следующим условиям:

• Они берутся из общедоступной таблицы (таблицы или предложения SELECT , не содержащего данных о пользователях из Ads Data Hub).
• Для обеспечения уникальности значений используется оператор SELECT DISTINCT .
• Они объединяются в запрос с помощью OUTER JOIN по всем отдельным столбцам.

Примеры запросов к публичным группам:

SELECT age_group_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT age_group_id FROM adh.age_group)
ON demographics.age_group = age_group_id
GROUP BY age_group_id

SELECT age_group_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT * FROM UNNEST([1, 2, 3]) AS age_group_id)
ON demographics.age_group = age_group_id
GROUP BY age_group_id

В первом примере защищенная adh.google_ads_impressions table объединяется с таблицей adh.age_group , которая не содержит данных о пользователях по столбцу age_group_id . Тот же самый столбец age_group_id из общедоступной таблицы появляется в предложении GROUP BY .

Аналогично, во втором примере защищенная таблица adh.google_ads_impressions объединяется с общедоступной таблицей, которая явно указана как UNNEST([1, 2, 3]) . Обратите внимание, что в обоих примерах группирующий ключ age_group_id берется из общедоступной таблицы.

Также можно указать несколько элементов группировки, например:

SELECT campaign_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT campaign_id, customer_id FROM adh.google_ads_campaign)
USING (campaign_id, customer_id)
GROUP BY campaign_id, customer_id

SELECT p.campaign_id, p.browser, COUNT(*) FROM adh.google_ads_impressions AS i
RIGHT OUTER JOIN (
 SELECT DISTINCT * FROM UNNEST([1, 2]) AS campaign_id
 CROSS JOIN UNNEST(['Chrome', 'Other']) AS browser
) AS p
 ON i.campaign_id = p.campaign_id AND i.browser = p.browser
GROUP BY campaign_id, browser;

Отсутствие фильтрации в запросах к общедоступным группам может быть полезно для часто выполняемых запросов, поскольку результат всегда возвращается для одних и тех же фиксированных значений ключей группировки. Это может быть особенно полезно, например, для создания периодических информационных панелей.

Предостережение: если общедоступная таблица содержит очень большое количество значений ключей группировки, то вы можете получить множество строк с небольшим количеством данных или без них, и все эти строки будут отмечены как содержащие значительный «шум». В этом случае следует явно указать меньший список ключей, содержащий только интересующие вас значения.

---

Поддерживаемые шаблоны запросов

Важно : Большинство стандартных рекомендаций 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_creative_conversions
  GROUP BY 1
)
SELECT * FROM result_1 JOIN result_2 USING(campaign_id)

Обратите внимание, что это поддерживается, но следует избегать в режиме проверки различий. Такая практика не создает проблем с шумом, поскольку каждый параллельный агрегат подвергается независимой фильтрации и шумоподавлению.

Агрегированные данные, объединенные с неагрегированными данными.

Примечание: Каждая агрегация получает шум независимо, поэтому суммарные значения могут не совпадать. В этом случае суммарные значения imps для конкретного campaign_id могут не совпадать с соответствующим значением campaign_imps .

Поскольку 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

Как правило, следует ограничивать количество вычислений одних и тех же результатов до 10 или менее раз. При приближении к этому порогу Ads Data Hub будет отображать предупреждения. Если вычисления одних и тех же результатов будут продолжаться и после превышения порогового значения, ваши задания начнут блокироваться с ошибками.

Узнайте о других передовых методах работы с запросами .

О компании Lookback Windows

Некоторые шаблоны запросов генерируют отчеты за длительный период времени, периодически обновляясь для включения новых результатов. Для работы в режиме «шума» такие запросы могут потребовать корректировки, поскольку пересчет предыдущих результатов приведет к блокировке. Вместо этого каждое задание должно генерировать только новые результаты, которые затем можно объединить с результатами предыдущих заданий для получения полного отчета.

Например, если вы создаете отчет по показателям за определенную дату, обновляемый ежедневно:

SELECT
  campaign_id,
  DATE(TIMESTAMP_MICROS(query_id.time_usec), @time_zone) AS event_date,
  COUNT(*) AS impressions
FROM adh.google_ads_impressions
GROUP BY 1,2

Не следует запускать эту операцию с большим диапазоном дат, так как это приведет к пересчету результатов за предыдущие дни. Вместо этого следует запускать каждое задание только за последний день, когда имеются новые данные, а затем объединять их с результатами предыдущих заданий. Если вы хотите собрать все результаты по нескольким заданиям в одной таблице, рассмотрите возможность использования оператора MERGE .

Вы по-прежнему можете пересчитывать предыдущие диапазоны дат для обновления результатов (например, чтобы учесть данные, поступившие с опозданием), но следует избегать слишком частого пересчета одного и того же результата, как описано ранее.

Прямая реагрегация

Шум применяется к первому слою агрегации данных между пользователями в запросе. Запросы с несколькими слоями агрегации будут объединять зашумленные результаты, поэтому итоговые агрегированные данные могут содержать гораздо больше шума. При проверке таких запросов выдается предупреждение:

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_creative_conversions 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 right joins

Внешние соединения с данными, принадлежащими клиентам, могут приводить к появлению строк с отсутствующими идентификаторами пользователей, что препятствует эффективной работе алгоритма фильтрации шума.

Оба этих запроса приводят к предупреждениям о проверке данных, поскольку допускают наличие несовпадающих строк с отсутствующими идентификаторами пользователей на стороне 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).