Exportar dados do Firebase Crashlytics para o BigQuery

Seus dados do Firebase Crashlytics podem ser exportados para o BigQuery para uma análise mais detalhada. Com o BigQuery, é possível analisar os dados usando o BigQuery SQL, exportá-los para outro provedor de nuvem e usá-los em visualizações e painéis personalizados com o Looker Studio.

O que você pode fazer com os dados exportados?

As exportações para o BigQuery contêm dados brutos de falhas, incluindo tipo de dispositivo, sistema operacional, exceções (apps Android) ou erros (apps Apple) e registros do Crashlytics, além de outros dados. Confira exatamente os dados do Crashlytics que são exportados e o esquema da tabela mais adiante nesta página.

Confira alguns exemplos do que você pode fazer com os dados exportados do Crashlytics:

• Executar consultas
  Você pode executar consultas nos seus dados do Crashlytics para gerar relatórios que agregam dados de eventos com falha em resumos mais fáceis de entender. Como esses tipos de relatórios não estão disponíveis no painel do Crashlytics no console do Firebase, eles podem complementar sua análise e entendimento dos dados de falha. Mais adiante nesta página, confira uma seleção de exemplos de consultas.

• Use um modelo do Looker Studio
  O Crashlytics fornece um modelo do Looker Studio pré-criado para visualizar os dados exportados.

• Criar visualizações
  Usando a interface do BigQuery, é possível criar uma visualização, que é uma tabela virtual definida por uma consulta SQL. Para instruções detalhadas sobre os diferentes tipos de visualizações e como criá-las, consulte a documentação do BigQuery.

• Combinar dados específicos do Crashlytics com dados de sessões do Firebase
  Também é possível exportar dados de sessões do Firebase ao configurar a exportação de dados do Crashlytics. Use esses dados para entender melhor os usuários e as sessões sem falhas.

Benefícios da exportação contínua para o BigQuery

Por padrão, os dados são exportados para BigQuery em uma exportação diária em lote. Além disso, é possível transmitir seus dados do Crashlytics e as sessões do Firebase em tempo real com o streaming do BigQuery. Use esse recurso sempre que quiser acessar dados em tempo real, por exemplo, apresentar informações em um painel ativo, assistir a um lançamento ao vivo ou monitorar problemas de aplicativos que acionam alertas e fluxos de trabalho personalizados.

Ao ativar a exportação contínua para o BigQuery, você também terá tabelas em tempo real (além das tabelas em lote). Os dois tipos de tabelas têm o mesmo esquema de conjunto de dados, mas há algumas diferenças importantes entre as tabelas em lote e em tempo real:

A tabela em lote é ideal para análise de longo prazo e identificação de tendências ao longo do tempo, porque armazenamos eventos de maneira durável antes de gravá-los. Além disso, eles podem ser preenchidos na tabela por até 30 dias*. Quando gravamos dados na sua tabela em tempo real, eles são gravados imediatamente no BigQuery e, por isso, é ideal para painéis ativos e alertas personalizados. Essas duas tabelas podem ser combinadas com uma consulta de agrupamento para aproveitar os benefícios de ambas.

Por padrão, a tabela em tempo real tem um prazo de validade de partição de 30 dias. Para saber como mudar isso, consulte Definir a validade da partição na documentação do BigQuery.

^{* Confira detalhes sobre o suporte de preenchimento em Fazer upgrade para a nova infraestrutura de exportação.}

Ativar exportação para BigQuery

1. No console do Firebase, acesse a guia Integrações.

2. No card do BigQuery, clique em Vincular.

3. Siga as instruções na tela para ativar a exportação para o BigQuery, incluindo as seguintes opções:

   • Para entender melhor os usuários e as sessões sem falhas, ative a exportação de dados de sessões do Firebase.

   • Para ter acesso quase em tempo real aos dados do Crashlytics e de sessões do Firebase no BigQuery, ative a exportação contínua.

O que acontece quando você ativa a exportação?

• O Firebase exporta dados dos apps vinculados ao BigQuery.

  • Durante a configuração, por padrão, todos os apps no projeto são vinculados ao BigQuery, mas é possível selecionar para não vincular apps específicos durante a configuração.

  • Todos os apps adicionados posteriormente ao projeto do Firebase são vinculados automaticamente ao BigQuery.

  • É possível gerenciar quais apps exportam dados a qualquer momento.

• O Firebase exporta dados para o local do conjunto de dados selecionado durante a configuração.

  • Esse local se aplica ao conjunto de dados Crashlytics e ao conjunto de dados de sessões do Firebase (se os dados de sessões estiverem ativados para exportação).

  • Esse local é aplicável apenas aos dados exportados para BigQuery e não afeta o local dos dados armazenados para uso no painel Crashlytics do console Firebase ou no Android Studio.

  • Depois que um conjunto de dados é criado, o local não pode ser alterado, mas é possível copiar o conjunto para um local diferente ou mover (recriar) manualmente o conjunto em um local diferente. Para saber mais, consulte Mudar o local das exportações atuais.

• O Firebase configura as sincronizações diárias dos seus dados para o BigQuery.

  • Depois de vincular ao BigQuery, pode levar até 48 horas para a exportação de dados do lote inicial.

  • A sincronização diária acontece uma vez por dia, independentemente da exportação programada que você tenha configurado no BigQuery. Observação: o tempo e a duração do job de sincronização podem mudar. Portanto, não recomendamos programar operações ou jobs downstream com base em um tempo específico da exportação.

• O Firebase exporta uma cópia dos dados existentes para o BigQuery.

  • Para cada aplicativo vinculado, essa exportação inclui uma tabela em lote contendo os dados da sincronização diária.

  • É possível configurar manualmente o preenchimento de dados da tabela de lote até os últimos 30 dias ou a data mais recente em que você ativou a exportação para BigQuery (o que for mais recente).

  Se você tiver ativado a exportação de dados de Crashlytics antes de meados de outubro de 2024, também poderá preencher os dados 30 dias antes do dia em que ativou a exportação.

• O seguinte se aplica se você ativar a exportação contínua para o BigQuery.

  • Cada app vinculado também terá uma tabela em tempo real com dados sempre atualizados, além da tabela em lote do app para exportação diária.

  • Depois de ativar a exportação contínua, pode levar até uma hora para que os dados comecem a ser transmitidos.

  Os dados não aparecem na tabela em tempo real?

  1. Verifique se você enviou pelo menos dois eventos do seu app para Crashlytics e aguardou alguns minutos após o envio.

  2. Verifique se o projeto do Firebase está no plano de preços Blaze de pagamento por uso.
     Para verificar isso, procure no canto inferior esquerdo do console Firebase.

  3. Se ainda não houver dados na tabela em tempo real depois de enviar dois eventos e esperar alguns minutos:

     1. Acesse o card BigQuery no console do Firebase.

     2. Desative e reative a exportação contínua.

     3. Verifique se a conta de serviço service-PROJECT_NUMBER@gcp-sa-crashlytics.iam.gserviceaccount.com está no seu projeto do Firebase e tem o papel de agente de serviço do Firebase Crashlytics.
        É possível verificar isso na página IAM do console do Google Cloud. Marque a caixa de seleção Incluir concessões do papel fornecidas pelo Google.

     4. Envie pelo menos dois eventos para Crashlytics e aguarde alguns minutos.

  4. Se os dados ainda não aparecerem na tabela em tempo real, entre em contato com o suporte do Firebase.

Exemplo de consultas

Exemplo 1: calcular métricas sem falhas usando dados de sessões do Firebase

Na versão mais recente, você lançou uma grande reformulação do app para resolver falhas em uma jornada crítica do usuário. Você recebeu avaliações excelentes dos usuários, mas quer evidências quantitativas de que seu app está mais estável do que antes.

As métricas sem falhas podem ajudar a fornecer essas informações. Essas métricas são medidas importantes que ajudam a entender a integridade geral do app. Com os dados de sessões do Firebase e os eventos Crashlytics, é possível calcular essas métricas com uma consulta básica.

Confira exemplos de consultas para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote e ANDROID).

Usuários sem falhas de uma versão específica:

SELECT
  TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date,
  (1 - (COUNT (DISTINCT installation_uuid) / COUNT (DISTINCT instance_id))) AS CFU
FROM
  `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions
LEFT JOIN
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics
ON
  TIMESTAMP_TRUNC(_PARTITIONTIME,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY)
WHERE
  crashlytics.error_type="FATAL"
  AND crashlytics.application.display_version="APP_VERSION"
  AND sessions.application.display_version = "APP_VERSION"
GROUP BY
  event_date
ORDER BY
  event_date

Sessões sem falhas na última semana (últimas 168 horas):

SELECT
  TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date,
  (1 - (COUNT (DISTINCT crashlytics.event_id) / COUNT (DISTINCT sessions.session_id))) AS CFS
FROM
  `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions
LEFT JOIN
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics
ON
  TIMESTAMP_TRUNC(_PARTITIONTIME,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY)
WHERE
  crashlytics.error_type="FATAL" AND _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND _PARTITIONTIME < CURRENT_TIMESTAMP()
GROUP BY
  event_date
ORDER BY
  event_date

Exemplo 2: número de falhas por dia

Depois de trabalhar para corrigir o máximo de bugs possível, você acha que sua equipe finalmente está pronta para lançar o novo app de compartilhamento de fotos. Antes de fazer isso, você quer conferir o número de falhas por dia no último mês para ter certeza de que a busca por bugs tornou o app mais estável com o tempo.

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote e ANDROID).

SELECT
  COUNT(DISTINCT event_id) AS number_of_crashes,
  FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes
FROM
 `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
GROUP BY
  date_of_crashes
ORDER BY
  date_of_crashes DESC
LIMIT 30;

Exemplo 3: encontrar as falhas de maior impacto

Para priorizar corretamente os planos de produção, você quer encontrar as 10 falhas de maior impacto no seu app. Você cria uma consulta que fornece os pontos de dados pertinentes.

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote e ANDROID).

SELECT
  DISTINCT issue_id,
  COUNT(DISTINCT event_id) AS number_of_crashes,
  COUNT(DISTINCT installation_uuid) AS number_of_impacted_user,
  blame_frame.file,
  blame_frame.line
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(),INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  issue_id,
  blame_frame.file,
  blame_frame.line
ORDER BY
  number_of_crashes DESC
LIMIT 10;

Exemplo 4: os 10 dispositivos com mais falhas

O outono é a temporada de lançamento de novos smartphones. Sua empresa sabe que isso também significa uma nova onda de problemas específicos de cada dispositivo, principalmente para Android. Para superar as preocupações de compatibilidade, você elaborou uma consulta que identifica os 10 dispositivos com mais falhas na última semana (168 horas).

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote e ANDROID).

SELECT
  device.model,
COUNT(DISTINCT event_id) AS number_of_crashes
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  device.model
ORDER BY
  number_of_crashes DESC
LIMIT 10;

Exemplo 5: filtrar por chave personalizada

Você é um desenvolvedor de jogos que quer saber em qual nível o jogo está apresentando o maior número de falhas.

Para ajudar a monitorar essa estatística, defina uma chave personalizada do Crashlytics chamada current_level e a atualize sempre que o usuário atingir um novo nível.

Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Crashlytics.setInt("current_level", 3);

Com essa chave na sua exportação para o BigQuery, é possível gravar uma consulta para relatar a distribuição dos valores de current_level associados a cada evento com falha.

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote e ANDROID).

SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
  value
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
UNNEST(custom_keys)
WHERE
  key = "current_level"
GROUP BY
  key,
  value
ORDER BY
  num_of_crashes DESC

Exemplo 6: extração de ID do usuário

Você tem um app Android que está em acesso antecipado. A maioria dos seus usuários adorou, mas três tiveram um número incomum de falhas. Para encontrar a raiz do problema, você criou uma consulta para extrair todos os eventos com falha que ocorreram com esses usuários, usando os IDs de usuário correspondentes.

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote e ANDROID).

SELECT *
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  user.id IN ("USER_ID_1", "USER_ID_2", "USER_ID_3")
ORDER BY
  user.id
 

Exemplo 7: localizar todos os usuários que enfrentam uma falha específica

Sua equipe acidentalmente lançou um bug crítico para um grupo de testadores Beta. Usando a consulta do exemplo "encontrar as falhas de maior impacto" acima, sua equipe conseguiu identificar o ID específico da falha. Agora, ela quer executar uma consulta para extrair a lista de usuários do app que foram afetados pela falha.

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote e ANDROID).

SELECT user.id as user_id
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  issue_id = "ISSUE_ID"
  AND application.display_version = "APP_VERSION"
  AND user.id != ""
ORDER BY
  user.id;

Exemplo 8: número de usuários afetados por uma falha discriminados por país

Sua equipe detectou um bug crítico durante o lançamento de uma nova versão. Você conseguiu usar a consulta do exemplo "encontrar as falhas de maior impacto" acima para identificar o ID específico da falha. Sua equipe agora quer ver se essa falha se espalhou para usuários em diferentes países ao redor do mundo.

Para criar essa consulta, ela precisa fazer o seguinte:

1. Ative a exportação de dados do Google Analytics para o BigQuery. Acesse Exportar dados do projeto para o BigQuery.

2. Atualize o app para transmitir um ID do usuário para o SDK do Google Analytics e para o SDK do Crashlytics.

   Swift

   Crashlytics.sharedInstance().setUserIdentifier("123456789");
   Analytics.setUserID("123456789");
   

   Objective-C

   CrashlyticsKit setUserIdentifier:@"123456789";
   FIRAnalytics setUserID:@"12345678 9";
   

   Java

   Crashlytics.setUserIdentifier("123456789");
   mFirebaseAnalytics.setUserId("123456789");
   

3. Crie uma consulta que use o campo ID do usuário para agrupar eventos no conjunto de dados do Google Analytics com falhas no conjunto de dados do Crashlytics.

   Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote e ANDROID).

   SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted
   FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` c
   INNER JOIN  `PROJECT_ID.analytics_TABLE_NAME.events_*` a on c.user.id = a.user_id
   WHERE
     c.issue_id = "ISSUE_ID"
     AND a._TABLE_SUFFIX BETWEEN '20190101'
     AND '20200101'
   GROUP BY
     c.issue_id,
     a.geo.country,
     c.user.id

Exemplo 9: os cinco principais problemas até agora

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote e ANDROID).

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Exemplo 10: cinco principais problemas desde DATE, incluindo hoje

Também é possível combinar as tabelas em lote e em tempo real com uma consulta de agrupamento para adicionar informações em tempo real aos dados confiáveis em lote. Como event_id é uma chave primária, o DISTINCT event_id pode ser usado para eliminar os eventos em comum das duas tabelas.

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote e ANDROID).

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`)
WHERE
  event_timestamp >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD")
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Visualizar dados exportados do Crashlytics com o Looker Studio

O Looker Studio transforma seus conjuntos de dados do Crashlytics no BigQuery em relatórios totalmente personalizáveis, mais fáceis de ler e de compartilhar.

Para saber mais sobre como usar Looker Studio, confira o guia de boas-vindas.

Usar um modelo de relatório do Crashlytics

O Looker Studio oferece uma amostra de relatório do Crashlytics que inclui um conjunto abrangente de dimensões e métricas do esquema exportado do Crashlytics para o BigQuery. Caso tenha ativado a exportação de streaming do Crashlytics para o BigQuery, será possível visualizar esses dados na página Tendências em tempo real do modelo do Looker Studio. Essa amostra pode ser usada como modelo para uma criação rápida de relatórios e visualizações novos com base nos dados brutos de falhas do próprio app:

1. Abra o modelo do painel Looker Studio do Crashlytics.

2. Clique em Usar modelo no canto superior direito.

3. No menu suspenso Nova fonte de dados, selecione Criar nova fonte de dados.

4. Clique em Selecionar no card do BigQuery.

5. Para selecionar uma tabela com os dados exportados do Crashlytics, escolha Meus projetos > PROJECT_ID > firebase_crashlytics > TABLE_NAME.

   Sua tabela em lote está sempre disponível para seleção. Se a exportação de streaming do Crashlytics para o BigQuery estiver ativada, será possível selecionar a tabela em tempo real.

6. Em Configuração, defina o Nível do modelo do Crashlytics como Padrão.

7. Clique em Conectar para criar a nova origem de dados.

8. Clique em Adicionar ao relatório para retornar ao modelo do Crashlytics.

9. Para concluir, clique em Criar relatório e crie uma cópia do modelo do painel do Crashlytics Looker Studio.

Entender o esquema no BigQuery

O Firebase cria novos conjuntos de dados no BigQuery para seus dados exportados:

• Conjunto de dados do Crashlytics

• Conjunto de dados de sessões do Firebase (se os dados de sessões estiverem ativados para exportação)

Crashlytics conjunto de dados

Os dados do Crashlytics são exportados para um conjunto de dados do BigQuery chamado firebase_crashlytics. O conjunto de dados abrange todo o projeto, mesmo que tenha vários apps.

Tabelas

Por padrão, o Firebase cria tabelas individuais dentro do conjunto de dados do Crashlytics para cada app no seu projeto vinculado ao BigQuery.

As tabelas são nomeadas com base no identificador do app (com pontos convertidos em sublinhados) e anexadas à plataforma do app (_IOS ou _ANDROID). Por exemplo, os dados de um app Android com o nome do pacote com.google.test ficariam em uma tabela chamada com_google_test_ANDROID.

• Se a exportação contínua para o BigQuery estiver ativada, os dados também serão transmitidos em tempo real para uma tabela anexada com _REALTIME (por exemplo, com_google_test_ANDROID_REALTIME).

• Cada linha em uma tabela representa um evento que ocorreu no app, incluindo falhas, erros não fatais e ANRs.

• As tabelas contêm um conjunto padrão de dados do Crashlytics, além de chaves personalizadas do Crashlytics definidas por você no app.

Linhas

Cada linha em uma tabela representa um erro encontrado pelo app.

Colunas

As colunas em uma tabela são idênticas para falhas, erros não fatais e ANRs.

• Se a exportação contínua para o BigQuery estiver ativada, a tabela em tempo real terá as mesmas colunas da tabela em lote.

• Você pode ter colunas em linhas que representam eventos sem stack traces.

Confira as colunas na tabela dos dados exportados de Crashlytics:

Conjunto de dados de sessões do Firebase

Os dados de sessões do Firebase são exportados para um conjunto de dados do BigQuery chamado firebase_sessions. O conjunto de dados abrange todo o projeto, mesmo que tenha vários apps.

Tabelas

Por padrão, o Firebase cria tabelas individuais dentro do conjunto de dados de sessões do Firebase para cada app no seu projeto vinculado ao BigQuery.

As tabelas são nomeadas com base no identificador do app (com pontos convertidos em sublinhados) e anexadas à plataforma do app (_IOS ou _ANDROID). Por exemplo, os dados de um app Android com o nome do pacote com.google.test ficariam em uma tabela chamada com_google_test_ANDROID.

Linhas

Cada linha em uma tabela representa um evento de sessão que ocorreu.

Colunas

Se a exportação contínua para o BigQuery estiver ativada, a tabela em tempo real terá as mesmas colunas da tabela em lote.

Confira as colunas na tabela dos dados de sessões do Firebase exportados:

Fazer upgrade para a nova infraestrutura de exportação

Em meados de outubro de 2024, a Crashlytics lançou uma nova infraestrutura para a exportação em lote de dados de Crashlytics para BigQuery.

Todos os projetos do Firebase serão atualizados automaticamente para a nova infraestrutura de exportação em lote a partir de 15 de setembro de 2025. Você pode fazer upgrade antes dessa data, mas verifique se as tabelas de lote BigQuery atendem aos pré-requisitos para upgrade.

Você pode fazer upgrade para a nova infraestrutura, mas verifique se as tabelas de lote BigQuery atendem aos pré-requisitos para upgrade.

Determinar se você está na nova infraestrutura

Se você ativou a exportação em lote em meados de outubro de 2024 ou mais tarde, seu projeto do Firebase usa automaticamente a nova infraestrutura de exportação.

É possível verificar qual infraestrutura seu projeto está usando: acesse o console Google Cloud. Se a "Configuração de transferência de dados" estiver marcada como Firebase Crashlytics with Multi-Region Support, seu projeto está usando a nova infraestrutura de exportação.

Diferenças importantes entre a infraestrutura de exportação antiga e a nova

• Essa nova infraestrutura oferece suporte a conjuntos de dados do Crashlyticsde locais fora dos Estados Unidos.

  • Exportação ativada antes de meados de outubro de 2024 e upgrade para a nova infraestrutura de exportação: agora é possível mudar o local da exportação de dados.

  • Exportação ativada em meados de outubro de 2024 ou mais tarde: durante a configuração você foi solicitado a selecionar um local para a exportação de dados.

• A nova infraestrutura não oferece suporte a preenchimentos de dados antes de você ativar a exportação.

  • A infraestrutura antiga oferecia suporte a preenchimentos de até 30 dias antes da data em que você ativou a exportação.

  • A nova infraestrutura oferece suporte a preenchimentos de até 30 dias ou da data mais recente em que você ativou a exportação para BigQuery (o que for mais recente).

• A nova infraestrutura nomeia as tabelas de lote BigQuery usando os identificadores definidos para seus apps do Firebase no projeto do Firebase.

  • A infraestrutura antiga gravava dados em tabelas de lote com nomes baseados nos IDs ou nomes de pacote no binário do app.

  • A nova infraestrutura grava dados em tabelas de lote com nomes com base nos IDs ou nomes de pacote definidos para os apps do Firebase registrados no seu projeto do Firebase.

Etapa 1: pré-requisito para a atualização

1. Verifique se as tabelas de lote BigQuery atuais usam identificadores correspondentes aos IDs ou nomes de pacote definidos para os apps do Firebase registrados no seu projeto do Firebase. Se eles não corresponderem, talvez haja interrupções nos dados exportados em lote. A maioria dos projetos estará em um estado adequado e compatível, mas é importante verificar antes de fazer o upgrade.

   • Você pode encontrar todos os apps do Firebase registrados no seu projeto do Firebase no console Firebase: acesse as settings Configurações do projeto, role até o card Seus apps para ver todos os apps do Firebase e as informações deles.

   • Todas as tabelas de lote BigQuery estão disponíveis na página BigQuery do console Google Cloud.

   Por exemplo, confira os estados ideais em que você não terá problemas com a atualização:

   • Você tem uma tabela de lote chamada com_yourcompany_yourproject_IOS e um app iOS do Firebase com o ID do pacote com.yourcompany.yourproject registrado no seu projeto do Firebase.

   • Você tem uma tabela de lote chamada com_yourcompany_yourproject_ANDROID e um app Android do Firebase com o nome de pacote com.yourcompany.yourproject registrado no seu projeto do Firebase.

2. Se você tiver nomes de tabelas de lote que não correspondem aos identificadores definidos para seus apps do Firebase registrados, siga as instruções mais adiante nesta página antes de fazer o upgrade manual ou antes de 15 de setembro de 2025 para evitar interrupções na exportação em lote.

Etapa 2: fazer upgrade manual para a nova infraestrutura

Se você tiver ativado a exportação em lote antes de meados de outubro de 2024, poderá fazer upgrade manualmente para a nova infraestrutura simplesmente desativando e ativando a exportação de dados Crashlytics no console Firebase.

Veja as etapas detalhadas:

1. No console do Firebase, acesse a guia Integrações.

2. No card do BigQuery, clique em Gerenciar.

3. Desative o controle deslizante Crashlytics para desativar a exportação. Quando solicitado, confirme que você quer interromper a exportação de dados.

4. Ative imediatamente o controle deslizante Crashlytics para reativar a exportação. Quando solicitado, confirme que você quer exportar os dados.

   A exportação de dados de Crashlytics para BigQuery agora usa a nova infraestrutura de exportação.

O nome da tabela de lote atual não corresponde ao identificador do app do Firebase