Oggi vi presento un brevetto molto interessante, “Model generation for ranking documents based on large data sets” assegnato a Google in data 22 Giugno 2010.

Questo brevetto merita un’attenta analisi, perché introduce nuove modalità per il ranking di grandi quantità di documenti (e ricordiamo che il nuovo indice di Google – Caffeine – è stato progettato anche per questa ragione).

Tutti i fattori di ranking esistenti possono essere condensati da Google in un unico singolo fattore: nella probabilità che l’utente u, data la query q, scelga il documento d.

L’utente diventa centrale nel ranking dei documenti

Per calcolare il posizionamento di un sito Google prende in considerazione la terna (utente, query, documento) ed è proprio l’utilizzo di una terna a costituire l’aspetto più innovativo.

Il documento non viene più valutato in termini assoluti; non si tratta più unicamente di personalizzazione dei risultati di ricerca. Google si spinge oltre: cerca di generare un modello di ranking ad hoc per ogni specifico utente che effettua una specifica query.

Generazione del modello

Partiamo da un’istanza (u, q, d). Ossia: c’è un utente u, che effettua una query q e seleziona un documento d. Di ogni istanza vengono memorizzate le caratteristiche (feature) più importanti in un feature-to-istance index.

I dati memorizzati da Google possono essere i seguenti:

• paese di provenienza dell’utente u;
• ora del giorno in cui l’utente u effettua la query q;
• lingua parlata nel paese di provenienza dell’utente u;
• le tre query effettuate dall’utente u prima dell’attuale query q;
• il linguaggio della query q;
• l’esatta stringa della query q, i singoli termini che la compongono e il numero di parole;
• i termini contenuti nel documento d;
• i termini contenuti nell’url del documento d;
• gli ancor text dei link che puntano al documento d;
• le parole nel titolo del documento d e nei documenti mostrati al di sotto e al di sopra di d nei risultati di ricerca;
• il numero di volte in cui una parola della query q è contenuta nel documento d;
• il numero di volte in cui l’utente u ha avuto accesso al documento d.

A partire da questi dati viene generato un ranking model specifico, che valuta appunto la probabilità che l’utente u, effettuando la query q decida di cliccare proprio sul documento d. Ed è proprio questa probabilità a costituire lo score, il punteggio in base al quale viene effettuato l’ordinamento dei risultati di ricerca.

Facciamo un esempio

L’utente accede a Google per la prima volta ed effettua una ricerca. In assenza di dati pregressi sul suo comportamento (l’utente non ha mai effettuato query analoghe in passato) viene calcolata una probabilità a priori.

Cosa accade quando l’utente, servito con un determinato set di risultati di ricerca clicca su un dato documento d?

Le probabilità a priori calcolate in precedenza vengono aggiornate tenendo conto di questa nuova probabilità misurata a posteriori (cioè dopo che l’utente ha scelto). E conseguentemente viene aggiornato il modello di ranking.

Grazie ai dati raccolti nel feature-to-istance index il motore di ricerca è in grado di aggiornare continuamente i propri modelli stabilendo non solo i pesi per ponderare ciascun criterio di ranking ma anche quali criteri utilizzare in funzione della specifica istanza.

Questo brevetto è fondamentale per capire:

1. come funzionano i meccanismi della personalizzazione dei risultati di ricerca;
2. come Google utilizza i dati degli utenti per perfezionare i propri algoritmi.

Se siete loggati in Google, effettuate una query e cliccate su un dato documento, Google utilizzerà quell’informazione per aggiornare il modello di ranking.

Ma l’aggiornamento del modello non riguarda solo voi. Google utilizza le informazioni memorizzate nel feature-to-istance index come training data per perfezionare il modello da utilizzare per tutti gli utenti con caratteristiche simili alle vostre.

Conclusione

Se vi loggate in Google, fate una ricerca e cliccate su un sito, il sito in questione guadagna posizioni nei vostri risultati di ricerca personalizzati.

Ma non solo. La vostra scelta influenza in qualche modo anche il ranking per gli utenti “simili” a voi.

Alla prossima.

Oltre la personalizzazione dei risultati di ricerca
© Fortunecat.it SEO Blog

Matt Cutts ha confermato che alla base del Google MayDay c’è una modifica degli algoritmi di Google. SearchEngineLand riporta:

Based on Matt’s comment at Google I/O, the pages that are now ranking well for these long tail queries are from “higher quality” sites (or perhaps are “higher quality” pages). My complete speculation is that perhaps the relevance algorithms have been tweaked a bit.

Fortunecat.it ve lo ha detto con 10 giorni di anticipo...

[/Update]

Google MayDay: in questi giorni ho ricevuto parecchie richieste a riguardo, quindi ho pensato di scrivere un post per fare po’ di chiarezza.

Ma cos’è Google MayDay?

In questo periodo numerosi webmaster hanno riscontrato una vistosa riduzione degli accessi provenienti da Google. Molti hanno notato che il calo più significativo di visite riguarda le cosiddette long tail, le frasi chiave costituite da 3 o più termini.

Questo problema è stato ironicamente battezzato “MayDay”, sia perche “la parola mayday è utilizzata in radiofonia per indicare un’immediata necessità di aiuto da parte di un’imbarcazione o di un velivolo” (da Wikipedia), sia perchè il calo di visite è stato notato nei primi giorni di Maggio (May Day).

Quali sono le possibili cause?

La mia opinione è la seguente: Google ha semplicemente “snellito” il proprio indice di ricerca.

Sicuramente avrete sentito parlare di Google Caffeine: Caffeine in sostanza è un aggiornamento dell’infrastruttura di Google, e tra gli obiettivi dichiarati di tale aggiornamento vi è proprio quello di aumentare la velocità delle ricerche.

Come si può “snellire” il Google Index?

Cerchiamo di capire come innanzitutto come è costituito un indice, facendo riferimento al brevetto “Index server architecture using tiered and sharded phrase posting list”.

Tutti i moderni motori di ricerca utilizzano le frasi per indicizzare, cercare, organizzare e descrivere i documenti. I documenti sono indicizzati tenendo conto delle frasi in essi contenute utilizzando una phrase posting list.

Le phrase posting list sono memorizzate in un cluster dell’index server e per motivi di performance possono essere raggruppate oppure partizionate in vario modo. Le frasi sono individuate considerando anche ogni possibile “phrasification” o variazione sul tema.

In termini più semplici:

• I motori di ricerca creano un indice che collega i documenti alle frasi presenti nel documento stesso.
• L’indice generato è denominato pertanto inverted index, perché fa corrispondere ad ogni frase chiave un set di documenti rilevanti.
• Possiamo immaginare l’intero indice come un’insieme di “blocchi” (le posting list), ciascuno relativo ad una frase chiave.

E qui arriviamo al punto fondamentale. Per rendere l’indice più “leggero” Google può agire su due fattori:

• sul numero di frasi chiave memorizzate;
• sul numero delle pagine indicizzate.

Iniziamo dal primo punto: come vengono processate le query?

I motori di ricerca di vecchia concezione scomponevano le query complesse in singole parole chiave. La query dell’utente veniva soddisfatta fornendo come risposta i documenti contenenti tutte le parole chiave, seguendo un matching “booleano” diretto.

I motori di ricerca attuali cercano di indicizzare i concetti, più che le semplici parole chiave. Proprio per questo le frasi chiave non vengono decomposte nelle singole parole ma in sottofrasi, generando un albero di frasi per modellare concettualmente una query complessa.

Andiamo con ordine

Un insieme di parole non costituisce di per sé una frase. Come fa il motore di ricerca a distinguere le frasi?
Google ovviamente ragiona in termini statistici. Le frasi concettualmente rilevanti appaiono nei documenti con maggiore frequenza rispetto alle combinazioni puramente casuali.

Il processo effettuato da Google è il seguente:

• Inizialmente vengono individuate delle possibili frasi, o frasi candidate.
• Ad ogni frase candidata viene assegnato un phrase score in funzione della posizione nei documenti e del modo in cui la frase stessa viene utilizzata.
• Solo se è statisticamente evidente che la frase è utilizzata in numerosi documenti (oppure anche in un singolo documento in modo diffuso), allora la frase candidata viene promossa da Google a frase “reale”.

Da quanto detto sinora risultano chiare le tecniche adottate da Google per indicizzare le frasi più significative o più importanti, che dir si voglia.

E le frasi lunghe e meno ricorrenti come vengono considerate?

Qui c’è il nodo fondamentale. Per ogni frase processata vengono anche estratte le possibili sottofrasi in modo da ridurre il costo computazionale dell’indicizzazione.

Facciamo un esempio concreto, ecco come potrebbero essere processate le tre query:

• hotel rimini 3 stelle sul mare;
• hotel tre stelle rimini fronte mare;
• albergo rimini tre stelle vicino al mare.

Le tre query/frasi vengono scomposte in sottofrasi e ricondotte ad un’unica unità concettuale. Per fare questo viene utilizzato un phrase tree, un albero che unisce logicamente fra loro le sottofrasi individuate.

Qual è di fatto l’effetto di questo nuovo algoritmo?

Per le frasi chiave più lunghe, per le cosiddette long tail, viene dato un minor peso al matching esatto dei termini, ed un peso maggiore al senso complessivo del documento.

Prima di Caffeine il fatto di scrivere nel vostro sito web la frase esatta “hotel rimini 3 stelle sul mare” vi dava un vantaggio significativo per quella long tail. Ora il peso della corrispondenza esatta è stato ridimensionato a favore di altri fattori, tra cui il senso del documento nel suo complesso, l’autorità del sito, ecc…

Riduzione del numero di pagine indicizzate

Ma siamo sicuri che il calo di visite sia solo dovuto alle long tail? Guardate questo diagramma che rapporta il numero di pagine indicizzate di FriendFeed in funzione della data di creazione delle pagine stesse.

E guardate anche cosa è accaduto a Punto-informatico.it:

Sembra incredibile, ma persino FriendFeed.com è stato soggetto ad una pesante deindicizzazione.

Fino a pochi mesi fa il numero di pagine indicizzate di FriendFeed era nettamente superiore, ve lo posso garantire in quanto uno dei miei seo tools utilizzava proprio Google per stimare il numero di link ad un dato dominio provenienti da FriendFeed.

E’ evidente quindi che per alleggerire il proprio immenso indice di ricerca Google ha dovuto rimuovere moltissime pagine. E in nome della velocità ha scelto di sacrificare le pagine più “anziane”.

Interessante, eh?

Alla prossima…

Google MayDay: un po’ di chiarezza
© Fortunecat.it SEO Blog

Il video affronta i seguenti argomenti:

• come Google affronta il tema delle performance;
• primi passi per rendere più veloce un sito web.

Need for speed

Perchè per Google la velocità ha una così grande importanza? Perchè migliora notevolmente la user experience.

Si è osservato ad esempio che un sito veloce ha un numero maggiore di conversioni. Sono state messe a confronto due versioni dello stesso identico sito, una ottimizzata (e quindi più veloce) e l’altra no. Dall’analisi delle landing page risulta che:

• su ShopZilla la maggiore velocità ha determinato dal 7% al 12% in più di conversioni;
• su Firefox è stato notato un aumento del 15.4% dei downloads.

Un sito più veloce inoltre ha una maggiore user satisfaction.

Tratto da “Performance related changes and their user impact” di Eric Shurmann e Jake Brutlag

Google e Bing hanno eseguito un test molto interessante: hanno mostrato ad alcuni utenti i propri risultati di ricerca con un certo delay. E’ emerso che maggiore era il ritardo, maggiore era la scontentezza degli utenti.

Con un delay di 2 secondi l’insoddisfazione degli utenti era aumentata del 3.8%, cosa che ha spinto Microsoft a porre fine all’esperimento in questione.

Infine: la lentezza del sito ha effetti negativi anche nel lungo periodo. Google e Microsoft hanno eseguito un altro test, ancora utilizzando i propri motori di ricerca. Hanno fornito a due gruppi di utenti dei risultati ritardati rispettivamente di 200 millisecondi e di 400 millisecondi.

Si può notare dal grafico sottostante come gli utenti serviti con un delay di 400 ms (in rosso) effettuino anche un minore volume di query.

Tratto da “Performance related changes and their user impact” di Eric Shurmann e Jake Brutlag

Ma la cosa più sorprendente è che – nonostante il delay venga rimosso in corrispondenza della 7° settimana (wk7) – il comportamento degli utenti risulta comunque affetto dai ritardi riscontrati nel passato (la curva in rosso si posiziona più in basso della curva in nero anche nella seconda parte del grafico, nonostante entrambi i gruppi di utenti non abbiano più alcun delay).

Riassumendo:

1. La velocità migliora le conversioni e la user satisfaction.
2. La lentezza determina effetti negativi anche nel lungo periodo.

Velocità e user experience vanno quindi di pari passo: proprio per questo Google ha deciso di inserire la velocità tra i propri ranking factors.

Ma attenzione: la velocità è solo uno dei circa 200 fattori considerati da Google, i contenuti e la rilevanza continuano ad essere prioritari.

Velocizzare il frontend a costo zero o con spesa minima

Ecco la “Regola d’oro” dell’ingegnere di Google Steven Sounders: l’80-90% del tempo di risposta dipende dal frontend.

Anche noi possiamo testare questo assunto utilizzando il servizio WebPageTest.org su un qualunque sito web: in tutti i casi si evince chiaramente che sono le immagini ad impegnare il maggior tempo di caricamento.

Tool disponibili

Veniamo agli strumenti che i webmaster possono utilizzare per monitorare le performance di propri siti.

• Prestazioni del sito, disponibile all’interno dei Google Webmaster Tools per i siti verificati. Questo strumento fornisce una stima del tempo medio di caricamento ed una valutazione comparativa della velocità rispetto agli altri siti web.
• PageSpeed, un plugin di Firebug per FireFox che assegna un voto alle pagine web analizzate e che indica gli aspetti da correggere per migliorare la velocità.

FAQ

E’ possibile controllare il tempo di risposta del mio server da diverse aree del mondo?

Certo, con WebPageTest.org puoi eseguire i test dagli Stati Uniti, dalla Gran Bretagna, dalla Cina e dalla Nuova Zelanda.

Qual è un buon tempo di risposta per un server?

Tieni bene a mente che sei i tuoi concorrenti sono veloci, allora stanno fornendo una migliore user experience per la tua stessa audience. Quindi è bene sapere prima di tutto cosa offrono i tuoi competitors.

2 secondi è il valore limite di accettabilità per gli ecommerce. Google per le proprie pagine punta invece ad un tempo di 1.5 secondi.

Il progressive rendering è utile per gli utenti?

Indubbiamente si. Il progressive rendering si ha quando il browser inizia a visualizzare i contenuti (anche parziali) non appena sono a sua disposizione.

Il progressive rendering è importante perchè dà all’utente un feedback visivo e lo aiuta a sentirsi maggiormente “in controllo” della navigazione.

Microsoft ha testato questo aspetto osservando che il progressive rendering ha migliorato dell’1.7% la user satisfaction degli utenti di Bing.

Per implementare il rendering progressivo anche nei nostri siti web è sufficiente inserire i fogli di stile a monte della pagina.

Performance e SEO

La velocità aumenta:

• le conversioni;
• le pageviews;
• il tempo di permanenza sul sito.

E riduce:

• la frequenza di rimbalzo;
• il carico del server.

Quest’ultimo punto è fondamentale: ShopZilla ad esempio ha osservato che ottimizzando le pagine ha ridotto i propri costi di gestione del 50%.

Concludendo

La velocità non è importante solo per gli utenti, ma anche per i SEO perchè ci consente di aumentare concretamente il valore delle nostre attività.

Alla prossima.

Velocità: ecco i consigli di Google
© Fortunecat.it SEO Blog

In giro ho letto molti post a riguardo, ma nessuno di questi ha affrontato la questione da un punto di vista pratico. Suddividiamo l’argomento in 3 semplici punti.

Come si fa a creare una landing page per cellulari?

Il linguaggio utilizzato è l’XHTML Mobile Profile, un derivato dell’XHTML 1.1 Basic. Le differenze tra i due linguaggi sono davvero minime e pertanto se crei una pagina semplice non vi dovrebbero essere particolari problemi nella compilazione del sorgente.

Ricordati che è fondamentale la validazione del codice. A tale scopo puoi utilizzare:

• Ready.mobi che oltre alla validazione assegna un punteggio di mobile friendliness;
• W3C MobileOK Checker, il validatore “ufficiale” della W3C.

Come si fa a testare una landing page per cellulari?

Non è necessario acquistare tutti i modelli di smartphone in commercio. E’ sufficiente installare su Firefox i plugin:

• XHTML MP;
• Web Developer.

Il primo plugin aggiunge a Firefox il supporto per l’XHTML Mobile Profile. Il secondo ci consente di testare la landing su diverse risoluzioni. Vediamo come.

Dopo aver installato il plugin Web Developer verrà attivata su Firefox la corrispondente toolbar. Clicchiamo su Ridimensiona / Modifica opzioni di ridimensionamento. Apparirà la seguente finestra:

Clicchiamo su Aggiungi ed inseriamo il campo “iPhone” con dimensioni dello schermo pari a 320×480. E’ fondamentale spuntare l’opzione “Ridimensiona la parte interna”, per emulare al meglio la risoluzione dell’iPhone. Dopo aver cliccato su OK, nel menu Ridimensiona della toolbar apparirà la voce iPhone precendentemente memorizzata. Cliccando su tale voce la finestra del browser verrà ridimensionata in modo tale che la pagina sia visualizzata proprio in un riquadro 320×480.

Ovviamente con Web Developer possiamo memorizzare anche altre risoluzioni: ad esempio il Nokia n97 ha una risoluzione di 360×640, un BlackBerry Bold 9700 di 480×360 e così via.

E’ molto importante effettuare test su vari modelli. Ricorda: lo scrolling orizzontale può disorientare l’utente.

Con questo plugin possiamo testare quindi tutte le risoluzioni possibili, utilizzando semplicemente il browser Firefox.

Come creare un’interfaccia user-friendly?

Ricordati che gli utenti degli smartphone non utilizzano il mouse ma navigano le pagine con la pressione delle dita grazie al touch screen.

Proprio per questo è opportuno utilizzare dei pulsanti al posto dei semplici link testuali. Per garantire la piena usabilità dei pulsanti su touch screen è necessario seguire queste 3 regole (suggerite peraltro anche dalle linee guida per lo sviluppo di applicazioni iPhone):

• il pulsante deve avere altezza e larghezza minima di 1,27 cm;
• tra un pulsante e l’altro ci deve essere uno spazio almeno pari a 0,32 cm;
• il pulsante deve trovarsi ad almeno 8 px dal bordo dello schermo.

Inoltre cerca di ridurre quanto più possibile la complessità dei form, perché gli utenti mobile potrebbero avere difficoltà nella compilazione: 3 campi sono più che sufficienti.

Questo è tutto. Se l’articolo è stato di tuo gradimento puoi condividerlo sui social network, puoi suggerire ai tuoi amici di diventare fan di questo portale su Facebook oppure potresti anche scrivere una recensione di Fortunecat.it sul tuo sito.

Alla prossima.

Creare una landing page per cellulari
© Fortunecat.it SEO Blog

I sistemi di information retrieval, generalmente chiamati motori di ricerca, creano un indice che collega i documenti presenti su internet alle singole parole contenute nei documenti stessi.

Il motore di ricerca, in risposta ad una query contenente uno o più termini, fornisce un set di documenti contenenti proprio i termini richiesti dall’utente.

Viene quindi effettuato un ordinamento (ranking) dei documenti che tiene conto di:

• link analysis;
• host domain (il fatto che il dominio venga espressamente nominato conferma l’impatto della rilevanza ed autorevolezza dell’intero dominio sul ranking);
• frequenza di occorrenze dei termini presenti nella query, ecc…

Ma un motore di ricerca evoluto non si limita al matching “booleano” dei termini: infatti per molte ricerche il matching esatto non produrrebbe i risultati desiderati.

Ad esempio – se ci limitassimo alla corrispondenza esatta – cercando Australian Shepherd (una razza canina) otterremmo come risposta anche documenti che parlano dell’Australia o degli Shepherd in generale.

Questo perché i sistemi di indicizzazione tradizionali si basano sulle parole piuttosto che sui concetti, e i concetti sono solitamente espressi utilizzando delle frasi.

Un modo per ovviare a questo inconveniente potrebbe essere quello di utilizzare i co-occurrence patterns: se le parole A, B e C sono presenti contemporaneamente in più documenti è probabile che siano in qualche modo collegate semanticamente.

Ma anche questo sistema ha delle controindicazioni. Supponiamo che le tre parole siano “Presidente”, “Casa” e “Bianca”.

Le parole “Casa” e “Bianca” generalmente compaiono in associazione al termine “Presidente”, ma prese singolarmente hanno ben poco a che fare con il concetto di “Presidente”. Quindi non possiamo ritenere semanticamente affini le tre parole in esame.

Come fa Google ad estrarre i concetti da un documento?

Se il motore provasse ad indicizzare tutte le frasi, ossia tutte le possibili combinazioni di termini, lo sforzo computazionale sarebbe enorme e i risultati sarebbero comunque inadeguati.

Quindi Google cerca di estrarre solo le keyphrase più importanti, estrapolando cioè solo le frasi utilizzate di frequente e/o in modo particolare all’interno dei documenti in esame.

L’obiettivo è quello di stabilire quali siano le frasi valide e significative, evitando così l’indicizzazione indiscriminata di tutte le combinazioni possibili di termini.

L’analisi delle frasi correlate

Per capire se due frasi sono correlate Google utilizza una metrica molto particolare: l’Informational Gain, dato dal rapporto tra il tasso di co-occorrenza effettivo di due frasi ed il tasso di co-occorrenza atteso.

In termini più semplici: se l’informational gain supera un valore di soglia, ossia se due frasi vengono utilizzate insieme con un tasso superiore a quello previsto/medio, Google classifica le frasi in questione come correlate.

Da un punto di vista semantico: le frasi correlate sono utilizzate in riferimento ad un dato argomento. Ad esempio “Presidente degli Stati Uniti” e “Casa Bianca” fanno riferimento a concetti molto vicini fra loro.

Capite bene quindi quanto questa patent sia attuale, soprattutto perché Google ha deciso di espandere i risultati di ricerca con i sinonimi. E non è un caso che nel post presente sul blog ufficiale di Google vengano fatti gli stessi esempi contenuti in questa patent.

Le frasi correlate e il ranking

L’utilizzo delle frasi correlate modifica persino i criteri di ranking, vediamo come.

Per ogni frase viene creata una “posting list” che identifica i documenti contenenti la frase in questione.
In aggiunta per ogni frase viene creata una seconda lista che contiene le frasi correlate a quella di partenza.

Dall’intersezione delle due liste il motore di ricerca riesce ad individuare i documenti che, oltre alla frase cercata, contengono anche le frasi correlate ad essa (documenti che quindi sono più rilevanti rispetto al concetto cercato dall’utente).

Il multiple index

Un altro aspetto molto interessante è che il motore di ricerca utilizza un indice multiplo. Sono infatti presenti un indice primario ed un indice secondario.

L’indice primario contiene l’index relativo alle frasi, con un numero limitato di documenti per ciascuna frase. Il ranking all’interno dell’indice primario è effettuato secondo criteri di rilevanza rispetto alla frase.

Tutti i documenti che non rientrano nell’indice primario finiscono nell’indice secondario, in cui il ranking è effettuato con criteri meno sofisticati.

Come viene assegnata la data ai documenti?

Come sapete tra le opzioni di ricerca di Google figura il ranking per data. Il brevetto è molto chiaro su questo punto. La data viene assegnata al momento dell’indicizzazione ma se il contenuto del documento viene aggiornato, anche la data viene aggiornata nell’istante di re-crawling. Questa informazione sicuramente vi tornerà utile per la real time search di Google, e per riciclare documenti “vecchi”.

I documenti che vengono aggiornati spesso inoltre traggono un beneficio in termini di ranking.

Indicizzazione “semantica”

Il sistema di indicizzazione si occupa anche di:

• identificare le frasi e le frasi correlate;
• indicizzare i documenti in relazione alle frasi;
• creare e mantenere una tassonomia relativa alle frasi.

Grassetto, corsivo, sottolineato?

Davvero degno di nota il fatto che l’algoritmo di indicizzazione, nell’individuare le possibili frasi rilevanti in un testo utilizzi anche la formattazione presente: se una porzione di testo è ad esempio in grassetto, è probabile che costituisca una frase rilevante.

Ma questo non significa che il grassetto migliori il ranking, sia chiaro. Significa unicamente che il motore potrebbe utilizzare quelle informazioni per estrarre con maggiore facilità le frasi rilevanti da un documento, e quindi per effettuare una migliore classificazione semantica dei documenti.

L’utilizzo delle congiunzioni (e, o…)

Le congiunzioni, utilizzate in modo opportuno, possono suggerire al motore di ricerca che alcuni concetti espressi mediante frasi sono collegati. Se scrivo ad esempio posizionamento nei motori e social media marketing, il motore è in grado di comprendere, seppure in modo limitato, che le frasi chiave sono semanticamente affini.

A cosa serve quindi l’utilizzo opportuno della formattazione e delle congiunzioni?

C’è un limite massimo alle frasi rilevanti memorizzate per ciascun documento. Un utilizzo opportuno di questi strumenti ci garantisce che il documento sia correttamente classificato dal motore di ricerca.

Ranking e frasi chiave

A ciascun documento nella posting list viene assegnato un punteggio che tiene conto:

• della rilevanza del documento stesso (es. pagerank);
• numero di occorrenze della frase chiave;
• anchor text e rilevanza dei documenti che linkano la risorsa;
• utilizzo di markup per evidenziare le frasi rispetto al resto del documento.

Per le risorse via via meno rilevanti vengono memorizzate sempre meno informazioni (es.: per i documenti dal basso ranking non viene neppure considerata la posizione delle frasi all’interno del documento).

Come fa il motore a modellare i concetti?

Il concetto è modellato grazie ad una matrice di frasi. L’unione e la compresenza di più frasi chiave identificano un’unità concettuale.

Gli utenti non apprezzano documenti lunghi che parlano di diversi topic, per il semplice motivo che l’utente visita la pagina generalmente dopo aver effettuato una query nel motore di ricerca. Se cerco “gatti” voglio leggere pagine che parlino di gatti, no? Quindi maggiore è l’attinenza con la query, migliore il posizionamento della risorsa.

Se siete ancora vivi dopo aver letto questo kilometrico post non dimenticatevi di condividerlo sui social e di abbonarvi al feed. Tra l’altro ho creato anche una pagina facebook con cui potete darmi del “supporto morale”.

Alla prossima.

Il posizionamento delle keyphrase
© Fortunecat.it SEO Blog

Cerchiamo di approfondire la cosa: il 15 Maggio 2008 a Google è stata assegnato il brevetto “Computer implemented interactive, virtual bookshelf system and method”. Questa patent è stata quasi certamente utilizzata come punto di riferimento per la ristrutturazione che Google Books sta subendo; nel brevetto infatti si fa riferimento:

• alle virtual bookshelf, ossia alle raccolte di libri generate dagli utenti (dai un’occhiata agli “scaffali” introdotti pochi giorni fa);
• alla trasformazione di Google Books in senso sociale, con la possibilità di condividere le proprie librerie con amici e colleghi;
• alla possibilità di inserire annotazioni per ciascun libro;
• ad un concetto più ampio di “book”, inteso più genericamente come libro, magazine o quotidiano;

La funzione “Aggiungi nota” tra l’altro è stata già implementata:

Sulla base di queste premesse azzardo 2 previsioni:

1. Sicuramente a breve sarà possibile aggiungere degli amici su Google Libri, esattamente come accade per Anobii.
2. E’ molto probabile che in un futuro non troppo lontano lo scaffale generato da ciascun utente possa anche essere inserito nei Google Profiles.

Ma torniamo a noi. L’introduzione di queste funzioni sicuramente comporterà delle novità per la ricerca dei libri. E dato che i libri rientrano nella universal search, quello che sto per dirvi potrebbe tornarvi davvero utile.

Cosa accade quando il server riceve una search query relativa ad un dato libro?

Vengono filtrati tutti i libri presenti nel database in modo da restituire solo i libri con i metadati corrispondenti a quelli inseriti dall’utente. Ma per metadati non si intendono solo quelli relativi alle caratteristiche del libro…

Le novità introdotte ampieranno notevolmente le fonti da cui Google attinge. I metadati proverranno infatti da:

• Informazioni relative al libro/magazine (come autore, titolo, ISBN, lingua, editore, formato, data di pubblicazione, informazioni sul copyright, ecc.).
• Annotazioni, recensioni e segnalibri degli utenti sul libro e sul suo contenuto, etichette (labels) applicate per facilitare la catalogazione o per creare gerarchie all’interno della propria raccolta di libri. In un passaggio si accenna anche al fatto che potrebbero essere usate come fonti di informazione gli scaffali di amici e colleghi, oltre che “scaffali di gruppo”.
• Database online specializzati, siti di recensioni, ecc…
• Query digitate dall’utente per ottenere il libro desiderato. Ad esempio se cerco “Marketing”, clicco su “Marketing Management” di Kotler e lo aggiungo al mio scaffale, la mia query viene aggiunta ai metadati del libro stesso.

Ci sono ampi margini quindi per provare a migliorare anche il posizionamento dei libri su Google Books.

Nota conclusiva: questo blog cerca di offrire contenuti originali e – spero – di qualità.

Se vuoi sostenere Fortunecat.it puoi:

• inserirmi nel tuo blogroll;
• andare nella home page, fare lo scroll della pagina e aggiungerti ai sostenitori con Google Friend Connect o NetworkedBlogs;
• abbonarti al feed RSS.

Alla prossima…

Google Libri: novità per il posizionamento?
© Fortunecat.it SEO Blog

D’ora quindi in poi gli abbonati al feed RSS riceveranno – oltre ugli update relativi ai post di approfondimento – anche le principali notizie del giorno.

Bene, oggi parliamo di contenuti duplicati facendo riferimento ad un brevetto piuttosto recente “Duplicate document detection in a web crawler system” del 1 Dicembre 2009.

Il motore di ricerca, in fase di scansione, individua una serie di documenti con il medesimo contenuto. In funzione di opportune metriche indipendenti dal tipo di query viene stabilito quali documenti devono essere inclusi nell’indice e quali devono essere filtrati.

Il motore di ricerca assegna ad una classe di documenti duplicati un fingerprint, una sorta di codice identificativo che in sostanza individua un contenuto comune a tutte le pagine in questione (ad es.: un codice a 64 bit calcolato a partire da un testo normalizzato).

Tutte le informazioni relative al set di documenti duplicati vengono memorizzate in forma di dati strutturati.

Quando il motore di ricerca individua un nuovo documento, prima di processarlo effettua un confronto con gli altri documenti già memorizzati. Nel caso vi sia una coincidenza di dati, il nuovo documento viene marcato con il fingerprint relativo ad una specifica classe di duplicati.

In termini più semplici: il motore di ricerca classifica i contenuti con un codice identificativo, pagine con lo stesso contenuto condividono lo stesso codice.

Un aspetto molto interessante: i “crawling layer”

Google classifica gli URL usando tre livelli di scansione:

1. livello base: contiene gli url delle pagine che vengono scansionate periodicamente;
2. livello daily: contiene gli url delle pagine che richiedono una scansione giornaliera;
3. livello real-time: contiene gli url di risorse che devono essere scansionate più volte al giorno, anche ad intervalli di pochi minuti (es. tweets).

Una pagina viene assegnata ad uno specifico layer in funzione della frequenza di aggiornamento e di altri indicatori (pagerank in primis).

Per ciascuna pagina inoltre viene calcolato il pagerank, e generata una mappa dei link e degli anchor text.

A questo punto la domanda è: quali documenti appariranno nei risultati di ricerca?

I componenti fondamentali in gioco sono due: il modulo Content Filter e il DupServer (il server che contiene le informazioni relative ai duplicati).

Quando viene individuata una nuova risorsa il Content Filter consulta il DupServer per capire se il documento è o meno un duplicato.

Facciamo un esempio:

Il motore individua il documento A. Il Content Filter consulta di DupServer e deduce che non esistono duplicati di A. Ad A viene assegnato un fingerprint 001 che identifica il contenuto di A.

Dopo 1 mese il motore scopre il documento B. Il Content Filter consulta il DupServer e scopre che B ed A hanno lo stesso contenuto.

Cosa succede ora?

1° caso: il pagerank di B è più basso del pagerank di A.

A “vince”. A e B rientrano nella stessa classe di duplicati il cui codice identificativo è 001, il codice di A. Questo sta a significare che l’insieme dei duplicati è rappresentato da A, e sarà proprio A ad apparire nei risultati di ricerca.

2° caso: il pagerank di B è più alto ma solo di poco.

A resta comunque la versione più rappresentativa. Ciò per due ragioni (mia interpretazione):

• A così viene comunque privilegiato per il fatto di essere stato indicizzato prima;
• si evita anche di modificare continuamente gli url nei risultati di ricerca.

3° caso: il pagerank di B è nettamente più alto.

B diventa la nuova versione più rappresentativa. B riceve un fingerprint tutto suo, es.: 002. D’ora in poi la classe di duplicati sarà identificata dal nuovo codice 002, segno appunto che il documento rappresentativo ora è B e non più A.

Conclusioni

Il criterio che Google utilizza per filtrare i documenti duplicati sembra essere fondamentalmente basato sul pagerank, ma le caratteristiche dell’algoritmo se non altro ci garantiscono che a parità di PR viene privilegiata di fatto la pagina indicizzata prima.

Approfondiremo ancora l’argomento quindi restate connessi. Alla prossima.

Google e l’individuazione dei duplicati
© Fortunecat.it SEO Blog

Tutto è nato da questa intervista gentilmente realizzata da Mirko, visto poi l’interesse mostrato verso questo tema ho pensato di creare una guida ad hoc.

Alla prossima.

Tutorial: creare una versione mobile del proprio blog
© Fortunecat.it SEO Blog

Colgo anche l’occasione per ringraziare tutti i relatori e i partecipanti per l’attenzione dimostrata.
A breve pubblicherò anche un resoconto dell’evento quindi restate connessi…

Uno sguardo sul mobile web
© Fortunecat.it SEO Blog

Bene, innanzitutto qual è il problema di Google?

Il web contiene un’immensa quantità di informazioni. Molti motori di ricerca effettuano il ranking dei documenti basandosi sui contenuti dei documenti stessi.

Altri motori, tra cui Google, effettuano il ranking anche in base alla struttura dei link della pagina web.

Tuttavia alcuni documenti possono essere interessanti per utenti che risiedono o che sono interessati ad una determinata area. Ad esempio: esercizi commerciali, testate giornalistiche locali, ecc.

Quindi è importante per il motore di ricerca capire se una pagina ha una sua “rilevanza geografica”, così da restituire non solo i risultati di ricerca più rilevanti ma anche i più vicini geograficamente all’utente.

I classici sistemi di ranking geografico hanno due evidenti limitazioni: quella di dare molto peso alla vicinanza e quella di restituire risultati solo all’interno di un raggio massimo dalla location di ricerca.

Il metodo adottato da Google invece è il seguente:

1. Il motore riceve la query;
2. Viene identificato un “topic”, un argomento o più correttamente un’area di pertinenza corrispondente alla query. Facciamo un esempio: sia che io cerchi “albergo” o che cerchi “bed & breakfast” l’argomento della ricerca è grossomodo lo stesso. Entrambe le query rientrano nel medesimo topic “hotel”. Inoltre per ciascun topic viene anche definita una “location sensitivity”.
3. Il motore individua una serie di documenti. Determina inoltre la location corrispondente a ciascun documento.
4. Viene effettuato il ranking.

Nota: gli stessi criteri sono utilizzati anche per mostrare gli ads più rilevanti in funzione dell’area geografica.

Schema dell’algoritmo

Il motore di ricerca include:

• Il document locator: individua un set di documenti rispondenti alla query dell’utente.
• Il ranking component: effettua il ranking dei documenti in funzione della rilevanza.
• Il location component: può determinare un “quality signal” inteso come “distance signal”; tiene conto della rilevanza geografica del set dei documenti.
• Il location database: memorizza i dati geografici e quelli relativi alla location.
• Il topic database: il motore di ricerca determina le relazioni che intercorrono tra i topics e la sensibilità geografica e memorizza il tutto nel suddetto database.

Il Location Component e la “sensibilità geografica”

Un’importante funzione del location component è la seguente: determinare analizzando il comportamento dell’utente (dai click e addirittura dal mouseover):

• fino a che punto risultati ordinati secondo criteri meramente geografici possano essere soddisfacenti per l’utente;
• il range di rilevanza geografica o sensibilità geografica per un topic.

Spieghiamo il range di rilevanza geografica con un esempio: se cerchi su Google “concessionaria auto” e “pizza”, il location component associa le query rispettivamente ai topic “automobili” e “ristoranti”.

Il location component quindi determina la sensibilità geografica dei due topic in questione. Un utente è disposto a viaggiare 50 km per comprare un auto ma non è disposto a fare 50 km per comprare una pizza, giusto?

La sensibilità geografica è proprio questa. E’ quindi evidente che nell’individuare i risultati di ricerca per la query “pizza” la vicinanza all’utente giocherà un ruolo molto più importante rispetto al caso delle automobili.

Questa sensibilità geografica – come vedremo – ha delle interessanti conseguenze sul ranking dei risultati.

Il Location Database: quali informazioni contiene?

Inoltre il location database può contenere al suo interno posizioni e indirizzi, una sorta di mappatura di:

• utenti;
• query;
• documenti.

Il motore di ricerca al momento dell’indicizzazione cerca di associare ad ogni documento scansionato anche una precisa collocazione geografica.

Il location database inoltre può essere consultato per individuare la posizione dell’utente, del documento e eventualmente per determinare la distanza che intercorre tra essi.

Il processo di indicizzazione e Ranking

1° Fase

Il motore di ricerca riceve una query dall’utente.

2° Fase

Viene associata una posizione geografica alla query. Questa associazione può avvenire in vari modi. La località può essere specificata espressamente dall’utente nella query (ad es.: “hotel roma”), oppure può essere desunta dall’indirizzo IP dell’utente, dalla sua browsing history, cache history o consultando i dati dell’utente nel location database.

3° Fase

Il motore di ricerca identifica i documenti rispondenti alla query.

4° Fase

Viene determinato un Topicl Score: è un punteggio assegnato in funzione di fattori diversi dalla posizione geografica, tra cui:

• informazioni relative al testo del documento;
• struttura dei link alla pagina;
• informazioni relative ai link alla pagina.

All’aumentare del topical score aumenta la rilevanza della risorsa.

5° Fase

Viene determinato un Distance Score: è una funzione monotona decrescente della distanza. Il che tradotto in linguaggio comprensibile significa che se la distanza diminuisce, il distance score aumenta.

Il distance score dipende però non solo dalla distanza tra utente e documento ma anche dalla sensibilità geografica e presenta un espressione matematica del tipo:

F(d,S)=a/(b + S·d)

dove a e b sono delle costanti scelte per tarare opportunamente l’algoritmo, d è la distanza ed S è la sensibilità geografica.

All’aumentare della sensibilità geografica i documenti più distanti dall’utente ricevono un distance score sempre più basso.

La sensibilità geografica S viene quantificata non solo in funzione dei diversi topics, delle query, utenti e località, ma anche in funzione del dettaglio richiesto dall’utente.

Se ad esempio scrivo esplicitamente nel motore di ricerca il CAP o l’indirizzo, il motore interpreta questa maggiore precisione come una maggiore sensibilità geografica.

6° Fase

Il topical score e il distance score vengono combinati in un unico punteggio: il Combined Relevance Score:

C(R,F) = k · R + l · F(d,S)

dove k e l sono delle costanti opportunamente scelte.

Alla prossima.

Google Local Search: criteri generali di funzionamento
© Fortunecat.it SEO Blog