Como se comporta o TrendTopics do Twitter ? (2) — Código, tratamento e visão geral dos dados

Esse artigo é parte de uma trilogia de textos apresentando meu projeto de estudo de datascience:

1- Contextualização,

2- Código, tratamento e visão geral dos dados

3- Criação do dashboard e exploração dos dados

Introdução

Link para Contextualização

Scrap do Twitter

A utilização dos dados do Twitter é muito facilitada com a API que a própria rede social disponibiliza. A utilização da sua versão gratuita tem algumas limitações como quantidade de tweets retornados, quantidade de chamadas e data pregressa possível de consulta. Como eu decidi focar nos trendtopics, essas limitações não foram obstáculos.

O código é uma execução contínua que faz chamadas na API cada 5 minutos, salvando o resultado em um arquivo CSV.

Código: trendtopicsTXT.py

WebScrap da programação de TV

Um script também em execução contínua, mas nesse caso a cada 15 minutos. As tags HTML são buscadas com o BeatifulSoup e as informações gravadas em arquivo texto. Após capturar os dados dos primeiros canais mostrados, é feito um page down na tabela pra carregar e pegar os dados de todos os canais.

O desenvolvimento desse código trouxe mais desafios e demandou mais estudo. Principalmente por causa da máxima “na minha máquina funciona”. Lembram que contei que usei um servidor gratuito da AWS de 1GB pra rodar os scripts? Levei um tempo até entender que o problema de executar no servidor era ter que trabalhar com Chrome com tão pouco recurso de máquina. Cheguei a tentar com Firefox mas não adiantou também. Outra tentativa foi garantir que o script do Twitter não executasse junto com o scraper para que os recursos ficassem dedicados, mas sem sucesso.

Por isso tive que abandonar a relação com a programação de TV, pelo menos por enquanto.

Código: Scrap2Chrome.py

Tratamento dos Dados

Os dados buscados foram, propositalmente, salvos com alguma repetição. Foi feito dessa maneira para evitar perder dados por alguma falta de conexão, por exemplo. É melhor filtrar os dados posteriormente do que utilizar alguma técnica de preenchimento de dados faltantes.

Para os dados de programação de TV, a ideia era simplesmente limpar as repetições. Mas com a mudança do foco, isso acabou não sendo feito.

Para os dados do Twitter a necessidade de tratamento era maior.

No momento em que escrevo, os dados brutos contém 1.025.657 de linhas.

Tratar os dados precisa de um cuidado extra pois é preciso garantir que a consistência dos dados seja mantida. Para isso é preciso escolher com cuidado as fórmulas que serão aplicadas, as medidas estatísticas que serão usadas, os atributos que serão usados e os que serão descartados.

As transformações feitas foram as seguintes:

1Primeira ação foi padronizar as hashtags tirando o # e colocando todas em caixa alta. Isso permitiu um agrupamento de trendtopics iguais e que eram mostrados separados por serem hashtags ou palavras no tweets.

2 Depois criei no dataframe colunas para representar a hora, id do dia da semana, nome do dia da semana e data sem hora. Fiz isso pra facilitar os tratamentos posteriores de agrupamento e pra mostrar informações nos gráficos

Enquanto escrevia o artigo, percebi que a informação de hora estava errada nos meus dados por causa da diferença de timezone entre o servidor que está capturando os dados e minha máquina, que está gerando o arquivo resumido para o dashboard. Tive que tratar essa questão forçando o timezone de São Paulo.

Resultado:

3 A captura dos trendtopics aconteceu a cada 5 minutos. Não conferi o retorno de todas as consultas mas pude notar falhas em alguma delas por problema de conexão e por erros de resposta da API. Isso poderia prejudicar a análise pois iria interferir no montante de ocorrências de uma hashtag.

Então, para diminuir o efeito dessas falhas de consultas, trabalhei com os dados em um intervalo de tempo diferente do capturado. Diminui a granularidade mas aumentei a confiança.

Com a informação de hora em coluna específica, fiz o agrupamento calculando a média das ocorrências por hora. Nesse momento aproveitei para desconsiderar a coluna com a hora completa pois não era mais relevante

4 No momento que escrevo esse texto, o tratamento dos dados resultou quase 90 mil registros de hashtags, quantidade e horário de consulta, compreendido entre 27/10/2020 e 17/02/2021.

Outras análises

Além dos tratamentos descritos acima, fiz uma outra análise que acabei não concluindo para esse estudo.

A ideia foi gerar substrings das hashtags para unir tópicos semelhantes que estariam separados por um plural, um sufixo ou prefixo, ou até uma composição com outra palavra.

Gerei as substrings, calculei as ocorrências de cada uma mas a quantidade de registros ficou muito grande. Seria preciso filtrar o que é lixo e o que é mistura: NOVE poderia vir de NOVEMBRO, NOVENA ou NOVELA.

Como não foi uma coisa trivial, decidi não evoluir nessa análise para limitar o escopo do estudo.

Conhecendo os dados

Com os dados lapidados, comecei alguns agrupamentos para análise exploratória. O objetivo era começar a ver como os dados se comportavam, entender se minhas suposições de horário e assunto faziam sentido e se tinha alguma aberração acontecendo.

Detectando outlier

A captura de dados começou no final de outubro. Demorei algo próximo a 30 dias pra ter gráficos que eu já pudesse analisar algo. Ao analisar quantidade de ocorrências por dia da semana, um dia da semana específico estava muito destacado frente aos outros. A primeira impressão foi que havia algum erro na captura ou no tratamento dos dados. Para tentar encontrar o erro, analisei os dados abertos e percebi que era impacto das eleições americanas no dia 03/11/2020. Apesar de eu ter consultado hashtags do Brasil, a eleição de 2020 nos EUA fez muito barulho por aqui também.

Eventos outliers como esse impactam muito uma análise por dia da semana ou por hora, como estou fazendo, quando os dados são de um curto espaço de tempo. Pensei em retirar os dados desses dias específicos mas voltei atrás, pois o efeito foi diminuindo a medida que o script do Twitter continuou executando e trazendo mais dados. Por isso, a decisão foi de manter os dados.

Visão geral dos dados

Todo o período

Depois de calculada a média por hora, decidi usar o somatório dessas médias ao exibir a informação durante todo o período, ao invés de fazer média no dia, pra ter uma noção mais próxima da quantidade de tweets que aconteceram.

Média de ocorrências por dia da semana

Usei a média para os efeitos de outliers diminuírem com o tempo

Média por hora do dia

Usei a média para os efeitos de outliers diminuírem com o tempo

Heatmap de dia da semana com hora do dia

Na minha opinião, a melhor visualização para mostrar o panorama do comportamento dos trendtopics em termos de quantidade de ocorrências. Em uma única visão é possível entender o comportamento por dia da semana e por hora do dia.

Notebook com código das transformações e que gera o arquivo CSV que será usado no dashboard. (AnaliseTT)

Conclusão

Interagir com o Twitter foi muito interessante mas tecnicamente simples. Serviu para mostrar algumas possibilidades futuras. Muita coisa relevante é disponibilizada com a API gratuita.

O webscrap da programação de TV teve mais desafios do ponto de vista de desenvolvimento. E raspar uma página com chamadas assíncronas trouxe complicações e aprendizados adicionais.

O tratamento de dados é um ponto da ciência de dados que precisa de muito cuidado pois informações são criadas a partir de outras e se por acaso houver algum erro na regra, toda a base pode ficar inconsistente. Acabei passando por isso nos agrupamentos e no timezone.

As visualizações iniciais dos dados já começam a mostrar que minhas suposições sobre futebol e Flamengo não passavam mesmo de vieses. E afirmações sem dados estão aí pra serem desconstruídas. Coisa que todo mundo sabe, mas é interessante ver quando os dados derrubam nosso próprio achismo.

No próximo artigo vou falar sobre o dashboard e as conclusões que consegui ter explorando os dados.