How can we help?

Atualização de dados e suporte a fuso horário

  • Atualizado

Visão geral: Visão geral: a atualização dos dados é o período de tempo entre a ocorrência do evento e a disponibilidade de dados na plataforma.

Fusos horários

TimeZoneMap.jpg

Atualização de dados e compatibilidade com fusos horários específicos do aplicativo

Atualização dos dados

A plataforma da AppsFlyer utiliza diferentes tipos de atualização de dados, como diariamente e em tempo real. Eles são usados para apresentar e disponibilizar dados. Cada um tem sua própria taxa de atualização de dados

Exemplo: taxas de atualização de dados no painel Eventos:

  • Métrica KPI: em tempo real
  • KPI médio: diário

Fusos horários

Na plataforma da AppsFlyer, um dia começa às 00:01 e termina às 24:00. O fuso horário padrão é UTC (GMT). Você pode modificar o padrão definindo um fuso horário específico do aplicativo. 

Princípios de data e fuso horário

O horário UTC é constante e não tem horário de verão/inverno. 

Hemisférios

  • Leste: os fusos horários designados como UTC+ /span>são aqueles localizados a leste do UTC.
  • Oeste: os fusos horários designados como UTC - são aqueles localizados a oeste do UTC.

Fuso horário específico do aplicativo

Você pode definir um fuso horário específico do aplicativo. Isso significa que os dados são agrupados em dias usando a hora local em vez de UTC.

Exemplo: 

Pequim: se o fuso horário específico do aplicativo estiver definido como Beijing (UTC +8), o dia começará às 16:01 UTC e terminará às 16:00 UTC do dia seguinte. 

Los Angeles: se o fuso horário específico do aplicativo estiver definido como Los Angeles (UTC -8), o dia começará às 08:01 UTC e terminará às 08:00 UTC do dia seguinte.

Diretrizes de fuso horário

  • Alinhe o fuso horário específico do aplicativo com o fuso horário definido com outros parceiros de atribuição, como o Google e o Meta ads.
  • Se você tiver mais de um aplicativo, recomendamos que você configure todos os aplicativos para o mesmo fuso horário. Para visualizar a configuração de fuso horário de um aplicativo, acesse configuração > configurações do aplicativo. Etapa 1:
  • A maioria dos relatórios e ferramentas de extração de dados é compatível com fusos horários específicos do aplicativo. Isso inclui relatório de diversos aplicativos se todos os aplicativos estiverem definidos no mesmo fuso horário específico do aplicativo.

Processamento diário 

Alguns relatórios e listas suspensas são processados uma vez por dia, isso é conhecido como atualização diária ou processamento diário. Estes são os princípios do processamento diário:

  • Os dados pertencentes a um dia específico, por exemplo, segunda-feira, são coletados em um intervalo. O dia começa às 00:01 e termina às 24:00 usando o horário específico do aplicativo.
  • Os dados recebidos até duas horas após a meia-noite são incluídos no intervalo do dia. Os dados recebidos até às 02:00 de terça-feira estão incluídos no intervalo de segunda-feira.
  • Às 02:00, horário local, o intervalo é fechado e nenhum dado pode ser adicionado a ele.
  • Os dados recebidos após as 02:00 são colocados no próximo bucket disponível, independentemente da data do evento.
  • O processamento diário do período fechado começa duas horas após a meia-noite UTC, independentemente do fuso horário específico do aplicativo. Por uma questão de simplicidade, afirmamos que o processamento começa à meia-noite UTC. Isso significa que, dependendo do fuso horário local, o repositório precisa esperar até a meia-noite UTC antes do início do processamento.

Fuso horário do hemisfério oriental e UTC:

mceclip9b.png

  • Podem passar até 11 horas desde o término do dia (hora local) até o início do processamento. Por exemplo:
    • Pequim (UTC+8): Necessidade de esperar oito horas antes do início do processamento
    • Berlim (UTC +1): Necessidade de esperar uma hora antes do início do processamento
    • UTC: Sem tempo de espera.
  • Dependendo do tipo de relatório, os dados ficam disponíveis 8 a 20 horas após o início do processamento. Por exemplo, os dados de Beijing ficam disponíveis a partir das 16:00, horário local. Os dados de Berlim ficam disponíveis a partir das 09:00.

Hemisfério ocidental:

mceclip7a.png

  • Podem passar até 23 horas desde o término do dia até o início do processamento. Por exemplo:
    • Los Angeles (UTC -8): necessário esperar 16 horas antes do início do processamento
    • Nova York (UTC -5): necessário esperar 19 horas antes do início do processamento
  • Dependendo do tipo de relatório, os dados processados ficam disponíveis 8 a 20 horas após o início do processamento. Por exemplo, os dados de Los Angeles ficam disponíveis a partir das 00:01, horário local, dois dias após o evento. Os dados de Nova York ficam disponíveis a partir das 03:01, horário local, dois dias após o evento.
  • Exemplo:
    • Os eventos acontecem na segunda-feira, horário de Los Angeles (UTC -8), o processamento diário começa à meia-noite UTC de terça-feira. Estamos em Los Angeles, terça-feira, 16:01.
    • Oito horas depois, na quarta-feira 00:01, horário de Los Angeles, o processamento de dados está concluído. Em termos práticos, os dados de segunda-feira ficam disponíveis para os anunciantes em Los Angeles quando eles começarem a trabalhar na manhã de quarta-feira.

Tipos de atualização de dados

 Classificar Disponibilidade Descrição 
Contínuo (também chamado de tempo real) 15 a 60 minutos após a ocorrência do evento O processamento de dados é contínuo. Este termo o distingue do processamento em lote que ocorre, por exemplo, diariamente. Os dados contínuos são atualizados com um atraso de 15 a 60 minutos após a ocorrência de um evento da seguinte forma: 
  • Atribuições (instalações, reatribuições e reengajamentos): 15 a 30 minutos.
  • Eventos in-app: 30 a 60 minutos.
Relatório em tempo real Poucos minutos depois de solicitar um relatório Os dados são atualizados minutos após a ocorrência do evento.
Diariamente

Zona UTC: 8 horas após a meia-noite UTC do dia do evento

Hemisfério oriental: 9 a 20 horas após a meia-noite UTC no dia do evento.

Hemisfério ocidental: Zona UTC: 21 a 32 horas após a meia-noite UTC no dia do evento.

  • Os dados são processados diariamente
  • A disponibilidade desses dados varia de acordo com o fuso horário específico do aplicativo
  • Os tipos de dados não compatíveis com fusos horários específicos do aplicativo usam o horário UTC
  • Os horários de disponibilidade de dados podem variar do dia a dia ou conforme indicado em artigos específicos
EOD (fim do dia) Diariamente no final do dia, fuso horário específico do aplicativo No final do dia do calendário. Ou seja, 00:01 do dia seguinte. Exemplo: os dados registrados na segunda-feira estão disponíveis a partir de terça-feira às 00:01, independentemente do fuso horário específico do aplicativo.
Intradiário (durante o dia) A cada 4 horas, em média
  • Os dados são coletados seis vezes ao dia, em média a cada quatro horas.
  • Os dados de cliques e impressões SRN para clientes sem ROI360 são coletados 3 vezes ao dia.
  • Os dados ETL de custo são enviados 4 vezes por dia, em média a cada 6 horas.
Ad revenue Depende do tipo de integração e do relatório Veja o artigo sobre receita publicitária para maiores detalhes.
PBA Diariamente Os dados ficam disponíveis de 11 a 12 horas após o final do dia UTC
  • O painel e os relatórios do PBA são atualizados diariamente usando o fuso horário UTC.
  • O processamento diário inclui eventos recebidos durante o dia anterior.
  • Durante os primeiros sete dias após a conversão, o PBA pode identificar eventos adicionais relacionados a uma conversão. Isso pode alterar os KPIs e a atribuição da fonte de mídia retroativamente.
  • Após sete dias, os caminhos fecham e não ocorrem mais mudanças.
  • Os relatórios de dados brutos incluem o campo final_data. Quando os dados verdadeiros são finais.
  • Exemplo detalhado
SKAN Consulte o tempo desde o horário de chegada do postback até a disponibilidade de dados em painéis e relatórios.

Postbacks recebidos em um determinado dia são processados no final do dia UTC. Os dados ficam disponíveis até às 11:00 UTC do dia seguinte. Ou seja, os postbacks do iOS recebidos na segunda-feira ficam disponíveis em relatórios e painéis na terça de manhã. Da mesma forma, os postbacks para parceiros são enviados na terça de manhã. 

A data de instalação nos relatórios e painéis é derivada da hora de chegada do postback, conforme detalhado no artigo do estúdio de conversão SKAN

Data Locker Diariamente Os dados ficam disponíveis de 8 a 10 horas após o final do dia UTC 
  • Os dados são processados diariamente.
  • Os dados estão contidos na pasta h=23 na data do evento. Por exemplo, os dados de segunda-feira estão disponíveis na pasta h=23 de segunda-feira na terça-feira, das 08:00 às 10:00 UTC.
  • Os dados da SKAN podem chegar um pouco mais tarde (consulte as informações da SKAN acima).

Atualização de dados e compatibilidade com fuso horário

Dados relacionados  Como é apresentado  Taxa de atualização dos dados
Taxa de atualização de dados(consulte a seção anterior para obter a chave para as taxas)
Dados aparecem usando o fuso horário específico do aplicativo
Instalações KPI

Contínuo

Exceções a serem observadas:

  • Os alertas do Protect360 são atualizados no horário UTC diário.
    • Atualizado diariamente às 16:00 UTC
Sessões, cliques, impressões, usuários leais KPI
  • Links de atribuição: Contínuo
  • SRNs: Intradiário
Eventos de receita in-app KPI Contínuo
Ad revenue KPI Ad revenue
Gastos com anúncios (custo) KPI
  • Link de atribuição: Contínuo (máximo até 2 horas após o clique)
  • API Intradiário
  • Ingestão de gastos com anúncios Até 4 horas após a ingestão
Desinstalações KPI diariamente. A AppsFlyer executa ping das lojas de aplicativos a cada 24 horas. A hora do evento da desinstalação representa a hora em que a AppsFlyer executou ping na notificação push silenciosa e descobriu que o aplicativo foi desinstalado. Este não é o horário real da desinstalação. X
Eventos in-app na interface Lista suspensa

Os nomes de eventos in-app exibidos nas listas suspensas são atualizados diariamente. 

Isso não afeta a taxa de atualização dos dados em si. 

Exemplos: listas suspensas de eventos in-app na Push API, painéis e públicos.

Dahsboard de Visão Geral  Página Contínuo
Painel do Protect360 Página  Diariamente (1)
Dashboard da SKAN Página Diariamente X
Página de atividade  Página
  • KPIs: Contínuo
  • Médias: à meia-noite do fuso horário específico do aplicativo

Exceção: Os dados MAU são UTC

Página de eventos  Página Contínuo
(linha em branco)    (Essa linha foi deixada em branco intencionalmente)  
Retenção Página Os KPIs de retenção estão disponíveis com granularidade diária e semanal. A atualização dos dados para cada um é diferente. 
  • KPIs de retenção diários: Diariamente
  • KPIs de retenção semanal: A semana começa na segunda-feira e termina no domingo. A retenção é calculada na segunda-feira às 12:00 UTC. A falta de compatibilidade com fuso horário específico do aplicativo para o KPI semanal resulta em uma diferença insignificante. 

Diariamente:

KPIs de retenção semanal: x

Coorte Página Contínuo (2)
Painel Personalizado Página Contínuo (3)
Audiências Página
  • As atualizações são enviadas aos parceiros a cada 24 horas.
  • A base de usuários é atualizada diariamente e armazena até 90 dias de dados do dispositivo
Página de informações do SDK Página Diariamente  X
Dados de exportação Página

Contínuo

 

Live Alerts

  • Dados brutos de receita de anúncios: Diariamente
  • Protect360:
    • Relatórios agregados: Diariamente
    • Dados brutos bloqueados: Contínuo
    • Dados brutos pós-atribuição: Diariamente
  • Eventos in-app orgânicos: Atualização com um atraso de várias horas.
Extrair API API  A atualização dos dados da Pull API é a mesma que os dados de exportação.

UTC padrão

 

Pivot  Página Diariamente

KPI regulares:

Master API  API Diariamente  (3)
Relatório do Data Locker API Conforme especificado no artigo do Data Locker. 

X

UTC

Postbacks API Contínuo N/D
API de push API Contínuo (4)

Semanalmente: x
 

Ambos

Eventos in-app servidor para servidor API Contínuo N/D

Observações:

(1) Todos os aplicativos para os quais o usuário tem permissão devem usar o mesmo fuso horário específico do aplicativo. Caso contrário, o fuso horário será revertido para UTC.

(2) Consulte as características e limitações de coorte quando o fuso horário for revertido para UTC.

(3) Todos os aplicativos selecionados devem usar o mesmo fuso horário específico do aplicativo. Caso contrário, o fuso horário será revertido para UTC.

(4) Os dados do relatório SKAN estarão disponíveis diariamente entre 08:00 e 10:00 UTC.

This article was translated using AI and may contain errors. For the most accurate information, please refer to the English version using the language selector.


Share article: