Previsão de classificação da Google App Store

Projeto de Akaash Chikarmane, Erte Bablu e Nikhil Gaur

Nesta postagem, mostraremos as etapas de pré-processamento de dados que realizamos e por que executamos essas etapas. Também falaremos sobre quaisquer transformações no conjunto de dados e procuraremos quaisquer relacionamentos enquanto exploramos os dados por meio da visualização. Por fim, falaremos sobre a motivação por trás de cada modelo que usamos (regressor linear, regressor XGB etc.), resumiremos o que eles são e, se aplicável, por que ajustamos os parâmetros da maneira como fizemos.

<”Fundo

À medida que os aplicativos móveis e se tornam tão predominantes, mais e mais desenvolvedores ganham a vida apenas com o desenvolvimento móvel. Tornou-se importante para os desenvolvedores poder prever o sucesso de seus aplicativos. Nosso objetivo era encontrar a avaliação geral de um aplicativo, porque grande parte da confiança dos usuários no aplicativo vem apenas dessa estatística. Aplicativos com classificação mais alta têm maior probabilidade de serem recomendados e mais confiáveis ​​para usuários que encontram o aplicativo enquanto navegam na app store.

Esboço de abordagem e justificativa

A grande maioria deste projeto foi sobre limpar e pré-processar os dados. Uma vez que todos os dados foram extraídos diretamente da Google Play Store, houve muitos erros na transcrição (valores NaN que não representam nada raspado, colunas de dados deslocadas etc.) e valores categóricos para traduzir ou codificar (mais sobre isso mais tarde). A partir daí, aplicamos uma variedade de modelos de regressão, como o Gradient-Boosting Regressor do pacote XGBoost, Linear Regression e RidgeRegression.

Coleta e análise de dados

Conjunto de dados: https://www.kaggle.com/lava18/google-play-store-apps

O conjunto de dados vem em duas partes: informações objetivas (estatísticas do aplicativo como tamanho, número de instalações, preço, categoria, número de resenhas, tipo, classificação de conteúdo, gêneros, última atualização, versão atual e versão mínima exigida do Android, e o número agregado de estrelas) e as avaliações do usuário (a própria avaliação, sentimento positivo / negativo / neutro, polaridade do sentimento e subjetividade do sentimento). Como esperamos que os desenvolvedores tenham acesso mais fácil às estatísticas de seus aplicativos do que às análises, suspeitamos que as informações objetivas contribuiriam muito mais para os objetivos gerais do projeto. No entanto, testamos modelos aumentados com e sem as informações de revisão. Ao comparar os dois resultados, decidimos se incluiríamos ou não os dados da revisão no modelo final.

O conjunto de dados objetivo tem 12 recursos e uma variável de destino (a classificação) e cerca de 10,8 mil entradas. O conjunto de dados de revisões do usuário contém as primeiras 100 revisões mais relevantes e 5 recursos para um total de 64,3 mil entradas. Todos os dados foram adquiridos raspando diretamente a Google Play Store e foram atualizados pela última vez há 3 meses.

Pré-processamento de dados

Os dados iniciais se pareciam com a imagem abaixo.

Os recursos Instalações, Classificação, Preço e Tamanho tiveram que ser processados ​​para que pudessem ser lidos como números, pois eram originalmente todos objetos. Cada recurso tinha seus problemas exclusivos que precisavam ser corrigidos. Para as instalações, as vírgulas e os ‘+’ s anexados às extremidades foram removidos. As avaliações foram convertidas em carros alegóricos. O preço precisava do ‘$’ removido. O tamanho era o mais problemático, pois todos eram escritos com KB e MB nas extremidades, de modo que exigiam a remoção do texto e as multiplicações para que estivessem na mesma unidade. O antes e depois das instalações e o tamanho são mostrados abaixo.

Também tivemos que escrever código para tornar certos recursos mais relevantes para o que estávamos fazendo. Por exemplo, Última atualização, da forma como foi fornecido, não foi muito útil porque era simplesmente a data da última atualização. Para torná-los mais utilizáveis, usamos o pacote Datetime para converter esses valores, transformando-os em dias desde a última atualização e classificando-os em caixas com uma “largura” de 3 meses e classificando-os. O código para transformar as datas é mostrado abaixo.

A engenharia de recursos constituiu grande parte deste projeto e um aspecto dele era lidar com todas as variáveis ​​categóricas. Os métodos principais que usamos foram codificação one-hot e codificação de rótulo. Na codificação one-hot, uma variável categórica de n variáveis ​​é expandida em n novas variáveis ​​onde os valores são booleanos que correspondem a se esse valor de variável categórica está ou não em o ponto de dados. A codificação de rótulo é mais direta, onde mapeia cada valor de variável categórica única para um número e aplica esse mapeamento à variável em questão. A codificação de rótulo era um bom esquema quando cada ponto de dados pertencia a apenas uma única categoria (ex. Categoria), mas a codificação one-hot era útil para quando o ponto de dados podia estar em várias categorias (ex. Gênero). As funções one-hot e label encoding são mostradas abaixo.

Em um esforço para normalizar os dados, tentamos aplicar a transformação log1p às avaliações. As classificações são extremamente distorcidas em direção ao limite superior do intervalo total, de modo que a transformação do log não foi capaz de corrigir a distorção tanto quanto faria se fosse menos extrema.

Antes da transformação:

Após a transformação do log:

Exploração de dados

Podemos ver que Família e Jogos têm a maioria dos aplicativos em nosso conjunto de dados, com todas as outras categorias tendo menos de 500 entradas.

A maioria dos aplicativos se encaixa na categoria Todos.

A classificação do conteúdo não afeta realmente a classificação, embora a maioria dos aplicativos esteja na categoria Todos.

Os aplicativos com classificação mais alta têm mais avaliações do que os aplicativos com classificação mais baixa. Alguns dos aplicativos com classificação mais alta têm significativamente mais avaliações do que outros. Isso pode ser causado por pop-ups no aplicativo ou incentivos no aplicativo.

As instalações e as revisões parecem estar moderadamente correlacionadas (r² = 0,435). Criamos um modelo onde usamos apenas um dos dois. Essa relação pode explicar por que categorias mais populares têm mais instalações e mais comentários.

Modelos e resultados

Usamos a divisão de teste de treinamento para dividir os dados em conjuntos de teste e treinamento. A validação cruzada com GridSearchCV foi usada para melhorar a pontuação de treinamento do modelo para encontrar o melhor alfa com Lasso, regressão de Ridge e XGBRegressor.

Um dos modelos que usamos foi o XGBRegressor do pacote XGBoost. Este modelo é geralmente muito eficaz, pois usa o aumento de gradiente (um conjunto de modelos mais fracos, geralmente árvores de decisão) para chegar a sua conclusão, mas tivemos que ser cautelosos com o sobreajuste, que é um dos perigos dos modelos que usam essa técnica. O valor médio quadrático inicial sem qualquer engenharia de recurso extensa (incluindo apenas codificação e limpeza) era de cerca de 0,228. Depois de transformar as classificações em log, o erro quadrático médio baixou para 0,219, que foi um pequeno ajuste, mas ainda um passo na direção certa.

Usamos a regressão linear depois de examinar a relação entre comentários, instalações e classificação. Como parte do exame, examinamos as informações estatísticas entre essas variáveis, como r-quadrado ajustado e valor de p, e decidimos pela regressão linear. O primeiro modelo de regressão linear usado foi entre Instalações e Classificação com uma pontuação de 0,2233, Nossos comentários e modelo de regressão linear de classificação nos deu um MSE de 0,2107, e o modelo de regressão linear combinado Avaliações, Instalações vs Classificação nos deu um MSE de 0,214.

Também usamos um modelo KNeighborsRegressor porque deu ao kernel de um usuário do Kaggle um bom erro quadrático médio, um modelo KNeighborsRegressor com Reviews como preditor nos deu um erro quadrático médio de 0,19948. O modelo é mostrado abaixo.

Conclusão

Para este projeto, pegamos os conjuntos de dados da Google Play Store e analisamos e processamos os dados. Depois que os dados foram transformados em um conjunto utilizável, usamos gráficos e funções para entender as correlações entre os recursos. Em seguida, usamos esse conhecimento para construir o melhor modelo possível para encontrar classificações com base no conjunto de dados limpo.

Achamos que encontrar um modelo decente não seria muito difícil e que estaríamos trabalhando para fazer um modelo muito preciso. Em vez disso, aprendemos que criar um modelo para encontrar a classificação não era uma tarefa simples. Conseguimos compreender melhor os desafios decorrentes do uso dos modelos que fizemos com um conjunto de dados complexo.

Poderíamos ter tentado: