Show Menu
TÓPICOS×

Solução de problemas dos feeds de dados

Essa seção apresenta informações sobre problemas comuns.

Erro ao salvar o feed

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(s) terá o mesmo nome de arquivo. Se esses arquivos forem entregues na mesma localização, um arquivo irá 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

Configuração BucketOwnerFullControl para feeds de dados da Amazon S3

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 dela tem o controle total do objeto (ler, excluir etc.). Isso é semelhante ao modo como a entrega por FTP funciona.
O AWS também possibilita que um usuário crie objetos em um bucket que pertencem a uma conta de usuário diferente. Por exemplo, se dois usuários do AWS, o usuárioA e o usuárioB, não pertencem à mesma conta do AWS, mas desejam criar objetos em outros buckets. Se o usuárioA cria um bucket, por exemplo, bucketA, ele ou ela pode criar uma política de bucket que permite explicitamente que o usuárioB crie objetos no bucketA, mesmo se o usuário não for o proprietário do bucket. Isso pode ser vantajoso, pois não exige que o usuárioA e o usuárioB troquem as 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”.
BucketOwnerFullControl fornece direitos entre contas para criar objetos em outros buckets. Se o usuárioB envia um objeto para o bucket do usuárioA, o usuárioB ainda é o “proprietário” do objeto e, por padrão, o usuárioA não recebe permissões para esse objeto, embora seja o proprietário do bucket. Os objetos não herdam as permissões do bucket pai. O usuárioB deve conceder permissões para o usuárioA, pois o primeiro ainda é o proprietário do objeto. Para esse envio entre contas, o AWS fornece um ACL BucketOwnerFullControl ao especificar o uso desse ACL pelo proprietário do bucket (usuárioA) e recebe as permissões para o objeto (ler, gravar, excluir etc.), embora o objeto seja “de propriedade” do usuárioB.

Falhas de transferência

Se houver uma falha de transferência no FTP (logon negado, conexão perdida, extraquota, etc.), a Adobe tenta automaticamente se conectar e faz até três tentativas de envio de dados. Se a falha continuar, o feed é marcado como falho e um email de notificação é enviado.
No caso de falha na transferência, você pode executar uma tarefa novamente até que seja concluída com sucesso.

Opções de reenvio

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

Impacto do horário de verão nos feeds de dados por hora

Em alguns fusos horários, o tempo será alterado 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 02h00).
Ao fazer transições de horário padrão -> horário de verão ("Spring Forward", primavera em diante), o cliente obterá apenas 23 arquivos. O horário saltado na transição do horário de verão é simplesmente omitido. Por exemplo, se a transição ocorrer às 02h00, eles terão um arquivo às 01h00 e um arquivo às 03h00. Não haverá arquivo às 02h00, visto que o horário padrão de 02h00 torna-se o horário de verão de 03h00.
Ao fazer transições de horário padrão -> horário padrão, ("Fall Back"), o cliente receberá 24 arquivos. No entanto, a hora de transição incluirá dados com o valor de 2 horas. Por exemplo, se a transição ocorrer às 02h00, o arquivo para 01h00 será atrasado em uma hora, mas conterá os dados para duas horas. Ele conterá os dados do horário de verão de 01h00 as 02h00 do horário padrão (que teria sido 03h00 do horário de verão). O arquivo a seguir começará às 02h00 do horário padrão.

Sem dados por um período de tempo

É possível optar por configurar o feed de dados para entregar um arquivo manifest se não houver dados coletados por um período específico. Se ativar essa opção, você receberá um arquivo manifest semelhante ao seguinte:
Datafeed-Manifest-Version: 1.0
 Lookup-Files: 0
 Data-Files: 0
 Total-Records: 0

Não há informações de domínio para relatório de domínio

Algumas operadoras de dispositivos móveis (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.

Visão geral do processamento de dados

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 ocorrer, 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.