Clara Rivera


En la línea de la entrada de Eduardo Manchón con consejos para mejorar la interfaz de un archivo KML, Pamela Fox sugería en el blog del API de Maps que, además de dominar el código y la programación, podríamos plantearnos como propósito de año nuevo intentar mejorar la experiencia de los usuarios haciendo nuestros mashups más fáciles de usar. Por esta razón, compartía con los lectores las diapositivas que utilizó en una charla en el ...
Clara Rivera


En la línea de la entrada de Eduardo Manchón con consejos para mejorar la interfaz de un archivo KML, Pamela Fox sugería en el blog del API de Maps que, además de dominar el código y la programación, podríamos plantearnos como propósito de año nuevo intentar mejorar la experiencia de los usuarios haciendo nuestros mashups más fáciles de usar. Por esta razón, compartía con los lectores las diapositivas que utilizó en una charla en el Silicon Valley Web Builder Bar Camp en otoño e incluía el link al vídeo en YouTube.

Me pareció una presentación muy buena, así que hablando con Pamela decidimos incluirla también en nuestro blog, y esta vez en español. Se trata de una presentación breve así que, como ella misma sugiere, si os parece importante añadir algo o tenéis sugerencias, no dudéis en hacérnoslas llegar bien por email o en los comentarios a esta entrada. Por cierto, también podéis ver la presentación a mayor tamaño.


Raúl Benito

En la entrada anterior de esta serie veíamos cómo desarrollar un widget en opensocial y probarlo. El único problema es que el proceso era engorroso y que teníamos que seguir varios pasos desde que se nos ocurría un cambio y lo veíamos ejecutar (lo que no predispone mucho a la experimentación). Pero los chicos de OpenSocial han pensado en eso y han desarrollado un widget que realmente es un pequeño entorno de desarrollo en OpenSocial al estilo de lo que widgetcreator es para iGoogle.

Raúl Benito

En la entrada anterior de esta serie veíamos cómo desarrollar un widget en opensocial y probarlo. El único problema es que el proceso era engorroso y que teníamos que seguir varios pasos desde que se nos ocurría un cambio y lo veíamos ejecutar (lo que no predispone mucho a la experimentación). Pero los chicos de OpenSocial han pensado en eso y han desarrollado un widget que realmente es un pequeño entorno de desarrollo en OpenSocial al estilo de lo que widgetcreator es para iGoogle.


La aplicación se encuentra en esta url, la añadimos a nuestra cuenta del sandbox de Google como vimos con la lista de amigos, y ya podemos empezar a experimentar.



El aspecto de la aplicación es más o menos unas pestañas, una pequeña explicación y luego unos campos de texto con un código de ejemplo, con un botón de ejecución que al pulsarlo ejecuta el campo de texto y presenta la salida en la misma página en negro. Guapo, ¿no?



Las pestañas simplemente separan los distintos conceptos que maneja OpenSocial:


People – Obtención de informacion de personas y amigos.

Data – Almacenamiento e información sobre el usuario de la aplicación.

Activities – Para añadir y obtener actividades al usuario de la aplicación (del tipo Raul le ha metido el dedo en el ojo a Javier).

Editor – Simplemente un sitio donde escribir y ejecutar sin mucha molestia código OpenSocial en Orkut.


Bueno, pues nada más por hoy. Instaladla y jugad con ella porque es realmente facil, y si hacéis algo interesante no olvidéis que podéis enviárnoslo.


Javier Arias

Hace unos días nos llegó a nuestra dirección de correo ( programacongoogle@google.com) la primera aplicación desarrollada por uno de nuestros lectores usando el API de Android. Me pareció muy adecuado que el primer comentario en este blog sobre una aplicación desarrollada con esta API fuese el particular "Hello World" de uno de nuestros lectores.
Javier Arias

Hace unos días nos llegó a nuestra dirección de correo (programacongoogle@google.com) la primera aplicación desarrollada por uno de nuestros lectores usando el API de Android. Me pareció muy adecuado que el primer comentario en este blog sobre una aplicación desarrollada con esta API fuese el particular "Hello World" de uno de nuestros lectores.

Carlos Fernández ha desarrollado una aplicación que permite leer y escribir notas de Meneame en un terminal que soporte Android. Una aplicación en su "version 0.00001" desarrollada "para empezar a jugar con el SDK y familiarizarme con los Activity, Intent, etc., etc.". Lo ha publicado en su blog donde también podréis encontrar el código fuente de la aplicación.


En este caso no estamos ante una aplicación desarrollada desde cero, Carlos ha tomado un midlet que ya tenía desarrollado y lo ha portado a Android. Esta aproximación me parece interesante ya que opino que una buena parte de las primeras aplicaciones que podremos ver en dispositivos que soporten Android serán precisamente aplicaciones portadas.

Son estos ejercicios de portado los que os darán las primeras impresiones en tres aspectos funcamentales de este nuevo entorno: el soporte de librerías estándar, fundamental para minimizar los cambios en la capa de lógica; la adaptación que será necesaria en el user interface, seguramente donde más esfuerzo se ha de concentrar; y las particularidades del dispositivo, como reaccionará nuestra aplicación ante una llamada entrante, señal de baja batería, etc.

Después de esta primera aproximación a Android me he quedado con ganas de más. Me pregunto qué seréis capaces de desarrollar usando el paquete android.location, la clase android.provider.Contacts o sacándole todo el provecho a sus capacidades gráficas. Animaos y enviadnos vuestra aplicación a programacongoogle@google.com para que la podamos comentar en este espacio. Como dice Carlos: "En definitiva, creo que es bastante divertido el Android… ". ¡A cuidarse!

Joaquín Cuenca

Ya hemos hablado de la importancia de la latencia en el tiempo de descarga de las páginas web. Reducir el número de "three-way handshakes" activando KeepAlives, el número de ficheros a descargar, paralelizarlos sobre un máximo de 4 dominios, etc., son consejos importantes para reducir el impacto de la latencia, pero hay algo que sobrepasa a cualquier otra técnica para reducir el tiempo de espera cuando queremos usar un recurso (imagen, hoja de estilo, javascript, etc.), y es no mandarle nada al navegador, siempre que éste tenga en caché una copia del recurso en cuestión.

Joaquín Cuenca

Ya hemos hablado de la importancia de la latencia en el tiempo de descarga de las páginas web. Reducir el número de "three-way handshakes" activando KeepAlives, el número de ficheros a descargar, paralelizarlos sobre un máximo de 4 dominios, etc., son consejos importantes para reducir el impacto de la latencia, pero hay algo que sobrepasa a cualquier otra técnica para reducir el tiempo de espera cuando queremos usar un recurso (imagen, hoja de estilo, javascript, etc.), y es no mandarle nada al navegador, siempre que éste tenga en caché una copia del recurso en cuestión.


El navegador divide los recursos que tiene en su caché en dos tipos, los "frescos" y los "dudosos". Los recursos frescos pueden usarse sin preguntarle nada al servidor. Los recursos dudosos se pueden usar, pero antes hay que preguntarle al servidor que nos lo envió si sigue siendo válido, o si hay que tirarlo a la basura y usar una nueva versión que el servidor le mandará al navegador.


¿Cómo controlar si un recurso entra en la caché, y si lo hace, el tiempo que permanece fresco? Con las cabeceras Cache-Control o Expires. La cabecera Expires contiene una fecha a partir de la cual el recurso debe ser considerado como dudoso. Si la fecha está en el pasado, o si no es una fecha (como "0"), se considerará inmediatamente al recurso como dudoso. La cabecera Cache-Control ofrece muchas más opciones, permitiendo por ejemplo especificar si un proxy que se encuentre entre el usuario y el servidor puede guardar el recurso en caché o si sólo el navegador puede hacerlo. Podéis leer la especificación para ver todas las subopciones de Cache-Control, siendo una de las más importantes max-age, que especifica durante cuántos segundos se tiene que considerar el recurso como fresco. Si se usa Cache-Control, toma prioridad sobre Expires. Recordemos que si un recurso es fresco, el navegador lo usa directamente sin decirle nada al servidor. Más rápido imposible.


Si el recurso es dudoso, ¿cómo puede el navegador comprobar si ha cambiado en el servidor o no? La pregunta, en prácticamente todos los casos, es completamente irrelevante. Es mejor que vuestros recursos siempre se mantengan frescos, poniendo un Expires o un Cache-Control max-age de muchos años. O están en la caché y pueden usarse directamente, o no están y hay que pedírselos al servidor.


¿Por qué muchas páginas los dejan pasar al estado "dudoso" (poniendo pequeños tiempos de expiración)? Porque quieren que si cambian el recurso, el navegador se baje la nueva versión. Esto es extremadamente problemático, porque en la práctica es imposible predecir cuándo se va a cambiar un recurso, así que no le podemos decir al navegador hasta cuándo lo puede mantener fresco, o nos arriesgamos a que el navegador use una versión antigua de algunas de nuestras imágenes, páginas de estilo, javascript, etc.


Tenemos tres alternativas para atacar este problema:


  1. Ignorarlo. Es lo que hacen todos los que ponen un tiempo corto en Expires. Es incorrecto porque el cliente puede ver una nueva versión de nuestra página web con una mezcla de recursos antiguos y nuevos. Es ineficiente, porque hace que el cliente le haga una petición al servidor para comprobar la validez del recurso una vez caduca, requiriendo un mínimo de una ida y vuelta al servidor, y más típicamente dos idas y vueltas (ver el artículo anterior sobre la importancia de la latencia)
  2. Poner el Expires a 0. Es correcto, ya que el cliente siempre ve la última versión del recurso. Es ineficiente, ya que siempre es necesario comprobar la validez del recurso.
  3. Nunca cambiar un recurso. Más específicamente, cuando quieras crear una versión nueva de un recurso, no le des el mismo nombre que otro recurso ya existente en tu página web. Es correcto, ya que la versión en la caché y en el servidor de un recurso siempre es la misma. Es eficiente, ya que si se sigue usando ese recurso y está en la caché, el navegador nunca le pregunta al servidor.


La última opción es obviamente la ideal, y la que más trabajo necesita por parte del desarrollador, ergo es la opción menos usada. En realidad no es tan difícil de implementar. En lugar de poner en el HTML enlaces como "imagen.png", pondremos un enlace llamado "imagen.png?v=1". El servidor evidentemente ignorará el "?v=1", pero el navegador eso no lo sabe. Cuando actualicemos "imagen.png", cambiamos el número de versión, y en el HTML ponemos "imagen.png?v=2". Así pues, en el mismo instante en que tengamos una versión nueva de "imagen.png" el navegador tendrá que pedírsela al servidor (él no tiene en su caché nada sobre "imagen.png?v=2"). Si queremos aumentar la legibilidad, o evitar que algún proxy no cachée nuestra imagen por usar un ? en la URL, podemos escribir imagen.v2.png, y eliminar el .v2 con mod_rewrite en Apache. Con un poco de esfuerzo, todo el proceso puede automatizarse. En Panoramio por ejemplo tenemos una tabla con el MD5 de todos los recursos estáticos qué usamos, y su número de versión (excepto para las imágenes que suben los usuarios). Cuando subimos una nueva versión de Panoramio, un script comprueba el MD5 de todos los recursos, y si este cambia, aumentamos su número de versión. Todas las URLs a nuestros recursos las generamos a través de una función que le añade a la URL el número de versión que hemos calculado anteriormente. Todo esto se basa en que nuestro HTML no debe de estar cacheado, o los clientes puede recibir una versión antigua del HTML con una versión nueva de algunos recursos.


Si teneis algún recurso para el que este tipo de solución no es práctica, entonces tendréis que dejar que vuestros recursos pasen al estado dudoso (o no cachearlo en absoluto). Para comprobar si un recurso sigue siendo válido, el navegador le pregunta al servidor si ese recurso ha cambiado desde que se metió en la caché, usando la cabecera If-Modified-Since. Si no ha cambiado, el servidor responde con HTTP/304 Not Modified, y si ha cambiado responde enviando el nuevo contenido.


Si nuestro recurso no tiene una fecha de modificación clara (por ejemplo, si se ha generado dinámicamente), este método de verificación no nos servirá. Si ese es nuestro caso, al enviar el recurso la primera vez tendremos que añadir la cabecera ETag, que contendrá un identificador único que deberá cambiar cuando cambie el recurso. Los ETag que tanto Apache como IIS generan no dependen exclusivamente del contenido del fichero, si no que también dependen de datos específicos del servidor (por ejemplo, el inode donde se encuentra el fichero). Si usamos varios servidores, este ETag será inutilizable. En la práctica hay muy pocas razones para usar un ETag, siendo la validación por fecha suficiente en la mayoría de los casos.


En el anterior artículo de esta serie preguntasteis por herramientas para poder medir el tiempo de descarga de páginas web. Una formidable es Fiddler, aunque sólo disponible para Windows. Específicamente para Firefox tenemos firebug, sin duda el plugin de desarrollo más útil que existe para Firefox, y que incluye un panel donde podemos ver el tiempo que tarda cada petición al servidor, pero ¡cuidado al interpretar los resultados!, firebug muestra cuando las peticiones entran en la cola de peticiones de Firefox, no cuando se despacha la petición realmente al servidor. El autor de Fiddler tiene un artículo donde habla también sobre el rendimiento de páginas web, y donde explica con algo más de detalle las diferentes cabeceras involucradas en todo el proceso de cacheo.


Queda bastante que hablar de este tema, sobre la compresión de los recursos en el servidor, y sobre todo de los distintos bugs en servidores y clientes que le ponen un poco de pimienta a la vida, pero ya es tarde. ¡Hasta la próxima!

Jesse Shieh

No hace mucho, en un viaje a Shanghai, hice un montón de fotos increíbles para mis amigos y familia. Cuando entré en mi iGoogle y vi el tema que había seleccionado, de repente quise poder crear mi propio tema con las fotos de Shanghai. ¿Acaso no sería esta una forma genial de personalizar aún más mi iGoogle? Resulta que muchos de vosotros habéis estado pidiéndonos esto también durante algún tiempo, así que os hemos escuchado. Estoy encantado de anunciar que, después de haber lanzado el API de temas para iGoogle hoy, ya podemos empezar todos a crear y compartir nuestros propios temas.
Jesse Shieh

No hace mucho, en un viaje a Shanghai, hice un montón de fotos increíbles para mis amigos y familia. Cuando entré en mi iGoogle y vi el tema que había seleccionado, de repente quise poder crear mi propio tema con las fotos de Shanghai. ¿Acaso no sería esta una forma genial de personalizar aún más mi iGoogle? Resulta que muchos de vosotros habéis estado pidiéndonos esto también durante algún tiempo, así que os hemos escuchado. Estoy encantado de anunciar que, después de haber lanzado el API de temas para iGoogle hoy, ya podemos empezar todos a crear y compartir nuestros propios temas.

Crear tu propio tema no es complicado. En tan solo tres pasos lo tendrás listo: diseñas imágenes para el encabezado y el pie, introduce metadata e información de color en un archivo XML, y envía tu tema. Para saber más acerca del API, puedes consultar la guía para el programador (en inglés). También hay unos ejemplos increíbles (ver abajo) de los diseñadores Yves Behar, Mark Frauenfelder, Troy Lee y John Maeda, que son un gran ejemplo de las distintas partes del API. Estos temas, junto con los que nos enviéis, estarán disponibles en el nuevo directorio de temas para los millones de usuarios de iGoogle. Así que no dudéis en probarla y decidnos qué os parece a través del foro de debate o, como siempre, enviadnos vuestros ejemplos a programacongoogle@google.com.

Earth-light de Yves Behar, fundador del estudio de diseño Fuseproject, en San Francisco:




Adventures in Lollipopland de Mark Frauenfelder, escritor, ilustrador, cofundador de Boing Boing, y editor jefe de Make Magazine:



Supermoto Mayhem de Troy Lee, diseñador y fundador de Troy Lee Designs:



Simplicity is Complex de John Maeda, diseñador gráfico, artista, Director Adjunto de Investigación en el Laboratorio de Medios de MIT y recientemente nombrado próximo presidente de Rhode Island School of Design (RISD):

Eduardo Manchón


Un archivo KML es a Google Earth lo que una página a un navegador web y, del mismo modo, un buen diseño de interfaz del KML mejora la experiencia de usuario y aumenta el tráfico desde Google Earth a tu sitio. La interfaz de un KML es visible en la burbuja (infowindow) y los puntos (markers o pines) definidos en el KML que luego aparecen en Google Earth al abrir ese archivo. Aquí van algunas recomendaciones para ambos elementos.
Eduardo Manchón


Un archivo KML es a Google Earth lo que una página a un navegador web y, del mismo modo, un buen diseño de interfaz del KML mejora la experiencia de usuario y aumenta el tráfico desde Google Earth a tu sitio. La interfaz de un KML es visible en la burbuja (infowindow) y los puntos (markers o pines) definidos en el KML que luego aparecen en Google Earth al abrir ese archivo. Aquí van algunas recomendaciones para ambos elementos.

La burbuja o infowindow:

- Logo: Es importante incluir el logo de tu proyecto en la infowindow y que sea un enlace que lleve a tu sitio. En Google Earth cada vez hay más KMLs y es bueno que esté claro a qué sitio pertenece y se pueda visitar.

- Geocodificación inversa: Cuando la gente vuela en Google Earth a niveles altos no se ve claramente donde está situado exactamente el elemento sobre el que has clicado. Puesto que incluir las coordenadas no es demasiado ilustratrivo, podemos utilizar un geocodificador inverso para mostrar el nombre del lugar donde se ha tomado la foto o el punto más cercano a esas coordenadas. En Panoramio, debajo de cada foto lo hacemos con el "near xxxx". Para el geocoding inverso puedes usar por ejemplo el Webservice de Geonames.org

- Enlaces interesantes: El KML esta muy bien para visualizar información en un mapa del mundo en 3D, pero si los usuarios quieren hacer algo, añadir un elemento o registrarse, deberan ir al sitio web. Mejor que incluir solamente un enlace genérico a la página de inicio es incluir enlaces a acciones concretas que puedan resultar de interés para los visitantes: añadir contenido, ver comentarios, ver información ampliada, etc. En Panoramio, por ejemplo, nosotros tenemos enlaces para subir tus fotos, escribir comentarios, marcar la foto, etc.

- Imágenes: Geolocalizar información significa vincularla a un lugar físico, por ello mostrar una foto de esa localización hace mucho más útil e interesante al KML. Cuando sea posible, siempre hay que mostrar una imagen del lugar y si no dispones de fotos puedes usar el API de Panoramio para mostrar fotos cercanas.

Los puntos o marcadores en Google Earth:

- Icono: Es interesante usar un icono para los puntos que resalte lo suficiente en la imagen de satélite de Google Earth, que sea distinguible del resto de iconos de otros KMLs y que no sea excesivamente grande para no ocultar el mapa demasiado. Un color que contrasta bastante bien con el fondo verde, azul y marrón de la Tierra es casi siempre el blanco. En ocasiones, una versión reducida del logo de tu proyecto puede ser adecuado añadiéndole un marco blanco si es necesario para aumentar su visibilidad. En lugar del icono genérico, en ocasiones puede ser útil mostrar un elemento más informativo, personalizado para ese punto, por ejemplo una mini-imagen o un icono personalizado. Esto ayuda al usuario a anticipar el contenido y no clicar en los iconos a ciegas.

- Título en rollover: No es conveniente mostrar el título de cada punto por defecto siempre para evitar superposiciones de textos cuando los puntos están muy cerca. Resulta más adecuado mostrar el titulo al pasar el ratón por encima del punto. Si un punto no tiene un título específico es interesante buscar alguna metadata de ese elemento que mostrar en el rollover. Como el punto anterior anticipar el contenido sin desplegar la burbuja en Google Earth es de gran ayuda para los usuarios.

- Distribución por el mapa: tener grandes zonas vacías en Google Earth y otras atiborradas de pines complica el uso de la información del KML. Es positivo encontrar una manera de distribuir los puntos por el mapa, pero ojo, sin uniformizar la distribución excesivamente. Una alta densidad de puntos en una zona indica intuitivamente a los usuarios que es una zona interesante y viceversa.

Un último elemento que es interesante personalizar es el panel de lugares de la izquierda donde se van mostrando en un listado los elementos mostrados. Allí debajo del nombre de cada elemento es interesante mostrar información de localización de ese elemento, ya sea obtenida del geocodificador inverso o la dirección postal del lugar.

Por cierto, en el archivo KML de Panoramio para Google Earth se puede ver un ejemplo práctico de todas estas recomendaciones.

Michael Weiss-Malik

Google Moon y Google Mars son buenos ejemplos de lo que se puede hacer con el API de Google Maps. Sin embargo, cuando lanzamos estos productos, con las ganas de ponerlos a disposición del público cuanto antes, no tuvimos ocasión de ir más allá y ofrecer el uso de las imágenes de Google Moon y Google Mars a través del API de Maps. ¡Pero eso era antes!

Michael Weiss-Malik

Google Moon y Google Mars son buenos ejemplos de lo que se puede hacer con el API de Google Maps. Sin embargo, cuando lanzamos estos productos, con las ganas de ponerlos a disposición del público cuanto antes, no tuvimos ocasión de ir más allá y ofrecer el uso de las imágenes de Google Moon y Google Mars a través del API de Maps. ¡Pero eso era antes!

El API de Maps v2.95 llega recién salida del horno con soporte explícito para mapas de la Luna y de Marte. ¿Quieres preparar tu próximo aterrizaje en la luna, mantener una base de datos de colonias alienígenas, o simplemente llevar un registro de lo que hemos perdido en Marte? Ahora, crear todo esto y más, es tan sencillo como crear cualquier otro mashup de Maps. ¡Ya no hay límites al cielo!

Y hablando del cielo... cuando estábamos trabajando con Mars y Moon, no nos quedamos ahí. En esta versión del API también hemos incluido soporte de las imágenes de Sky. Sí, ahora puedes utilizar el API de Maps para crear versiones web del cosmos utilizando nuestra galería de imágenes telescópicas. Eso sí, como todavía no dominamos el geoposicionamiento intergaláctico ni la búsqueda de rutas espaciales, tendréis que seguir utilizando los mapas de la Tierra para buscar pizzerías o encontrar la mejor forma de llegar a vuestro destino. Al menos, por ahora.

Michael Kosowsky, de HeyWhatsThat.com ha creado una aplicación que consitutye un gran ejemplo de este nuevo tipo de mapas. En su página Visibilidad Cósmica se pueden ver y entender las fases de la Luna o de Marte. Incluso se puede ver dónde están los planetas o el horizonte, y todo personalizado para diferentes ubicaciones y horas. Esperamos que este ejemplo sea solo uno de los primeros y que haya muchos por venir.

Todo esto ha sido posible gracias a las siguientes constantes predefindas GMapType,que hemos añadido al API de Maps v2.95:

  • G_MOON_ELEVATION_MAP
  • G_MOON_VISIBLE_MAP
  • G_MARS_ELEVATION_MAP
  • G_MARS_INFRARED_MAP
  • G_MARS_VISIBLE_MAP
  • G_SKY_VISIBLE_MAP
Estas constantes funcionan como G_NORMAL_MAP y G_SATELLITE_MAP, ya conocidas por los que estéis familiarizados con el API. Podéis ver algunos ejemplos si queréis más información, y aquí tenéis una demo rapidita:







No olvidéis que los datos de sky están referenciados con el sistema de coordenadas del cielo, lo cual para nosotros, los terrícolas, a menos que estemos acostumbrados, puede resultar algo lioso al principio. El eje vertical se conoce como "declinación" y el horizontal como "ascensión recta". Si queréis más información sobre este sistema de coordenadas, podéis utilizar algún buen buscador. Nosotros también hemos recopilado información al respecto para los interesados en superponer KMLs en el cielo sobre Google Earth. Como recogemos en esta documentación, es importante recordar que los mapas de sky no soportan los KMLs tal cual, por las diferencias en el sistema de coordenadas.

Y esto es todo por el momento. Ahora, esperamos que probéis estas novedades, os gusten y ¡creéis mapas de otros mundos! (Post en inglés.)



Eduardo Manchón

 Hace unas semanas me sorprendió la algarabía que se montó cuando una persona dió a conocer que ganaba 132.000 dólares al mes con Adsense y la demostración práctica de que Adsense, por si solo, puede ser un modelo de negocio para un proyecto web. Supongo que la razón de que no lo vea como algo extraño es haber estado involucrado en dos proyectos ...
Eduardo Manchón

 Hace unas semanas me sorprendió la algarabía que se montó cuando una persona dió a conocer que ganaba 132.000 dólares al mes con Adsense y la demostración práctica de que Adsense, por si solo, puede ser un modelo de negocio para un proyecto web. Supongo que la razón de que no lo vea como algo extraño es haber estado involucrado en dos proyectos, Loquo y Panoramio, cuyos modelos de negocio estaban basados exclusivamente en Adsense. En ambos proyectos, Adsense funcionó muy bien y fue imprescindible.

El modelo de negocio suele ser algo muy sesudamente elaborado y delicado. En cambio, Adsense parece demasiado fácil para ser cierto, y quizás de ahí viene el escepticismo. Sin embargo, Adsense te resuelve el problema del modelo de negocio en 3 minutos: los que tardas en darte de alta e incluir en tu sitio web la línea de código prefabricada que te indica su tutorial.


Con Adsense solo dependes de tí mismo, "simplemente" tienes que captar tráfico y Adsense se encarga de convertirlo automáticamente en ingresos. Captar tráfico no es fácil, pero con Adsense ya no dependes de terceros para conseguir ingresos por publicidad y puedes dedicar tu tiempo exclusivamente a mejorar tu proyecto web y, consecuentemente, a atraer más personas. El sueño de cualquier webmaster, centrarse en desarrollar y olvidarse de todo lo demás: comerciales, ventas, pagos...


Adsense va un paso más allá de la publicidad tradicional a todos los niveles:

  • Usuario: Adsense es generalmente poco intrusivo, al contrario que la publicidad tradicional que basa su modelo en "interrumpir" para captar la atención. Adsense trata de adaptar la publicidad a los contenidos de la página que el usuario esta viendo.
  • Anunciante: Adsense acaba con la antigua regla de oro de la publicidad "sé que estoy tirando la mitad del dinero que invierto en publicidad, pero no se qué mitad". Con Adsense el anunciante puede saber cuántos de sus anuncios son vistos, cuántos reciben clics y cuántos de esos clics se convierten en ventas. No solo sabe cuánto ingresa por cada euro gastado en publicidad, sino que lo sabe para cada campaña y cada tipo de anuncio concreto.
  • Webmaster: recibe un precio justo por su publicidad. Con el sistema de pujas por parte de los anunciantes el webmaster no tiene la incertidumbre de poner un precio demasiado alto o demasiado bajo, el mercado determina ese precio.

Ciertamente todo esto suena muy bien, pero al final las preguntas que se hace un webmaster son ¿me puedo fiar de este sistema? y ¿cuánto voy a ganar?


Respecto a la primera pregunta, hay que tener en cuenta que el modelo de negocio de Google está basado principalmente en los ingresos de publicidad y las cifras de beneficios que publica regularmente parecen indicar que funciona bien . Adsense apareció hace ya 4 años y cada vez son más los sitios que lo usan.

Responder a cuánto puedes ganar es más complejo y depende de 4 factores.

  • El tráfico: el factor más importante. La formula es simple, a más tráfico más ingresos, y dependerá de lo bien que lo hagas con tu proyecto. Evidentemente hay proyectos web que por su naturaleza no pueden generar tráfico suficiente y requieren otros modelos de negocio, por ejemplo, un gestor de facturación online.
  • El tipo de contenidos de tu sitio: si hay muchos anuncios relacionados con tus contenidos es probable que ganes más dinero.
  • El CTR: es el número de clicks por cada 100 veces que se visualiza el anuncio. Este número está visible en la administración de tu Adsense y depende de dos cosas, la visibilidad de los anuncios en tu página y lo interesantes que resulten para el público los anuncios que el algoritmo de Adsense ha decidido que se ajustan a tus contenidos.
  • El eCPM indica tus ingresos por cada 1.000 páginas vistas, un estándar del mercado para compararte con otros sitios, pero internamente lo realmente importante es saber lo que te pagan por clic o tu CTR, el eCPM es la combinación de ambos.
  • Lo que se paga por clic. Es un número que no aparece directamente en la administración de Adsense y te indica lo que los anunciantes te están pagando. Un CTR de 1,5% significa 15 clics por cada 1.000 páginas y si tu eCPM es de 3 dólares, eso significa que cada clic se te paga a 0,20 dólares de media. Los clics se pagan mejor cuando el anunciante vende productos caros o con mucho margen.

Ahora creo que sería interesante ver ejemplos prácticos con números reales.


El CTR puede ir desde un 0,5% o menos, si los anuncios están en una posición poco visible en la página y/o difícilmente encajan con los contenidos, hasta un 2% en sitios donde los anuncios están bien visibles. Personalmente considero que un CTR demasiado alto, por ejemplo, 5% significaría que estás molestando a tus usuarios, o sea, que la publicidad se ve demasiado. Además un CTR tan alto puede ser un efecto puntual y luego provocar que los usuarios terminen ignorando totalmente la publicidad (efecto ceguera). El tipo de los 132.000 dólares al mes tiene un CTR muy normal de 0.93%, no parece que abusase del sistema. Igualmente, nosotros en Panoramio, hace un año, teníamos un CTR de 1,05%.


Respecto al eCPM, por dar otro ejemplo propio, en Panoramio en esa época era de alrededor de 1,5 dólares, lo que significaba unos 0,14 dólares por clic. Al contrario que el CTR, no se puede definir cuál es el pago por clic razonable, puesto que depende de hasta dónde quieran llegar los anunciantes. El tipo de los 132.000 dolares tuvo un eCPM muy alto, de 9,87 dólares, lo que supone con su CTR de 0,93% un ingreso por cada clic de 1,06 dólares. Esto depende mucho del tipo de sitio, por ejemplo, los números de Panoramio eran relativamente bajos al ser un sitio de fotografía con poco texto donde Adsense tenía difícil ajustar los anuncios al contenido. Tener 1,06 dólares por clic como el tipo de los 132.000 dólares es alto, pero no es nada descabellado para sitios con contenidos donde se paga bien la publicidad, en su caso era una web de tonos para móvil con solo 75.000 visitantes únicos y medio millón de páginas vistas, un tráfico relativamente pequeño. En cambio, los grandes sitios con decenas de millones de páginas vistas suelen tener un contenido más variado o generalista que dificulta a Adsense encajar bien los anuncios, con lo que el CTR y el pago por clic suele ser mucho más bajo, si bien el gran tráfico suele compensar. A estos sitios la orientación por secciones para enfatizar ciertas partes del contenido puede ayudarles.

Raúl Benito

OpenSocial es el API que Google está definiendo para facilitar el desarrollo de aplicaciones sociales. Como probablemente ya sabréis, su peculiaridad es que no fuerza ningún entorno de ejecución, es decir, que la podemos usar en cualquier contenedor de ...
Raúl Benito

OpenSocial es el API que Google está definiendo para facilitar el desarrollo de aplicaciones sociales. Como probablemente ya sabréis, su peculiaridad es que no fuerza ningún entorno de ejecución, es decir, que la podemos usar en cualquier contenedor de OpenSocial.

En este post vamos a hacer una pequeña aplicación OpenSocial, pero mientras desarrollamos nuestra futura aplicación necesitamos alguna manera de ejecutarla (no sé por qué, a mi nunca me salen bien a la primera). Para ello, Google ha habilitado el sandbox de Orkut: así podremos probar nuestras aplicaciones. Lo primero que hay que hacer, por tanto, es pedir el alta para acceder. Para ello solo necesitáis una cuenta Google, es decir, la cuenta de gmail de toda la vida, y acceder a http://sandbox.orkut.com/.

Para poder desplegar y poder probar nuestra aplicación, ésta tendrá que estar publicada en algún lugar público de Internet. Para esto tenemos varias alternativas: bien tenemos algún servicio de hosting, bien un servidor web corriendo en nuestra máquina y nuestro router adsl configurado para permitir el acceso desde fuera. Como configurar el router y levantar un demonio web en nuestra máquina puede ser un poco intimidatorio, mi recomendación es que utilicéis Google Pages para hospedar el gadget.

Como primer ejemplo podemos probar con una lista de amigos. Lo copiamos en un fichero, por ejemplo, social.xml y lo subimos a Google Pages (usad el panel de Uploaded Stuff en la parte derecha de la pantalla, y sacad la url con el boton izquierdo del ratón).


A continuación, añadimos la aplicación con el link sacado de Google Pages a nuestro sandbox de Orkut y ya está: tenemos nuestra aplicación preparada para ejecutarse.




Si todo ha ido bien, os debería aparacer una pantalla como esta:


Pulsando en el link de la izquierda "List of friends...", se debería ejecutar nuestra aplicacion.