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

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

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

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

Создавайте запросы с помощью тестовых данных

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

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

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

Учитывайте статистику за прошлые периоды

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

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

Чтобы снизить вероятность существенного перекрытия результатов, изменяйте основные параметры запросов, например диапазоны дат или идентификаторы кампаний.

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

Рекомендация. Не запускайте несколько запросов с датой окончания в текущий день.

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

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

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

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

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

Рекомендация. Добавляйте в запросы сводки по отфильтрованным строкам.

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

Делайте поправку на обнуленные идентификаторы пользователей

Рекомендация. При анализе результатов делайте поправку на обнуленные идентификаторы пользователей.

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

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

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

Эффективность

Предотвращайте повторную агрегацию

Рекомендация. Избегайте повторного агрегирования пользовательских данных.

Обработка запросов, которые объединяют ранее агрегированные результаты, например содержат несколько параметров 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 данные отдельных запросов за предыдущие семь дней.
Разбейте запросы на логические подзапросы (например разнесите несколько объединений по разным запросам) или другими способами снизьте объем обрабатываемых данных. Затем вы сможете в BigQuery объединить результаты отдельных запросов в единый набор данных. Это поможет в случае нехватки ресурсов, но обработка запроса может замедлиться.
Если в BigQuery возникают ошибки из-за превышения квот для ресурсов, можете использовать временные таблицы, чтобы разделить запрос на несколько запросов BigQuery.
Ссылайтесь на меньшее количество таблиц в одном запросе. В противном случае для обработки требуется большой объем памяти, что может приводить к ошибкам выполнения запроса.
Перепишите запросы так, чтобы они объединяли меньшее количество пользовательских таблиц.
Перепишите запросы так, чтобы таблица не объединялась с самой собой.