# Crowd Management Optimization
Alla fine di aumentare la qualità complessiva del dato sia in termini di output sia in qualità dei profili utente abbiamo individuato una serie di azioni che combinate insieme (in quanto predecessori) ci porteranno sensibili miglioramenti nelle aree in cui ad oggi siamo più scarsi:
* Possibilità di acquisire in modo verticale specifici cluster di utenti (B2B/B2C)
* Aumentare la nostra conoscenza sulle caratteristiche (feature) dell'utente
* Estendere la nostra attuale "crowd-base" tramite sorgenti di terze parti (#OpenCrowd)
## Augmented profile
Per indirizzare queste necessità dobbiamo in-primis passare attraverso un processo di rivisitazione dell'oggetto di dominio "utente della crowd" che dovrà per forza estendersi in modo da poter ospitare N-metadata (Augmented profile) con cui estendere ogni i-esimo profilo utente.
Estendere il profilo dell'utente significa applicare le giuste strutture dati (logiche e fisiche) per permettere di collezzionare informazioni utili (e ricercabili) su ogni i-esimo utente.
Queste informazioni possono essere relative a diversi aspetti della vita dell'utente e possono spaziare tra diversi domini:
* Casa e Famiglia
* Lavoro
* Shopping
* Social media usage
* Internet & Technology
* Mobility
* Video Games
* Salute
* Bellezza
* Cura della casa
* Alimentazione
* Viaggi
* Finanza personale
* Sports
:::success
* Demografiche: chi sei / identikit
* Cosa fai di lavoro?
* Dove vivi?
* Che PC usi?
:::
:::success
* Aree di expertise (non legato a quello che hai ! hai) - area di competenza / cosa sei bravo a fare
* Familiari con la pulizia della casa
* Sei bravo a cucinare (skill)
:::
:::success
* Interessi
*
:::
questi sono solo alcuni dei domini sui quali si possono formulare "domande" per scoprire qualcosa di più dei nostri utenti... ma ci sono dei dubbi:
:::info
chi fa questo domande?
come sono fatte questo domande?
come le possiamo porre?
:::
va cambiato quindi il paradigma per acquisire le informazioni sui clienti (metadati) che va svincolato dal concetto dei filtri; potremmo creare invece un concetto di recupero di informazioni continue basato su micro-survey “flat” senza relazioni gerarchiche.
queste che chiamiamo domande di *micro-surveys*, che sono fatte da esperti di dominio di DSCOVR tramite una struttura di dominio ben precisa che permette di assolvere a diversi requisiti:
* semplicità: fatte per essere create in modo veloce da ricercatori (e in futuro forse anche clienti)
* avere una struttura flat senza relazioni
* avere una data di scadenza (TTL)
la `semplicità` viene data dal fatto che le domande sono relative ad un i-esimo dominio e possono essere fatte in modo disgiunto da altre domande all'interno dello stesso dominio; la loro struttura piattà senza relazioni fa concentrare l'esperto di dominio di DSCOVR sul catturre i comportamenti "macro" senza scendere nei dettagli (che andremo a richiedere in seguito e che sono specifici del piano di ricerca); il TTL e un semplice intero che rappressenta il numero di giorno di validità di quella domanda.
facciamo un esempio pratico, poniamo ad esempio di fare all'utente una serie di domande relative al dominio "mobility", questa domande (o micro-survery) potremmo idealmente rappressentarle con un DSL di questo tipo:
```json
{
"_id": "uuid",
"_domain": "mobility",
"_desc": "L'auto",
"survey": [{
"001": {
"question": "Hai un auto?",
"type": "Bool",
"ttl": "200d"
},
"002": {
"question": "Da quanto tempo hai un auto?",
"type": "INT",
"validator": "YearDate",
"ttl": "200d"
}
"003": {
"question": "La tua auto è elettrica?",
"type": "Bool",
"ttl": "200d"
}
"004": {
"question": "Fai più di 20.000km all'anno",
"type": "Bool",
"ttl": "200d"
}
}]
}
```
ipotizziamo poi di proporre tramite una interfaccia (di cui parleremo dopo) in modo randomico ad esclusione all'utente una delle i-esime domande da questo dominio, quello che andremo ad ottenere sarà una risposta circostanziata e puntuale che andremo a trattare come una **feature** del nostro "dataset" utente.
quest feature possono essere salvate in modo incrementale usando strutture dati con accesso key=value, come ad esempio (per reference):
```json
{
"userId": "001",
"mobility": {
"004": {
"response": "Yes"
}
}
}
```
```json
{
"userId": "099",
"mobility": {
"002": {
"response": "2020"
}
}
}
```
andare a definire i possibili "type" tramite tipi base ci permette di effettuare sulle feature, query in modo agevole (con modalità che vedremo in seguito); i tipi base non sono infiniti andremo ad indiduarne un set:
* bool
* interi (input libero con validatore, o lista)
* liste
* testo
individuando un insieme ristretto di questo tipo, possiamo sviluppare logiche di backend che consentano al ricercatore di inserire direttamente queste domande in ogni dominio. A livello di backend, sarà possibile creare nuovi domini, aggiungere nuove domande ai domini, modificare il TTL delle singole domande e deprecare singole domande (non è possibile cancellarle, ma devono essere deprecate).
:toilet:
> in questo modo, è possibile effettuare il campionamento o il filtraggio della base di clienti in base a tipologie specifiche utilizzando una ricerca tramite una chiave=valore.
>
> Ad esempio:
>
> Domanda: Dammi tutti gli utenti che possiedono un'auto, di tipo elettrico dal 2020.
>
> Query di questo tipo, con semplici semantiche come "ha" "non ha" "da" "a", sono molto più facili da comporre e aggiornare.
>
> Questo metodo di filtraggio ci permetterebbe di capire quale potenziale campione di utenti con determinate caratteristiche abbiamo a disposizione nella popolazione su Tak!
>
> Per quanto riguarda i singoli progetti, invece, procederemo con domande specifiche che non vengono salvate nel profilo dell'utente.
>
> Effettueremo un controllo automatico della qualità del rispondente (ad esempio, risposte incoerenti a più micro-survey) e verificheremo il livello di compatibilità con le richieste del cliente.
:toilet:
:::success
TODO:
* wireframe basici
* esempio di ui input domini e domande
* esempio di ui rolling random
:::
## Open Crowd
Il concetto di OpenCrowd ci permette di aprire la nostra piattaforma a *data-sources* esterne via:
* API RESTful endpoint con OpenAPI Specification (OAS),
* CSV/XLSX file
abilitando semplici use case di integrazione:
* un endpoint RESTful permette a soggetti terzi di inserire o aggiornare "user profile" dalle loro fonti dati integrando le "Crowd API DSCOVR"
* una funzionalità di backend che fa leva sulla stessa logica di delle RESTful API permette ad un utente di biz di uplodare un tabular file in formato CSV/XLSX all'interno della sua tenant
gli "user profile" aggiunti vanno a far parte degli utenti invocabili privatamente, in fase di creazione dell'esperimento/attività/conversazione.
### Open Crowd for SalesForce
# Acquisition pages
Dobbiamo estendere il processo di acquisizione dei clienti introducendo un secondo livello di interazione.
Attualmente, l'utente da acquisire interagisce esclusivamente con Tak!, che nelle sue varianti (tenant verticali), viene utilizzata come punto di registrazione e autenticazione.
Il metodo attuale di acquisizione è molto limitato poiché non consente di acquisire utenti specifici tramite una landing page, ma ci obbliga (come nel caso di pro.dscovr.io) a creare tenant ad hoc.
Vorremmo superare questo concetto introducendo come concetto sottostante alla "tenant" quello di landing page, come rappresentato nel seguente diagramma.
Associando le landing page alle tenant, è possibile definire meccanismi di acquisizione di questi "contatti" come pubblici o privati.
* Pubblici: Gli utenti possono essere acquisiti e conferiti a Tak! (a parte le preoccupazioni sulla privacy).
* Privati: Gli utenti acquisiti possono essere utilizzati esclusivamente all'interno di quella specifica tenant (come negli esempi forniti).
esempi:
Le landing page (A, B, C) consentono di acquisire utenti verticali come outdoor_enthusiast, expert e mamme, e di salvarli in TAK! in quanto queste landing page sono subordinate a Tak!. Questi utenti saranno utilizzabili.
Inoltre, le landing verticali per UNICREDIT e SISAL consentono di acquisire utenti in modo privato che saranno utilizzabili esclusivamente per
menti, attività e conversazioni di UNICREDIT e SISAL.
:::success
Come possiamo vedere, stanno emergendo dei concetti di "data-sources".
Questi "data-sources" consentono, durante la creazione di un esperimento/attività/conversazione, di attingere da diverse fonti per determinare il campione.
Ad esempio, Unicredit ci chiede di condurre un'analisi di mercato con il 50% degli utenti provenienti dal processo di acquisizione verticale dei financial expert e il restante 50% di utenti provenienti da Tak! con determinate caratteristiche.
:::
Come possono essere implementate le acqusition page:
* possiamo integrare un servizio esterno (es. [ActiveCampaign](https://help.activecampaign.com/hc/en-us/articles/360016066860-How-to-create-a-landing-page-in-ActiveCampaign) e configurare reindirizzamenti HTTP 302 su rotte specifiche. Ad esempio:
```
blabla.dscovr.io/la-community-dei-meccanici
HTTP 302
piattaforma-di-langing.com/id/42
```
* opppure, come fatto per le tenant, possiamo creare delle pagine basate su template in cui è possibile modificare da backend la copia, i colori primari e apportare piccole modifiche al layout.
:::danger
Questa è una decisione che dobbiamo prendere insieme ad Alberto Bergesio, in quanto impatta anche sui ragionamenti di performance marketing e community che stiamo portando avanti.
:::
## Tak! experience redesign
## TL;DR;
Il redesign di TAK! deve abilitare:
* una UI più semplice da navigare
* delle landing page integrate in Tak!
* la mobile app: `Tak! Mobile`
### Tak! Mobile APP
L'app mobile di TAK! dovrà essere una versione nativa o PWA (probabilmente nativa, purtroppo, per poter utilizzare le funzionalità di screen-sharing). Al momento, sappiamo che fino a quando lo sviluppo di Daily.co non sarà pronto a supportare lo screen-sharing, possiamo solo puntare a iniziare il lavoro, ma solo dopo il redesign.
---------------
# Live interview cross analisys and reporting
La global summary delle live interview deve avere due viste, la prima lista deve essere un listing delle LI più significative per delle metriche di scoring che andiamo ad individuare
come si selezionano le live-interview più significative: e possibile sviluppare un prompt che dato un numero N di interviste ottenga, uno scoring per ogni LI
---------------
# Enrollement & welcome process on app.dscovr.io
Già on-going su:
https://linear.app/dscovr/issue/DSC-834/enrollment-customer-su-appdscovrio
# Modulo Survey Block
# OR
# Modulo Video Survey
TBD
## TL;DR;
# Open-ended question aka Analisi delle domande aperte
- domanda insierimento
- upoload risposte
- preseted prompt di analisi
- single shot
////////////////////////
1. onboarding b2b: onbording via Linkedin, IT Manager, pubblicati con Tak! Pro
2. workable - team taylor // API
3. dimensionamento di quanto ci costa fare una mini integrazione,
4. acquisizioni
1. creazione post
2. listing
3. via telefono o wa
5. TAK! PRO azienda a parte
// **recrutiing continuo via landing page**
// farmaciti, ottici, responsabile di punto vendita (retailer),
INGEGNERIZZARE UN PROCESSO: OTTICI / TELAPASS (FLEET MANAGER) /
7. analisi risp aperte
due richiesta da due clienti (fater, bolton), risposte apertre casino da analizzare.
3. caricamente filmati:
caricamento filmati, con analizzatore del livello di qualità.
quando vuoi
poi me ne vado a casa a finire le slide del cda
Sign in with Wallet
Connect another wallet