Author Archives: theMage

Empresas

Modelos de Negócio Online

Published by:

Tenho estado a trabalhar num CMS para uma empresa de media tradicional, que publica várias revistas. Eles questionam-se como rentabilizar os respectivos sites, e isso levou-me a mim a colocar a mesma questão.

No caso dos meus sites, a questão nunca foi como ganhar dinheiro com eles, mas a verdade é que ao longo de vários anos dediquei muitas horas à construção de ferramentas, a pesquisa e criação de conteúdos, a criar e alterar o design dos sites.

E, claro, coloquei muito do meu dinheiro nestes sites, especialmente no registo dos domínios, acesso à internet e aluguer de servidores.

Hoje olho para os meus sites, cuja quantidade se escreve com dois dígitos, e para a lista de domínios que tenho registados, todos com óptimos projectos editoriais, mas pouco tempo para os implementar e colocar online, e percebo que tenho o mesmo problema que este cliente.

Claro que eu tenho um problema acrescido. Eles têm dezenas de pessoas a criar novos conteúdos todos os dias. Eu estou a solo e apenas o faço nos tempos livres.

Esqueçamos portanto os meus pequenos sites e concentremo-nos nas situações em que existe conteúdo e investimento para a sua criação, como este cliente, e como muitas empresas idênticas, como as centenas de revistas que existem não apenas no nosso país, como também no resto do mundo.

A maioria destas equipas editoriais está permanentemente vigilante a tudo o que de relevante se passa na sua área. Isto dá-lhes a oportunidade de criar conteúdos novos à medida que as coisas vão acontecendo.

Por outro lado, a maioria do tempo estas equipas estão concentradas em criar ou adaptar conteúdos mais profundos, que serão publicados nas revistas, em papel.

Por razões de espaço estes conteúdos são muitas vezes cortados, e publicados apenas parcialmente nas revistas, não sendo completamente incomum um artigo com 3000 palavras acabar por ser reduzido a 2000 por razões de espaço disponível na revista.

Estes conteúdos reduzidos são muitas vezes os que vão parar ao site. Esta é, no entanto, a versão errada para colocar online. A versão a colocar online deveria ser a versão original. Por alguma razão o autor escreveu originalmente mais texto.

Mas, dizem-me, assim ninguém vai comprar a revista, uma vez que os conteúdos estão todos online, e ainda mais completos.

Sim, é verdade. A menos que estes conteúdos estejam disponíveis apenas para quem adquirir a revista.

Mas, deverão todos os conteúdos estar disponíveis apenas para as pessoas que comprem ou assinem a revista?

Na minha opinião não. Os sites têm tudo a ganhar se alguns dos conteúdos estiverem disponíveis a qualquer pessoa.

Por um lado se alguns dos conteúdos estiverem disponíveis para toda a gente, é provável que com o tempo mais pessoas descubram o site, e consequentemente a revista.

Por outro lado esse conteúdos vão ser indexados pelos motores de pesquisa, o que vai trazer novos utilizadores ao site, tornando com isso a revista conhecida para esses utilizadores e potenciando com isso a aquisição de novos clientes.

Mas, então, que conteúdos disponibilizar e que conteúdos guardar apenas para os clientes da revista em papel?

Bem, penso que a segmentação dos conteúdos se poderia fazer em três grupos.

O primeiro é que conteúdos disponibilizar a todos os visitantes do site no momento da criação. Bem, este tipo de redacções todos os dias cria algumas noticias, por vezes dezenas de pequenas noticias, que são pouco mais que citações de outras fontes. Estes conteúdos ocupam por norma menos de 10 a 15 minutos por artigo.

Estes conteúdos, devido ao seu reduzido custo, penso que poderiam ser disponibilizados imediatamente, até porque a maioria deles nunca irá ser publicada de qualquer das formas.

Restam com isto os artigos que implicam mais pesquisa, mais longos, mais elaborados, independentemente de virem a ser publicados na revista ou não. Na minha perspectiva estes conteúdos devem estar disponíveis apenas aos clientes da revista. Esta é a forma de incentivar a compra da revista, ou a sua assinatura.

Se os artigos são publicados na revista aparecem online apenas algum tempo depois de a revista estar nas bancas (ou ser enviada aos assinantes), se não forem publicados em papel ficariam disponíveis online imediatamente para todos os assinantes.

Mas, tanto num caso como noutro, deverão os artigos estar acessíveis apenas aos assinantes eternamente?

Penso que não. Penso que se poderão criar ainda dois intervalos de tempo distintos. Afinal de contas, depois de ser publicado um número de uma revista já ninguém mais vai comprar o número anterior, pelo que os conteúdos do mês anterior poderiam ser rentabilizados de outra forma, sem com isso afectar a venda da revista.

Como? Criando um sistema de assinatura online, em que os assinantes desta forma possam pagar para ter acesso a um artigo em particular, ou por um período de tempo (um dia, um mês, um ano?), a todos os conteúdos premium que tenham mais do que a idade de uma (ou duas) edição em papel (no caso da revista mensal, um mês – ou dois).

Assim, supondo que tenho interesse pela área da revista, mas não sou um profissional da área, pelo que não preciso de ler as reportagens no mês em que são escritas, apenas quero poder ir ler alguma informação da área de vez em quando, posso subscrever a assinatura online. Ou se sou estudante e quero aceder a uma reportagem especial que fizeram há alguns meses, posso aceder a ela desta forma, por um valor muito mais reduzido que o custo da assinatura da revista.

Mas, e ao fim de um ano, ou dois, esta informação ainda é relevante? Bem, historicamente tudo é importante. Mas será que ainda alguém vai pagar para aceder a conteúdos tão antigos? Provavelmente não.

Por isso, em determinada altura esses conteúdos podem ser libertados para serem acedidos de forma anónima, para que qualquer utilizador os possa ver. Desta forma promove-se a qualidade dos conteúdos da revista, permite-se aos motores de pesquisa indexar mais conteúdos do site, o que ajuda a dar mais relevância ao mesmo, e a fazer com que ele apareça em mais pesquisas relacionadas com a sua área de actividade.

E claro, colocar publicidade no site também ajuda, pois permite rentabilizar o tráfego de todos os artigos, mesmo daqueles que estão disponíveis para toda a gente.

Se o site tem pouco tráfego pode oferecer-se esse espaço aos anunciantes da edição em papel, mas sempre fazendo ver que é uma oferta, uma promoção, e não algo a que eles terão direito sempre que anunciarem na edição em papel, porque quando o site tiver mais tráfego poderemos querer vender esse espaço, e os nossos anunciantes habituais são os primeiros potências clientes da lista.

Mas, dizem vocês, isso é possível com os assinantes, mas e as revistas que são vendidas nas bancas, como permitimos que as pessoas tenham ainda assim acesso à versão estendida desses conteúdos?

Bem… eu tenho algumas ideias, e você? E têm alguma ideia melhor para rentabilizar este tipo de sites?


Estatísticas

Estatísticas Web – Novos dados

Published by:

Hoje, especialmente entre os bloggers, procuram-se novas informações ou utilizam-se de forma mais intensa informações que anteriormente eram quase ignoradas.

Nem sempre essas informações são obtidas exclusivamente através de dados de tráfego do site. Algumas dessas informações apenas se conseguem quando se cruza dados de tráfego com dados provenientes de outras fontes.

Entre os novos dados estatísticos que se encontram hoje na moda estão:

Long Tail

A Long Tail é levar um pouco mais longe uma informação que anteriormente já se considerava.

Trata-se das palavras utilizadas nos motores de pesquisa e que resultam em visitas ao site.

Anteriormente desta informação era apresentada apenas um top, entre 10 e 50 palavras (e/ou expressões) mais utilizadas. Hoje os webmasters e bloggers querem saber não apenas quais as mais utilizadas, mas todas as palavras que resultaram em visitas ao site.

EPM (Earnings per Thousand) ou CPM (Comission per Thousand)

O M em EPM ou CPM vem no numero mil em numeração romana (M). CPM pode também ser utilizada para significar Cost Per Thousand, o que faz sentido especialmente do ponto de vista do anúnciante, que é quem tem o dinheiro para anúnciar, e consequentemente a quem normalmente os termos se adequam.

Na prática este indicador permite ter uma ideia da rentabilidade do tráfego de um site.

Das muitas informações que se podem calcular acerca do tráfego se um site este é uma das poucas que apenas está disponível quando o site faz venda directa de espaço publicitário.

No mundo dos blogs, se esta informação fosse disponibilizada permitiria encontrar os nichos de mercado em que mais facilmente se rentabilizaria um blog. Claro que isso poderia acabar por criar um excesso de sites nesse nicho, e consequentemente criar mais espaço para anúncios que os anúncios existentes, baixando com isso o valor do nicho.

Algumas das redes de anúncios, como é o caso do Google Adsense, proíbem mesmo os seus associados de revelar este valor.

Earnings Per User ou Lucro por utilizador

Este indicador, tal como o E/CPM é indicativo da rentabilidade do tráfego, mas considera os utilizadores únicos do site ao invés dos pageviews.


na Web

Tem uma ideia

Published by:

Christine Kane era até há alguns momentos um nome desconhecido para mim. Trata-se de uma cantora/escritora de canções que tem também um blog, onde escreve sobre a sua musica, sobre o que a inspira e a forma como compõe.

Cheguei até ela de um dos vários blogs sobre marketing que leio (não perguntem qual, pois abri o link e só mais tarde o fui ler, como faço sempre, pelo que não sei bem qual é o referer).

Cheguei ao blog dela através de um post intitulado Are You hook-able?, que recomendo bastante a qualquer blogger, tal como vários outros artigos relacionados com esse.

Mas aquele que realmente me inspirou foi o post Getting Discovered, Getting Discouraged, and Getting a Clue..

O texto dela é inspirado e direcionado para músicos em prespectiva, pessoas que gostariam de ser cantores profissionais, escritores de canções, mas na realidade aplica-se a qualquer pessoa, em qualquer àrea de actividade.

Tem vários outros posts interessantes, é uma das novas adicções ao meu feed reader.


Estatísticas

Estatísticas Web – Recolha de Dados

Published by:

Antes de processar estatísticas é necessário recolher os dados relativos ao tráfego do site.

Existem vários tipos de dados e várias formas de obter esses dados.

Recolha de dados por inclusão

Uma das formas de recolher dados de tráfego mais utilizada entre os bloggers é através da inclusão de um código HTML em todas as páginas do site.

O código adicionado pode ser uma imagem ou um ficheiro javascript, ou mesmo um conjunto dos dois.

Nos casos em que é adicionada uma imagem esta é muitas vezes utilizada para mostrar um dos dados calculados a partir do tráfego (pageviews, unique Users, tamanho da long tail, depende de solução para solução, veremos detalhes de algumas delas mais à frente noutros posts), ou pode ser utilizada apenas para divulgar a solução utilizada.

Nos casos em que é utilizado um script javascript este pode ser utilizado para obter algumas informações adicionais acerca das condições de navegação do utilizador, que não são possíveis de recolher de outras formas. Alguns exemplos desta informação é a resolução do monitor ou os plugins que estão activos. Quase tudo o resto pode ser obtido por outras formas.

A grande vantagem das soluções de recolha de dados por inclusão é o software que faz a recolha trata tudo, sem ser necessário ter privilégios especiais no servidor onde o site está a correr. No caso dos blogs que estão nas principais plataformas grátis (blogger.com, blogs.sapo.pt, weblogs.pt, etc) esta é mesmo a única forma de se obter informação acerca do tráfego do site ou do blog.

A inclusão de código javascript em particular é a única forma de saber, por exemplo, que resolução têm os monitores dos utilizadores do site.

As desvantagens destas técnicas estão relacionadas com os utilizadores que não vêm imagens ou não correm javascript e os robots.

Com esta técnica os robots não correm os scripts javascript, pelo que não conseguimos saber quando é que o site é indexado, e mesmo quando se utilizam imagens os robots apenas a pedem um número muito restrito de vezes, e não sempre que pedem uma página onde elas apareçam.

O mesmo se passa com utilizadores que tenham as imagens ou o javascript desactivado ou que não suportem esse tipo de funcionalidades, como nos casos dos browsers de texto (como o links ou o lynx).

Recolha no servidor

A recolha de logs no servidor é uma das melhores soluções, e das mais simples de implementar quando se têm acesso às configurações do servidor.

A grande vantagem da recolha de dados no servidor é que todos os pedidos a que o servidor responde ficam registados nos ficheiros de logs, independentemente de serem feitos pelos robots dos motores de pesquisa, por browsers com suporte de imagens e javascript ou por browsers minimalistas, que apenas mostram texto.

Esta soluções, no entanto, nem sempre está disponível, como no caso em que o site se encontra numa das muitas plataformas de alojamento gratuito (ou nas ferramentas de blog grátis).

Recolha por sniffing

Uma terceira forma de recolher a informação de tráfego é sniffando essa informação da rede.

Esta é uma situação pouco comum, mas é bastante satisfatória quando existe uma grande quantidade de servidores, por vezes a correr em plataformas diferentes, mas em que todo o tráfego passa num ponto comum da rede, pois permite centralizar a recolha de logs, facilitando bastante a gestão dessa recolha, especialmente porque muitas vezes plataformas diferentes (IIS em Windows e Apache, por exemplo) produzem formatos de logs distintos, que são depois difíceis de comparar e analisar conjuntamente.

Conclusão

Estas três são as mais comuns formas de recolha de logs. Cada uma delas têm o seu próprio lugar, e pensar que uma delas é melhor ou pior é esquecer que na realidade cada uma delas se adapta mais facilmente a um determinado ambiente.

A forma como os dados são recolhidos depende do tipo de ambiente em que os sites a analisar se encontram, mas também da ferramenta de análise que se pretende utilizar. Algumas ferramentas incluem já o processo de recolha, normalmente por inclusão, outras dependem de formatos específicos de logs.

Nos próximos artigos ao analisar algumas das soluções de estatísticas mais conhecidas e utilizadas falarei sobre as formas de recolha de dados a utilizar para cada uma delas.


Em Destaque Estatísticas

Estatísticas Web

Published by:

Nos últimos tempos, e especialmente entre os bloggers, volta a falar-se de estatísticas.

Mas o tipo de informação que se procura extrair dos dados de tráfego de um site ou blog é cada vez mais extensa e mais diversa.

Até há pouco tempo atrás os webmasters procuravam saber tops diversos, o número de pageviews e unique Users (e nalguns casos de visitas) de um site, e pouco mais.

Hoje procura-se um pouco mais de informação, especialmente no que diz respeito aos referers, os URLs de onde vêm os novos utilizadores.

Mas as ferramentas não evoluíram de forma completa, então são muitas vezes utilizadas diversas aplicações no sentido de obter informação estatística diversa.

Fiquem a saber um pouco mais sobre estatísticas Web ao longo dos seguintes posts:

Estatísticas

Estatísticas – Unique Users

Published by:

O protocolo HTTP, e em consequência disso a Web, não pretende implementar sessões e identificação de utilizadores. Nas últimas versões do protocolo foram adicionadas funcionalidade que permitem, em determinadas condições, obter várias informações acerca dos utilizadores, mas ainda assim não é possível identificar um utilizador inequivocamente.

Em consequência disso, quando se contabilizam utilizadores únicos (Unique Users), recorre-se a vários métodos, que a seguir apresento.

IP + User Agent

O método de identificação de Unique Users que menos implicações tem é implementado através da utilização do IP do utilizador e do seu User Agent, e considera-se um utilizador único cada conjunto de IP e User Agent.

Este método tem vários problemas, nomeadamente, se vários utilizadores acedem à internet através da mesma ligação, com computadores configurados de forma idêntica, como muitas vezes acontece em ambientes empresariais, são contados como se de um único utilizador se tratasse.

Outra situação com idêntico problema é quando os pedidos de vários utilizadores passam por um mesmo proxy, sendo que neste caso o IP que chega ao site é o do proxy, e muitas vezes o próprio User Agent é o do proxy, e não o do browser do utilizador. Diversos pedidos para o mesmo URL, mesmo que feitos por utilizadores diferentes podem não chegar ao servidor e ser servidos de cache pelo proxy.

O problema oposto coloca-se quando um mesmo utilizador utiliza browsers diferentes, ou mesmo computadores diferentes. Idêntica situação ocorre quando o utilizador tem uma ligação à internet com IP dinâmico (o que representa a quase totalidade dos acessos à internet).

Nestas situações, o mesmo utilizador é contado múltiplas vezes, uma por cada par IP (publico)+Browser com que aceda ao site.

Cookies

Quando se utilizam cookies para identificar os utilizadores, sempre que um novo utilizador chega ao site è enviado um cookie ao browser, que depois o reenvia de volta em cada pedido que faz. Este cookie, normalmente, tem uma validade relativamente grande, por forma a permitir identificar os utilizadores ao longo de múltiplas sessões.

Mas também este sistema não é perfeito, pois existem várias situações em que um único utilizador é contabilizado várias vezes. Estes essas situações estão aquelas em que o utilizador apaga os cookies, em que utiliza browsers diferentes, ou mesmo computadores distintos, entre outras.

Noutros casos os utilizadores têm os browsers configurados por forma a não aceitarem cookies, e outras têm programas que impedem o envio dos cookies (normalmente firewalls).

Nesta situação contabiliza-se um Unique User por cada cookie diferente que se recebe.

Username

Alguns sites são privados, ou obrigam os seus utilizadores a registarem-se para conseguírem aceder a parte (ou ao todo) dos seus conteúdos.

Estes sites dispõem, provavelmente, da forma mais fiável de contabilizar os Unique Users, através do username utilizado.

Este sistema pode ainda ser distorcido, como nos casos em que o registo é grátis e o mesmo utilizador cria várias contas (porque um qualquer recurso que o site disponibiliza é limitado por utilizador, ou porque se esqueceu do username ou password originais, entre outras razões), ou nos casos em que o acesso é pago, e vários utilizadores partilham um acesso, reduzindo assim os seus (deles) custos.

Apesar disso, este é talvez o sistema mais fiável de contabilizar Unique Users, porque a maioria dos utilizadores vai autenticar-se com o mesmo username e password sempre que visitar o site, independentemente da forma como essa autenticação for feita.

Mas, nesse caso, porque não se utiliza sempre este sistema? Porque ele obriga a que os utilizadores estejam registados e que se autentiquem sempre que acedem ao site. É uma prática cada vez mais comum entre os grandes fornecedores de informação, como jornais, revistas ou sites noticiosos de grande dimensão, como o New York Times permitirem aceder aos seus arquivos apenas a utilizadores registados.

No entanto, na maioria das situações, os utilizadores não consideram aceitável registarem-se, especialmente se o site a que estão a aceder não lhes é ainda conhecido. Por isso outro métodos, são muito utilizadores, mesmo em sites onde existe a possibilidade de os utilizadores se registarem.

Conclusão

Estão são as três formas mais comuns de contabilizar utilizadores únicos. O terceiro métodos, do username de acesso, é pouco utilizado, especialmente porque os utilizadores gostam de acreditar que estão a aceder à internet de forma anónima, ainda que em muitos casos esse anonimato seja muito pouco mais que aparente (Como no caso dos dados da AOL, que referi recentemente).

Mas todos estes métodos de contabilizar Unique Users são falíveis, pelo que o valor deUnique Users deve sempre ser considerado como meramente indicativo.

A aplicação que se usa para calcular as estatísticas também tem influência nos resultados, e pode mesmo acrescer um novo conjunto de problemas ao problema apresentado, mas esses novos problemas não dizem já respeito apenas à contabilização dos Unique Users, mas a todo o processo estatístico, pelo que falaremos dele num post mais à frente.

Entretanto, têm estatísticas dos vossos blogs e sites? Que aplicações utilizam para as calcular?


Estatísticas

Estatísticas Web – Conceitos

Published by:

Este é o primeiro de uma série de artigos sobre estatísticas Web. Uma breve apresentação da série será publicada nos próximos dias, sendo que, por hoje, vos deixo apenas uma apresentação de alguns dos conceitos e medidas mais utilizadas.

  • PageView: Um pageview é o equivalente a uma página visualizada pelo utilizador. Este conceito tem algumas variantes, como sejam automated pageview (quando a página faz refresh automaticamente) e repeated pageview (quando o utilizador faz refresh no browser manualmente, ou quando volta à página por qualquer razão).
  • Hit: Um hit é um request feito pelo browser. Imagens, ficheiros javascript, CSS, flash, e mesmo frames HTML, todos são considerados hits, mas apenas o pedido inicial é considerado para contagem de pageviews.
  • Unique User: Idealmente um Unique User corresponde a um utilizador único, a uma pessoa. Mas o mundo real está longe de ser um mundo ideal, e por isso este valor raramente coincide com o número de utilizadores únicos reais de um site. Existem várias formas de contabilizar este indicador, cada uma delas com as suas vantagens e desvantagens, pelo que voltaremos a este tópico nos próximos dias.
  • Visit: Uma visita é um conjunto de pageviews efectuados por um unique user, separados entre si por intervalos de tempo inferiores a um valor pré-definido (normalmente 30 minutos).
  • Referer ou Referrer: o referer(em inglês o correcto é referrer, mas referer é bastante mais utilizado) de uma página é o URL onde o utilizador se encontrava antes de vir para o nosso site. Os referers, normalmente, são listagens de pesquisas ou páginas com links para o nosso site. Por norma os referers internos (no próprio site não são considerados, mas podem conter informação muito interessante. Mais uma vez voltaremos aqui mais tarde).
  • Cookie: um cookie é um pequeno pacote de informação, que é enviado para o servidor sempre que são feitos pedidos. Pode ser utilizado para diversas finalidades, sendo a mais comum o controlo de sessões.
  • User Agent: cada browser, bem como a maioria dos robots e crawlers, tem uma assinatura própria, que enviam ao servidor sempre que trazem um pedido. A expressãoUser Agent é utilizada para significar o browser utilizado e a assinatura, sendo que, normalmente, a assinatura é o nome do browser.
  • Robot e Crawler: Chama-se Robot a qualquer programa que faça de forma automática, independentemente da finalidade, pedidos de URL’s. Os robots mais comuns são os que indexam os sites para os motores de pesquisa. A este grupo de robots chama-se Crawler. Outro tipos de robots são, por exemplo, programas que copiam sites completos, independentemente da finalidade dessa cópia (com sorte apenas para leitura off-line, sem acesso à internet), programas de monitorização, entre muitos outros. Na maioria dos casos estes programas são identificados pelo User Agent (neste caso a sua assinatura). A razão porque estes User Agents são referidos é porque, uma vez que eles não representam utilizadores reais, não são considerados quando se contabilizamPageViews ou Unique Users.
SEO

Long Tail

Published by:

Recentemente assistiu-se a um fenómeno interessante em vários blogs portugueses. Esse fenómeno, a que chamarei fenómeno cantora convenientemente vestida fez-me pensar sobre long tail.

Uma long tail normalmente inclui palavras menos populares numa àrea, mas ainda assim relacionadas com essa área.

Com o fenómeno referido blogs essencialmente focados em tecnologia publicaram um post sobre o site da não referida senhora e repentinamente viram o seu tráfego sofrer picos logarítmicos, nalguns casos a passar de centenas de pageviews por dia para as centenas de milhar.

Entretanto houve mesmo quem se aventurasse a ir um pouco mais longe e fazer mesmo alguns testes, incluindo referência várias relacionadas com sexualidade, incluindo as conhecidas drageias azuis.

Se, por um lado, as referências originais foram consequência de uma simples referência a um site, nos testes seguintes tratou-se mesmo de verificar até que ponto se chegaria com as keywords mais usuais.

Antes que perguntem, não vejo problema nenhum nestas práticas, que não seja a dispersão do tipo de utilizadores do site.

Um site focado em tecnologia, normalmente é rentabilizado indirectamente e, por vezes, directamente.

A rentabilidade indirecta que um blogger obtém ao escrever sobre a sua área é a divulgação do seu nome junto dos seus pares e dos seus potenciais clientes ou entidades patronais (outro tipo de cliente).

Nalguns casos o blogger tenta também rentabilizar o blog colocando anúncios sob as mais diversas formas. É aos “lucros” resultantes destes anúncios que chamo de rentabilidade directa.

Mas, então, o que acontece quando um blog se vê repentinamente inundado por utilizadores que não têm interesse na sua área principal?

Para começar o blog tem uma quantidade de tráfego de visitantes com interesse no post um pouco (ou muito) fora do contexto, que podem até percorrer o blog, mas que vão acabar por esquecê-lo, porque este não se dedica regularmente aos temas do seu interesse.

Hoje esse tráfego extra não tem na maioria das situações um custo inerente (para o blogger, pelo menos), e quando o tem é relativamente reduzido. Nos casos em que o blog é rentabilizado directamente esse tráfego extra traduz-se por vezes num rendimento extra, consequência do aumento de visualizações ou clicks nos banners.

Mas é nestas situações, em que o aumento de tráfego se traduz em aumento de receitas que o perigo espreita.

Por vezes o blogger pode sentir-se tentado a trocar a sua forma tradicional de escrever (que por vezes foi o que tornou o seu blog conhecido e que, em última instância, fez com que as keywords erradas num dos seus posts o transformem no post mais lido de sempre) por artigos semeados de keywords nada relacionadas com o blog.

Com isso um blog com uma lista de keywords bastante relacionadas com a sua área torna-se num blog com uma long tail quase infinita, mas que não permite definir o perfil dos seus utilizadores.

Mas quando um blog perde o foco, perde também uma outra propriedade, a linkabilidade. Chamo linkabilidade à aptidão de um blog de obter links de outros blogs.

Um blogger que se foque num tema ou numa área vai pensar duas vezes em criar um link para outro blog que regularmente cria posts cheios de keywords, especialmente se essas keywords nada têm a ver com a área principal desse blog.

Existe ainda um outro risco, este relacionado com os cada vez mais eficientes algoritmos de indexação dos motores de pesquisa. Enquanto o racio entre os posts reais e as experiências sobrecarregadas de keywords se mantiver elevado o blog continuará a ser indexado, mas se esse rácio baixar muito o blog corre o risco de ser considerado spammer e banido dos motores de pesquisa ou, no mínimo, começar a ser penalizado.

E os motores de pesquisa estão à espreita e a cada dia que passa melhoram os seus algoritmos para eliminar dos seus índices URLs e sites que se dediquem a criar spam de keywords, nome porque esta prática é conhecida.

E esta também é uma razão para que blogs que não aderem a este tipo de práticas não apontem para sites que o fazem, pois os algoritmos dos motores de pesquisa têm, já hoje, uma componente de spamrank, em que o rank de spam que for atribuído a um site se propaga a todos os sites com links para ele, baixando com isso a posição dos sites com links para os spammers.

Acho, no entanto, que é importante fazer experiências, pois á a única forma de perceber realmente como as coisas funcionam. Mas fazê-lo num blog com um tráfego e uma audiência que interessa manter é perigoso.

E este blog vai ficar realmente com uma long tail, mas é uma cauda que nem é composta de penas, nem coberta de pelos, nem de escamas… é apenas um amontoado de detritos que traz um pouco de tudo ao blog, mas muito poucos visitantes estarão interessados no que tenhamos para vender.

Criar uma long tail é realmente importante. Mas é preciso que ela seja relacionada com a área do site ou do blog, que ela traga mais utilizadores interessados, e não tráfego apenas. É uma vez mais uma questão de se colocar a qualidade antes da quantidade.

Ou será que o importante é o contrário?


Programação

PpW – XSS nos CSSs

Published by:

Já vos falei neste site de XSS por duas vezes, mas ainda existe uma terceira opção, em que eu próprio não tinha pensado. Não é muito mau, uma vez que apenas funciona em sites que permitam alterar os CSSs ou introduzir tags <STYLE> nos campos, e é exploitable apenas em Internet Explorer…

Bem. Não deixei este post para depois porque me lembrei imediatamente de um grande site onde isto poderia ser utilizado de forma grandiosa. Não, não vou dizer qual é o site, mas trata-se de um site de social networking. De um dos maiores.

Mas voltemos um pouco atrás, aos detalhes.

O referido exploit utiliza a funcionalidade url(“url”) que pode ser utilizado em várias propriedades dos CSSs, nomeadamente background, background-image, list-style-image, entre outros. Um pequeno teste para verificar a possibilidade de efectuar o exploit seria simplesmente:


<style>
li {
list-style-image: url("javascript:alert('XSS')");
}
</style>
<ul><li>Teste</li></ul>

Assim existe agora mais um forma de injectar javascript, sem conseguir adicionar tags de <script>.

Do ponto de vista da criação de sites aparece assim mais uma preocupação, que passa por verificar com cuidado em que consições se permite aos utilizadores alterar as CSSs dos sites, sendo isto especialmente relevante em sites de comunidades, em que cada utilizador pode costumizar o seu próprio perfil.

Aparentemente o exploit apresentado apenas funciona em Internet Explorer, mas é bastante recente, poderá funcionar noutros browsers.