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
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:
- 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:
- 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:
|
| 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. |
|
| 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 |
|
| 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 |
|
| 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 |
|
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:
|
✓ |
| Sessões, cliques, impressões, usuários leais | KPI |
|
✓ |
| Eventos de receita in-app | KPI | Contínuo | ✓ |
| Ad revenue | KPI | Ad revenue | ✓ |
| Gastos com anúncios (custo) | KPI |
|
✓ |
| 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 |
|
✓ 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.
|
Diariamente: ✓ KPIs de retenção semanal: x |
| Coorte | Página | Contínuo | ✓ (2) |
| Painel Personalizado | Página | Contínuo | ✓ (3) |
| Audiências | Página |
|
✓ |
| Página de informações do SDK | Página | Diariamente | X |
| Dados de exportação | Página |
Contínuo
Live Alerts
|
✓ |
| 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.