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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Избегайте повторной агрегации

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

Запросы, объединяющие результаты, которые уже были агрегированы, например, в случае запроса с несколькими 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

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

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

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

Советник по запросам

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

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

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

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