Práticas recomendadas

As práticas recomendadas a seguir sugerem técnicas para desenvolver consultas centradas na privacidade que funcionam.

Privacidade e precisão de dados

Desenvolver consultas usando dados de sandbox

Prática recomendada: consulte os dados de produção somente durante o processo de produção.

Sempre que possível, use dados de sandbox para desenvolver consultas. As tarefas que usam esses dados não criam outras oportunidades para que verificações de diferença filtrem os resultados de consulta. Além disso, devido à falta de verificações de privacidade, as consultas de sandbox são executadas mais rápido, o que permite uma iteração mais ágil na elaboração da consulta.

Se tiver que desenvolver consultas usando dados reais, por exemplo, com tabelas de correspondências, escolha períodos e outros parâmetros que não vão se sobrepor a cada iteração da consulta. Com isso, você diminui a probabilidade de sobreposição de linhas. Execute a consulta no intervalo de dados que escolher.

Analisar com cuidado os resultados históricos

Prática recomendada: diminua a probabilidade de sobreposição do conjunto de resultados entre consultas executadas recentemente.

A taxa de alteração entre os resultados da consulta afeta a probabilidade de os resultados serem omitidos posteriormente devido a verificações de privacidade. É mais provável que seja entregue um segundo conjunto de resultados bastante semelhante àquele que foi retornado antes.

Modifique os principais parâmetros da sua consulta, como períodos ou IDs das campanhas, para reduzir a probabilidade de uma sobreposição significativa.

Não consultar dados de hoje

Prática recomendada: não execute várias consultas com a data de término para hoje.

Isso resultaria na filtragem das linhas. Essa orientação também vale para a execução de consultas logo após a meia-noite usando dados do dia anterior.

Não consultar os mesmos dados mais do que o necessário

Práticas recomendadas:

  • Selecione datas de início e término vinculadas.
  • Em vez de consultar janelas sobrepostas, execute consultas em conjuntos de dados não integrados e agregue os resultados no BigQuery.
  • Use resultados salvos, em vez de refazer a consulta.
  • Crie tabelas temporárias para cada período da consulta.

O Ads Data Hub restringe quantas vezes você pode consultar os mesmos dados. Considere isso na hora de acessar informações.

Não usar mais agregações do que o necessário na mesma consulta

Práticas recomendadas:

  • Minimizar o número de agregações de uma consulta
  • Reescrever consultas para combinar agregações quando possível

No Ads Data Hub, você pode usar 100 agregações de usuários diferentes em uma subconsulta. Por isso, recomendamos reescrever consultas que gerem mais linhas com chaves de agrupamento específicas e agregações simples, em vez de mais colunas com chaves amplas e agregações complexas. Evite o seguinte padrão:

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

As consultas que contam eventos dependentes do mesmo conjunto de campos precisam ser reescritas usando a instrução "GROUP BY".

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

O resultado pode ser agregado da mesma forma no BigQuery.

As consultas que criam colunas de uma matriz e depois as agregam precisam ser reescritas para mesclar essas etapas. 

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)

A consulta anterior pode ser reescrita desta forma:

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

As consultas que usam combinações diferentes de campos em agregações distintas podem ser reescritas em várias outras consultas mais específicas.

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

A consulta anterior pode ser dividida em:

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

e

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

É possível dividir esses resultados em consultas separadas, criar e agrupar as tabelas em uma única consulta ou combiná-las com "UNION" se os esquemas forem compatíveis.

Otimizar e entender agrupamentos

Prática recomendada: use um LEFT JOIN em vez de um INNER JOIN para unir cliques ou conversões a impressões.

Nem todas as impressões estão associadas a cliques ou conversões. Se você aplica INNER JOIN em cliques ou conversões de impressões, as impressões que não estão vinculadas a cliques ou conversões são excluídas dos resultados.

Imagem mostrando vários tipos de agrupamento com diagramas de Venn

Contribuir com alguns resultados finais no BigQuery

Prática recomendada: evite consultas do Ads Data Hub que agrupem resultados agregados. Opte por criar duas consultas separadas e agrupe os resultados no BigQuery.

As linhas que não atenderem aos requisitos de agregação ficam fora dos resultados. Portanto, se a consulta agrupar uma linha sem agregação suficiente com outra suficientemente agregada, a linha resultante vai ser filtrada. Além disso, as consultas com várias agregações têm performance inferior no Ads Data Hub.

É possível agrupar resultados (no BigQuery) de várias consultas de agregação (do Ads Data Hub). Os resultados calculados usando consultas comuns vão compartilhar os esquemas finais.

A consulta a seguir agrupa os resultados individuais do Ads Data Hub (campaign_data_123 e campaign_data_456) no 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)

Usar resumos de linhas com filtros

Prática recomendada: adicione resumos de linhas com filtros às suas consultas.

Resumos de linhas com filtros: listam os dados que foram filtrados devido a verificações de privacidade. Os dados das linhas com filtros são somados e adicionados a uma linha agregadora. Os dados filtrados não podem mais ser analisados. No entanto, eles fornecem um resumo da quantidade de informação que foi filtrada e descartada.

Considerar IDs de usuários zerados

Prática recomendada: considere os IDs de usuários zerados nos resultados.

O ID do usuário final pode ser definido como 0 por vários motivos, incluindo: desativação da personalização de anúncios, motivos regulatórios etc. Dessa maneira, dados provenientes de vários usuários ficam marcados com um user_id de 0.

Se quiser entender dados como o total de impressões ou de cliques, inclua esses eventos. No entanto, esses dados não serão úteis para conseguir insights sobre os clientes e, por isso, vão ser omitidos pelos filtros se você estiver fazendo essa análise.

É possível excluir esses dados dos resultados. Basta adicionar WHERE user_id != "0" às consultas.

Performance

Evitar reagregação

Prática recomendada: evite várias camadas de agregação entre os usuários.

É preciso haver mais recursos para processar consultas que combinam resultados já agregados, como no caso de uma consulta com vários GROUP BY ou agregação aninhada.

Geralmente, consultas com várias camadas de agregação podem ser divididas, o que melhora a performance. Mantenha as linhas no nível do evento ou do usuário durante o processamento e, em seguida, combine com uma única agregação.

Não use os seguintes padrões:

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

As consultas que usam várias camadas de agregação precisam ser criadas novamente e usar uma única camada de agregação.

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

Dividir consultas que podem ser separadas com facilidade. É possível mesclar resultados no BigQuery.

Otimizar para o BigQuery

Geralmente, as consultas que realizam menos tarefas têm uma performance maior. Na hora de avaliar a performance da consulta, a quantidade de trabalho depende dos seguintes fatores:

Se a execução da consulta não estiver de acordo com seus contratos de nível de serviço ou se você encontrar erros devido ao esgotamento de recursos ou ao tempo limite, considere o seguinte:

  • Use os resultados de consultas anteriores em vez de recalcular. Por exemplo, o total semanal pode ser a soma calculada no BigQuery de sete consultas agregadas diárias.
  • Decomponha consultas em subconsultas lógicas (como dividir vários agrupamentos em várias consultas) ou restringir o conjunto de dados que estão sendo processados. É possível combinar resultados de tarefas individuais em um único conjunto de dados no BigQuery. Embora contribua para o esgotamento dos recursos, isso pode deixar a consulta mais lenta.
  • Se você tiver recursos com muitos erros no BigQuery, use tabelas temporárias para dividir sua consulta em várias outras do BigQuery.
  • Faça referências a menos tabelas em uma única consulta porque isso usa muita memória e pode causar falhas na consulta.
  • Reforme suas consultas e faça com que mesclem menos tabelas de usuários.
  • Modifique suas consultas para elas não mesclarem a mesma tabela de novo.

Orientador de consultas

Se o seu SQL é válido, mas pode causar um exagero na filtragem, o orientador de consultas mostra ações recomendadas durante o processo de desenvolvimento de consultas para evitar resultados indesejados.

Os acionadores incluem os seguintes padrões:

Para usar o orientador de consultas: