Come promuovere gli eventi in Google Search e non solo attraverso il Knowledge Graph

Riportiamo di seguito il video ufficiale di Justin Boyan in cui il product manager della ricerca di Google spiega perfettamente come promuovere gli eventi nelle ricerche di Google attraverso il Knowledge Graph e l’utilizzo del formato JSON-LD di schema.org.

Il video è  interessante perché parla

• del nuovo formato JSON-LD markup,  
• nuove proprerties di schema.org per specificare le informaziondi di un evento
• come gli eventi sono linkati nel Knowledge Graph;
• e come fare apparire gli eventi nella ricerca, in Google Maps, Google Now ecc.

Il Knowledge Graph è il sistema di Google per organizzare milioni di informazioni su persone, luoghi e cose nel mondo reale.

Le informazioni del Knowledge Graph provengono da molte fonti, come Wikipedia, Google Maps, U.S. FDA (Food and Drug Administration), MusicBrainz per gli album musicali e così via..

Ma nel caso degli eventi pensiamo che la fonte migliore per le informazioni dell’evento sia rappresentata dagli stessi organizzatori dell’evento.

Per esempio quando gli utenti chiedono le date dei concerti prossimi di Keith Urban vogliamo dare una risposta autorevole che provenga dallo stesso Keith o dal suo staff ufficiale. Similmente quando gli utenti cercano informazioni su cosa succede in un luogo d’incontro – che sia un music club, uno stadio, il teatro, o una libreria – pensiamo che il sito della sede sia la fonte migliore per le risposte.

Questa è la base del nostro nuovo approccio per gli eventi nella Ricerca di Google. Noi chiediamo agli organizzatori degli eventi di farsi carico dei loro stessi eventi nel Knowledge Graph, aggiungendo markup di dati strutturati nei loro siti ufficiali.

Google è in grado di leggere questi markup quando fa la scansione del web, li aggiunge al Knowledge Graph e li mostra agli utenti nella ricerca.

Ed ecco come si possono facilmente aggiungere i mark up grazie al nuovo formato JSON-LD. Ma prima di addentarci nei dettagli tecnici diamo una sbirciata al modo in cui gli eventi dal Knowledge Graph si presentano in SERP.

Partiamo con l’esempio di una canzone “Alligator Strut” (vedi min. 1:53): la cerchiamo e vediamo che l’autore è Anton Shwartz… Chi è? Bene, è un sassofonista. Ha pochi album, è ben istruito…

Guardiamo i prossimi eventi… c’è una lista ricca di eventi e possiamo scoprirli uno per uno e vedere quale è quello più vicino a chi cerca. Quando clicco su uno di essi, si trovano maggiori dettagli, inclusa una mappa. E sulla destra si ha la possibilità di cliccare sul sito ufficiale dove si trovano tutti i dettagli.

Il Knowledge Graph “spinge” i rich snippets degli eventi nei risultati di ricerca; i listing degli eventi su Google Maps; facilita le notifiche in Google NOW per informare automaticamente le persone sugli eventi di interesse che hanno luogo nelle vicinanze e su quando le loro bands preferite arrivano in zona.

Ma per poter sfruttare queste caratteristiche gli organizzatori devono aggiungere dei mark up sul loro sito. Si deve prestare particolare attenzione ai dati sui siti web ufficiali degli artisti che effettuano dei tour – come cantanti e attori – ai siti ufficiali di luoghi di incontro e molto presto ai siti ufficiali degli eventi annuali, come festival e conferenze.

E per ogni evento per cui si vendono biglietti, si guarderà al primo sito ufficiale di vendita biglietti per tutti i dettagli.

I markup per gli eventi utilizzano il vocabolario di schema.org per marcare le proprietà chiave di ogni evento. Schema.org è solo un insieme di nomi di proprietà standard per dati strutturati concordati dai principali motori di ricerca.

Quando google processa una pagina web, è in grado di riconoscere le proprietà di schema.org in numerosi e diversi formati markup che includono microdata e RDFa.

Ora vedremo un nuovo formato: JSON – LD. A differenza degli altri formati, il formato JSON – LD non chiede di intrecciare i dati strutturati con il contenuto html mostrato. È ciò che lo rende ancora più developer friendly ed è per questo che google lo sta sposando.

Diamo un’occhiata! (vedi min. 4:32) Ecco come appare il formato JSON-LD quando è embeddato in una pagina web, in questo caso la pagina del tour di Keith Urban. Come si può notare è solo un blocco di dati JSON.

Le chiavi JSON sottolineate in giallo, come “startDate”e “location”, sono nomi di proprietà schema.org.

L’intero blocco JSON dovrebbe essere inserito in un tag di script e, dopo, lo si può inserire ovunque nella pagina web, sia nell’head che ne l body.

Vediamo qualche proprietà interessante.

La prima è @type. Si dovrebbe utilizzare il più specifico subtype di evento da applicare all’ evento in questione. I subtype popolari includono vari tipi di eventi: commedie; festival; eventi gastronomici, musicali, sportivi; teatro. Questo aiuta Google a categorizzare l’evento e in alcuni a casi si possono specificare perfino campi extra, rilevanti per quello specifico tipo di evento, come la squadra di casa o la squadra esterna, nel caso degli eventi sportivi.

La seconda è “startDate”. È necessario che sia in formato ISO 8601. L’orario è incluso nel campo ed è espresso nell’ora locale del luogo dell’evento. Se l’evento ha un orario di fine stabilito si può specificare che si sta utilizzando una proprietà separata per la data di fine (“endDate”).

La successiva è “location”. Il valore di questa proprietà è un sub-object annidato del @type place. In base alla nostra esperienza, questo tipo di nidificazione di dati gerarchici crea molti problemi agli sviluppatori nel formato di microdati RDFa. Ma nel JSON-LD è davvero molto semplice.

Si può vedere che il sub-object place dovrebbe avere tra le proprietà un “name”  che è il nome del luogo dell’incontro e un “address”. L’indirizzo può essere dato come stringa singola che per Google è facile da estrapolare o come un insieme di campi individuali in un altro sub-object nidificato di @type di indirizzo postale.

• per  l’evento  https://schema.org/Event in fondo alla pagina ci sono i vari @type  ( ora sono BusinessEvent, ChildrensEvent, ComedyEvent, DanceEvent, DeliveryEvent, EducationEvent, Festival, FoodEvent, LiteraryEvent, MusicEvent, PublicationEvent, SaleEvent, SocialEvent, SportsEvent, TheaterEvent, UserInteraction, VisualArtsEvent )
• per le Place di @type specifici ce ne sono centinaia e trovate l’albero qui https://schema.org/docs/full.html
• per i performer il @type li trovate qui https://schema.org/performer
• e infine per le offerte il @type è https://schema.org/Offer

C’è un’altra proprietà interessante che riguarda il luogo (place) che si chiama “same as”. Questa proprietà è disegnata per aiutarti a collegare i tuoi dati con il knowledge graph. Il valore della proprietà “same as” dovrebbe essere un url che inequivocabilmente indica l’identità degli items.

Per esempio la pagina Wikipedia del luogo di incontro, la pagina Freebase, o l’home page ufficiale. In questo caso è fornita l’home page di Fiddler’s Green Anphitheatre in modo da far capire a Google che Fifddler’s Green si riferisce all’Anfiteatro di Colorado e non al luogo mitico nell’aldilà dove i violinisti suonano e i ballerini ballano per tutta l’eternità.

Tornando al codice, vediamo il markup “performer” dell’evento. Da notare il link del “Same as”, che questa volta punta a una pagina di Wikipedia, così da assicurare che  Google capisca esattamente quale artista del mondo reale si sta esibendo all’evento. Le urls same as, tra parentesi, non devono apparire nella porzione della pagina web visibile all’utente. Sono solo un suggerimento per i motori di ricerca per comprendere cosa è visibile all’utente. Se ci sono numerosi artisti all’evento, bene. Si può usare l’array di JSON per elencarli tutti.

Infine, l’ultima proprietà è “offers”. È dove vanno le informazioni sui biglietti all’interno di un sub-object offer. Per un evento con biglietto, la key property da specificare è l’URL della pagina web che l’utente dovrebbe visitare per acquistare il biglietto. Se si specifica il link per acquistare il biglietto, Google in privato visiterà quella pagina web e cercherà di raccogliere più dettagli sulle modalità di acquisto biglietti da qualunque dato strutturato incontra.

Diamo un’occhiata a ciò che possiamo trovare su una pagina per l’acquisto di biglietti. Il resto del markup dovrebbe essere in sostanza lo stesso, ma nel ticket offer ci dovremmo aspettare delle proprietà extra. La “category” del biglietto, come “primary” o “secondary”; il “price”; l’”availability”, che dovrebbe essere impostata su sold out se è sold out e il “validfrom” che specifica quando questi biglietti vanno in vendita.

Una volta implementato, non resta che testare! Per essere sicuri che il markup sia coretto prima di metterlo online, basta copiarlo nel nuovo Event Markup Tester di Google. Restituisce messaggi di errore dettagliati e problemi di sintassi, come la mancanza di una virgola, e problemi di dati come la mancanza di una proprietà richiesta o dati formattati in modo errato. Si può anche visualizzare il riassunto di tutti i markup che abbiamo trovato sul tuo sito nella dashboard dei dati strutturati che è disponibile nei WMT.

Quando Google effettua il crawling sul tuo sito, leggerà gli eventi con mark up per verificare che essi siano consistenti con ciò che gli utenti visualizzano sulla pagina web e li importerà direttamente nel Knowledge Graph e per l’utilizzo attraverso i prodotti Google.

Altre informazioni utili le potete trovare qui:

• Pagina di assistenza sui dati strutturati: https://support.google.com/webmasters/topic/3068649
• Test di verifica rich snippet eventi – Strumento di test per il markup degli eventi
• JSON-LD  w3c Recommendation, 
• Rich snippet events su Google
• Plugin per wordpress tratta solo alcune delle questioni di cui abbiamo parlato sopra, ma meglio di niente.
• Data highlighter per gli eventi di Google, annuncio ufficiale

Se poi hai bisogno di una consulenza per  ottimizzare i tuoi eventi su Google non esitare a contattarci.