IGOR LEMOS VICENTE
UTILIZANDO MACHINE LEARNING PARA IDENTIFICAR CLIENTES TRIALS QUE SE TORNARÃO PAGANTES EM UM SAAS
Trabalho de conclusão de curso apresentado como requi-sito para obtenção do grau de Bacharel em Ciência da Computação da Universidade Federal da Fronteira Sul. Orientador: Denio Duarte
CHAPECÓ 2019
Vicente, Igor Lemos
Utilizando Machine Learning para identificar clientes trials que se tornarão pagantes em um SaaS / Igor Lemos Vicente. – 2019.
57 f.: il.
Orientador: Denio Duarte.
Trabalho de conclusão de curso (graduação) – Universidade Federal da Fronteira Sul, curso de Ciência da Computação, Chapecó, SC, 2019. 1. Aprendizado de máquina. 2. Software-as-a-Service. 3. Previ-são de converPrevi-são. 4. Aprendizado Supervisionado. 5. Classificadores. I. Duarte, Denio, orientador. II. Universidade Federal da Fronteira Sul. III. Título.
© 2019
Todos os direitos autorais reservados a Igor Lemos Vicente. A reprodução de partes ou do todo deste trabalho só poderá ser feita mediante a citação da fonte.
RESUMO
Um sistema SaaS é um software oferecido como serviço tal que um usuário que o deseje utilizar precisa apenas de uma forma de acesso, normalmente via navegador web. Nesse modelo de entrega de software, os sistemas pagos normalmente possuem um período chamado de trial em que o usuário pode testar o sistema antes de comprá-lo. Este trabalho tem por objetivo identificar quais são os usuários em trial que se tornarão pagantes em um sistema SaaS. Para isso, os dados gerados pelo uso cliente no sistema são usados em 3 algoritmos de classificação: Support Vector Classifier, K Nearest Neighbours e Random Forest Classifier. Além dos dados gerados pelo usuário, novos dados estatísticos que são gerados na execução deste trabalho também se mostraram úteis na predição da assinatura do cliente. Nos testes realizados, o Random Forest Classifier obteve uma performance melhor na métrica F1-score. Ao final do trabalho, um modelo é criado para a utilização na empresa fornecedora dos dados.
Palavras-chave: Aprendizado de máquina. Software-as-a-Service. Previsão de conversão. Aprendizado Supervisionado. Classificadores.
ABSTRACT
A SaaS system is a software delivered as a service in such a way that an user that wants to use it need only a way to access it, usually via a web browser. In this software delivery model, paid systems usually have an time range called trial in which an user can test the system before buying it. This issue has as a goal the identification of the users in trial who will become payers in a SaaS system. For that, the generated data by the customer’s system use are used in 3 classification algorithms: Support Vector Classifier, K Nearest Neighbours and Random Forest Classifier. Besides the user’s generated data, new statistical data generated in the execution of this issue showed to be useful on the customer’s subscription prediction. In the executed tests, Random Forest Classifierobtained better performance on the F1-score metric. In the end of the issue, a model is created to be used in the case company.
Keywords: Machine Learning. Software-as-a-Service. Conversion Prediction. Supervisioned Learning. Classifiers.
LISTA DE ILUSTRAÇÕES
Figura 1 – Representação visual de um programa comum (à esquerda) e um programa de aprendizado de máquina (à direita) . . . 23 Figura 2 – Uma árvore de decisão classificadora de entidades do folclore brasileiro com
base nos dados da Tabela 1 . . . 26 Figura 3 – Exemplo de hiperplano e vetores de suporte do algoritmo Support Vector
Classifier. . . 27 Figura 4 – Plano colorido conforme conceito por trás da execução do K Nearest Neighbours 28 Figura 5 – Matriz confusão . . . 29 Figura 6 – Resultados obtidos no trabalho de (RAUTIO, 2019) . . . 32 Figura 7 – Fluxo da metodologia usada em (PRASASTI et al., 2014) . . . 33 Figura 8 – Curvas ROC dos resultados da busca de hiperparâmetros dos classificadores
em (PRASASTI et al., 2014) . . . 34 Figura 9 – Distribuições criadas a partir da probabilidade de classificação do algoritmo
SVM em (PRASASTI et al., 2014) . . . 35 Figura 10 – 10 melhores features por dia . . . . 40 Figura 11 – Melhores métricas alcançadas do experimento, separadas por dia . . . 44
LISTA DE ALGORITMOS
1 Algoritmo para criação de modelos para validação dos algoritmos . . . 40 2 Algoritmo para criação dos modelos com a melhor combinação de
LISTA DE TABELAS
Tabela 1 – Conjunto de dados artificial com entidades do folclore brasileiro . . . 25 Tabela 2 – Resultados de ambos os classificadores utilizados em (PRASASTI et al., 2014) 34 Tabela 3 – Exemplos de alguns atributos de valores originais e gerados para um usuário 38 Tabela 4 – Características dos conjuntos de dados . . . 39 Tabela 5 – Valores de k do Algoritmo 1 que obtiveram os melhores resultados para o
Random Forest Classifier . . . 41 Tabela 6 – Valores de hiperparâmetros utilizados na validação em grade . . . 43 Tabela 7 – Melhores combinações de hiperparâmetros para cada dia . . . 44
SUMÁRIO
1 INTRODUÇÃO . . . . 17
2 SOFTWARE AS A SERVICE(SAAS) . . . . 19
2.1 VANTAGENS DE UM SAAS . . . 19
2.2 BELASIS . . . 20
3 APRENDIZADO DE MÁQUINA . . . . 23
3.1 APRENDIZADO SUPERVISIONADO . . . 24
3.2 CLASSIFICADORES . . . 25
3.2.1 Random Forest Classifier . . . 25
3.2.2 Support Vector Classifier . . . 26
3.2.3 K Nearest Neighbours . . . 27
3.2.4 Métricas de Avaliação . . . . 28
4 TRABALHOS RELACIONADOS . . . . 31
4.1 CHURN PREDICTION IN SAAS USING MACHINE LEARNING . . . 31
4.2 CUSTOMER LIFETIME VALUE AND DEFECTION POSSIBILITY PRE-DICTION MODEL USING MACHINE LEARNING: AN APPLICATION TO A CLOUD-BASED SOFTWARE COMPANY . . . 33
5 PROJETO DOS EXPERIMENTOS . . . . 37
5.1 OBTENÇÃO DA BASE DE DADOS . . . 37
5.2 DESCRIÇÃO DAS FEATURES . . . . 38
5.3 CRIAÇÃO E VALIDAÇÃO DOS MODELOS . . . 39
6 EXPERIMENTOS . . . . 43
7 CONCLUSÃO . . . . 47
REFERÊNCIAS . . . . 49
APÊNDICE A – FEATURES EXTRAÍDAS NAS BUSCAS . . . . 51
17 1 INTRODUÇÃO
O modelo de entrega de um sistema no formato Software-as-a-Service (SaaS) possibilita que usuários possam usá-lo sem precisar de configuração e manutenção de infraestrutura e máquinas para hospedagem do servidor da aplicação. Por se encontrar acessível pela internet, o usuário necessita apenas de uma conexão e um navegador web para poder utilizar o sistema.
Na empresa colaboradora do trabalho, a criação de uma conta com acesso ao sistema pode ser realizada de forma instantânea por um usuário. Este, ao criar seu acesso, passa a ter um período de 7 dias para desfrutar das funcionalidades que o sistema oferece de forma gratuita. Passado esse período de teste (chamado de trial), o usuário, para continuar o uso, deve assinar um dos planos disponibilizados pela aplicação. Caso não o faça, o sistema fica bloqueado, impedindo-o de realizar qualquer outra ação que não seja a efetivação da assinatura. Os planos ofertados variam de preço conforme as funcionalidades oferecidas.
Para a empresa, é importante que um usuário em período de teste efetive a assinatura de algum dos planos, tornando-se, assim, um cliente com assinatura ativa. Algumas medidas são tomadas para este fim, sendo uma delas a venda ativa por telefone. Nessa medida, funcionários encarregados pela sua execução contatam o prospecto por meio de telefone ou mensageiros instantâneos apresentando o produto e sanando dúvidas que possam ter surgido para o usuário durante o período de teste. Esse contato comumente ultrapassa 1 hora de tempo empregado, tornando problemática o contato com os vários clientes que se cadastram no sistema todos os dias.
Pelo motivo citado, conseguir distinguir um usuário que tem pouca ou nenhuma chance de se tornar um cliente ativo de um usuário que possui uma probabilidade maior de se tornar assinante se evidencia como uma tarefa importante para um melhor uso da força de trabalho da empresa. Ao prever quais usuários são mais propensos à efetivação da assinatura, a empresa passa a usar menos recurso para contatos que se mostram infrutíferos e passa a ter disponibilidade de esforços de seus colaboradores para a execução de outras tarefas. Tal distinção, porém, mostra-se uma tarefa complicada para mostra-ser executada pela falta de informações sobre o usuário. Para facilitar a entrada do usuário no período de testes, o mínimo de informações é requisitado pela aplicação. Uma abordagem apoiada nos dados gerados pelo usuário durante o uso do sistema no período de teste poderia ser usada para análise de comportamento, mas mostra-se também inviável humanamente pelo grande volume de dados.
Este trabalho, então, tem como objetivo identificar clientes que têm alta probabilidade de assinar o sistema oferecido pela empresa colaboradora. Para isto, foi utilizada uma abordagem que utiliza aprendizado de máquina por meio de três algoritmos considerados na fase de execução do projeto: K Nearest Neighbours, Random Forest Classifier e Support Vector Classifier. Os três algoritmos foram validados na etapa do projeto com base na métrica F1-score.
O conjunto de dados utilizado para o trabalho foi extraído da base de dados da empresa colaboradora. Na extração, features foram criadas para representar o comportamento do usuário
18
no sistema nos primeiros 7 dias de teste que são disponibilizados assim que criam um novo acesso. A partir features iniciais, outras foram criadas a fim de melhorar a performance dos algoritmos utilizados.
A importância de cada feature foi quantificada e o conjunto delas foi ordenado da mais importante para a menos importante para cada conjunto de dados. Após isso, para cada conjunto de dados, um número de melhores features foi extraído e usado para a criação de um modelo com um dos algoritmos de aprendizado de máquina. Todas as combinações desses diferentes elementos (conjunto de dados, algoritmo e um subconjunto de features) foram usadas para o procedimento descrito e ao final, pode-se identificar as combinações que alcançaram melhores resultados. Depois, para cada conjunto de dados, as melhores combinações de elementos foram identificadas e com base nisso, um algoritmo foi selecionado para a execução dos experimentos. Além da identificação de possíveis clientes, o resultado do trabalho ajuda na explicitação de novas informações que mostram quais são os itens mais relevantes e influentes na decisão de um usuário se tornar cliente ou não.
O trabalho é dividido em 6 capítulos. No Capítulo 2, o modelo de negócio SaaS é descrito e suas principais vantagens são listadas. A empresa colaboradora com o trabalho é apresentada nesse capítulo.
O referencial teórico do trabalho é apresentado no Capítulo 3. Neste, são apresentados os principais conceitos necessários para a compreensão dos métodos utilizados de aprendizado de máquina. Os algoritmos utilizados na execução do trabalho também estão descritos nesse capítulo.
No Capítulo 4, dois trabalhos relacionados são apresentados. Ambos os trabalhos têm o objetivo de prever o churn (deserção de um cliente pagante) de clientes de plataformas SaaS. Cada trabalho aborda diferentes algoritmos para se chegar a esse objetivo. Nesse capítulo são apresentados os principais pontos de cada trabalho, além de suas formas de execuções, resultados e relações com o presente trabalho.
No Capítulo 5 está descrito o projeto executado neste trabalho. A descrição começa na obtenção dos dados que serão usados no trabalho, passa pela criação de features, tratamento de dados, criação e validação dos modelos e termina escolhendo Random Forest Classifier por este se mostrar o com melhor performance. O modelo é escolhido para ser usado no experimento descrito no Capítulo 6, que cria modelos do algoritmo escolhido com diferentes hiperparâmetros, buscando melhorar a performance alcançada no Capítulo 5.
Por fim, no Capítulo 7 é feita a conclusão com base nos resultados obtidos do trabalho. As limitações do trabalho e os trabalhos futuros também são mostrados.
19 2 SOFTWARE AS A SERVICE (SAAS)
Software as a Service(Software como serviço, traduzido literalmente) é um paradigma de entrega de software onde este está hospedado em um local que não necessariamente precisa ser o mesmo local do uso (GODSE; MULIK, 2009). Ao contrário dos sistemas clássicos com alguma variante do ciclo de edita, compila e conecta (TURNER; BUDGEN; BRERETON, 2003), gerando uma imagem binária que é instalada na máquina que o software será utilizado, o modelo SaaS entrega o serviço pela internet, normalmente via navegadores que rodam nos dispositivos do usuário (FOX; PATTERSON; JOSEPH, 2013).
O modelo de entrega de um SaaS separa a posse e o uso de um software. O dono passa a ser um agente que hospeda o software e o usuário um agente que o acessa, sob demanda, através de uma interface de cliente via internet ou intranet. Esse novo modelo entrega o software não mais como um produto, mas como um serviço, cobrando do usuário de acordo com seu uso (LAPLANTE; ZHANG; VOAS, 2008), ao contrário das aplicações clássicas que são vendidas como um produto “numa caixa” como cita (TORBACKI, 2008). Exemplos de SaaS incluem buscas, redes sociais e acesso a vídeos (FOX; PATTERSON; JOSEPH, 2013).
2.1 VANTAGENS DE UM SAAS
O modelo SaaS possui algumas vantagens sobre o modelo tradicional de entrega de software. Algumas dessas vantagens são, segundo (FOX; PATTERSON; JOSEPH, 2013):
a) Pouca preocupação com hardware, sistema operacional ou outros requisitos de sis-tema por parte do usuário, dado que a aplicação não é instalada localmente;
b) Os dados do serviço normalmente ficam com o servidor, tirando a necessidade do usuário realizar cópias de segurança, além de evitar danos com perdas ou falhas de dispositivos usados para o acesso ao software;
c) Compartilhamento de informações entre um grupo de forma mais fácil. Empresas não precisam mais sincronizar dados, visto que os dados ficam em um local só. Além disso, quando os dados são grandes e são frequentemente atualizados, faz mais sentido mantê-los centralizado;
d) Pouco ou nenhum problema com compatibilidade, já que o sistema roda num servidor dedicado, com ambiente configurado e personalizado para este;
e) Facilidade de testar novas versões com apenas uma parte dos usuários;
f) Como apenas os desenvolvedores possuem uma cópia do software, eles podem atualizá-lo frequentemente, desde que não seja alterada a interface. Isso também acaba com os pedidos frequentes de permissão para atualização de software.
Empresas que antes não conseguiriam ter acesso a sistemas de gestão por falta de recursos, dinheiro ou pessoas, hoje podem contar com sistemas de modelo SaaS que tornam
20
mais barato o acesso e o uso. Um exemplo disso é o segmento de salões de beleza, que comumente são pequenas e médias empresas que podem ser atendidas hoje por fornecedoras de softwares acessíveis pela internet. Uma dessas fornecedoras é a Belasis, que será apresentada na próxima seção e é a empresa objeto deste estudo .
2.2 BELASIS
Criada em 2015, a Belasis é uma empresa que tem em seu portfólio um sistema para gestão de empresas que prestam serviços. Embora atenda algumas regras de negócio gerais, a empresa foca nos segmentos de salões de beleza, barbearias, esmalterias, clínicas e spas. A entrega da solução da empresa é feita por um SaaS onde os usuários que desejam ter acesso às funcionalidades devem ter apenas conexão com a internet e um navegador web. Por usar o modelo de negócio SaaS, a empresa torna possível que um ramo de negócio como o dos salões de belezas, barbeiros e clínicas de estéticas possam usufruir de um sistema que antes seria muito custoso e/ou trabalhoso de se implementar.
Ao se cadastrar no sistema, o usuário tem 7 dias de teste grátis. Após esse tempo, o usuário deve contratar algum plano e efetivar a assinatura para continuar com o uso. Os planos da empresa são de acordo com as funcionalidades que estão presentes neles. Neste trabalho, usuário, cliente e salão serão usados com o mesmo sentido, a menos que destacado o contrário. O objetivo do trabalho foi criado com base nos dados de uso dos usuários do sistema Belasis. A empresa contribuiu para o presente trabalho disponibilizando a base de dados que será usada para a construção do conjunto de dados. Os dados de uso de um usuário são baseados no uso das funcionalidades que o sistema oferece. O uso, por sua vez, é representado pelos registros de modelos criados no banco de dados enquanto o usuário usa as funcionalidades.
As funcionalidades do sistema são criadas para atender principalmente 3 necessidades dos salões de beleza. A primeira é a da agenda, que serve para controlar os horários de serviços marcados. Um agendamento pode ser criado por uma pessoa que tem acesso ao sistema. Além dos usuários do sistema, os seus clientes também podem marcar um agendamento por meio de aplicativos para celulares.
A segunda principal funcionalidade é a comanda. Nesta, registra-se o consumo e serviços prestados ao cliente durante sua permanência no estabelecimento. Ao final do atendimento e no pagamento das pendências, o usuário do sistema fatura a comanda (isto é, grava o valor do pagamento, as formas de pagamento, descontos, etc.).
A terceira principal funcionalidade é, na verdade, um conjunto de outras funcionalidades, agrupadas no módulo chamado de financeiro. Neste módulo, é possível gravar despesas e receitas (inclusive aquelas de origem na comanda), realizar conferência de caixa, gerar relatórios, entre outras funcionalidades.
Além das 3 descritas acima, outras funcionalidades puderam ter seu uso quantificado e foram usadas no trabalho. Uma destes é o cadastro de produtos e serviços, que contém
21 informações de produtos vendidos ou consumidos e serviços realizados pelas empresas que usam o sistema. Para os produtos, também é possível gravar marca, categoria, fornecedores e compras realizadas. Para os agendamentos, é possível criar cores que representam status personalizados. São usados para simbolizar agendamentos especiais, como um cliente VIP, um retrabalho, etc. É possível também cadastrar clientes e anamneses realizadas, além da criação de campanhas que permitem o envio de mensagens com promoções para esses clientes. Os profissionais das empresas também são cadastrados num modelo próprio, que podem ter vales (adiantamentos de salário) e avaliações (realizadas pelos clientes) atreladas. Para os clientes que vão rotineiramente ou querem realizar diversos serviços para uma ocasião especial, é possível também criar pacotes de serviços, que são previamente pagos e posteriormente têm seus saldos baixados quando usados. Por fim, conforme dito, despesas, receitas e conferências de caixa são possíveis de serem cadastradas no módulo financeiro.
Essa explicação breve das funcionalidades tem como fim contextualizar o leitor às features que serão usadas no conjunto de dados usado para a predição. No capítulo a seguir, apresentaremos os algoritmos de aprendizado de máquina que foram avaliados para usar realizar essa predição.
24
isso, como dirigir um automóvel e entender uma imagem (SHALEV-SHWARTZ; BEN-DAVID, 2014).
Para a construção de um modelo, comumente segue-se 4 etapas (DUARTE; STÅHL, 2019). A primeira etapa é a escolha de um conjunto de dados para servir como entrada (entrada e saída do modelo à direita na Figura 1). Na segunda etapa, escolhe-se o algoritmo que criará o modelo. Na terceira etapa, decide-se pela estratégia de otimização do modelo e, por fim, na quarta etapa, valida-se o modelo.
Depois de construído e validado o modelo, ele estará pronto para receber novos exemplos e prever suas etiquetas. Os novos (ou futuros) exemplos são exemplos que não foram usados na construção do modelo. Podem ser os exemplos usados no conjunto de teste, que podem ter a etiqueta para comparação, ou exemplos que não possuem resposta e, portanto, são os que se deseja obtê-la. As etiquetas, também chamadas labels, são o valor-resposta associado a um exemplo. Esse valor pode ser previsto (pelo modelo) ou pré definido (no conjunto de dados).
Vale ressaltar que a primeira etapa da construção de um modelo pode conter a entrada e a saída, conforme dito, ou pode conter só a entrada. Isso porque há problemas em que o conjunto de dados não possui uma etiqueta (saída, no caso) objetivamente correta. Um exemplo disso é a categorização de um artigo de um jornal. A categoria desse artigo pode ser “Esporte”, “Política” ou até mesmo “Esporte” e “Política”. Para esse tipo de problema, usa-se os chamados algoritmos de aprendizado não-supervisionado. O problema atacado neste trabalho se encaixa no tipo de aprendizado supervisionado e, portanto, não entraremos no escopo do aprendizado não-supervisionado. A explicação do paradigma de aprendizado supervisionado está na Seção 3.1 abaixo.
3.1 APRENDIZADO SUPERVISIONADO
O aprendizado supervisionado descreve o tipo de aprendizado tal que o conjunto de dados possui etiqueta para cada um dos exemplos. Nesse tipo de aprendizado, usa-se a etiqueta com a saída correta para otimizar o modelo durante sua construção. Para a validação, normalmente utiliza-se uma parte do conjunto de dados que não foi utilizada para criar o modelo. Essa parte é chamada de conjunto de teste e é usada para comparar cada etiqueta desse conjunto com a etiqueta de resposta que o modelo gerou.
O valores das etiquetas de um conjunto de dados utilizado na construção de um modelo de aprendizado supervisionado podem ser números contínuos ou discretos. A distinção entre esses dois tipos é importante para saber qual o tipo do problema o modelo tem de resolver. Os principais são dois: problemas de regressão e problemas de classificação (RAUTIO, 2019). No problema de regressão, as etiquetas são valores numéricos e contínuos. Um caso de uso para esse tipo de algoritmo é a predição da temperatura. Já para o problema de classificação, os valores são do tipo discreto. O próprio problema do trabalho é um exemplo de um problema de classificação. Nele buscamos descobrir se um cliente assinará ou não o sistema, portanto,
25 procuramos uma resposta dentro do conjunto de “Sim” e “Não”.
Os tipos de algoritmos para atacar esses dois tipos de problemas são chamados de regressores e classificadores. O problema de regressão não é atacado neste trabalho, portanto focaremos apenas nos classificadores que estão descritos na próxima seção.
3.2 CLASSIFICADORES
Classificadores são algoritmos supervisionados de aprendizado de máquina. Nesse tipo, as etiquetas que os modelos tentam prever são valores discretos. Neste trabalho são comparados 3 algoritmos de classificação: Support Vector Classifier, Random Forest Classifier e K Nearest Neighbours. Cada algoritmo será descrito nas subseções a seguir.
3.2.1 Random Forest Classifier
Para entender o algoritmo Random Forest Classifier, primeiro é preciso entender o que são Árvores de decisão. Isso porque o algoritmo Random Forest Classifier é um algoritmo composto por diversas árvores de decisão, como será explicado.
Árvores de decisão é um preditor, h : X → Y, que prevê a classe de um exemplo x por meio de uma travessia de um nó raiz a um nó folha (SHALEV-SHWARTZ; BEN-DAVID, 2014). Para cada nó dessa travessia, há uma divisão de caminhos que são tomados de acordo com alguma feature do exemplo. Para exemplificar, pode-se criar um conjunto de dados artificial que descreve entidades do folclore brasileiro. Esse conjunto tem 3 exemplos e 2 features: número de membros inferiores e se tem cabeça ou não. Esse conjunto de dados pode ser visto na Tabela 1.
Tabela 1 – Conjunto de dados artificial com entidades do folclore brasileiro Nº de membros inferiores Possui cabeça? Entidade
1 Sim Saci Pererê
4 Não Mula sem cabeça
4 Sim Lobisomem
A Figura 2 mostra uma possibilidade de uma árvore de decisão para o conjunto de dados da Tabela 1. Suponha que um novo exemplo apareça com 4 patas e uma cabeça. Para a travessia da árvore, inicia-se no nó raiz. Tendo o exemplo 4 patas, seguindo pelo caminho da direita até a segunda condição, onde continua à direita pois o exemplo tem cabeça. Chega-se, então, à etiqueta prevista: Lobisomem.
O problema que a árvore de decisão tenta resolver é criação de uma árvore, como no exemplo da Figura 2, para dizer quais são as etiquetas de exemplos que não foram vistos antes. O modo usual de se criar uma árvore se dá conforme (SHALEV-SHWARTZ; BEN-DAVID, 2014). Primeiro começa com o nó raiz. São executadas diversas iterações. Em cada iteração,
31 4 TRABALHOS RELACIONADOS
Neste capítulo, dois trabalhos relacionados são apresentados. Para cada trabalho é apresentado o problema, solução encontrada e qual a relação do trabalho descrito com o trabalho aqui apresentado. A referência para cada estudo estará no primeiro parágrafo da seção que o descreve.
4.1 CHURN PREDICTION IN SAAS USING MACHINE LEARNING
O trabalho de (RAUTIO, 2019) tem por objetivo prever churn de clientes de uma empresa que tem como oferta um SaaS para marketing digital. A definição de churn, no contexto do trabalho citado, é a de um evento onde um cliente deixa de usar os produtos ou serviço de uma empresa. A base de dados usada pelo autor foi extraída da empresa finlandesa Smartly.io, que oferece soluções em marketing para plataformas como Facebook ou Pinterest.
Para alcançar o objetivo, o autor utiliza métodos de aprendizado de máquina. Os algoritmos e a execução da solução abordada serão explicados a seguir.
O autor descreve o churn como algo importante para ser prevenido e argumenta que a maior parte das empresas não tem conhecimento dos fatores que levam ao churn do cliente para reagir a tempo. Os objetivos específicos do trabalho são dois: encontrar o melhor algoritmo de aprendizado de máquina para prever o churn da empresa e encontrar os fatores que mais influenciam nisso.
Um dos problemas do autor é o baixo volume de dados para comparação. Como ele mesmo cita, geralmente mais dados para comparação significam melhores resultados. Para a predição de churn, a empresa precisa de informações de seus consumidores, que, neste caso, não são muitos. Além disso, por a taxa de churn ser abaixo dos 5%, o conjunto de dados acaba se tornando desbalanceado e suscetível a ruídos.
Outro problema é quando o motivo do churn se dá por um fator externo ao serviço oferecido. O autor cita alguns desses motivos, partindo dos mais comuns como corte de recursos de marketing nas empresas contratantes do sistema até mais específicos, como a única pessoa que sabia usar o serviço saindo da empresa.
O autor tem algumas opções para formular o problema, como “Qual a probabilidade de um cliente virar churn?” e “Quais são os clientes que possuem mais chance de virarem churn?”. A formulação escolhida foi “Com base nos dados dos últimos 2 meses desse cliente, ele virará churn?”, fazendo com que o problema seja um problema de classificação tal que as classes são “Sim” e “Não”. Por conter as etiquetas dos exemplos usados, o tipo de aprendizado é o supervisionado.
A métrica escolhida pelo autor foi a precisão, por ser mais importante para a empresa conseguir identificar verdadeiros-positivos, segundo ele. Foram usados 4 algoritmos na execução do trabalho: Redes neurais recorrentes (algoritmo Long Short-term Memory , abreviado para
34
removidos registros de usuários que não aceitaram nem recusaram a renovação até o período da extração da base. Foi criado um algoritmo para a execução desse passo.
O terceiro nó representa o passo de adaptação do conjunto de dados para ser usado nos algoritmos, além da separação do conjunto de treinamento e testes. O quarto nó é o passo que usa os dados resultantes do terceiro nó para a criação dos modelos. São criados seis modelos, combinando as categorias de produtos e os algoritmos.
Por fim, no quinto e último nó, os resultados são analisados e é criada a distribuição que é comparada com os resultados dos classificadores.
Tabela 2 – Resultados de ambos os classificadores utilizados em (PRASASTI et al., 2014) Produto Classificador Acurácia Revocação Precisão F1-score
LP C.45 72.12% 83.91% 74.10% 78.71%
SVM 82.61% 86.88% 88.05% 87.46%
MP SVMC.45 81.95%72.68% 85.80%84.86% 88.14%74.54% 86.96%79.37%
HP C.45 82.87% 76.39% 92.87% 84.15%
SVM 82.94% 76.85% 92.58% 83.99%
Fonte: Traduzido de (PRASASTI et al., 2014)
Figura 8 – Curvas ROC dos resultados da busca de hiperparâmetros dos classificadores em (PRASASTI et al., 2014)
Fonte: (PRASASTI et al., 2014)
Os valores das métricas dos resultados dos classificadores está no Tabela 2. No trabalho, o autor usou a busca por combinação dos melhores parâmetros. Os resultados foram ordenados
35 por acurácia, precisão, revocação e F1-score, seguindo essa ordem de importância. Além da tabela, foram criados três gráficos de curva ROC (Receiver Operating Characteristics), como pode ser visto na Figura 8. Em cada um desses gráficos, há três linhas, sendo uma para cada modelo e a linha dos palpites aleatórios, que significa, numa classificação binária, uma porcentagem de 50% de acerto. Neste tipo de gráfico, o eixo x representa a taxa de falsos positivos e o eixo y a taxa de verdadeiros positivos, fazendo com que a posição (1,0) no gráfico seja a ótima.
Os resultados das distribuições de frequências criadas pelo autor a partir das probabilida-des do SVM estão representadas na Figura 9. Para essa distribuição, o limiar definido pelo autor foi 50%, ou seja, todos os exemplos que ficarem acima de 50% de chance de serem positivos serão assim classificados e abaixo disso serão classificados como negativos.
Figura 9 – Distribuições criadas a partir da probabilidade de classificação do algoritmo SVM em (PRASASTI et al., 2014)
Fonte: (PRASASTI et al., 2014)
Em cada gráfico da Figura 9, a linha azul representa os clientes que viraram churn. No gráfico superior direito, essa linha mostra 2 picos, um no valor aproximado x = 0.1 e outro no valor aproximado x = 0.9. Esses picos representam, respectivamente, o número de clientes que não tiveram uma probabilidade alta de serem churn e não viraram churn e o número de clientes que tiveram uma probabilidade alta de virarem churn e viraram. Por isso, nesta linha, quanto maior o número de clientes acima de x = 0.5 e quanto menor o número de clientes abaixo de x = 0.5, mais assertiva foi a probabilidade. O inverso é verdadeiro para a linha tracejada em vermelho, que significa os clientes que se mantiveram no sistema.
36
Com base nos resultados representados na Tabela 2 e nas Figuras 8 e 9, o autor conclui que ambos os algoritmos utilizados tiveram uma boa performance. Também pode-se concluir que o método utilizado com base nas distribuições apresentados e que resulta na probabilidade de um usuário virar churn mostrou-se útil e aceitável, visto que sua comparação com os resultados das métricas de classificações variaram pouco.
No trabalho também foi criada uma forma de predição de Customer Lifetime Value (Valor de tempo vida do usuário, traduzido literalmente), que é o valor monetário que o usuário irá despender no sistema. Saber esse valor de antemão mostra-se útil para a estratégia que será usada para manter esse usuário no sistema, otimizando os gastos conforme o valor que será retornado.
Como no primeiro trabalho relacionado, uma das relações do trabalho citado com o presente trabalho também se dá na semelhança do contexto do problema atacado. Além disso, a comprovação de bons resultados para o SVM influenciaram para a escolha do algoritmo neste trabalho, embora o conjunto de dados do autor não tenha o mesmo nível de desbalanceamento. Insightscomo o uso das curvas ROC para apresentar os resultados também foram extraídos.
37 5 PROJETO DOS EXPERIMENTOS
5.1 OBTENÇÃO DA BASE DE DADOS
O primeiro passo do projeto foi a definição do período de tempo em que os dados dos clientes estariam contidos. Isso porque as funcionalidades do sistema, tal como o modelo de negócio, oferta e marketing que a empresa utiliza só tiveram uma certa estabilidade em relação às alterações recentemente. O período escolhido, então, foi de um ano e seis meses, contando a partir do início de 2018.
Um usuário, ao entrar no sistema, passa a ter 7 dias para testá-lo. Cada um desses dias apresenta uma nova oportunidade para a predição de assinatura, por isso foram criados 7 conjuntos de dados. Cada conjunto de dados D, tal que 1 6 D 6 7, representa o D-ésimo dia de teste dos usuários.
A construção dos conjuntos de dados teve início na cópia da base de dados de clientes. Esta cópia foi inserida numa instância do banco de dados MySQL hospedada na máquina que foi utilizada para a execução dos experimentos. A partir dessa base de dados, foram executadas buscas que retornaram valores que descrevem o uso do sistema pelos clientes.
Foram executadas 38 buscas, uma para os identificadores da conta do usuário, uma para cada atributo descrito no Apêndice A e um com valor binário, sinalizando se o cliente assinou ou não o sistema nos 30 primeiros dias contados a partir do seu registro. Este último atributo é a etiqueta.
Os resultados das buscas foram agrupados por usuário e por dia, constituindo os conjuntos de dados originais. Esse agrupamento é possível pois a data de criação de cada registro encontra-se gravada na baencontra-se de dados. Disponibilizadas, então, a data de criação de conta e a data de criação de cada registro que representa um valor de alguma feature, é possível saber quais são aqueles registros que foram criados no n-ésimo dia da conta do usuário, tal que 1 ≤ n ≤ 7. Esse agrupamento acontece pois há a relativização dos dias de teste de um usuário, isto é, o dia 1 de um usuário A pode não ser no mesmo dia 1 de um usuário B. Para a execução do trabalho, só importa quantas comandas foram criadas no primeiro dia de vida da conta de um usuário, por exemplo, independente da data deste dia.
Do conjunto total de usuários buscados, alguns registros foram removidos por se tratarem de contas utilizadas pela equipe de desenvolvimento do produto para testes e demonstrações, restando 3.373 registros. Conforme dito, os dias de conta do usuário são relativos à criação das contas e, por isso, todos os conjunto de dados têm o mesmo número de registros, pois todos os usuários tem o dia 1, 2, 3, 4, 5, 6 e 7.
A partir dos atributos retornados das buscas, outros 87 novos foram criados. 28 desses novos atributos são médias de objetos ou valores registrados pelo usuário no dia e nos dias anteriores do conjunto de dados, 28 são medianas, também de objetos e valores registrados do dia e dos dias anteriores, 10 são de razões de registros ou valores sobre o número total de
38
clientes, 3 são de razões de registros ou valores sobre o número total de comandas e 18 são de razões de registros ou valores sobre o número total de profissionais. A criação de novas features nos conjuntos de dados resultou numa melhora média de 7,72% nas melhores combinações encontradas com o Algoritmo 1. Essa média foi calculada conforme a seguinte equação:
Í7
i=1Bi− bi
7
Tal que Bi é o resultado percentual da melhor combinação possível (considerando as features geradas) para o dia i e bi o resultado percentual da melhor combinação possível (considerando apenas as features originais) para o dia i. As melhores combinações dizem respeito às combinações de subconjunto de melhores features e algoritmos que obtiveram melhores resultados na execução no Algoritmo 1 e descritas na Seção 5.3.
5.2 DESCRIÇÃO DAS FEATURES
A Tabela 3 mostra alguns exemplos que resumem todos os tipos de atributos no conjunto de dados. Na primeira coluna da tabela, o nome dos atributos. Da segunda coluna em diante, o Dn, representando o n-ésimo dia de conta. No Apêndice A, os atributos originais estão descritos
um a um. Abaixo, são explicados conceitos de alguns atributos gerados a partir dos originais que se aplicam a todos do mesmo grupo. Para a listagem de todos os atributos gerados, consultar o Apêndice B.
Tabela 3 – Exemplos de alguns atributos de valores originais e gerados para um usuário
Feature D1 D2 D3 D4 D5 D6 D7 comandas 5 34 0 26 49 47 0 venda_total 422,0 2995,0 0,0 2748,0 4065,0 3664,0 0,0 comandas_media 0 19,5 13,0 16,25 22,8 26,83 23,0 venda_total_media 0 1708,5 1139,0 1541,25 2046,0 2315,67 1984,86 comandas_mediana 0 19,5 5 15,5 26 30,0 26 venda_total_mediana 0 1708,5 422,0 1585,0 2748,0 2871,5 2748,0 comandas_d_por_cliente_t 0,5 0,34 0,0 0,17 0,29 0,25 0,0 venda_total_d_por_cliente_t 42,2 29,95 0,0 18,44 23,77 19,7 0,0 venda_total_d_por_comanda_d 84,4 88,09 0 105,69 82,96 77,96 0 comandas_d_por_profissional_t 0,83 5,67 0,0 4,33 8,17 7,83 0,0 venda_total_d_por_profissional_t 70,33 499,17 0,0 458,0 677,5 610,67 0,0
Voltando à explicação da Tabela 3, os atributos originais são apenas a comandas e venda_total. Os atributos comandas_media e venda_total_media são atributos gerados a partir dos originais e guardam a média de objetos e valores registrados, respectivamente. Repare que no primeiro dia, ambos os atributos estão com valor zero. Isso porque o valor real seria redundante no conjunto. A alternativa de simplesmente não usar os atributos de média no conjunto do primeiro dia para remover a redundância foi descartada para tornar mais fácil
39 a execução dos algoritmos de testes que serão explicados no decorrer do trabalho. Para os atributos comandas_mediana e venda_total_mediana, a lógica é a mesma dos atributos de média, só alterando o valor de média para mediana.
Os atributos comandas_d_por_cliente_t e venda_total_d_por_cliente_t são os atributos de razão sobre o número total de clientes. No primeiro atributo é possível observar a letra d depois de comandas e a letra t depois de cliente. Essas letras sinalizam que o cálculo da razão está sendo feito com as comandas criadas no dia (d) sobre os clientes criados ao todo (t), como na equação abaixo:
comandas_d_por_cliente_t = Quantidade de comandas criadas no dia Quantidade de clientes criados ao todo Vale ressaltar que não inclui os dias futuros.
A hipótese para a criação dessas razões é que elas descrevem o relacionamento entre as funcionalidades do sistema e isto ajudará o modelo a diferenciar um usuário que cria vários registros de um objeto apenas para testar o sistema (e geralmente cria várias comandas para um mesmo cliente, por exemplo) de outro que cria vários registros por já estar usando o sistema (várias comandas para vários clientes). Para os outros atributos que simbolizam razões, a lógica é a mesma, com a exceção do atributo venda_total_d_por_comanda_d, que tem como divisor um valor que foi registrado apenas no dia, e não ao todo (por isso o d depois de comanda).
O resultado final do conjunto de dados criado está resumido na Tabela 4. Tabela 4 – Características dos conjuntos de dados
Número de features originais 36
Número de features geradas 87
Número total de features 123
Número total de exemplos 3.373
Número de exemplos com classificação positiva 275 (8,15%) Número de exemplos com classificação negativa 3.098 (91,85%)
5.3 CRIAÇÃO E VALIDAÇÃO DOS MODELOS
Após criados os conjuntos de dados, utilizou-se a interface SelectKBest da biblioteca scikit-learn para atribuir notas de importância a cada uma das features e ordená-las das mais importantes para as menos importantes. A interface citada utiliza a função Qui-quadrado para chegar a esses valores. A Figura 10 mostra as 10 melhores features de cada conjunto de dados. Na figura, o eixo x representa os dias, ou seja, cada conjunto. O eixo y, por sua vez, representa a posição da feature no ordenamento, indo da menor e mais importante, até a décima posição. Cada quadrado no gráfico mostra a posição da feature que está associada a sua cor. As linhas pontilhadas mostram a movimentação das features no ordenamento. Com base nessa figura, podemos perceber que as features movimentacao_saida e venda_total se mantiveram
41 features. Como a iteração vai de 1 a 123, a iteração abrange o uso de apenas a melhor feature até todas as features. Depois de separar o X com apenas as melhores features, o conjunto é dividido em 2: conjunto de testes (variável teste) e conjunto de treino (variável treino). Essa divisão está programada para deixar 40% do conjunto para o teste e os outros 60% para o treinamento. Por ser um conjunto de dados desbalanceado em relação às etiquetas, a divisão é estratificada, o que significa que ambos os conjuntos terão por volta de 8,15% de exemplos positivos (conforme Tabela 4), mesmo que para isso tenha que repetir alguns exemplos em ambos os conjuntos. No último ciclo, que vai da linha 6 à 10, é iterado sobre os 3 algoritmos utilizados. Para cada algoritmo, um modelo será criado com o conjunto de treino (linha 7) e testado com o conjunto de testes (linha 8). Os hiperparâmetros de cada algoritmo são os padrões de suas implementações na biblioteca scikit-learn. Atribui-se então os resultados à variável resultado (linha 8) que são salvos em um arquivo (linha 9). Os resultados são os valores das principais métricas (F1-score,
precisão, revocação e acurácia).
Levando em conta o contexto atual da empresa, a métrica que mais condiz com as regras de negócio que seriam contempladas com este trabalho é a F1-score. Isso porque, no contexto,
uma boa precisão significa menos tempo desperdiçado contatando clientes que não virarão pagantes e uma boa revocação significa mais clientes que se tornarão pagantes sendo atendidos. No inverso, uma má precisão significa mais tempo desperdiçado contatando clientes que não se tornarão pagantes e uma má revocação significa menos clientes que podem se tornar pagantes tendo um atendimento personalizado. Por bons resultados em ambas as métricas beneficiarem, de certa forma, igualmente a empresa, a métrica da média harmônica fora escolhida para ser usada na criação e validação dos modelos.
Tabela 5 – Valores de k do Algoritmo 1 que obtiveram os melhores resultados para o Random Forest Classifier
Dia Número de melhores features
1 74 2 77 3 38 4 66 5 73 6 114 7 53
Definida a métrica, os resultados do Algoritmo 1 então são ordenados e separadas as melhores performances de cada algoritmo. Na comparação de resultados, o Random Forest Classifier teve uma performance melhor que os outros dois algoritmos em todos os dias. A média da diferença do Random Forest Classifier para o K Nearest Neighbours e para o Support Vector Classifierfoi de 27,91% e 14,64%, respectivamente. A partir disso, então, decide-se pelo Random Forest Classifier para dar continuidade ao experimento. Na Tabela 5 estão dispostos os melhores valores de k (obtidos no Algoritmo 1) para cada dia da semana. Esses números são
42
a quantidade de melhores features que foram utilizadas para alcançar os resultados obtidos para o algoritmo Random Forest Classifier. Estes valores também serão utilizados nos experimentos para a construção de um Random Forest Classifier com hiperparâmetros otimizados.
43 6 EXPERIMENTOS
No projeto dos experimentos foram obtidos resultados para cada combinação de algo-ritmo e número de melhores features ao executar-se o Algoalgo-ritmo 1. A partir disso, o algoalgo-ritmo Random Forest Classifierfoi escolhido para ser usado nos experimentos.
Os números de melhores atributos da Tabela 5 serão usados nos experimentos. Isso significa que nos experimentos, ao contrário do projeto, não se usou a alternância entre esses números. Por outro lado, novos valores de hiperparâmetros foram testados por meio da validação em grade. Nesta técnica, são escolhidos, para cada hiperparâmetro, valores que podem ser usados. Depois, para cada combinação do conjunto de hiperparâmetros, é criado um modelo e seus resultados são validados. Ao final, obtém-se a combinação que obteve o melhor resultado. O algoritmo de validação em grade utilizado foi o GridSearchCV da biblioteca scikit-learn. Na Tabela 6 estão listados os valores escolhidos para os hiperparâmetros.
Tabela 6 – Valores de hiperparâmetros utilizados na validação em grade Hiperparâmetro Valores
n_estimators [100, 10, 50, 200] criterion [gini, entropy] min_weight_fraction_leaf [0,.1,.2,.4,.5]
max_features [auto, sqrt, log2, None] min_impurity_decrease [0,.1,.2,.4,.5]
bootstrap [Sim, Não]
class_weight [None, balanced, balanced_subsample]
Foi criado o Algoritmo 2 para a validação dos hiperparâmetros e registro dos resultados para cada conjunto de dados. No algoritmo, as linhas 1 e 9 delimitam o único ciclo deste algoritmo. Esse ciclo é necessário para que o processo seja executado para os 7 conjuntos de dados. Na linha 2, o conjunto de dados do dia d é lido e atribuído à variável dataset e na linha 3 essa variável é redimensionada para excluir os atributos que não estão entre os k melhores. Os valores de k estão listados na Tabela 5 e são diferentes para cada conjunto de dados. A linha 4 separa o conjunto de dados resultante (variável X) em 2: conjunto de testes e conjunto de treinamento. Na linha 5, a melhor combinação de hiperparâmetro é encontrada com a técnica de validação em grade e é atribuída para a variável melhores_hiperparâmetros. Na linha 6, o modelo é criado utilizando o conjunto de treinamento e a melhor combinação de hiperparâmetros encontrada. Na prática, as operações da linha 5 e da linha 6 são executadas ao mesmo tempo, pois a implementação da validação em grade já cria os modelos para validá-los. Por fim, as linhas 7 e 8 testam o modelo com o conjunto de dados de teste e salvam o resultado em um arquivo para análise.
Os melhores parâmetros encontrados na execução do Algoritmo 2 estão dispostos na Tabela 7.
45 A Figura 11 mostra o resultado final para as métricas de F1-score, revocação e precisão. Pode-se perceber que, com excessão do dia 6, todos os dias possuem um F1-score igual ou melhor ao dia anterior. A explicação intuitiva para isso pode ser a de que as ações de um usuário nos primeiros dias podem não condizerem com as ações que ele faria no dia a dia. Por estar no começo do período de teste, o cliente pode estar em uma fase mais exploratória e menos processual.
Ainda sobre a Figura 11, pode-se perceber que o único dia em que a revocação ficou maior do que a probabilidade randômica (50% de chance de um usuário se tornar ativo) foi o quarto dia. Neste dia a precisão também teve a segunda pior performance. Não foi possível levantar nenhuma hipótese para este evento.
O melhor resultado para a métrica F1-score e para a precisão foi no dia 7. Pela caracterís-ticas de alguns atributos, que derivam seu valor de informações de dias passados (como a razão de comandas criadas por profissionais totais cadastrados), pode-se cogitar que essa influência ajude o algoritmo fornecendo um conjunto de dados mais descritivo do usuário.
Para a métrica de precisão, um valor acima de 70% foi alcançado em 3 dos 7 conjuntos de dados utilizados. Já para a métrica de revocação, nenhum do 7 conjuntos de dados utilizados possibilitou um resultado maior que a probabilidade randômica (50%) de acerto. Um modelo com tais resultados representa na prática um nível bom de certeza em relação às predições positivas, mas um nível de certeza ruim em relação às predições negativas.
47 7 CONCLUSÃO
O objetivo principal do trabalho era criar um modelo de predição de clientes que se tornariam assinantes em um SaaS. Para isto, os algoritmos Random Forest Classifier, Support Vector Classifier e K Nearest Neighbours foram comparados utilizando a base de dados da empresa colaboradora e, dentre eles, o Random Forest Classifier teve melhor performance na etapa de projeto do experimento. Já no experimento, o Random Forest Classifier foi testado com uma combinação de parâmetros numa tentativa de melhorar os resultados obtidos.
Uma boa precisão fora alcançada e, conforme dito, uma boa precisão significa que os usuários classificados como possíveis assinantes se tornarão realmente assinantes. Para a empresa, o benefício disso é menos gasto de recursos ou dinheiro com falso-positivos que provavelmente não se tornarão assinantes. Mesmo sendo definida a F1-score como métrica principal para o trabalho, o resultado com uma boa precisão é um ponto a favor do uso de aprendizado de máquina para a predição de clientes.
Por fim, baseando-se nos resultados, uma estratégia de vendas pode ser criada tal que o contato com o cliente aconteça no 3º ou no 5º dia de vida de sua conta. Isso se dá por o algoritmo ter uma maior precisão nesses dias. Embora o 7º dia possua a maior precisão dos dias, um usuário nessa fase já pode ser atendido por um setor que lida com clientes já ativos. Isso quer dizer que a venda pró-ativa faz mais sentido quando é feita antes do término do trial. É válido, portanto, concluir que o objetivo geral foi em parte alcançado.
Também foi possível identificar quais funcionalidades usadas pelos usuários influenciam mais em sua decisão de assinar ou não o sistema. Com essa informação, a empresa colaboradora obtém mais uma base para as tomadas de decisões em relação a manutenção ou incremento de funcionalidades.
Além dos resultados obtidos na criação do modelo, o aprendizado adquirido durante a execução do trabalho abre possibilidades para uso de aprendizado de máquina nos processos de decisões da empresa colaboradora.
Para os trabalhos futuros, muitos dos passos comuns à criação de modelos podem ser melhorados. Na obtenção de dados, pode-se criar novos atributos que incorporem mais o registro histórico dos usuários nos dias anteriores ao conjunto de dados. No tratamento de dados, o problema do desbalanceamento pode ser tratado com técnicas de oversampling ou undersampling. E por fim, na criação do modelo, outros classificadores podem ser testados. Com a base de dados, pode-se, ainda, buscar identificar clientes ativos que poderão se tornar churn, assim como fora feito nos trabalhos relacionados.
49 REFERÊNCIAS
1.6. Nearest Neighbors — scikit-learn 0.21.3 documentation. [S.l.: s.n.]. https://scikit-learn.org/stable/modules/neighbors.html. Acesso em 23/11/2019.
BRASIL Ministério do Planejamento, Desenvolvimento e Gestão. Gabinete do Ministro. Portaria nº 442, de 27 de dezembro de 2018. Diário Oficial da União, Brasília, DF, 27 dez, p. 517, 2018. . Gabinete do Ministro. Portaria nº 468, de 22 de dezembro de 2017. Divulga os dias de feriados nacionais e estabelece os dias de ponto facultativo, no ano de 2018, para cumprimento pelos órgãos e entidades da Administração Pública federal direta, autárquica e fundacional do Poder Executivo. Diário Oficial da União, Brasília, DF, 26 dez, p. 983, 2017.
CRISTIANINI, Nello; SHAWE-TAYLOR, John et al. An introduction to support vector machines and other kernel-based learning methods. [S.l.]: Cambridge university press, 2000. DUARTE, Denio; STÅHL, Niclas. Machine learning: a concise overview. In: DATA Science in Practice. [S.l.]: Springer, 2019. p. 27–58.
FOX, Armando; PATTERSON, David A; JOSEPH, Samuel. Engineering software as a service: an agile approach using cloud computing. [S.l.]: Strawberry Canyon LLC, 2013.
GODSE, Manish; MULIK, Shrikant. An approach for selecting software-as-a-service (SaaS) product. In: IEEE. 2009 IEEE International Conference on Cloud Computing. [S.l.: s.n.], 2009. p. 155–158.
LAPLANTE, Phillip A; ZHANG, Jia; VOAS, Jeffrey. Distinguishing between Software Oriented Architecture and Software as a Service: What’s in a Name? figshare, 2008.
PRASASTI, Niken et al. Customer lifetime value and defection possibility prediction model using machine learning: An application to a cloud-based software company. In: SPRINGER. ASIAN Conference on Intelligent Information and Database Systems. [S.l.: s.n.], 2014. p. 62–71. RAUTIO, Anton. CHURN PREDICTION IN SAAS USING MACHINE LEARNING, 2019. SHALEV-SHWARTZ, Shai; BEN-DAVID, Shai. Understanding machine learning: From theory to algorithms. [S.l.]: Cambridge university press, 2014.
TORBACKI, W. SaaS–direction of technology development in ERP/MRP systems. Archives of Materials Science, v. 58, p. 58, 2008.
TURNER, Mark; BUDGEN, David; BRERETON, Pearl. Turning software into a service. Com-puter, IEEE, v. 36, n. 10, p. 38–44, 2003.
51 APÊNDICE A – FEATURES EXTRAÍDAS NAS BUSCAS
a) agendamentos, agendamentos_cancelados, agendamentos_confirmados, agen-damentos_nao_confirmados: Número de agendamentos cadastrados no sistema. Primeiro o número total e, nos outros 3, o número por status do agendamento. O status"cancelado"é usado quando o cliente cancela previamente o agendamento. O status"não confirmado"representa um agendamento que ainda não foi confirmado pelo cliente e o "confirmado"representa um agendamento que já foi confirmado. Essa confirmação pode ser feitas de várias formas e não entram no escopo do sistema. b) anamneses: Número de anamneses criadas no sistema. Uma anamnese precisa,
necessariamente, estar atrelada a um cliente. A anamnese é um formulário dinâmico usado para entrevistas com os clientes e pacientes.
c) avaliacoes: Número de avaliações feitas pelos clientes dos estabelecimentos. Uma avaliação está atrelada a um serviço realizado e cadastrado em uma comanda. Uma comanda pode ter vários serviços, portanto, uma comanda pode ter várias avaliações. d) campanhas: Campanhas são formas de divulgar promoções, anúncios ou qualquer outra coisa que o usuário queira mostrar no website personalizado da empresa ou enviar por meio de mensagens de texto para seus clientes.
e) categorias: Categorias de produtos. Servem para definir comissões por categoria ou apenas para agrupar e organizar a lista de produtos.
f) clientes: Cadastro dos clientes das empresas. Consta, nesse cadastro, uma grande gama de informações do cliente, que vão desde e-mail, nome, endereço a dados mais específicos como dependentes (ligação entre um cliente e outro), pontos do programa de fidelidade etc.
g) comandas e comandas_finalizadas: A comanda é, conforme dito, onde fica regis-trada a presença do cliente no que tange ao consumo e serviços realizados. Uma comanda finalizada é uma comanda que já foi paga pelo cliente e o usuário deu baixa no sistema, atrelando pagamentos e exibindo-os no módulo do financeiro.
h) compras: Registros de compras realizadas pelo estabelecimento. São também uma forma de dar entrada de um produto no estoque.
i) compras_total: O valor total pago nas compras registradas no sistema.
j) cores_agendamentos: Cores personalizadas para os agendamentos. As cores perso-nalizadas, como dito anteriormente, servem para dar visibilidade de um agendamento com base em seu status ou o que ele significa. Um exemplo para isso é quando um cliente tem que voltar a um salão para fazer o "retrabalho". Nessa situação, o cliente em questão tem que ser tratado com um tato diferente, e por isso a cor no agendamento serve como um sinal visual para aqueles profissionais que o atenderão.
52
k) despesas: Quantidade de registros de despesas criados. Uma despesa é uma saída monetária. Tipos de despesas incluem pagamento de salários, comissões, produtos, etc.
l) dia_segunda_feira, dia_terca_feira, dia_quarta_feira, dia_quinta_feira, dia_sexta_feira e dia_sabado, dia_domingo: Atributos booleanos que diz qual o dia da semana do n-ésimo dia do usuário do exemplo. Por exemplo, se estamos analisando o conjunto de dados do dia 3 e o 3º dia de teste de um usuário caiu na data 16 de novembro de 2019, então o atributo dia_sabado terá como valor "Verda-deiro" enquanto os outros 6 atributos terão como valor "Falso". A ideia desse atributo é levar em conta se o uso do sistema por parte do usuário ser maior ou menor pode ser justificado pelo dia da semana (menos uso no domingo e mais uso nas sextas-feira, por exemplo).
m) fechamento_caixa: Quantidade de fechamento de caixa realizado pelo usuário. Um fechamento de caixa é uma conferência de caixa. O fluxo de uso normalmente é iniciado no começo do turno do estabelecimento com a abertura do caixa e, ao final, é feito uma conferência para checar se o dinheiro físico no caixa é igual ao registrado no sistema. Daí, então, o caixa é fechado e um registro é criado.
n) feriado: Atributo que diz se o dia da semana do n-ésimo dia do usuário do exemplo é feriado. Por exemplo, se o 3º dia de teste de um usuário caiu no dia 25/12/2018, então esse atributo terá valor verdadeiro. A definição das datas de feriado está em (BRASIL, 2017) e (BRASIL, 2018).
o) fornecedores: Quantidade de fornecedores cadastrados no sistema. Um registro é uma descrição de fornecedor. Pode ser usado nas compras para registro de entrada de produtos.
p) marcas: Número de marcas de produtos. Serve apenas para organização e agrupa-mento de produtos.
q) movimentacao_entrada e movimentacao_saida: Valor monetário movimentado. Grava o que foi recebido e o que foi enviado, respectivamente. A movimen-tacao_saida diz respeito aos valores das despesas cadastradas. A movimenta-cao_entradadiz respeito aos recebimentos cadastrados.
r) pacotes e pacotes_finalizados: Pacotes são produtos ou serviços que são comprados antecipadamente ao seu uso. Um exemplo disso é quando um cliente de uma empresa vai ao salão para cortar o cabelo todo mês. O estabelecimento pode vender, então, 12 cortes (um ano de corte, portante) por um preço menor, de uma vez. A partir daí, o cliente não precisa pagar o corte enquanto este pacote comprado tiver saldo suficiente. Um pacote pode ser simplesmente salvo ou faturado. Ao ser faturado, ele se torna um pacote finalizado.
53 s) pacotes_pre_definidos: Ao vender um pacote, o usuário precisa escolher quais são os produtos que serão vendidos manualmente. Um pacote pré definido é uma facilidade para o usuário que permite o preenchimento automático de pacotes com definições pré-existentes.
t) profissionais: Número de profissionais cadastrados no sistema. O registro do pro-fissional é usado para a criação de agendamentos, comandas, registro de pagamento de comissões, etc.
u) recebimentos: Recebimentos são transações em que o beneficiado é o estabeleci-mento. Pode ser um pagamento por um serviço prestado, por exemplo.
v) servicos_produtos: Quantidade de produtos ou serviços cadastrados.
Um registro de serviço é necessário para a criação de um agendamento, de uma comanda, entre outros.
w) vales: Registros de pagamentos adiantados a um profissional. Está relacionado com uma despesa, já que ao pagar o profissional, o estabelecimento gera uma saída de dinheiro (a despesa, no caso).
x) venda_total: Valor total de venda cadastrado. É a soma dos valores de todas as comandas criadas.
55 APÊNDICE B – LISTA DE FEATURES GERADAS
1. agendamentos_cancelados_d_por_profissional_t 2. agendamentos_cancelados_media 3. agendamentos_cancelados_mediana 4. agendamentos_confirmados_d_por_cliente_t 5. agendamentos_confirmados_d_por_cliente_t 6. agendamentos_confirmados_d_por_profissional_t 7. agendamentos_confirmados_media 8. agendamentos_confirmados_mediana 9. agendamentos_d_por_cliente_t 10. agendamentos_d_por_profissional_t 11. agendamentos_media 12. agendamentos_mediana 13. agendamentos_nao_confirmados_d_por_profissional_t 14. agendamentos_nao_confirmados_media 15. agendamentos_nao_confirmados_mediana 16. anamneses_media 17. anamneses_mediana 18. avaliacoes_d_por_comanda_d 19. avaliacoes_d_por_profissional_t 20. avaliacoes_media 21. avaliacoes_mediana 22. campanhas_media 23. campanhas_mediana 24. categorias_media 25. categorias_mediana 26. clientes_d_por_profissional_t 27. clientes_media 28. clientes_mediana 29. comandas_d_por_cliente_t 30. comandas_d_por_profissional_t 31. comandas_finalizadas 32. comandas_finalizadas_d_por_cliente_t
56 33. comandas_finalizadas_d_por_comanda_d 34. comandas_finalizadas_d_por_profissional_t 35. comandas_finalizadas_media 36. comandas_finalizadas_mediana 37. comandas_media 38. comandas_mediana 39. compras_media 40. compras_mediana 41. compras_total 42. compras_total_media 43. compras_total_mediana 44. cores_agendamentos_media 45. cores_agendamentos_mediana 46. despesas_d_por_profissional_t 47. despesas_media 48. despesas_mediana 49. fechamento_caixa_media 50. fechamento_caixa_mediana 51. fornecedores_media 52. fornecedores_mediana 53. marcas_media 54. marcas_mediana 55. movimentacao_entrada_d_por_cliente_t 56. movimentacao_entrada_d_por_profissional_t 57. movimentacao_entrada_media 58. movimentacao_entrada_mediana 59. movimentacao_saida_d_por_profissional_t 60. movimentacao_saida_media 61. movimentacao_saida_mediana 62. pacotes_d_por_cliente_t 63. pacotes_d_por_profissional_t 64. pacotes_finalizados_d_por_cliente_t 65. pacotes_finalizados_d_por_profissional_t
57 66. pacotes_finalizados_media 67. pacotes_finalizados_mediana 68. pacotes_media 69. pacotes_mediana 70. pacotes_pre_definidos_d_por_profissional_t 71. pacotes_pre_definidos_media 72. pacotes_pre_definidos_mediana 73. profissionais_media 74. profissionais_mediana 75. recebimentos_d_por_cliente_t 76. recebimentos_d_por_profissional_t 77. recebimentos_media 78. recebimentos_mediana 79. servicos_produtos_d_por_profissional_t 80. servicos_produtos_media 81. servicos_produtos_mediana 82. vales_d_por_profissional_t 83. vales_media 84. vales_mediana 85. venda_total_d_por_cliente_t 86. venda_total_d_por_comanda_d 87. venda_total_d_por_profissional_t 88. venda_total_media 89. venda_total_mediana
