Un'API per i contenuti è utile per le PMI se si desidera distribuire gli stessi servizi, dati aziendali o offerte su più canali in modo controllato. Se si gestisce solo un sito web di dimensioni contenute e non si prevede di utilizzare applicazioni aggiuntive, un CMS tradizionale è solitamente sufficiente. I fattori decisivi sono l'effettivo impegno richiesto per la manutenzione e i canali di cui l'azienda avrà bisogno negli anni a venire.
Nel mio lavoro con le PMI, noto spesso che l'interfaccia raramente rappresenta il primo collo di bottiglia. Solitamente, ciò che manca sono contenuti coerenti e strutturati. I servizi sono elencati in modo diverso sul sito web rispetto alla brochure di vendita, gli orari di apertura sono stati modificati solo in un punto, oppure la traduzione italiana non corrisponde più alla versione tedesca.
Un'API per i contenuti non risolve il problema della disorganizzazione dei contenuti. Tuttavia, rende una struttura di contenuti ben definita riutilizzabile più volte.
Quando un'API di contenuti è vantaggiosa per le PMI
Un'API di contenuto è un'interfaccia attraverso la quale le applicazioni recuperano contenuti gestiti centralmente in un formato definito. L'API di contenuto separa il contenuto dalla sua presentazione visibile: il titolo di un servizio rimane lo stesso record di dati, ma può essere visualizzato in dettaglio sul sito web, in forma compatta in un'app e con informazioni aggiuntive nel portale partner.
Un'API per i contenuti è particolarmente utile se si verificano diverse delle seguenti condizioni:
- Pubblichi gli stessi servizi su un sito web, in un'app o su un portale partner.
- La tua attività opera con più sedi, marchi o siti web.
- Prezzi, disponibilità, persone di contatto e dati sulle prestazioni sono soggetti a modifiche periodiche.
- Il multilinguismo è parte integrante della quotidianità lavorativa e le traduzioni devono essere approvate in modo tracciabile.
- I partner esterni dovrebbero poter accedere a determinate informazioni, ma non visualizzare l'intero sistema.
- Desideri fornire informazioni aziendali tramite un'interfaccia di intelligenza artificiale controllata.
- È già previsto un negozio, un'area protetta o un altro canale digitale.
Se questi punti non si applicano, un'API per i contenuti potrebbe rappresentare un livello aggiuntivo non necessario. Un sito web con un numero di pagine compreso tra cinque e venti, sostanzialmente stabili, non richiede automaticamente un'architettura disaccoppiata.
Quando un CMS classico è sufficiente
Nella sua forma classica, un sistema di gestione dei contenuti (CMS) combina strettamente la gestione e la presentazione dei contenuti. Si modifica una pagina, se ne visualizza la struttura e si pubblica il contenuto direttamente sul sito web.
Un CMS tradizionale è solitamente la scelta più economica se:
- Il sito web è il tuo unico canale di output rilevante,
- Il contenuto viene modificato raramente.
- Non è prevista alcuna app o portale per i partner.
- solo una o poche persone modificano i contenuti
- Le pagine sono progettate principalmente come testi continui,
- il disponibile Budget Si stanno effettuando investimenti migliori in termini di posizionamento, testi e guida per l'utente.
Anche un CMS tradizionale può offrire campi strutturati e output tramite API. Pertanto, la scelta non è sempre "CMS tradizionale o API per i contenuti". Spesso, un CMS con contenuti ben strutturati e un'interfaccia abilitata rappresenta il compromesso ideale.
Tre fasi di espansione sensate
- CMS classico: Adatto a un sito web principale, con contenuti gestibili e modifica visiva diretta.
- CMS con API per i contenuti: Ideale se il sito web rimane centralizzato, ma singoli contenuti vengono anche distribuiti ad altre applicazioni.
- Piattaforma basata sulle API: Ideale quando si pianificano fin dall'inizio più canali con pari priorità. Primo API Il modello dati, le interfacce e le regole di accesso vengono definiti prima delle singole interfacce utente.
Un CMS headless è una possibile implementazione tecnica della terza fase. Un CMS headless gestisce i contenuti in modo centralizzato, ma non impone necessariamente l'aspetto del sito web, dell'app o del portale.
Esempio pratico: un piccolo elenco di servizi
Prendiamo come esempio un'impresa artigianale o di servizi altoatesina con dodici servizi. Uno di questi, ad esempio, si chiama "Manutenzione in loco". Nel sistema attuale, questo servizio è presente come blocco di testo sul sito web tedesco, come copia separata sul sito web italiano, come breve testo nel portale partner e come paragrafo in un documento di vendita digitale.
Se la persona di contatto responsabile cambia, è necessario individuare e correggere singolarmente quattro voci. Se si aggiornano solo tre voci, si otterranno informazioni contraddittorie.
In un sistema strutturato, il servizio non viene memorizzato come una pagina completa. Al contrario, i campi di contenuto strutturati rappresentano il significato del servizio.
Aree di contenuto di base
- ID interno: un identificatore permanente e indipendente dalla lingua
- Titolo dello spettacolo: separati per lingua
- Breve descrizione: per mappe, elenchi e visualizzazioni per dispositivi mobili
- Descrizione lunga: per la pagina dettagliata dei servizi
- Destinatari: ad esempio, privati cittadini, imprese o istituzioni pubbliche
- Logica dei prezzi: Prezzo fisso, prezzo di partenza, calcolo individuale o nessuna informazione pubblica
Campi di controllo e rilascio
- Contatto: Collegamento a un record centrale dei dati di contatto
- Regione: disponibilità spaziale del servizio
- Validità: Data di inizio e data di fine facoltativa
- Stato della versione: Bozza, in fase di revisione, approvato o archiviato
- Stato della lingua: completo, in traduzione o non ancora disponibile
Questo rende il contenuto riutilizzabile. Il sito web può visualizzare una descrizione estesa, immagini e informazioni di contatto. L'app utilizza il titolo, una breve descrizione e la regione. Il portale partner integra documenti interni o termini e condizioni. Un'interfaccia basata sull'intelligenza artificiale riceve solo i campi per i quali è autorizzato l'accesso e che sono destinati all'elaborazione automatica.
Dalla fonte centrale all'output dell'API
La procedura operativa deve essere chiaramente documentata:
- Interfaccia editoriale: Una persona crea o modifica un servizio.
- Test: Vengono controllati i campi obbligatori, la lingua, la validità e lo stato di approvazione.
- Fonte centrale dei contenuti: Il set di dati rilasciato diventa la versione vincolante.
- Output dell'API: L'API Content fornisce campi definiti in un formato leggibile dalle macchine.
- Canali di uscita: Il sito web, l'app, il portale dei partner e l'interfaccia AI utilizzano i dati consentiti in ciascun caso.
- Monitoraggio: Vengono registrati gli errori, i contenuti obsoleti e i recuperi non riusciti.
Questa fonte centrale viene spesso definita " Unica Fonte di Verità" . Non si tratta di un singolo file, bensì di una posizione centrale e autorevole in cui contenuti specifici vengono conservati e approvati. Il piano di avvio di 30 giorni per una fonte dati centrale ti mostra come costruire queste fondamenta su piccola scala.
Esempio del contenuto di un output API
La rappresentazione tecnica varia a seconda del sistema. Tuttavia, il contenuto dell'output API per un servizio dovrebbe essere inequivocabile e includere, ad esempio, le seguenti informazioni:
- ID prestazione: servizio-012
- Lingua: de
- Titolo: Manutenzione in loco
- Breve descrizione: testo rilasciato
- Status: pubblicato
- Valido da: data fissa
- Contatto: ID di contatto collegato
- aggiornamento: Ora dell'ultima modifica approvata
L'ID persistente mantiene il collegamento al record di dati originale. I titoli in tedesco e italiano possono cambiare senza che le applicazioni perdano questa associazione.
Riutilizzare i contenuti senza presentare tutto allo stesso modo
Riutilizzare i contenuti non significa che ogni canale debba copiare la stessa pagina. La fonte centrale fornisce i dati e i moduli di testo approvati. Il singolo canale determina la presentazione, l'ordine e l'interazione.
Sito web
Il sito web presenta il servizio in dettaglio: vantaggi, procedura, immagini, domande frequenti e informazioni di contatto. È inoltre possibile creare elementi della pagina ottimizzati per i motori di ricerca utilizzando campi strutturati, ma questi devono essere sottoposti a revisione editoriale.
App
Un'app spesso richiede una presentazione più breve. L'app può recuperare il titolo, una breve descrizione, la regione e la persona di contatto senza dover copiare l'intero testo lungo del sito web.
Portale partner
Un portale partner può collegare le informazioni di servizio disponibili pubblicamente con i dati protetti. Gli utenti autorizzati possono visualizzare documenti, processi interni o termini e condizioni individuali, ad esempio. Le applicazioni pubbliche non hanno accesso a questi campi protetti se i diritti di accesso sono configurati correttamente.
interfaccia IA
Un'interfaccia basata sull'intelligenza artificiale dovrebbe fornire solo informazioni verificate e chiaramente definite. L'interfaccia può offrire servizi, posizioni, metodi di contatto o regole, ma non deve accedere a dati interni non verificati. L'intelligenza artificiale rimane uno strumento di elaborazione; la responsabilità per i contenuti, l'approvazione e i limiti spetta agli esseri umani.
La fonte centrale determina quali contenuti sono vincolanti. Il canale di output determina come vengono utilizzati i contenuti rilasciati.
Il multilinguismo come parte integrante del modello dati
Soprattutto in Alto Adige, non basta semplicemente copiare una pagina in tedesco e tradurla in seguito. Il multilinguismo dovrebbe essere definito fin dall'inizio nelle specifiche del servizio, specificando quali campi dipendono dalla lingua, quali informazioni si applicano a tutte le lingue e quando una traduzione può essere pubblicata.
Un modello affidabile, pertanto, distingue:
- Dati indipendenti dalla lingua: ID, logica di prezzo, regione, validità e persona di contatto
- Contenuti dipendenti dalla lingua: Titolo, breve descrizione, descrizione estesa e URL
- Approvazioni relative alla lingua: La versione tedesca potrebbe essere pubblicata, mentre quella italiana è ancora in fase di revisione.
- Soluzioni alternative dipendenti dalla lingua: Regole per le traduzioni mancanti o scadute
La mancanza di una versione italiana non dovrebbe essere automaticamente sostituita con contenuti in tedesco. Per alcune aziende, un'indicazione chiara è più appropriata, per altre una lingua alternativa temporanea. La decisione dipende dal pubblico di riferimento, dal prodotto o servizio offerto e dalla rilevanza legale del contenuto. Approfondisco l'architettura informativa fondamentale nell'articolo sulla pianificazione di siti web multilingue.
Versioning: Mantenere le modifiche tracciabili
Il controllo delle versioni salva non solo il contenuto corrente, ma anche le versioni precedenti e le relative modifiche. Per il catalogo dei servizi, questo significa che è possibile visualizzare chi ha modificato e approvato un prezzo, una descrizione del servizio o un referente.
Un sistema di controllo delle versioni efficace risponde ad almeno cinque domande:
- Chi ha modificato il record dei dati?
- Quando è stata apportata la modifica?
- Quali campi sono stati modificati?
- Chi ha rilasciato la nuova versione?
- È possibile ripristinare una versione precedente valida?
Il controllo delle versioni è particolarmente importante quando sono coinvolte più persone o traduttori esterni. Senza una cronologia tracciabile, una fonte di dati centrale può diffondere gli errori su più canali più rapidamente rispetto a un sistema separato.
Assegna i diritti di accesso in base alle attività
I diritti di accesso devono essere assegnati in base alle mansioni. Una persona che traduce testi in italiano non ha automaticamente bisogno di accedere alla logica dei prezzi, alle impostazioni tecniche o all'amministrazione degli utenti.
Per un team di piccole dimensioni, spesso bastano pochi ruoli ben definiti:
- Redazione: Crea e modifica contenuti, ma non è autorizzato a pubblicarli.
- Traduzione: Vengono modificati solo i campi lingua assegnati.
- Pubblicazione: controlla il contenuto e imposta lo stato di pubblicazione
- Amministrazione: gestisce il modello dati, i ruoli e le interfacce
- Accesso all'API di lettura: Può recuperare contenuti definiti, ma non modificarli.
Per il sito web, l'app e il portale partner è necessario utilizzare credenziali di accesso separate. Se un account deve essere bloccato, gli altri canali devono rimanere funzionanti. Le interfacce con accesso in scrittura richiedono regole più restrittive rispetto all'accesso in sola lettura.
Memorizzazione nella cache e soluzioni alternative in caso di interruzione
La memorizzazione nella cache significa che i contenuti precedentemente recuperati vengono temporaneamente archiviati per un periodo di tempo definito. Ciò impedisce al sito web di dover accedere nuovamente alla fonte centrale a ogni richiesta di pagina. Con una configurazione appropriata, una versione valida e aggiornata può rimanere temporaneamente disponibile se l'API dei contenuti non è disponibile per un breve periodo.
La memorizzazione nella cache necessita di regole chiare:
- Per quanto tempo è possibile conservare temporaneamente i dati relativi alle prestazioni?
- Quali modifiche devono essere immediatamente visibili?
- Come viene aggiornata la cache dopo un rilascio?
- È lecito memorizzare nella cache contenuti protetti?
- Quale ultima versione valida può essere consegnata in caso di malfunzionamento?
Le soluzioni di fallback sono risposte alternative predefinite. Una soluzione di fallback impedisce a un'applicazione di visualizzare in modo incontrollato contenuti vuoti o errati in caso di dati mancanti.
Le regole per l'elenco esemplificativo dei servizi potrebbero essere le seguenti:
- Se l'API non è temporaneamente disponibile, il sito web visualizza l'ultima versione valida memorizzata nella cache.
- In assenza di traduzione, l'opera non verrà pubblicata automaticamente in un'altra lingua.
- Una volta scaduto, un servizio scompare dagli elenchi pubblici ma rimane archiviato internamente.
- Qualora manchi una persona di contatto, verrà utilizzato un contatto generico condiviso.
- Se un record di dati contiene un valore obbligatorio non valido, rimane attiva l'ultima versione rilasciata.
- Se non è disponibile uno stato valido, il canale visualizza un messaggio sostitutivo comprensibile anziché i dettagli tecnici dell'errore.
Un piano di riserva fa parte della pianificazione operativa e dovrebbe essere testato prima del rilascio.
Prima e dopo: la differenza pratica
In precedenza: i contenuti venivano gestiti canale per canale.
- Il servizio verrà modificato sul sito web tedesco.
- Il sito web italiano verrà adattato in seguito.
- Il portale dei partner rimarrà invariato per il momento.
- L'app utilizza ancora un testo obsoleto.
- Un documento di vendita digitale deve essere ricreato manualmente.
- Non è chiaramente documentato quale versione sia vincolante.
Successivamente: un set di dati viene distribuito in modo controllato
- La redazione sta modificando il set di dati centrale sulle prestazioni.
- La traduzione verrà elaborata e verificata separatamente.
- Una persona responsabile rilascia la nuova versione.
- L'API dei contenuti fornisce la versione rilasciata.
- Il sito web, l'app e il portale dei partner stanno aggiornando le rispettive visualizzazioni.
- La gestione delle versioni documenta lo stato precedente e quello nuovo.
- La memorizzazione nella cache e i meccanismi di fallback garantiscono una consegna controllata.
La differenza cruciale risiede nella natura del legame : ogni applicazione sa quale record di dati è valido e quali campi è autorizzata a utilizzare.
Cosa non risolve automaticamente un'API di contenuti
Un'API per i contenuti riduce la duplicazione dell'inserimento dei dati solo quando il modello dati, i processi e le responsabilità sono chiaramente definiti. Senza queste basi, la disorganizzazione si sposta semplicemente dalle pagine e dai documenti ai campi e alle interfacce.
Pertanto, anche i seguenti compiti rientrano nell'ambito dell'implementazione:
- Definire i tipi di contenuto e i campi obbligatori
- Ripulire e assegnare i contenuti esistenti
- Collegare tecnicamente ciascun canale di uscita
- Documentare diritti, autorizzazioni e responsabilità
- Test delle interfacce e dei meccanismi di fallback
- Implementare le modifiche al modello dati in modo controllato
- Controlla regolarmente i registri degli errori e gli aggiornamenti.
Per un'azienda con un sito web semplice, questo sforzo potrebbe risultare sproporzionato. Tuttavia, per un catalogo di servizi multilingue con più canali, lo stesso impegno può ridurre, nel lungo periodo, la duplicazione degli interventi e le informazioni contraddittorie.
Piano di sviluppo di 90 giorni per un'API di contenuti
Una strategia sensata per i prossimi 90 giorni non inizia con la scelta di un sistema. La strategia inizia con i contenuti, i canali e le responsabilità.
Giorni da 1 a 15: Chiarire l'inventario e l'obiettivo
- Annotare tutti i luoghi in cui i servizi vengono attualmente forniti.
- Segnala le informazioni duplicate, contraddittorie e obsolete.
- Dare priorità al sito web, all'app, al portale dei partner e ai canali pianificati.
- Designare una persona responsabile del catalogo dei servizi.
- Definisci i vantaggi economici: meno manutenzione, meno errori o pubblicazione più rapida.
Giorni dal 16 al 30: Modellazione del catalogo dei servizi
- Iniziate con un numero di servizi rappresentativi che va da cinque a dodici.
- Definisci i campi obbligatori, i campi facoltativi e i collegamenti.
- Separare le informazioni dipendenti dalla lingua da quelle indipendenti dalla lingua.
- Imposta lo stato di rilascio, la validità e l'archiviazione.
- Prima di incorporare i nuovi contenuti, ripuliscili.
Giorni dal 31 al 50: Configurazione del sistema e delle autorizzazioni
- Configurare l'interfaccia editoriale e la fonte centrale dei contenuti.
- Creare ruoli per la modifica, la traduzione, l'approvazione e l'amministrazione.
- Separare gli accessi API in lettura dagli accessi in scrittura.
- Abilita la gestione delle versioni e il ripristino dei test.
- Creare la documentazione tecnica dei campi e degli endpoint.
Giorni 51-70: collega il sito web come primo canale
- Controlla l'output API del catalogo dei servizi.
- Crea viste per siti web utilizzando set di dati reali.
- Simula nello specifico campi mancanti e contenuti non validi.
- Verifica la durata della memorizzazione nella cache e gli aggiornamenti successivi alle approvazioni.
- Verifica gli URL multilingue e lo stato della lingua.
Giorni dal 71 all'85: Test del secondo canale
- Collega un'app, un portale partner o un'applicazione interna.
- Vengono visualizzati solo i campi effettivamente necessari al secondo canale.
- Configura credenziali di accesso e diritti di accesso separati.
- Verifica se le modifiche appaiono coerenti su entrambi i canali.
Giorni da 86 a 90: Test di malfunzionamenti e funzionamento
- Simula un errore dell'API.
- Verifica l'ultima cache valida.
- Verifica la presenza di traduzioni mancanti.
- Verifica la presenza di servizi scaduti e campi obbligatori non validi.
- Definisci le responsabilità relative alla manutenzione, agli errori e al rilascio dei contenuti.
- Aggiungi ulteriori contenuti e canali solo dopo aver effettuato dei test con esito positivo.
Strumento di supporto alle decisioni per la tua PMI
È possibile ridurre il processo decisionale a tre domande:
- Pubblichi gli stessi contenuti in almeno due posizioni diverse?
- È necessario coordinare in modo affidabile più lingue, ruoli o approvazioni?
- È realistico pensare che un altro canale digitale possa essere lanciato entro i prossimi due o tre anni?
Se rispondi "no" a tutte e tre le domande, un CMS tradizionale sarà probabilmente sufficiente. Se rispondi "sì", dovresti predisporre campi di contenuto strutturati. Se rispondi "sì" a due o tre domande, vale la pena considerare seriamente un'API per i contenuti del CMS o un'architettura API-first.
In Berger+Team, analizziamo innanzitutto il posizionamento, i contenuti e i processi operativi. Solo in seguito decidiamo se un sito web tradizionale, un CMS con interfaccia o una piattaforma disaccoppiata rappresenti l'opzione migliore. Il nostro lavoro di progettazione e sviluppo web integra il modello dei contenuti, l'esperienza utente e l'implementazione tecnica, anziché pianificare l'interfaccia in modo isolato.
Domande e risposte sull'API dei contenuti
Ogni PMI ha bisogno di un'API per i contenuti?
No. Per un sito web gestibile con modifiche poco frequenti, un CMS tradizionale è solitamente più semplice ed economico. Un'API per i contenuti diventa rilevante per le PMI non appena i contenuti vengono utilizzati su più canali, in più lingue o controllati da ruoli diversi.
WordPress è inadatto a un'API per i contenuti?
No. A seconda della sua struttura e delle estensioni utilizzate, WordPress può fornire contenuti tramite interfacce. Il fattore cruciale è se servizi, persone e luoghi vengono gestiti come record di dati strutturati o sono inclusi solo in pagine dal design libero.
Posso utilizzare un'API di contenuti per riutilizzare automaticamente i contenuti più volte?
Sì, a condizione che il contenuto sia strutturato, approvato e destinato al rispettivo canale. Tuttavia, siti web, app e portali dei partner richiedono comunque una propria presentazione e una connessione tecnica ben mantenuta all'API dei contenuti.
Cosa succede se l'API dei contenuti non funziona?
Una cache configurata correttamente può fornire temporaneamente l'ultimo stato valido. Inoltre, i meccanismi di fallback definiscono il modo in cui le applicazioni reagiscono a contenuti mancanti, record di dati non validi o interruzioni prolungate.
Come funzionano le traduzioni in un'API di contenuti?
I dati indipendenti dalla lingua, come ID e validità, rimangono centralizzati, mentre titoli, descrizioni e URL sono gestiti per ciascuna lingua. Ogni versione linguistica dovrebbe avere un proprio stato e un proprio processo di approvazione per evitare la pubblicazione accidentale di traduzioni incomplete.
Chi è autorizzato a modificare e pubblicare contenuti?
I diritti di accesso determinano chi è autorizzato a scrivere, tradurre, revisionare o pubblicare. I team di piccole dimensioni traggono vantaggio da ruoli ben definiti, poiché la responsabilità rimane tracciabile e i dati critici non possono essere modificati da chiunque.
È possibile aggiungere un negozio o un'app in un secondo momento?
Sì, se il modello di contenuto e le interfacce sono stati progettati per essere estensibili. Un canale aggiuntivo rimane un progetto separato perché la presentazione, i processi, la sicurezza e, se applicabile, le transazioni devono essere implementati e testati separatamente.
Come posso fornire ai sistemi di intelligenza artificiale dati aziendali affidabili?
Un'interfaccia di intelligenza artificiale dovrebbe ricevere solo set di dati approvati, aggiornati e chiaramente descritti. Le regole di accesso, il versioning e la registrazione degli eventi contribuiscono a proteggere le informazioni interne e a garantire la tracciabilità delle modifiche.
Cosa dovrebbe implementare per prima una PMI: un'API per i contenuti o un modello di contenuti?
Iniziate con il modello dei contenuti e un catalogo di servizi piccolo e semplificato. Solo quando campi, lingue, responsabilità e approvazioni sono chiari, un'API per i contenuti può supportare in modo affidabile molteplici utilizzi.
