Migrando do OneSignal para o Pushwoosh

O OneSignal colocou um teto rígido no plano grátis. Em breve, push mobile e mensagens in-app deixam de ser gratuitos acima de 1.000 usuários ativos mensais (MAU). Contas novas batem no limite em 1º de setembro de 2026, contas existentes em 1º de outubro. Se o seu app passa de mil usuários ativos por mês, você tem 3 caminhos: ficar e pagar, cortar audiência, ou migrar.

O que muda e quando

Source: OneSignal

• O plano grátis continua funcionando abaixo de 1.000 MAU. Acima disso, push mobile e mensagens in-app passam para um nível pago.
• As datas: o limite vale para contas novas a partir de 1º de setembro de 2026 e contas existentes a partir de 1º de outubro de 2026, segundo o FAQ de cobrança do OneSignal.
• O limite: menos de 1.000 MAU para push mobile e in-app. Ao ultrapassar, esses canais param de enviar até você fazer upgrade.
• O que não muda: web push, email e SMS continuam funcionando dentro dos mesmos limites de plano de antes. A mudança é específica para mobile.
• As jornadas também são afetadas: qualquer etapa de jornada que envia um push ou uma mensagem in-app simplesmente pula as assinaturas mobile.
• Apagar assinantes não é uma saída. Se você apagar assinaturas mobile que estavam ativas nos últimos 30 dias, seu plano só pode ser reabilitado 30 dias após a exclusão, e somente se você ficar abaixo do limite durante todo esse período.

Como funciona a migração

Se você decidiu migrar, aqui está a parte que muda como você planeja isso: nós rodamos a migração para você. Do seu lado, o trabalho são três itens: um arquivo de exportação, suas credenciais de push, e a troca do SDK no seu próximo release do app. Tudo o mais (limpar os dados, mapear plataformas, recriar tags, importar a audiência, verificar a entregabilidade) é com a gente.

A troca roda em duas frentes ao mesmo tempo. Uma importação única move sua base existente, então sua audiência continua alcançável desde o primeiro dia, antes de qualquer usuário atualizar o app. O SDK então assume cada dispositivo conforme o dono instala o novo build. Você precisa das duas, e uma não trava a outra.

1. O que conseguimos e não conseguimos migrar

Você não precisa auditar isso sozinho. Aqui está o panorama completo desde já, para nada te pegar de surpresa no meio da migração.

Quanto tempo leva

A troca do SDK e um envio de teste limpo são um dia de trabalho para um desenvolvedor. A importação roda em paralelo do nosso lado, e é ela que mantém seu alcance intacto desde o primeiro dia: dispositivos importados já são alcançáveis antes de qualquer atualização do app. A audiência do seu app então migra para o SDK do Pushwoosh no ritmo em que seus usuários instalam o novo build, o que leva semanas e nunca chega a 100% dos dispositivos. É exatamente por isso que a importação existe.

A ordem importa:

1. Exporte sua audiência. Nos envie seu app_id do OneSignal e uma App API key, e nós puxamos a exportação por conta própria, ou exporte o CSV você mesmo. Detalhes abaixo.
2. Nos envie suas credenciais de push. As mesmas chaves que o OneSignal já usa para enviar. Nós fazemos o upload delas antes da importação, para que todo dispositivo importado seja alcançável.
3. Troque o SDK. Remova o SDK do OneSignal, adicione o SDK do Pushwoosh, inicialize com o seu código de aplicação do Pushwoosh e o token de API do dispositivo. Os passos por plataforma estão nas Versões A a C.
4. Verifique a entrega. Registre um dispositivo de teste e envie um push para você mesmo antes de mexer no tráfego de produção.
5. Aprove a planilha de tags. Nós a montamos a partir da sua exportação; você risca as tags mortas e marca as que têm múltiplos valores. Nós importamos e recriamos seus segmentos.
6. Troque o envio. Assim que a entrega de teste estiver limpa e a importação confirmada, aponte suas campanhas para o Pushwoosh e pare de enviar pelo OneSignal.

2. Exporte sua audiência

Opção A (recomendada): nós fazemos por você. Nos envie seu app_id do OneSignal e uma App API key, e nós puxamos a exportação por conta própria. Sua parte termina aqui.

Opção B: você mesmo faz. No OneSignal, vá em Audience > Subscriptions e exporte o CSV, ou chame o endpoint de exportação:

curl -X POST 'https://api.onesignal.com/players/csv_export?app_id=YOUR_APP_ID' \
  -H 'Authorization: Key YOUR_APP_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"extra_fields":["external_user_id","timezone_id","notification_types"]}'

A resposta retorna csv_file_url, um CSV comprimido em gzip que fica disponível para download por três dias.

Source: OneSignal

Estas colunas precisam estar no arquivo. Qualquer outra coisa é opcional e nós ignoramos.

Nota: external_user_id e timezone_id não fazem parte da exportação padrão. Peça explicitamente pelo parâmetro extra_fields acima, ou pelo seletor de colunas no dashboard.

3. Envie suas credenciais de push

Estas são as mesmas credenciais que o OneSignal já usa para enviar em seu nome, então nada novo precisa ser criado. Não conseguimos puxá-las do OneSignal por conta própria: uma chave que já foi enviada nunca mais pode ser baixada, então esse passo é seu.

Nós fazemos o upload das credenciais na sua aplicação Pushwoosh antes de a importação começar. Essa ordem importa: uma importação sem credenciais gera um banco cheio de dispositivos para os quais nada consegue entregar.

4. Revise suas tags e segmentos

Source: OneSignal

As tags são migradas, e você não precisa inventariá-las sozinho. No OneSignal, uma tag é uma string simples de chave/valor, sem tipo declarado. No Pushwoosh, cada tag é declarada uma vez por aplicação com um tipo (String, Integer, Boolean, Date, List ou Price), e só então passa a guardar valores.

Assim que temos sua exportação, te enviamos uma planilha de revisão de tags montada a partir do próprio arquivo. Ela lista cada tag que encontramos, com os dados preenchidos: valores de amostra, quantos dispositivos carregam um valor, e o tipo que propomos. Sua parte são duas colunas: riscar as tags que você não usa mais, e marcar as que podem guardar vários valores ao mesmo tempo. Tudo o mais é uma proposta que você pode aprovar como está.

Por que perguntamos em vez de adivinhar: o tipo de uma tag é fixado assim que ela é criada, então uma tag multi-valor que criarmos como String simples precisa ser apagada e reimportada. Uma tag que parece ter valor único na exportação é exatamente o caso que não conseguimos detectar só pelos dados. Se não recebermos resposta, importamos cada tag com o tipo que inferimos e te avisamos quais foram um chute.

Os segmentos são reconstruídos. A API do OneSignal consegue filtrar uma exportação por segmento e listar os nomes dos seus segmentos, mas não retorna os filtros por trás deles, então não há nada para importar. Dois caminhos possíveis:

1. Reconstruir as condições (recomendado). Nos envie sua lista de segmentos com os filtros; screenshots servem. Nós os recriamos em cima das tags importadas. Segmentos reconstruídos são dinâmicos: continuam se atualizando conforme sua audiência muda.
2. Congelar a composição. Fazemos uma exportação por segmento e marcamos cada arquivo com uma tag de marcador, por exemplo os_segment = vip_users. Rápido, mas o resultado é um retrato estático que não se atualiza sozinho.

Segmentos construídos em cima de dados comportamentais próprios do OneSignal (contagem de sessões, tempo de uso, “Active Users”, “Engaged Users”) não podem ser reproduzidos no momento da importação, porque esse histórico fica no OneSignal. Os equivalentes no Pushwoosh começam a se preencher assim que o nosso SDK entra no seu app.

5. O que fazemos do nosso lado

1. Criamos e configuramos a sua aplicação Pushwoosh e fazemos upload das credenciais do passo 3.
2. Limpamos a exportação: descartamos linhas de quem cancelou a inscrição e linhas com token vazio, mapeamos os códigos de plataforma do OneSignal para os nossos, convertemos as tags, e mapeamos o seu external_user_id para o nosso User ID.
3. Criamos o schema de tags, depois importamos a audiência em lotes, verificando cada lote.
4. Enviamos um push de teste para um pequeno grupo de controle e comparamos o resultado com o esperado.
5. Reportamos de volta: quantas assinaturas estavam no arquivo, quantas foram importadas, e o motivo de cada linha que ignoramos.

6. Coloque o SDK do Pushwoosh no seu próximo release do app

A importação torna sua audiência existente alcançável imediatamente, mas é uma ponte, não o destino final. Só o SDK do Pushwoosh dentro do seu app consegue pegar um novo token quando o SO o rotaciona (reinstalação, restauração, upgrade de SO), registrar usuários que instalarem depois da migração, e reportar aberturas, mensagens in-app e desinstalações.

Remova o SDK do OneSignal no mesmo release. Dois SDKs de push em um único build competem pelos mesmos callbacks de notificação, e nós não testamos essa combinação. Manter o OneSignal enviando enquanto o novo build é distribuído é normal e esperado; manter os dois SDKs dentro de um mesmo build não é. Os passos específicos de cada plataforma estão nas Versões A a C abaixo.

7. Web push: como seus assinantes voltam

Web push não é importável, e isso é um limite técnico real, não uma escolha do Pushwoosh. Uma assinatura de web push é assinada com o par de chaves VAPID de quem a criou, e a chave privada do OneSignal nunca sai do OneSignal — a própria documentação deles marca as chaves de assinatura web como disponíveis somente para os SDKs do OneSignal. Nenhum provedor consegue importar as assinaturas web de outro provedor. O que funciona no lugar disso é a reinscrição silenciosa:

1. Remova o snippet do OneSignal e cancele explicitamente o registro do service worker dele. Deixar o worker antigo no lugar faz dois workers competirem no mesmo domínio.
2. Instale o SDK de Web Push do Pushwoosh, com o nosso service worker na raiz do seu domínio.
3. Inicialize com o seu código de aplicação e o seu token de API do dispositivo (apiToken), depois habilite a inscrição automática (autoSubscribe: true, ou chame Pushwoosh.subscribe()). Sem o token, as chamadas do SDK voltam como 401.

Um visitante que retorna é então reinscrito silenciosamente. A permissão de notificação que o navegador guarda pertence ao seu domínio, não ao seu provedor anterior, então nenhum segundo prompt aparece e o usuário não percebe nada. A velocidade com que sua base se recupera depende da velocidade com que as pessoas voltam: a maior parte da audiência costuma voltar dentro de uma semana, com uma cauda ao longo do mês seguinte.

Três casos para ficar de olho:

• Visitantes que bloquearam notificações não podem ser reinscritos. O navegador recusa e não vai perguntar de novo a eles. Eles ficam de fora, o que é o resultado correto.
• Visitantes que cancelaram a inscrição no seu site, mas mantiveram a permissão do navegador concedida, seriam reinscritos silenciosamente. Tecnicamente válido, mas traz de volta pessoas que saíram de propósito. Se você tem uma lista de supressão (pelo seu próprio user id ou email), nos envie e nós excluímos esses usuários de todas as campanhas. Se não tem, recomendamos inscrever só em um clique explícito (um sino ou um prompt) em vez de automaticamente.
• Se o seu web push rodava em um subdomínio do seu fornecedor anterior em vez do seu próprio domínio, a permissão pertence a esse subdomínio. Esses assinantes não podem ser recuperados e precisam optar por receber de novo no seu site. Confira qual configuração você tem antes de planejar a troca.

8. O que esperar depois da importação

• Um dispositivo pode aparecer duas vezes por um tempo. O registro importado carrega o identificador do OneSignal; quando o nosso SDK roda no mesmo dispositivo, ele se registra com o próprio identificador. O registro antigo é removido pelo rastreamento de desinstalação ou pela limpeza automática de 90 dias de inatividade. Fornecer o external_user_id mantém os dois registros sob um único perfil de usuário nesse meio-tempo.
• Tokens mortos saem na sua primeira campanha. Apple e Google só revelam que um token é inválido quando uma mensagem é de fato enviada, então o primeiro envio depois da migração também limpa sua base.
• Seu número importado vai ser menor que o contador do OneSignal. Linhas de quem cancelou a inscrição, linhas com token vazio e linhas de web push são excluídas por design. Nosso relatório te diz exatamente quantas caíram em cada grupo.

9. Onde clicar

Caminhos exatos para os itens do seu lado, para ninguém precisar caçar em dashboards.

Checklist antes de 1º de outubro

Mantenha isso aberto enquanto avança. Nada aqui precisa de um formulário para baixar.

Versão A: iOS e Android nativos

iOS. Adicione o SDK iOS do Pushwoosh, depois defina duas chaves no Info.plist: Pushwoosh_APPID com o seu código de aplicação do Pushwoosh e PW_API_TOKEN com o seu token de API do dispositivo. Chame registerForPushNotifications() onde você hoje dispara o prompt do OneSignal, e siga o quick start de iOS para o snippet exato de inicialização da sua versão do SDK. Remova o SDK do OneSignal e a chamada de registro dele para que os dois não peçam token ao mesmo tempo.

Android. Adicione a dependência com.pushwoosh:pushwoosh-firebase, depois adicione duas entradas meta-data dentro da tag <application> do AndroidManifest.xml: com.pushwoosh.appid com o seu código de aplicação e com.pushwoosh.apitoken com o seu token de API do dispositivo. Chame Pushwoosh.getInstance().registerForPushNotifications() na sua lógica de inicialização. Sua configuração do Firebase continua como está, com o google-services.json no projeto; as credenciais do FCM vão no Control Panel, na configuração da sua plataforma Android.

Defina suas tags com setTags() e o identificador do seu usuário com setUserId() nos mesmos pontos onde você chamava os equivalentes do OneSignal, para a segmentação continuar funcionando depois da troca.

Versão B: Flutter e FlutterFlow

O FlutterFlow encapsula o SDK Flutter do Pushwoosh, então a migração é principalmente configuração, não código.

1. Adicione o pacote Flutter do Pushwoosh como uma dependência customizada no seu projeto.
2. Em uma custom action, inicialize o SDK com o seu código de aplicação e registre para notificações push, seguindo o quick start de Flutter para a API de inicialização atual.
3. Defina as credenciais nativas do mesmo jeito que qualquer app Flutter faz: Pushwoosh_APPID e PW_API_TOKEN no Info.plist para iOS, com.pushwoosh.appid e com.pushwoosh.apitoken no AndroidManifest.xml para Android.
4. Remova a integração do OneSignal para os dois SDKs não ficarem registrando ao mesmo tempo.
5. Mapeie tags e user id com setTags() e setUserId() nas suas custom actions.

Versão C: React Native

1. Instale o plugin: npm install pushwoosh-react-native-plugin --save, depois pod install para iOS.
2. Inicialize e registre no seu componente raiz:

import Pushwoosh from 'pushwoosh-react-native-plugin';

Pushwoosh.init({ pw_appid: "YOUR_APPLICATION_CODE" });
Pushwoosh.register();

3. Adicione o token de API do dispositivo de forma nativa: PW_API_TOKEN no Info.plist para iOS, com.pushwoosh.apitoken como meta-data no AndroidManifest.xml para Android. No Android, mantenha o google-services.json no projeto — as credenciais do FCM em si ficam no Control Panel.
4. Remova o pacote React Native do OneSignal e a chamada de init dele.
5. Leve suas tags e user id junto com setTags() e setUserId() da API do plugin.

FAQ

Dúvidas a qualquer momento vão para o seu contato de onboarding no Pushwoosh. Preferimos responder antes da importação do que reconciliar números depois dela.