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+ 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.
- 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
| Taxa | 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 | ✓ |
|
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: ✓ Semanalmente: x |
|
Cohort |
Página |
Contínuo |
✓ (2) |
|
Painel Personalizado |
Página | Contínuo |
✓ (3) |
|
Audiences |
Página |
|
✓ |
|
Página de informações do SDK |
Página |
Diariamente |
x |
|
Live Alerts |
Página |
|
✓ |
|
Dados de exportação |
Página |
Contínuo
Exceções a serem observadas:
|
✓ |
|
Pull 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 |
✓ KPIs de retenção semanal: x |
|
Master API |
API |
Diariamente |
✓ (3) |
|
Data Locker |
API | Conforme especificado no artigo do Data Locker. |
x UTC |
|
Postbacks |
API |
Contínuo |
N/D |
|
Push API |
API | Contínuo |
✓ 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. |
|||