📃Destinations
Configurações do projeto
Destinations
API Rest Agnostic
A seguir temos as configurações necessárias para cadasdtrar um REST API com "destination".
```json
"rest_api": [
{
"id": "instanceid",
"method": "POST",
"base_url": "https://api.rd.services",
"routes": {
"contacts": "/platform/contacts",
"deals": "/platform/deals",
"companies": "/platform/companies"
},
"docs": "https://developers.rdstation.com/en/reference/contacts",
"is_active": true,
"api_key": "asas",
"api_version": "v15.0",
"auth_type": {
"type": "Bearer",
"settings": {
"token": "samplexasasadda"
}
},
"headers": {
"Content-Type": "application/json",
"accept": "application/json"
}
}
]
},
```method
O atributo é o tipo de VERBO padrão que será utilizado caso uma rota não tenha um verbo definido.
routes
São as rotas configuradas como destino e podem ser definidas a partir de uma condição em Filtros. Ao apontar para um destino API Rest Agnostic iremos enviar o evento "as-is" para a base_url + route selecionada e utilizar o tipo de verbo para requisição da rota ou o default.
{{route}}
Se for adicionado {{route}} na base_url a rota default será interpolado no local exato onde {{route}} foi inserido. Logo, se você precisa alterar a ordem da concactenação utilize {{route}}.
Se
Quando a rota ou qualquer rota for interpolada na base_url, ao invés de concatenar base_url com rota.default.path será interpolado no local exatado de route.
O resultado do uso de {{route}} na base url irá resultar em para o exemplo com `deals`.
base_url + deals.path
DE: http://localhost:3000/{{route}}?access_key={{access_key}}"
PARA: http://localhost:3000/platform/deals/?access_key={{access_key}}"
Sem {{route}} o resultado seria
base_url + deals.path
DE: http://localhost:3000/?access_key={{access_key}}"
PARA: http://localhost:3000/?access_key={{access_key}}/platform/deals/"
api_version
Caso `api_version` esteja definido é necessário que `base_url` tenha a variável de interpolação `{{api_version}}` para a correta aplicação da versão. Veja o exemplo.
auth_type
Há variadas possibilidades para autenticar em uma API REST. No Agnostic Data temos algumas suportadas para a implementação de um destination REST.
Lembre-se
Existem duas formas de fluxo de dados:
1) Destinations são fluxos onde todo o payload será encaminhado para o destino
no máximo o usuário pode remover alguns campos via filtros para casos como supressão de dados pessoais, etc.
2) Actions: é possível introspectar no conteúdo do evento e modificar, incrementar, adicionar dados ao evento ou outras ações.
Uma função poderá ouvir o gatilho de uma action para executar qualquer manipulação. (Atualmente essa estratégia está em beta fechado).
Temos dois tipos de tratamentos
Diretos onde para cada evento (tupla) poderá ser enviado para um destination (evento original ou supressão de alguns campos ou uma action (conteúdo personalizado)
Aggregations quando uma computação/processamento de agregação de dados é realizada. (a definir)
Settings para auth_type
Quando auth_type {type: "access_key"}
Com auth_type "access_key" será substituída as variáveis em settings como parâmetros de URL (querystring), desta forma, a a url_base deverá ter os mesmos nomes de variáveis dentro de settings para serem interpoladas.
No exemplo abaixo, aplicamos o auth_type "access_key" para a URL do Google Analytics Measurement. Veja o exemplo.
URL base Google Analytics Measurement ID "https://www.google-analytics.com/mp/collect?measurement_id=MEASUREMENT_ID&api_secret=API_SECRET";
Lembre-se: acima temos apenas um exemplo para o Google Analytics Measurement, contudo para o GA Measurement a implemente oficial do Agnostic Data basta informar id e access_token pela console de cadastro de destinations, onde id é measurement_id e access_token é api_secret.
Quando auth_type {type: "Bearer"}
Quando auth_type {type: "Oauth2"}
BigQuery Destination (schematized)
Para configurar um Google Biguery como Destino é simples basta informar o id do projeto, dataset e tabela, um e-mail de uma service account e sua private key convertida em base64.
is_active: Indica se a configuração está ativa ou não. .
id: Identificador no formato "PROJECT_ID.DATASET.TABLE".
project_id: O ID do projeto no GCP.
client_email: O e-mail da service account associado à conta de serviço que tem permissão para acessar o BigQuery no projeto.
Papéis:
role = "roles/bigquery.dataEditor"
role = "roles/bigquery.jobUser"
role = "roles/bigquery.dataEditor"
private_key_base64: A chave privada da conta de serviço codificada em base64. Essa chave é usada para autenticar a conta de serviço ao acessar o BigQuery.
account_id: O ID da conta de serviço associada (service account) à configuração.
dataset_name: O nome do conjunto de dados (dataset) no BigQuery onde os dados serão armazenados.
dataset_table: O nome da tabela dentro do conjunto de dados onde os dados serão armazenados. Neste caso, a tabela é chamada "events".
dataset_location: A localização geográfica onde o conjunto de dados está localizado no BigQuery. Isso pode afetar a latência e a conformidade regulatória. Lista de locais.
Utilize o esquema abaixo para receber os eventos "as-is" do Agnostic Data.
BigQuery Destination (raw changelog)
Diferente do destino BigQuery esquematizado com os campos pré-definidos e modelados conforme nosso AVRO Scheme, o cliente também pode habilitar um BigQuery Destination Raw Changelog.
Os dados armazenados nesta tabela são brutos, ou seja, estão no formato original em que foram capturados, sem processamento, filtragem ou agregação. Neste contexto, implica que a tabela não apenas registra eventos, mas especificamente as mudanças ou atualizações que ocorrem. Isso pode incluir informações sobre o que foi alterado, quando, e possivelmente quem fez a mudança, oferecendo um histórico detalhado de eventos que alteram o estado ou os dados dentro do sistema.
Explorando os dados
Dicas de processamento dos dados raw
Faça a importação das bibliotecas necessárias
em seguida faça a consulta utilizando um controle de tempo e limite devido ao grande volume de dados.
Atribua a variável df para começar a manipular seus dados.
Normalize o JSON
Acesse os dados e aprenda profundamente! Veja um exemplo de exploração.
Elastic Cloud Destinations
Para configurar um Elastic Cloud como Destino é simples basta informar o id do projeto, o nome do índice, url do endpoint disponível na console do elastic e a chave convertida em base64.
Renomeando evento para um destino (elastic - consulte-nos)
Existem casos de uso onde você precisará alterar o nome do evento original para um nome final desejado, por exemplo, caso um índice do elastic não possa receber mais eventos por exemplo view_content podemos renomeá-lo para o destino Elastic utilizando event_rename.
Abaixo payload para configurar o Destination Elastic para renomear todos os eventos view_content.
Elastic: Renomeando um índice baseado em um evento
Existem casos de uso onde você precisará alterar o nome do índice padrão para um nome final desejado, por exemplo, caso um índice do elastic não possa receber mais eventos por exemplo view_content podemos renomeá-lo para o destino Elastic utilizando index_rename_by_event
Os nomes dos índices criados pelo Agnostic Data no Elastic seguem o padrão abaixo:
Digamos que você precise alterar de events_YOUR_AGNOSTICDATA_PROJECT_ID_view_content para events_YOUR_AGNOSTICDATA_PROJECT_ID_view_content_v2. Siga os passos para definir o payload.
Abaixo payload para configurar o Destination Elastic para renomear todos os eventos view_content.
Google Ads (roadmap)
Prerequisites
Uma conta Google Ads "linkada" para uma uma Conta de Administrador do Google Ads (Google Ads Manager account)
Customer ID(s) - https://support.google.com/google-ads/answer/1704344
Customer Statuses Filter - https://developers.google.com/google-ads/api/reference/rpc/v15/CustomerStatusEnum.CustomerStatus
Principais tabelas
customer
customer_label
campaign_criterion
campaign_bidding_strategy
campaign_label
label
ad_group_ad
ad_group_ad_label
ad_group
Last updated