<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Encurtadores de URL: Uma Disputa Estratégica pela Web de Tempo Real</title>
	<atom:link href="http://webholic.com.br/2009/12/15/encurtadores-de-url-uma-disputa-estrategica-pela-web-de-tempo-real/feed/" rel="self" type="application/rss+xml" />
	<link>http://webholic.com.br/2009/12/15/encurtadores-de-url-uma-disputa-estrategica-pela-web-de-tempo-real/</link>
	<description>Tendências, Apps, Startups, Social Media, venture capital, tudo que um geek precisa saber sobre a Web!</description>
	<lastBuildDate>Wed, 08 Feb 2012 22:31:24 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: Socorra.me! A Queda do Migre.me e os Riscos dos Encurtadores de URL&#160;&#124;&#160;Diego Roriz</title>
		<link>http://webholic.com.br/2009/12/15/encurtadores-de-url-uma-disputa-estrategica-pela-web-de-tempo-real/#comment-1410</link>
		<dc:creator>Socorra.me! A Queda do Migre.me e os Riscos dos Encurtadores de URL&#160;&#124;&#160;Diego Roriz</dc:creator>
		<pubDate>Fri, 03 Sep 2010 13:40:15 +0000</pubDate>
		<guid isPermaLink="false">http://webholic.com.br/?p=2481#comment-1410</guid>
		<description>[...] Permitem com facilidade medir performance em tempo real: Portanto, eles sempre vão ser uma boa pedida para quem quiser medir o retorno de um link enviado por email ou mesmo pelo Twitter. Serviços como o Bit.ly estão investindo pesado nesta estratégia. [...]</description>
		<content:encoded><![CDATA[<p>[...] Permitem com facilidade medir performance em tempo real: Portanto, eles sempre vão ser uma boa pedida para quem quiser medir o retorno de um link enviado por email ou mesmo pelo Twitter. Serviços como o Bit.ly estão investindo pesado nesta estratégia. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Carlos Ribeiro</title>
		<link>http://webholic.com.br/2009/12/15/encurtadores-de-url-uma-disputa-estrategica-pela-web-de-tempo-real/#comment-1409</link>
		<dc:creator>Carlos Ribeiro</dc:creator>
		<pubDate>Wed, 16 Dec 2009 01:33:02 +0000</pubDate>
		<guid isPermaLink="false">http://webholic.com.br/?p=2481#comment-1409</guid>
		<description>Diego, encurtadores tem várias desvantagens, pois realmente podem induzir latência e esconder conteúdo ilícito ou perigoso. Mas isso são desvantagens pontuais, para o usuário, que são compensadas pela vantagem estratégica para o dono do encurtador.

 A grande vantagem do encurtador é permitir monitorar cliques em conteúdo de terceiro, sem hospedar o conteúdo e sem modificar nenhuma página. A única pessoa que sabe quem clica em uma URL na Web tradicional é o dono do site. Mas com o encurtador, é possível monitorar este tráfego. Assim o interesse em ter seu próprio encurtador é duplo:

1) interceptar referências a páginas arbitrárias em serviços de terceiros (Twitter, MSN, Skype, etc.);
2) evitar que um serviço de terceiro intercepte o seu tráfego.

Veja que um serviço de encurtador tem acesso a praticamente a mesma informação que aparece para um serviço como o Google Analytics. Ele recebe todos os headers: de onde o cliente veio, IP, etc., em tempo real. A informação é valiosa demais para ficar na mão de outros. Por isso todo mundo quer ter o seu.</description>
		<content:encoded><![CDATA[<p>Diego, encurtadores tem várias desvantagens, pois realmente podem induzir latência e esconder conteúdo ilícito ou perigoso. Mas isso são desvantagens pontuais, para o usuário, que são compensadas pela vantagem estratégica para o dono do encurtador.</p>
<p> A grande vantagem do encurtador é permitir monitorar cliques em conteúdo de terceiro, sem hospedar o conteúdo e sem modificar nenhuma página. A única pessoa que sabe quem clica em uma URL na Web tradicional é o dono do site. Mas com o encurtador, é possível monitorar este tráfego. Assim o interesse em ter seu próprio encurtador é duplo:</p>
<p>1) interceptar referências a páginas arbitrárias em serviços de terceiros (Twitter, MSN, Skype, etc.);<br />
2) evitar que um serviço de terceiro intercepte o seu tráfego.</p>
<p>Veja que um serviço de encurtador tem acesso a praticamente a mesma informação que aparece para um serviço como o Google Analytics. Ele recebe todos os headers: de onde o cliente veio, IP, etc., em tempo real. A informação é valiosa demais para ficar na mão de outros. Por isso todo mundo quer ter o seu.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Carlos Ribeiro</title>
		<link>http://webholic.com.br/2009/12/15/encurtadores-de-url-uma-disputa-estrategica-pela-web-de-tempo-real/#comment-1412</link>
		<dc:creator>Carlos Ribeiro</dc:creator>
		<pubDate>Wed, 16 Dec 2009 01:33:00 +0000</pubDate>
		<guid isPermaLink="false">http://webholic.com.br/?p=2481#comment-1412</guid>
		<description>Diego, encurtadores tem várias desvantagens, pois realmente podem induzir latência e esconder conteúdo ilícito ou perigoso. Mas isso são desvantagens pontuais, para o usuário, que são compensadas pela vantagem estratégica para o dono do encurtador.

 A grande vantagem do encurtador é permitir monitorar cliques em conteúdo de terceiro, sem hospedar o conteúdo e sem modificar nenhuma página. A única pessoa que sabe quem clica em uma URL na Web tradicional é o dono do site. Mas com o encurtador, é possível monitorar este tráfego. Assim o interesse em ter seu próprio encurtador é duplo:

1) interceptar referências a páginas arbitrárias em serviços de terceiros (Twitter, MSN, Skype, etc.);
2) evitar que um serviço de terceiro intercepte o seu tráfego.

Veja que um serviço de encurtador tem acesso a praticamente a mesma informação que aparece para um serviço como o Google Analytics. Ele recebe todos os headers: de onde o cliente veio, IP, etc., em tempo real. A informação é valiosa demais para ficar na mão de outros. Por isso todo mundo quer ter o seu.</description>
		<content:encoded><![CDATA[<p>Diego, encurtadores tem várias desvantagens, pois realmente podem induzir latência e esconder conteúdo ilícito ou perigoso. Mas isso são desvantagens pontuais, para o usuário, que são compensadas pela vantagem estratégica para o dono do encurtador.</p>
<p> A grande vantagem do encurtador é permitir monitorar cliques em conteúdo de terceiro, sem hospedar o conteúdo e sem modificar nenhuma página. A única pessoa que sabe quem clica em uma URL na Web tradicional é o dono do site. Mas com o encurtador, é possível monitorar este tráfego. Assim o interesse em ter seu próprio encurtador é duplo:</p>
<p>1) interceptar referências a páginas arbitrárias em serviços de terceiros (Twitter, MSN, Skype, etc.);<br />
2) evitar que um serviço de terceiro intercepte o seu tráfego.</p>
<p>Veja que um serviço de encurtador tem acesso a praticamente a mesma informação que aparece para um serviço como o Google Analytics. Ele recebe todos os headers: de onde o cliente veio, IP, etc., em tempo real. A informação é valiosa demais para ficar na mão de outros. Por isso todo mundo quer ter o seu.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Diego Sana</title>
		<link>http://webholic.com.br/2009/12/15/encurtadores-de-url-uma-disputa-estrategica-pela-web-de-tempo-real/#comment-1408</link>
		<dc:creator>Diego Sana</dc:creator>
		<pubDate>Tue, 15 Dec 2009 18:49:51 +0000</pubDate>
		<guid isPermaLink="false">http://webholic.com.br/?p=2481#comment-1408</guid>
		<description>Discordo completamente. Os encurtadores só atrasam o desenvolvimento da web. Pras poucas aplicações que fazem mining de real valor da &quot;web em tempo real&quot;, como o tweetmeme, ou o buzzvolume, ou o collecta (e outros sistemas de busca similares), as urls curtas são apenas um ponto de latência extra e consumo desnecessário de recursos, já que as informações que realmente interessam estão nas urls destino. Os encurtadores são só um meio, e desnecessário por sinal. O twitter poderia muito bem, ao invés de usar encurtadores, incluir as urls como metadados nos tweets (deixando os links curtos apenas pra clientes sms). Quem já usou a API deles sabe que a cada tweet de 140chars retornado via json vêm associados vários outros dados e metadados que ocupam pelo menos 10 vezes mais espaço.</description>
		<content:encoded><![CDATA[<p>Discordo completamente. Os encurtadores só atrasam o desenvolvimento da web. Pras poucas aplicações que fazem mining de real valor da &#8220;web em tempo real&#8221;, como o tweetmeme, ou o buzzvolume, ou o collecta (e outros sistemas de busca similares), as urls curtas são apenas um ponto de latência extra e consumo desnecessário de recursos, já que as informações que realmente interessam estão nas urls destino. Os encurtadores são só um meio, e desnecessário por sinal. O twitter poderia muito bem, ao invés de usar encurtadores, incluir as urls como metadados nos tweets (deixando os links curtos apenas pra clientes sms). Quem já usou a API deles sabe que a cada tweet de 140chars retornado via json vêm associados vários outros dados e metadados que ocupam pelo menos 10 vezes mais espaço.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Diego Sana</title>
		<link>http://webholic.com.br/2009/12/15/encurtadores-de-url-uma-disputa-estrategica-pela-web-de-tempo-real/#comment-1411</link>
		<dc:creator>Diego Sana</dc:creator>
		<pubDate>Tue, 15 Dec 2009 18:49:00 +0000</pubDate>
		<guid isPermaLink="false">http://webholic.com.br/?p=2481#comment-1411</guid>
		<description>Discordo completamente. Os encurtadores só atrasam o desenvolvimento da web. Pras poucas aplicações que fazem mining de real valor da &quot;web em tempo real&quot;, como o tweetmeme, ou o buzzvolume, ou o collecta (e outros sistemas de busca similares), as urls curtas são apenas um ponto de latência extra e consumo desnecessário de recursos, já que as informações que realmente interessam estão nas urls destino. Os encurtadores são só um meio, e desnecessário por sinal. O twitter poderia muito bem, ao invés de usar encurtadores, incluir as urls como metadados nos tweets (deixando os links curtos apenas pra clientes sms). Quem já usou a API deles sabe que a cada tweet de 140chars retornado via json vêm associados vários outros dados e metadados que ocupam pelo menos 10 vezes mais espaço.</description>
		<content:encoded><![CDATA[<p>Discordo completamente. Os encurtadores só atrasam o desenvolvimento da web. Pras poucas aplicações que fazem mining de real valor da &#8220;web em tempo real&#8221;, como o tweetmeme, ou o buzzvolume, ou o collecta (e outros sistemas de busca similares), as urls curtas são apenas um ponto de latência extra e consumo desnecessário de recursos, já que as informações que realmente interessam estão nas urls destino. Os encurtadores são só um meio, e desnecessário por sinal. O twitter poderia muito bem, ao invés de usar encurtadores, incluir as urls como metadados nos tweets (deixando os links curtos apenas pra clientes sms). Quem já usou a API deles sabe que a cada tweet de 140chars retornado via json vêm associados vários outros dados e metadados que ocupam pelo menos 10 vezes mais espaço.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Por que o Google e Facebook entraram no mercado de encurtadores de links</title>
		<link>http://webholic.com.br/2009/12/15/encurtadores-de-url-uma-disputa-estrategica-pela-web-de-tempo-real/#comment-1407</link>
		<dc:creator>Por que o Google e Facebook entraram no mercado de encurtadores de links</dc:creator>
		<pubDate>Tue, 15 Dec 2009 17:13:34 +0000</pubDate>
		<guid isPermaLink="false">http://webholic.com.br/?p=2481#comment-1407</guid>
		<description>[...] Ribeiro do ReadWriteWeb Brasil examina o mercado atual de diminuidores de URLs: As URLs encurtadas representam para a busca em tempo real [...]</description>
		<content:encoded><![CDATA[<p>[...] Ribeiro do ReadWriteWeb Brasil examina o mercado atual de diminuidores de URLs: As URLs encurtadas representam para a busca em tempo real [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

