Рекомендации

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

Конфиденциальность и точность данных

Разработка запросов к данным песочницы

Лучшая практика : запрашивайте производственные данные только во время их выполнения.

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

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

Внимательно рассмотрите исторические результаты

Лучшая практика : Уменьшите вероятность перекрытия наборов результатов между недавно выполненными запросами.

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

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

Не запрашивайте сегодняшние данные

Лучшая практика : не выполняйте несколько запросов, где конечной датой является сегодняшняя дата.

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

Не запрашивайте одни и те же данные чаще, чем необходимо.

Лучшие практики :

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

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

Не используйте в одном запросе больше агрегаций, чем необходимо.

Лучшие практики:

• Минимизируйте количество агрегаций в запросе
• Перепишите запросы, чтобы объединить агрегации, когда это возможно.

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

SELECT
  COUNTIF(field_1 = a_1 AND field_2 = b_1) AS cnt_1,
  COUNTIF(field_1 = a_2 AND field_2 = b_2) AS cnt_2
FROM
  table

Запросы, подсчитывающие события в зависимости от одного и того же набора полей, следует переписать с использованием оператора GROUP BY.

SELECT
  field_1,
  field_2,
  COUNT(1) AS cnt
FROM
  table
GROUP BY
  1, 2

Результат можно агрегировать таким же образом в BigQuery.

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

SELECT
  COUNTIF(a_1) AS cnt_1,
  COUNTIF(a_2) AS cnt_2
FROM
  (SELECT
     1 IN UNNEST(field) AS a_1,
     2 IN UNNEST(field) AS a_2,
   FROM
     table)

Предыдущий запрос можно переписать так:

SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1

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

SELECT
  COUNTIF(field_1 = a_1) AS cnt_a_1,
  COUNTIF(field_1 = b_1) AS cnt_b_1,
  COUNTIF(field_2 = a_2) AS cnt_a_2,
  COUNTIF(field_2 = b_2) AS cnt_b_2,
FROM table

Предыдущий запрос можно разделить на:

SELECT
  field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1

и

SELECT
  field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1

Вы можете разделить эти результаты на отдельные запросы , создать и объединить таблицы в одном запросе или объединить их с помощью UNION, если схемы совместимы.

Оптимизация и понимание соединений

Лучшая практика : используйте LEFT JOIN вместо INNER JOIN для объединения кликов или конверсий с показами.

Не все показы связаны с кликами или конверсиями. Поэтому при использовании INNER JOIN кликов или конверсий с показами показы, не связанные с кликами или конверсиями, будут отфильтрованы из результатов.

Присоединяйтесь к некоторым окончательным результатам в BigQuery

Рекомендация : избегайте запросов Ads Data Hub, объединяющих агрегированные результаты. Вместо этого создайте два отдельных запроса и объедините результаты в BigQuery.

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

Вы можете объединить результаты (в BigQuery) нескольких агрегационных запросов (из Ads Data Hub). Результаты, вычисленные с помощью общих запросов, будут использовать общие финальные схемы.

Следующий запрос берет отдельные результаты Ads Data Hub ( campaign_data_123 и campaign_data_456 ) и объединяет их в BigQuery:

SELECT t1.campaign_id, t1.city, t1.X, t2.Y
FROM `campaign_data_123` AS t1
FULL JOIN `campaign_data_456` AS t2
USING (campaign_id, city)

Примечание: вы можете использовать подстановочные таблицы для запроса объединения нескольких таблиц с одинаковыми именами в одном наборе данных.

Использовать отфильтрованные сводки строк

Лучшая практика : добавляйте в запросы отфильтрованные сводки строк.

Сводки по отфильтрованным строкам содержат данные, отфильтрованные в результате проверок конфиденциальности. Данные из отфильтрованных строк суммируются и добавляются в строку сбора данных. Хотя отфильтрованные данные не подлежат дальнейшему анализу, они дают представление о том, какой объём данных был отфильтрован из результатов.

Примечание: Требования к агрегации применяются к самим сводкам отфильтрованных строк. Если итоговая сводка отфильтрованных строк окажется ниже требований к агрегации, сама сводка отфильтрованных строк будет отфильтрована.

Учетная запись для обнуленных идентификаторов пользователей

Лучшая практика : учитывайте обнуленные идентификаторы пользователей в результатах.

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

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

Вы можете исключить эти данные из своих результатов, добавив WHERE user_id != "0" к своим запросам.

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

---

Производительность

Избегать повторного агрегирования

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

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

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

Следует избегать следующих моделей:

SELECT SUM(count)
FROM
  (SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)

Запросы, использующие несколько уровней агрегации, следует переписать так, чтобы они использовали один уровень агрегации.

(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )

Запросы, которые можно легко разбить, следует разбить. Вы можете объединить результаты в BigQuery.

Оптимизировать для BigQuery

Как правило, запросы с меньшим объёмом данных работают лучше. При оценке производительности запросов объём необходимой работы зависит от следующих факторов:

• Входные данные и источники данных (I/O) : Сколько байтов считывает ваш запрос?
• Связь между узлами (перетасовка) : сколько байтов ваш запрос передает на следующий этап?
• Вычисления : Сколько ресурсов процессора требуется для выполнения вашего запроса?
• Выходы (материализация) : Сколько байтов записывает ваш запрос?
• Антишаблоны запросов : соответствуют ли ваши запросы лучшим практикам SQL?

Если выполнение запроса не соответствует вашим соглашениям об уровне обслуживания или вы сталкиваетесь с ошибками из-за исчерпания ресурсов или истечения времени ожидания, рассмотрите следующее:

• Использование результатов предыдущих запросов вместо повторного вычисления. Например, ваш недельный итог может быть суммой, вычисленной в BigQuery по результатам 7 однодневных агрегированных запросов.
• Разбиение запросов на логические подзапросы (например, разделение нескольких объединений на несколько запросов) или иное ограничение набора обрабатываемых данных. В BigQuery можно объединить результаты отдельных заданий в один набор данных. Хотя это может помочь справиться с нехваткой ресурсов, это может замедлить выполнение запроса.
• Если вы сталкиваетесь с ошибками превышения ресурсов в BigQuery, попробуйте использовать временные таблицы, чтобы разделить ваш запрос на несколько запросов BigQuery.
• Ссылайтесь на меньшее количество таблиц в одном запросе, так как это использует большой объем памяти и может привести к сбою запроса.
• Перепишите ваши запросы так, чтобы они объединяли меньше пользовательских таблиц.
• Переписывайте запросы так, чтобы избежать объединения одной и той же таблицы с самой собой.

Запрос консультанта

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

Триггеры включают в себя следующие шаблоны:

• Объединение агрегированных подзапросов
• Объединение неагрегированных данных с потенциально разными пользователями
• Рекурсивно определенные временные таблицы

Чтобы воспользоваться консультантом по запросам:

• Пользовательский интерфейс . Рекомендации будут отображаться в редакторе запросов над текстом запроса.
• API . Используйте метод customers.analysisQueries.validate .