Perguntas frequentes sobre feeds de dados

Perguntas frequentes sobre feeds de dados.

Os nomes dos feeds devem ser exclusivos?

Os nomes de arquivos do feed de dados são criados a partir da ID do conjunto de relatórios e data. Qualquer par de feeds configurados para a mesma RSID (ID do conjunto de relatórios) e data terá o mesmo nome de arquivo. Se esses feeds forem entregues na mesma localização, um arquivo sobreporá o outro. Para evitar uma sobreposição de arquivos, não é possível criar um feed com potencial para sobrepor um feed já existente na mesma localização.

Tentar criar um feed quando já existe outro com o mesmo nome de arquivo resulta na seguinte mensagem:

Se receber essa mensagem de erro, considere as seguintes soluções alternativas:

• Alterar o caminho de entrega
• Alterar as datas, se possível
• Alterar o conjunto de relatórios, se possível

Quando os dados são processados?

Antes de processar dados por dia ou por hora, os feeds de dados aguardam até que todas os hits inseridos na coleta de dados no período (dia ou hora) tenham sido gravados no data warehouse. Depois que isso ocorre, os feeds de dados coletam os dados com carimbos de data e hora que correspondem ao período, compactando-os e reenviando-os via FTP. Nos feeds por hora, os arquivos são normalmente gravados no data warehouse dentro de 15 a 30 minutos depois da hora, mas não há um período de tempo definido. Se não houver dados com carimbos de data e hora correspondentes ao período, o processo tenta novamente o próximo período. O processo do feed de dados atual usa o campo date_time para determinar quais hits pertencem à hora. Esse campo se baseia no fuso horário do conjunto de relatórios.

Qual é a diferença entre colunas com um prefixo post_ e colunas sem um prefixo post_?

As colunas sem o prefixo post_ contêm os dados exatamente como foram enviados para a coleção de dados. As colunas com um prefixo post_ contêm o valor após o processamento. Exemplos que podem alterar um valor são persistência de variáveis, regras de processamento, regras VISTA, conversão de moeda ou outra lógica do lado do servidor aplicada pela Adobe. A Adobe recomenda usar a versão post_ de uma coluna, quando possível.

Se uma coluna não tiver uma versão post_ (por exemplo, visit_num), ela pode ser considerada uma coluna posterior.

Como os feeds de dados lidam com distinção entre maiúsculas e minúsculas?

No Adobe Analytics, a maioria das variáveis não diferencia maiúsculas de minúsculas para fins de relatório. Por exemplo, 'neve', 'Neve', 'NEVE' e 'nEve' são considerados o mesmo valor. A diferenciação entre maiúsculas e minúsculas é mantida nos feeds de dados.

Se você vir variações de maiúsculas e minúsculas diferentes do mesmo valor entre colunas que sejam ou não de publicação (por exemplo, "neve" na coluna anterior e "Neve" na coluna posterior), sua implementação usará valores em maiúsculas e minúsculas no site. A diferenciação entre maiúsculas e minúsculas na coluna posterior foi transmitida e armazenada no cookie virtual ou processada ao mesmo tempo que o conjunto de relatórios.

Os bots são filtrados pelas regras de bot do Admin Console nos feeds de dados?

Os feeds de dados não incluem bots filtrados pelas regras de bot do Admin Console.

Por que vejo vários valores 000 na coluna event_list ou post_event_list do feed de dados?

Alguns editores de planilhas, especialmente o Microsoft Excel, arredondam automaticamente números grandes. A coluna event_list contém muitos números delimitados por vírgulas, às vezes fazendo com que o Excel os considere números grandes. Ele arredonda os últimos vários dígitos para 000.

A Adobe recomenda não abrir automaticamente arquivos hit_data.tsv no Microsoft Excel. Em vez disso, use a caixa de diálogo Importar dados do Excel e verifique se todos os campos são tratados como texto.

Por que as informações estão faltando na coluna de domínio para algumas operadoras?

Algumas operadoras de celular (tais como T-Mobile e O1) não fornecem mais informações de domínio de pesquisas de DNS Reverso. Sendo assim, os dados não estão disponíveis para relatório de domínio.

Por que não posso extrair arquivos "por hora" de dados que têm mais de sete dias?

Para dados com mais de 7 dias, os arquivos "Por hora" de um dia são combinados em um único arquivo "Diariamente".

Exemplo: um novo Feed de dados é criado em 9 de março de 2021, e os dados de 1º de janeiro de 2021 a 9 de março são entregues como "Por hora". No entanto, os arquivos "Por hora" anteriores a 2 de março de 2021 são combinados em um único arquivo "Diário". Você pode extrair arquivos "Por hora" somente de dados com menos de sete dias a partir da data de criação. Nesse caso, de 2 de março a 9 de março.

Qual é o impacto do horário de verão nos feeds de dados por hora?

Em alguns fusos horários, a hora será alterada duas vezes por ano devido às definições do horário de verão. Os feeds de dados seguem o fuso horário em que o conjunto de relatórios é configurado. Se o fuso horário do conjunto de relatórios não seguir o horário de verão, a entrega do arquivo continuará normalmente como qualquer outro dia. Se o fuso horário do conjunto de relatórios seguir o horário de verão, a entrega do arquivo será alterada para a hora em que ocorreu a alteração de horário (normalmente às 2h).

Ao fazer as transições de horário padrão -> horário de verão (“Spring Forward”, horário adiantado na primavera), o cliente obterá somente 23 arquivos. O horário ignorado na transição do horário de verão é omitido. Por exemplo, se a transição ocorrer às 2h, os clientes obterão um arquivo à 1h e outro às 3h. Não haverá arquivo às 2h, visto que o horário padrão de 2h torna-se o horário de verão de 3h.

Ao fazer as transições de horário de verão -> horário padrão, (“Fall Back”, horário de outono atrasado), o cliente obterá os 24 arquivos. Contudo, o horário de transição incluirá o equivalente a horas de dados. Por exemplo, se a transição ocorrer às 2h, o arquivo para 1h será atrasado em uma hora, mas conterá os dados para duas horas. Ele conterá os dados do horário de verão de 1h às 2h do horário padrão (que teria sido 3h do horário de verão). O próximo arquivo começa às 2h do horário padrão.

Como o Analytics lida com falhas de transferência de FTP?

Se uma transferência FTP falhar (devido a um logon negado, uma conexão perdida, um erro de cota excedida ou outro problema), a Adobe tentará automaticamente se conectar e enviar os dados até três vezes. Se a falha continuar, o feed é marcado como falho e um email de notificação é enviado.

Se uma transferência falhar, você poderá executar uma tarefa novamente até que seja concluída com sucesso.

Se você tiver problemas para que um feed de dados seja mostrado no site de FTP, consulte Solucionar problemas de tarefas.

Como faço para reenviar um trabalho?

Depois de verificar/corrigir o problema de entrega, execute novamente o trabalho para obter os arquivos.

Qual é a configuração BucketOwnerFullControl para feeds de dados do Amazon S3?

BucketOwnerFullControl fornece direitos entre contas para criar objetos em outros buckets.

O caso de uso comum da Amazon S3 é que o proprietário da conta da Amazon Web Services (AWS) cria um bucket e, em seguida, cria um usuário com permissões para criar objetos nele, além de fornecer credenciais para esse usuário. Nesse caso, os objetos de um usuário pertencem à mesma conta, e o proprietário da conta tem controle total implícito sobre o objeto (leitura, exclusão etc). Esse processo é semelhante ao modo como a entrega por FTP funciona.

O AWS também possibilita que um usuário crie objetos em um compartimento que pertence a uma conta de usuário diferente. Por exemplo, se dois usuários do AWS, o usuário A e usuário B, não pertencem à mesma conta do AWS, mas desejam criar objetos em outros buckets. Se o usuário A cria um bucket e dá a ele o nome de "bucketA", ele pode criar uma política de bucket que permite explicitamente que o usuário B crie objetos no bucketA, mesmo que não seja o proprietário do bucket. Essa política pode ser vantajosa porque não exige que o usuário A e o usuário B troquem credenciais. Em vez disso, o usuárioB fornece ao usuárioA o número da conta, e o usuárioA cria uma política de bucket que essencialmente diz “permitir que o usuárioB crie objetos do bucketA”.

No entanto, objetos não herdam permissões do bucket primário. Portanto, se o usuário B faz o upload de um objeto para o bucket do usuário A, o usuário B ainda "possui" esse objeto e, por padrão, o usuário A não recebe permissão para esse objeto, embora o usuário A seja o proprietário do bucket. O usuárioB deve conceder permissões para o usuárioA, pois o primeiro ainda é o proprietário do objeto. Para conceder essa permissão, o usuário B deve fazer upload do objeto com uma ACL BucketOwnerFullControl, que especifica que o proprietário do bucket (usuário A) recebe permissões totais para o objeto (leitura, gravação, exclusão etc), mesmo que o objeto seja "pertencente" ao usuário B.