Reavaliar as regras de envio de email pra não cair no spam

[ricardopoppi]

Hoje o envio individual de emails para cada candidato por seleção e pressão está levando nosso dominio pro spam.

O ideal é implementarmos uma regra de relatório diário ou semanal com os dados de seleção e pressão

[ricardopoppi]

@parrahenri vamos trabalhar a proposta de texto dos relatórios diarios dos candidatos aqui. Te peço fazer uma proposta de texto corrido pra gente usar nesse relatório, com base nos indicadores que selecionamos aqui:

STATUS de seu card, mostrando os dados da interna:

• como respondeu em cada um dos 3 critérios
• quantas vezes foi selecionado
• quantas vezes foi pressionado
• quantas vezes foi compartilhado

UPDATE de status:

• Quantos novos selecionados hoje
• quantos novos pressionados hoje
• quantos compartilhamentos hoje

[danielhmarinho]

@ricardopoppi devemos avaliar se o relatório diário ainda é a melhor solução por dois pontos. A complexidade não é baixa de se fazer um digest ,mas isso tudo bem, o problema pra mim é que sendo diária ainda temos uma chance grande de cair no spam.

[ricardopoppi]

Fiquei pensando nisso... São 8k candidatos né? Mas na lógica só. Mandaremos report pra quem teve interação. Acho que se fizermos a cada dois dias não entramos em spam

[danielhmarinho]

@ricardopoppi mesmo se mandássemos pra so os candidatos que tiveram interação. Esses candidatos provavelmente vão ter interação todo dia. Ai um email todo dia mostrando que 2 pessoas me selecionaram e 3 me pressionaram enche o saco e eu jogo pra spam.

[ricardopoppi]

@danielhmarinho vc tem razão. o ideal seria que tivéssemos uma forma do candidato descadastrar. mas aí acho que essa funcionalidade começa a ficar complexa demais, se assemelhando a um sistema de mailing. talvez semanal seja uma boa nesse sentido, já que são 4 semanas até a eleição. a não ser que vc me diga que há uma solução simples pra unsubscribe nas libs que estamos usando. tem?

[danielhmarinho]

@ricardopoppi não existe uma solução muito simples pra isso. A gente não esta criando uma lista de emails e enviando, são coisas geradas pelo backend e a gente não tem um sistema de subscribe pra isso. Semanal é complicado até porque a gente ainda teria que implementar o digest, não é como se ele fosse ficar pronto agora. Talvez a gente pensar em um meio termo pra isso fosse bom.

[ricardopoppi]

@danielhmarinho imaginei, ter unsubscribe implica em a gente ter a gerencia de lista antes. e aí, é outro sistema, dentro do sistema né?

creio que a melhor opção seria a gente focar no digest, pois mesmo sendo mais trabalhoso, traz valor pra campanha. Outra coisa que podemos avaliar é ter um gatilho onde os envios só começam a partir de um número absoluto ou relativo de interações nos cards de cada candidato. Então seriam só os top 500 ou 1.000 que receberiam emails, por exemplo. Aí a gente diminui o número de envios, foca naqueles que tão sendo mais pressionados e diminui com isso o número de possíveis reports de spam.

[danielhmarinho]

@ricardopoppi eu tinha pensado nisso de um numero absoluto, por exemplo deu 100 pressões envia algo do tipo. Mas o que fazemos com o cara que foi pressionado menos vezes? Envia junto? Ai o gatilho não vai funcionar?

[ricardopoppi]

@danielhmarinho se a gente tiver um numero absoluto ou relativo (ex: mandamos para os 500 candidatos mais pressionados) os outros só recebem se entrarem nessa lista mais seleta. Os envios podem ser executados a cada 4-5 dias e feitos de forma assincrona (tipo 100 por dia). Essa é uma opção.

[danielhmarinho]

@ricardopoppi so que isso é meio que um furo ne? Noa deveria precisar estar em uma lista seleta, a ideia é que todos sem comprometam contra a corrupção, ai parece que a gente ta meio que ignorando a pressao de alguns. Mas acho que seria a forma ideal de se fazer isso

[ricardopoppi]

Sim fica esse furo mesmo. Pensei como solução possível, não ideal. Esse furo seria parcialmente preenchido pelo share público nas redes que aí afetaria a todos

[parrahenri]

a gente cai no spam pelo no. de disparos ou pelo número de relatos de pessoas que recebem o email e dizem que é spam? ou os dois?

[parrahenri]

NOME, temos novidades pra você!

Seu perfil está chamando muita atenção no aplicativo Unidos Contra a Corrupção:

Atualmente, esse é seu status em relação aos 3 compromissos possíveis na campanha: (INDICAÇÃO DAS 3 RESPOSTAS)

NO PERÍODO xx pessoas selecionaram seu perfil, demonstrando que gostaram de seu perfil e quiserem conhecer mais detalhes.

NO PERÍODO xx pessoas pressionaram seu perfil para que se comprometa com os compromissos da campanha.

NO PERÍODO xx pessoas compartilharam seu perfil em outras redes, divulgando para amigos e familiares.

No momento, seu perfil tem:

XX Seleções XX Pressões XX Compartilhamentos

Se ainda não se comprometeu, faça isso agora mesmo para que avisar todos que pressionaram seu perfil dessa mudança de opinião e para aumentar a quantidade de seleções e compartilhamentos!

[parrahenri]

@ricardopoppi texto

[ricardopoppi]

blz! @parrahenri sobre sua pergunta, seria os dois, já que o número de denuncias de spam é proporcional ao de disparos. Se a gente concentra os disparos, segundo algum critério, a chance de denuncia diminui bem

[ricardopoppi]

@parrahenri pra eu poder abrir essa pra implementação, a gente tem que terminar de definir a regra. Sugestão:

(i) os envios rodam a cada 4 dias (ii) enviam para os 1000 perfis de candidatos com mais interação no período (desde o ultimo envio, 4 dias antes) (iii) calculo do ranking pra definir os 1000 perfis: 2 x (número de pressões) + (número de seleções) + (número de compartilhamentos)

Que tal? (cc @danielhmarinho @davidCarlos)

[parrahenri]

de acordo

[danielhmarinho]

@ricardopoppi agora temos que definir a prioridade em relação ate mesmo ao blockchain. Temos duas semanas para ajustes blockchain e correções. Essa funcionalidade demoraria no mínimo uma semana

[ricardopoppi]

Essa dos envios de emails é mais prioritária que blockchain. Blockchain mantem o valor mesmo após as eleições essa aqui não. Só faz sentido se entrar logo. Então mantemos essa aqui priorizada. Vou atualizar a #212 com o que definimos aqui

[ricardopoppi]

como definimos as regras vou fechar essa aqui, a de implementação é a #212