Conceitos do conector do LinkedIn Ads

info

Beta

Esse recurso está em Beta. Os administradores do workspace podem controlar o acesso a esse recurso na página Pré-visualizações . Consulte Gerenciar prévias do Databricks.

Saiba como funciona o conector gerenciado do LinkedIn Ads no Lakeflow Connect.

Como o conector funciona

O conector do LinkedIn Ads ingere dados do LinkedIn Ads no Databricks usando a API de marketing do LinkedIn, fixada por pin na versão 202604 da API. O conector é compatível com dois tipos de tabelas:

• Tabelas de entidades: Essas tabelas contêm dados de configuração sobre suas contas de anúncios, como campanhas, criativos e usuários da conta. As tabelas de entidades são totalmente atualizadas a cada atualização do pipeline. Eles não suportam ingestão incremental ou acompanhamento de histórico (SCD tipo 2).
• Tabelas de relatórios pré-criadas: estas tabelas contêm métricas de desempenho e demográficas, como impressões, cliques e gastos. As tabelas de relatórios oferecem suporte à ingestão incremental com uma janela de retrocesso configurável que captura revisões que chegam com atraso.

Para obter uma lista de tabelas suportadas e seus esquemas, consulte a referência do conector LinkedIn Ads.

Namespaces de origem

O conector expõe tabelas de origem sob dois tipos de namespace. Quando você define um objeto de pipeline, o source_schema que você especifica determina de qual namespace a tabela vem:

• default: Contém a tabela única de toda a fonte, account_history, que abrange todas as contas de anúncio que o token de autorização pode alcançar.
• Namespaces por conta: um namespace para cada conta de anúncio patrocinado, nomeado de acordo com o ID da conta de anúncio patrocinado. Este nome de namespace é o valor que você definiu como source_schema na especificação do seu pipeline. Todas as quatro tabelas de entidade restantes e todas as sete tabelas de relatório residem aqui.

Como onze das doze tabelas são por conta, um pipeline que ingere mais de uma conta de anúncios repete essas definições de tabela uma vez por conta, com um source_schema diferente a cada vez.

Para encontrar um ID de conta de anúncio patrocinado, abra a conta no LinkedIn Campaign Manager. O ID numérico aparece abaixo do nome da conta e na URL da página, após /accounts/ (por exemplo, https://www.linkedin.com/campaignmanager/accounts/512345678/).

Janelas de ingestão e retrospectiva incrementais

O LinkedIn revisa as métricas de um dia no local à medida que conversões tardias e atualizações de atribuição chegam, portanto, uma linha que o conector já ingeriu pode mudar posteriormente. Para capturar essas revisões, cada atualização incremental relê uma janela posterior de datas já sincronizadas, em vez de buscar apenas as novas.

Na primeira atualização, um relatório é lido desde sua data de início até ontem. Em cada atualização posterior, cada grão (uma conta de anúncio ou uma campanha, dependendo do relatório) retoma a partir de seu último cursor confirmado menos lookback_window_days, com o limite mínimo na data de início do relatório. A retrospectiva default é de 7 dias, e você pode definir qualquer valor de 0 a 365. Defina-o pelo menos com a duração da janela de atribuição de conversão da sua organização para que as conversões tardias sejam registradas em suas tabelas.

O progresso é rastreado por granularidade em vez de por tabela, o que significa que uma falha durante a atualização mantém as granularidades que já foram concluídas, em vez de reiniciar todo o relatório:

• ad_analytics_by_campaign_report rastreia o progresso por account de anúncio.
• O relatório criativo e todos os cinco relatórios demográficos acompanham o progresso por campanha.

Como o progresso é por granularidade, reduzir sync_start_date após a primeira atualização não preenche retroativamente um relatório que já foi sincronizado. Somente contas ou campanhas que aparecem pela primeira vez começam a partir da nova data. Para reingerir o histórico anterior, execute um refresh completo na tabela.

Famílias de relatórios

Os sete relatórios pré-criados se enquadram em duas famílias com formatos diferentes:

• Os relatórios de desempenho diários geram uma linha por entidade pivô por dia. A coluna day contém uma data ISO e a coluna de entidade é nomeada de acordo com o pivô do relatório, portanto, o relatório de campanha é indexado por campaign_id e o relatório criativo por creative_id.
• Os relatórios mensais de dados demográficos dos membros produzem uma linha por campanha, por valor demográfico, por mês. As respostas demográficas do LinkedIn não contêm a campanha, portanto, o conector atribui campaign_id a partir da campanha que consultou.

Relatórios mensais não podem ser restringidos abaixo de um mês civil. O LinkedIn não retorna linhas para um intervalo inferior a um mês com granularidade mensal, portanto, uma sync_start_date que cai no meio do mês é alinhada de volta ao primeiro dia desse mês, e a linha retornada para esse mês é um agregado de mês completo.

Horizontes de retenção de dados

O LinkedIn limita o período retroativo que cada família de relatórios pode ser lida. Estes são os limites do LinkedIn, não os do conector:

• Os dados de desempenho diários são retidos por 10 anos.
• Os dados demográficos profissionais são retidos por 2 anos.

Uma sync_start_date mais antiga que o horizonte que se aplica ao relatório falha na leitura, porque os dados anteriores a ela não podem ser recuperados da API. A mensagem de erro indica a data mais antiga que você pode usar.

Fuso horário

O conector avalia todos os limites de data do relatório em UTC, em vez do fuso horário da ad account, e você não pode alterar isso. Se sua conta de anúncios estiver em um fuso horário diferente do UTC, espere que os totais diários sejam diferentes do que a interface do usuário do LinkedIn Campaign Manager mostra para o mesmo dia civil.