Integrazione dati Harvest con i dati dei candidati

[paolomainardi]

Al momento abbiamo uno script che sta runnando da qualche giorno (in cron) che si tira giù tutti i tweet che hanno hashtag "#twitantonio", dall'applicazione non facciamo nessun tipo di tracking.

Il codice è questo:
https://github.com/spaghetti-open-data/twitAntonio/blob/master/harvest/harvest-cron.js

Lo schema è questo:
https://github.com/spaghetti-open-data/twitAntonio/blob/master/config.js.production#L46

Usiamo la Search API, questo è la documentazione:
https://dev.twitter.com/docs/using-search

[paolomainardi]

Quello che ci interessa si trova dentro l'oggetto Entities: https://dev.twitter.com/docs/tweet-entities

[stefanoduri]

Quello di non poter tracciare dal sito è un po' un peccato. Forse si potrebbero modificare i link associati ai candidati aggiungendo i parametri che vengono gestiti da Google Analytics (v.http://support.google.com/analytics/bin/answer.py?hl=en&answer=1033867)

Esempio di click su un link "Lista Monti":
http://twitantonio.it/?mep_name=&mep_country=&mep_localParty=Lista%20Monti&utm_source=site&utm_medium=box&utm_campaign=lista%2Bmonti

Gli stessi link diretti a Twitter potrebbero passare per un proxy:
Esempio: al posto di
https://twitter.com/intent/user?screen_name=Marco_Abatecola
mettere
twitter.php?screen_name=Marco_Abatecola&utm_source=site&utm_medium=tw_link&utm_term=Marco_Abatecola&utm_campaign=lista%2Bmonti
con twitter.php che poi fa soltanto una redirect sull'url giusto

immagino che questa soluzione sia un po' un casino da implementare in corsa, però

[paolomainardi]

Ciao Stè, hai ragione, purtroppo le web intents non offrono molto, ma gestiscono in parte quello che scrivi:
https://dev.twitter.com/docs/intents

Qui c'è un inizio di integrazione:
https://github.com/spaghetti-open-data/twitAntonio/blob/master/public/javascripts/application.js#L57

[marcopagliarulo]

Secondo me si risolve agevolmente con l'event tracking di Google Analytics https://developers.google.com/analytics/devguides/collection/gajs/eventTrackerGuide considerate che per gli intents basterebbe inserire nei link questo codice : onClick="_gaq.push(['_trackEvent', 'Intents', 'tweet/user']);

dove tweet per il click su tweet e user per il link sul link all'account del candidato.

Ugualmente si può tracciare tutte le altre azioni semplicemente con la coppia Category Action

[paolomainardi]

@Morpheus80ta infatti usando le callback delle webintents riusciamo proprio a fare questo, magari senza modificare il link, ottimo suggerimento.

[stefanoduri]

sì, anche a me sembra una buona soluzione, molto più semplice di un'operazione sui link

[paolomainardi]

@stefanoduri Io partirei da qui, coordinandomi però con il codice che sta scrivendo @Morpheus80ta. L'idea di fondo è quella di usare i dati dei tweet che stiamo raccogliendo con l'harvest con i candidati che abbiamo nel nostro DB.

Le info sull'harvest sono sul commento iniziale, se vuoi ti passo un dump det tweet che abbiamo fetchato fino ad ora.

Questo è il codice di @Morpheus80ta
marcopagliarulo@ebcf5a3

Che al momento non integra l'harvester, ma tira giù le extra info direttamente da Twitter.

Lo step successivo sarebbe quello di scrivere il collante che mette insieme candidato-tweet_scaricati_harvester

[marcopagliarulo]

Ok su questo fronte mi sono sbloccato, ora ho ben chiaro come recuperare i dati da mongo, facilissimo :-)

Correggetemi se sbaglio, abbiamo bisogno dei tweet con hastag twitantonio ricevuti dai candidati, a quanti e quali di questi hanno risposto, quanti retweet hanno fatto dei tweet con twitantonio (almeno così ho capiro dal mokup della issue #18, ho passato l'harvest sulle api 1.1 ci sono molte più info. I tweet raccolti vengono attualmente usati da qualche parte per cui va fatto un refactoring? I tweet che sono stati raccolti potrebbero essere nuovamente raccolti con le api 1.1?

Se riuscite a darmi queste informazioni per domani mattina penso di completare.

@paolomainardi ti chiedo un consiglio, implemento tutto sul model dei tweet con vari metodi per fare le ricerche tra i tweet e poi le richiamiamo dal mainController?

[twinbit]

Grandissimo Marco!

Mi sembra una soluzione perfetta e pulita, su ogni layer, +1
Il giorno 02/feb/2013 00:01, "Marco Pagliarulo" notifications@github.com
ha scritto:

Ok su questo fronte mi sono sbloccato, ora ho ben chiaro come recuperare i
dati da mongo, facilissimo :-)

Correggetemi se sbaglio, abbiamo bisogno dei tweet con hastag twitantonio
ricevuti dai candidati, a quanti e quali di questi hanno risposto, quanti
retweet hanno fatto dei tweet con twitantonio (almeno così ho capiro dal
mokup della issue #18#18,
ho passato l'harvest sulle api 1.1 ci sono molte più info. I tweet raccolti
vengono attualmente usati da qualche parte per cui va fatto un refactoring?
I tweet che sono stati raccolti potrebbero essere nuovamente raccolti con
le api 1.1?

Se riuscite a darmi queste informazioni per domani mattina penso di
completare.

@paolomainardi https://github.com/paolomainardi ti chiedo un consiglio,
implemento tutto sul model dei tweet con vari metodi per fare le ricerche
tra i tweet e poi le richiamiamo dal mainController?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/58#issuecomment-13018810.

[marcopagliarulo]

Come spesso faccio per accelerare gli sviluppi ho analizzato i requisiti e cercato le soluzioni idonee.

Fermo restando che fondamentalmente ci servono le conversazioni tra gli utenti twtitter partendo dai candidati come punto di unione e considerando che sulla base dell'hashtag twitantonio i dati che estrapoliamo sono potenzialmente inconsistenti in quanto qualche utente durante la conversazione potrebbe eliminare l'hashtag per recuperare caratteri, sono giunto a questa soluzione.

Manteniamo l'harvesting così com'è sulla base dell'hashtag twittantonio semplicemente spostando la richiesta dalla versione 1 alla 1.1 delle API (già fatto), al termine dell'harvesting lanciamo un processo di map/reduce che riaggrega i tweet sulla base della conversazione, e recuerara i tweet mancanti inserendoli nella collection base dei tweet, il risultato del processo di map/reduce lo memorizziamo in una nuova collection come oggetti contenenti la sequenza di tweet appartenenti alla discussione ed effettuiamo un altro processo di map/reduce che riporti i conteggi che servono a noi, così il processo di elaborazione lo carichiamo sul db con frequenza di 15 minuti e non portiamo un carico del server costante nell'elaborazione dei dati al momento della richiesta.

Vi chiedo un parere così da finalizzare la soluzione e implementarla, in attesa completo i test sull'harvesting basato sulle nuove api di twitter.

[paolomainardi]

Io direi di procedere, vedi tu quale procedura utilizzare, mi sembra un architettura abbastanza complessa, ma confido in te 👍

[nelsonmau]

a bologna si direbbe 'socc'mel!'

[nelsonmau]

@paolomainardi @gaspa @Morpheus80ta una lamer-richiesta volante: il sorting è eccezionale, ma va valorizzato. Propongo togliere la select da lì (tutta) e metterla sotto l'header nel div dove compaiono i box dei candidati. Apriamo una issue?

[paolomainardi]

Sono d'accordo, apriamo una issue.

[nelsonmau]

@Morpheus80ta @paolomainardi faccio alcune domande: è possibile con questi dati attibuire un tasso di engagement per singoli candidati? si può dire quante volte rispondono a quelli che mandano loro dei tweet?

Si può poi stampare nel box candidato anche la data di iscrizione a twitter? Altri spunti?

[paolomainardi]

La discussione sul nuovo harvester è qui: #82

Qui teniamo le discussioni sul passo successivo, Dati Harvester <-> Candidati