Distribuzione controllata di contenuti PDF (articoli scientifici, manuali, normative, report) verso biblioteche universitarie, ospedali, enti sanitari, editori istituzionali e pubblica amministrazione. Entitlement basato su IP di rete + fallback per accesso individuale, tracking dei download per l'editore, dashboard analytics, 2FA obbligatoria amministratori. Integrazione con sistemi bibliotecari esistenti.
01Perché non basta un Drive condiviso
La tentazione iniziale, per un editore che deve consegnare PDF a clienti paganti, è quasi sempre la stessa: cartella cloud condivisa, link riservato, fattura a parte. Funziona finché il contenuto è poco e i clienti sono pochi. Smette di funzionare nel momento esatto in cui qualcuno chiede: "quanti dei nostri utenti hanno davvero scaricato il numero di marzo?".
Un Drive condiviso non distingue fra un utente autorizzato e un link inoltrato a un collega fuori dal contratto. Non sa se stai leggendo da dentro la rete ospedaliera o da un bar. Non registra nulla di utile all'editore: né quante volte un titolo è stato consultato, né quale biblioteca rende davvero l'abbonamento, né quali articoli andrebbero rilanciati.
Un CMS istituzionale fa cinque cose che un file system condiviso non fa: tracking dei download con attribuzione alla sottoscrizione, conformità alle licenze (scadenze, limiti d'uso, clausole di prestito), analytics per l'editore, controllo accessi granulare per collana/rivista/singolo articolo, e watermarking per scoraggiare la redistribuzione non autorizzata. Non sono optional: sono il motivo per cui un cliente istituzionale è disposto a pagare una licenza annuale invece di cercarsi il PDF altrove.
02Come funziona l'entitlement
Il cuore del sistema è capire, al momento della richiesta, se l'utente ha diritto di leggere quel contenuto. Le istituzioni non ragionano per utenti individuali — ragionano per reti: "tutto ciò che parte dal nostro range IP è autorizzato". Questo è il pattern dominante e il sistema lo supporta in modo nativo.
- IP-based (range e CIDR): ogni istituzione cliente viene registrata con uno o più blocchi di rete. Una biblioteca universitaria può avere dieci subnet diverse, un ospedale una sola, un ente pubblico può arrivare con un elenco di indirizzi pubblici dei suoi uffici periferici. Il sistema risolve in modo trasparente.
- SSO federato: integrazione con Shibboleth (federazione IDEM per le università italiane), EZproxy per chi sta dietro a proxy bibliotecari, OpenAthens per alcuni editori anglosassoni. In questi casi l'identità viene delegata all'istituzione, il CMS valida l'attribute release e concede l'accesso.
- Token individuali come fallback: per l'utente che legge da casa la sera, da cellulare o in trasferta. Credenziali personali legate alla sottoscrizione istituzionale, con 2FA opzionale, validità allineata al contratto.
- Validazione periodica delle liste: i range IP cambiano, le istituzioni si riorganizzano. Il sistema notifica quando un range non riceve traffico per N mesi, per verificare che sia ancora valido e che l'editore non stia pagando banda per entitlement morti.
03Paywall e controllo accessi
Il paywall non è un interruttore on/off. Le politiche reali che un editore istituzionale deve gestire sono più articolate:
- Per rivista o collana: l'abbonamento dà accesso a tutto ciò che quella testata pubblica per un arco temporale definito.
- Per singolo articolo: pay-per-view, utile per l'istituzione che non vuole abbonarsi all'intera testata ma ha bisogno di uno specifico contributo.
- Abbonamenti con scadenza: accesso valido dal 1 gennaio al 31 dicembre, rinnovo gestito dall'editore, il sistema revoca automaticamente alla scadenza.
- Prestito a tempo (loan-based): modello tipico delle biblioteche — un utente prende in prestito un PDF per N giorni, durante i quali è leggibile, dopo si revoca. Utile per contenuti con licenza limitata.
Ogni regola è configurabile dall'editore senza intervento tecnico. La gestione è self-service da dashboard, con audit log completo di chi ha cambiato cosa e quando.
04Tracking e analytics per l'editore
Il dato che l'editore vuole non è "quanti download totali" — è "quale istituzione genera valore, quale titolo tira, dove il funnel si rompe". La dashboard analytics è costruita intorno a queste domande:
- Download aggregati per istituzione con breakdown mensile — per capire quali abbonamenti vanno rinnovati senza discussioni e quali invece meritano una telefonata commerciale.
- Trend mensili per collana — per decidere quali testate rilanciare editorialmente.
- Top titoli per periodo — per guidare scelte editoriali basate su evidenza, non su sensazioni.
- Funnel landing → paywall → download — per vedere quanti utenti arrivano alla pagina, quanti superano il paywall, quanti completano il download. Ogni step mancante è un pezzo di contratto che non funziona.
- Export CSV di ogni report — per il reporting verso autori, comitati scientifici, board editoriale, senza dipendere da dashboard proprietarie.
05Esperienza lato lettore
Il principio guida: zero attriti per l'utente autorizzato. Chi lavora in una biblioteca universitaria, in un reparto ospedaliero o in un ente pubblico non deve accorgersi che esiste un sistema di controllo. Deve vedere il contenuto, scaricarlo, usarlo.
- Accesso trasparente se la richiesta arriva da un IP istituzionale riconosciuto — niente login, nessun banner.
- Fallback a credenziali personali se l'utente è fuori rete. Login minimo, con opzione "ricordami" e 2FA disponibile su scelta dell'istituzione.
- Preview del PDF (prime pagine, metadati, abstract) prima del download — così l'utente sa cosa sta per prendere.
- Storico personale opzionale: l'utente che lo attiva ritrova i suoi download passati, accelerando il ritorno a contenuti già consultati. Disattivabile in qualsiasi momento per motivi di privacy.
La differenza tra un sistema tollerato e un sistema apprezzato si gioca tutta qui. Un controllo invisibile è un controllo che non genera ticket di supporto.
06Compliance e licensing
Un editore che vende a istituzioni pubbliche italiane ed europee ha vincoli precisi, e il sistema li rispetta per costruzione.
- GDPR-compliant: dati bibliotecari trattati secondo finalità dichiarate, minimizzazione dei log identificativi, retention configurabile per classe di dato, export e cancellazione su richiesta.
- Watermark personalizzabile applicato al PDF scaricato — intestazione dell'istituzione, timestamp, identificativo di sessione. Non blocca un determinato abuso, ma rende rintracciabile chi ha redistribuito cosa.
- Logging accessi conservato secondo quanto previsto dal contratto editore-istituzione. Durata, granularità e modalità di esportazione sono parametri contrattuali, non scelte tecniche.
- Export per audit: quando una delle parti chiede un rendiconto (revisione contabile, verifica interna, contestazione) il sistema produce report firmati con i soli dati pertinenti all'audit.
- 2FA obbligatoria per gli amministratori: chi gestisce entitlement, pricing o contratti accede solo con secondo fattore. Per gli utenti finali la 2FA è disponibile ma facoltativa, per non compromettere l'esperienza.
07Integrazioni tipiche
Il CMS non vive da solo: fa parte di un ecosistema editoriale e amministrativo che esiste già. Le integrazioni che realizziamo più spesso:
| Modello entitlement | Pro | Contro |
|---|---|---|
| IP-based / CIDR | Zero attriti, nessun login, copertura intera istituzione | Utenti fuori rete esclusi, serve fallback |
| Proxy bibliotecario (EZproxy) | Copertura anche fuori rete, gestito dalla biblioteca | Dipendenza da infrastruttura cliente, diagnosi complessa |
| SSO federato (Shibboleth, IDEM) | Identità certa, revoca immediata, audit per persona | Richiede integrazione con IdP cliente, onboarding più lungo |
| Token individuale | Funziona ovunque, 2FA possibile, ideale per singoli | Gestione credenziali lato utente, più superficie di attacco |
Nessuno di questi modelli è il giusto in assoluto. La scelta dipende dal profilo del cliente: un editore scientifico con clientela universitaria privilegia IP + Shibboleth, un editore di normative tecniche per la PA punta su IP + token, un editore medico che vende a singoli professionisti oltre che a strutture integra pay-per-view e token individuali. Il CMS supporta tutti contemporaneamente — l'impostazione è per singolo cliente, non per singola piattaforma.
- Sistemi di gestione abbonamenti esistenti (proprietari o di terze parti) per sincronizzare scadenze e ranges IP senza doppio data entry.
- CRM editoriali per popolare automaticamente il pannello commerciale con dati di uso reale dell'istituzione.
- CMS editoriali esistenti (flussi redazionali, pubblicazione, DOI) — il nostro layer si occupa di distribuzione e paywall, non sostituisce la redazione.
- Export verso BI tools (Metabase, Looker, Power BI) via database read-only o dump periodico, per chi fa reportistica centralizzata.