En Canal IP llevamos mucho tiempo esperando este día: la presentación pública de nuestra plataforma Hisocial. Hemos empezado (después de una beta privada) con una beta pública limitada a 60 participantes, que accedieron a la misma con invitaciones, que se han agotado…en menos de 24 horas.

y ya se han empezado a crear las primeras promociones…

Veamos algunos detalles de Hisocial:

¿Qué es Hisocial?

Hisocial es una plataforma Saas (Software as a service) que permite a sus usuarios crear de una forma muy fácil y rápida promociones online en varios idiomas.

Los tipos de promociones que se pueden crear son:

Cupones y ofertas (vales de descuento, promos 2×1…), tanto de carácter físico como para tiendas online
Concursos online que permitan a los concursantes aportar diverso tipo de material (texto, fotos, escritos…)
Áreas vip/áreas de descarga, se crea un acceso restringido a una área donde se pueden descargar todo tipo de materiales (un estudio de mercado, un salvapantallas….)

A medio plazo se desarrollarán nuevos módulos (compra colectiva ofertas colectivas …)

¿Qué objetivos tiene?

Hisocial tiene dos objetivos muy claros para el promotor:

Que pueda conseguir una base de datos completa de todos los participantes de la promoción
Que tenga  una gran difusión en las redes sociales (Facebook y Twitter), mediante elementos que favorecen la viralidad de las promociones

¿Qué ventajas ofrece Hisocial?

Multiplataforma
Multiidioma
Multimódulos (cupones,  concursos, áreas vip…)
Actualizaciones automáticas (plataforma Saas)
Fácil uso
Rapidez en la creación de promociones
Enfoque a la viralidad y difusión en redes sociales
Panel de control online
Completas estadísticas
Servicio integrado de difusión de las promociones
Servicios complementarios personalizados de difusión
Actual fase Beta gratuita

¿Donde se publican las promociones creadas con Hisocial?

Una de las grandes ventajas de Hisocial es que es multiplataforma, las promociones creadas pueden ser publicadas en:

La web del promotor (sirve para todo tipo de webs)
La página que tenga el promotor en Facebook
La página de Hisocial en Facebook
En Twitter
La web de Hisocial (se facilita una url para cada promoción, lo que permite que puede ser enlazada desde cualquier sitio)

¿Por qué crear una promoción online?

Las promociones online son una excelente herramienta para:

Incrementar tu base de fans o seguidores en las redes sociales.
Dirigir más tráfico hacia tu web o tus páginas en las redes sociales.
Crear tu propia lista de correo, tanto para email marketing como para marketing directo.
Crear conciencia de marca online e interactuar de forma más directa con tus clientes.
Fomentar la compra de un producto recién lanzado.
Múltiples canales simultáneos de difusión: tu web, tu página de Facebook, tu perfil de Twitter y nuestra plataforma de promociones en Hisocial.

En breve fecha ampliaremos el número de invitaciones disponibles. Si quieres puedes apuntarte en la siguiente lista de espera

En un post anterior hablábamos del freemium como modelo de negocio. Pues bien el periodo de prueba (free trial) es en cierto modo una variante o una alternativa de dicha estrategia de negocio. Cuando hablamos de periodo de prueba en un entorno saas (software as a service) surgen una serie de dudas que trataremos de investigar en este artículo. Entre ellas:

1 – ¿Es una buena opción?

2 – ¿Cuál debe  ser la duración de la prueba?

3 – ¿Debemos requerir la tarjeta de crédito para acceder a la prueba?

4 – ¿Cómo evitar la picaresca?

En líneas generales podemos decir que el periodo de prueba es una opción en principio sin riesgos tanto para los clientes como para los proveedores Saas. Los clientes tienen la opción de probar el servicio y ver si se adapta a sus necesidades sin necesidad de realizar ninguna inversión. Los proveedores limitan el riesgo de ofrecer una alternativa freemium completa, con los inconvenientes que vimos en el articulo anterior. Podemos distinguir tres variantes de periodo de prueba:

1 – Periodo de prueba sin facilitar datos de tarjetas de crédito

2 – Facilitándolos pero sin cargos hasta pasado el periodo de prueba

3 – Cargándolos desde el principio, pero con el compromiso de abonarlos si el cliente no está satisfecho (money back guarantee)

Es evidente que la primera opción facilita la entrada de nuevos potenciales clientes, pero probablemente la tasa de conversión a clientes definitivos sea la más baja de las tres. La tercera sea todo lo contrario y la segunda sea una vía intermedia. Una ventaja de las opciones dos y tres es que evitamos la picaresca, en el sentido de usuarios que hacen la prueba y después vuelven a registrarse con otros datos para hacerla nuevamente, por contra, y sobretodo en entornos empresariales, estas dos opciones dificultan que personas dentro de la empresa la prueben (ya que no siempre tienen acceso a los datos de la visa) y se conviertan en prescriptores de nuestra plataforma. Existen, evidentemente, vías mixtas que combinen las anteriores alternativas, por ejemplo dar un periodo muy corto de prueba (e.g  3 días) y para prolongarlo obligar a dar los datos de la visa o ofrecer una garantía de reembolso. Otra consideración a tener en cuenta, es el grado de “esfuerzo” que debe realizar el usuario para utilizar nuestra plataforma, es un hecho demostrado que cuando pagamos por algo ponemos más interés en ello, en este sentido si nuestro servicio saas es de carácter complejo  o no es una cuestión a tener en cuenta, pues puede suceder que si se requiere una dedicación determinada del usuario sea más difícil de obtenerla si no le exigimos un compromiso financiero que nos asegure su implicación mental en el servicio.¿Cuál es la mejor de las tres alternativas?, francamente no tengo la respuesta y creo además que puede variar según cada sea nuestro modelo saas, por lo que mi recomendación sería probar las tres alternativas y ver cual es la mejor para nuestro negocio. Para ello puede resultar muy útil realizar las tipicas pruebas de A/B testing (por ejemplo con Google website optimizer) presentado en disitintas landing pages las tres opciones y ver los resultados.

Si hablamos de la duración del periodo de prueba está claro que cuanto más largo sea más nos acerca a un modelo freemium puro, por ello debemos tener en cuenta las consideraciones que vimos anteriormente (coste de mantener el servicio gratuito, amplitud de nuestro target, imagen de marca…) pues son aplicable igualmente en este caso. Dicho de otro modo, cuanto más caro sea para nosotros mantener la prueba, menor sea la amplitud de nuestro target o mayor sea el riesgo de uso fraudulento de nuestra plataforma, menor debe el periodo de prueba concedido y en un caso extremo no debe existir.

Vía este blog, vemos un interesante estudio sobre la duración habitual concedida por los proveedores Saas (el estudio tiene una muestra de 317 proveedores), y destaca el hecho de que más de la mitad concede un trial de 30 días.

Del mismo estudio (aunque sea offtopic), destacamos también el siguiente gráfico, que nos muestra que la mayoría de proveedores se inclina por ofrecer 3 ó 4 planes dentro de su oferta comercial.

Acabamos este artículo indicando que una alternativa al periodo de prueba (aunque no sea excluyente), es facilitar al usuario una demo operativa, a la que pueda acceder sin que tenga que facilitar ningún tipo de dato. Está claro que ello facilitará su utilización, pero con la contraprestación evidente que no implicaremos al usuario de la misma forma. Una idea interesante es combinar ambas estrategias, es decir facilitamos al usuario la utilización de nuestra plataforma saas mediante una demo anónima y una vez haya experimentado con ella le damos la posibilidad de registrase, acceder a una prueba personalizada gratuíta manteniendo todos los datos que haya entrado previamente en la demo.

Con motivo de un nuevo proyecto Saas que estamos preparando en Canal IP estoy dándole vueltas a la posibilidad en que se base en un modelo freemium. En la jerga de Internet se entiende por freemium cuando se presta un servicio o se da una aplicación gratis en unos supuestos (free) y se cobra en otros (premium). Existen múltiples posibilidades para ello, veamos algunas de ellas:

1- Gratis un tiempo limitado o un número determinado de usos. Es una de las alternativas más conservadoras, en puridad casi no podría considerarse un modelo freemium. La mayor ventaja que presenta es que controlamos perfectamente los recursos consumidos por los usuarios de la versión gratuita, el mayor inconveniente es que este modelo tiene poca viralidad, ya que muchos usuarios no se molestarán en probar algo que después tendrían que pagar.

2- Gratis para una versión con menos funcionalidades que la de pago. Es una de mis variantes favoritas (ya no lo tengo tan claro). La clave está en encontrar el equilibrio justo entre viralidad y tasa de conversión. Si la versión gratuita es muy limitada pocos usuarios la probarán, pero si es demasiado generosa pocos usuarios se verán incentivados a pasarse a la opción de pago.

3- La versión gratuita lleva publicidad, la de pago no. El problema de esta variante es que caemos en una peligrosa dependencia de los anuncios como fuente de ingresos de nuestro negocio, con todo lo que ello comporta.

4- Gratis para cierto tipo de usuarios. En este caso también favorecemos la viralidad, pero conlleva un trabajo administrativo considerable para evitar la picaresca de los usuarios.

Como siempre en estos casos vamos a bucear un poco por la red para extraer algunas reflexiones sobre el tema. Se trata sin duda, de un tema muy debatido y con opiniones diversas, veamos algunas de las más interesantes.

En primer lugar hemos de tener en cuenta, que en un modelo freemium hay un evidente coste de mantener a los usuarios que no pagan,  coincido plenamente en lo que dice  el CEO de Dropbox , Drew Houston: “So the big lesson there is if you adopt a freemium business model your marketing cost is the free users.” En el sentido de que integramos dentro de las partidas que componen nuestro gasto de publicidad, dicho coste. El problema, claro está, es controlar el crecimiento del mismo, ya que nos puede suceder lo que explica Ruben Gamez en este articulo: Why Free Plans Don’t Work, una gran cantidad de usuarios gratuitos (con unos enormes gastos de mantenimiento) y una pobre tasa de conversión

Cuenta en el articulo, que tras probar todo tipo de tácticas para aumentar la tasa de conversión, al final optó por la vía radical de eliminar la opción gratuita, y logró multiplicar por ocho el número de usuarios de pago. Una opción similar, aunque no tan radical, fue la escogida por la gente de 37 signals, donde se necesita casi una lupa para poder escoger la opción gratuita en su plataforma Basecamp (cuadrado rojo):

Otro de los problemas del freemium, es lo que les paso a mailchimps, que multiplicaron  el número de incidencias debido a los usuarios gratuitos, ello es lógico ya que este tipo de destinatarios son más proclives a causarnos problema y hacer un uso indebido de nuestro servicio o aplicación, entre otras cosas porque se pueden amparar más fácilmente en el anonimato.

En la misma línea leo a unos de los responsables de chargify, que comenta la considerable mala reputación que sufrieron al eliminar los planes gratuitos, en sus propias palabras:

“Over the past year, we discovered that the customer that never paid had the highest support load. Once we made the announcement about the price change, the same applied to complaining about Chargify across multiple public channels. Those customers that were working on a hobby business, or just something they were not investing in significantly, seemed to have the time to tweet all day long, post multiple negative comments on every possible channel available, and shout the loudest”.

Jesús Encinar, fundador de idealista.com, tampoco se muestra favorable a empezar con un modelo freemium, estas notas lo resumen:

1. El cliente que paga por tus servicios los utiliza efectivamente. Un cliente que utiliza tu servicio intensamente, porque lo paga, es mucho mejor que 10 que lo utilizan sólo superficialmente porque es gratis
2. Comenzando con pocos clientes puedes asegurarte que aportas valor a los pocos que pagan porque todo el valor que creas (tráfico, ventas) lo disfrutan sólo unos pocos. Además es difícil que alguien pase de gratis a pagar. Dándo tu servicio gratis al principio aumentas el trauma en el momento del cambio
3. Los clientes te ven como una empresa seria cuando cobras. Lo que transmites cuando ofreces el servicio gratuitamente es que ni tú mismo valoras tu servicio.

Sean Ellis nos deja dos interesantes reflexiones para que un modelo freemium funcione:

“There are times when freemium doesn’t make sense.  For example, it rarely works with products exclusively targeting enterprises (open source has done well with enterprises, but that’s probably more a function of product flexibility than price). Also, freemium requires that the marginal user cost for the free product is zero or low”

En este punto debo reconocer un poco mi sorpresa, esperaba encontrar cientos de opiniones favorables al freemium y cada vez me da más la sensación de que los puntos negativos superan a los positivos. Una alternativa interesante parece ser hacer el camino contario a lo que el sentido común quizás nos pueda indicar, empezar “premium” y cuando aseguremos unas estabilidad financiera de la plataforma probar la vía freemium. De todas formas en este artículo podemos ver algunas historias freemium de éxito:

y varios proyectos que están en la buena dirección:

Pero nuevamente me encuentro un documento contundente contra el freemium del que vale la pena extraer varias perlas:

“Freemium in SaaS can be used as an effective go-to-market strategy, but it is the rare case where this method leads to a substantial increase in paying customers; it more often leads to increased overhead, negative product positioning, and can lead to overall failure”

“Free trials or “Try before you buy” are fine, and expected, but free in perpetuity, like  Freemium, has potentially negative consequences “

“Assuming free users are "hot prospects” ready to be converted into paying customers is wrong.”

“The Freemium model as an entry point into corporate customers has many potential drawbacks. Quite often the application will be used by employees within an Enterprise that do not know the others are using it because they all have individual accounts on the free version. This will lead to fragmented use within a company with no need to ever consolidate under one, very prompt and reliable, corporate payer. Simply put, the SaaS vendor could be missing out on a large corporate sale because of their use of the Freemium model.”

“Without revenue, their business will fail as, by definition, a business has revenue. Otherwise it is a hobby; even non-profits have revenue”

“It is a safe bet that business customers have a higher money-to-time ratio than the average consumer. This means that out of the gate, anyone looking at a solution to their problem will likely spend money if it can save them time”

Después de todas estas valiosas aportaciones, estas son algunas de las reflexiones que personalmente creo se deben valorar a la hora de optar o no por el modelo freemium:

- Analizar nuestra capacidad financiera y ver si podrá soportar el mantenimiento de los usuarios gratuitos

- Contemplar si existe la posibilidad de dar a los usuarios gratuitos un soporte más reducido que a los usuarios de pago

- Comparar el coste de los usuarios gratuitos con el coste que supondría un plan de marketing alternativo para difundir nuestro producto sin tener usuarios gratuitos

- Un factor muy importante es tener en cuenta si los usuarios gratuitos aportan valor añadido al sistema, este es el típico caso de los marketplace donde se requiere que muchos usuarios participen en la plataforma para conseguir que la misma triunfe (típico caso de infojobs), en el otro extremo están las plataformas donde no hay interrelación entre los usuarios, en este caso el valor aportado por los usuarios es mucho más reducido.

- Debe estudiarse si los usuario gratuitos son más proclives a crear incidencia (e incluso problemas legales), amparándose en el anonimato

- Diferenciar entre modelos B2B y B2C

- La posibilidad de vender o no servicios/productos complementarios a los usuarios gratuitos es también un factor crucial.

- Amplitud del target. Un modelo freemium no funciona si el target es muy reducido.

Dada la complejidad del tema dejo las anteriores conclusiones como temporales y seguro que en futuros post volveremos a hablar de este apasionante tema

Hablábamos en un post anterior de la relación simbiótica asimétrica que se produce entre Facebook y los desarrolladores de aplicaciones, pues bien vamos a profundizar un poco más sobre el tema. Utilizaremos para ello la guia práctica que nos proporciona Facebook con ejemplos de lo que considera ajustado o no a su normativa (me ceñiré sólo a algunos de los aspectos más relevantes).

- Anuncios

“You must not include advertisements or promotions, cross-promote other apps, or provide web search functionality on user profile pages or in content distributed through Facebook social channels.

User profile pages and Facebook social channels are not intended to be advertisement methods. However, you may advertise on your apps’s canvas pages.”

Queda claro que el único espacio para realizar anuncios mediantes aplicaciones es en el espacio contenedor de la aplicación (lo que ellos llaman “canvas”). Facebook se reserva el derecho exclusivo a realizar anuncios en el resto de la plataforma (anuncios que evidentemente son de pago y son una de sus principales líneas de ingresos previstas para el futuro de la empresa).

Se formulan a continuación algunos ejemplos prácticos basados en su normativa para anunciantes, que incluye los anuncios dentro de las aplicaciones:

- “Ads may make limited references to "Facebook" in their title, body, or image for the purpose of clarifying the destination of the ad.

Ads cannot imply any endorsement of the product, service, or ad destination by Facebook.”

Los anuncios no pueden dar a entender, directamente o indirectamente, que Facebook tiene vinculación alguna con muestra aplicación

Anuncio correcto

Anuncio incorrecto

- “Ads cannot use Facebook logos, trademarks, or site terminology (including but not limited to Facebook, The Facebook, FacebookHigh, FBook, FB, Poke, Wall, and other company graphics, logos, designs, or icons).Facebook site features cannot be emulated.”

Los anuncios no deben llevar a confusión a los usuarios, y que puedan ser interpretados como parte de la plataforma

- “Ads cannot insult, harass, or threaten a user.” “Ads must not be false, misleading, fraudulent, or deceptive.”

Evidente

- “You may not give data you receive from us to any party, including ad networks.

Unless authorized by us, your ads may not display user data — such as users' names or profile photos — whether that data was obtained from Facebook or otherwise.”

Tal como se expone en  los principios para desarrolladores, uno de los conceptos fundamentales es proteger los datos personales de los usuarios, por este motivo aunque se permita utilizar los datos recabados del usuario de la aplicación mediante la api de Facebook para la correcta utilización de la misma, no se permite guardar esos datos para fines distintos.

Por otra parte los anuncios no pueden contener datos de los usuarios (salvo autorización previa de Facebook).

Ejemplo de un anuncio incorrecto (ya que utiliza datos de los usuarios):

- Botón “me gusta”

“You must not incentivize users to Like any Page other than your own site or app, and any incentive you provide must be available to new and existing users who Like your Page.

You must not automatically reward users for Liking your Page. Instead, you should make it clear that Liking your page allows fans–both new and existing–to become eligible for current and future rewards”.

Uff, parece un juego de palabras pero intentaremos sacar algunas conclusiones al respecto:

- Se puede incentivar al usuario a apretar el botón “me gusta” sólo para tu site o aplicación. No debería haber ningún problema en interpretar que si alguien utiliza una aplicación de otro, puede incentivar a apretar el botón “me gusta” tanto de la aplicación como del site propio. Un ejemplo explicará mejor mi interpretación, A desarrolla una aplicación, B utiliza esa aplicación en su página de Facebook, los visitantes que se conecten a la página de B, pueden ser incentivados a apretar el botón “me gusta” tanto del site (perteneciente a B) como de la aplicación perteneciente a A.

- No debes dar un incentivo automático a alguien que aprete el botón “me gusta” (la pregunta es obvia ¿Qué se entiende por automático?)

Facebook nos da un ejemplo gráfico para ilustrar sus directivas, pero no estaría de más que desarrollara más este punto y mostrara más ejemplos.

- “Stream”

“Stream stories must accurately represent interesting actions users have performed or content they want to share. Users should never be surprised by the publication of a story on their behalf, or by its content or timing”.

En pocas palabras se objetivo, y no utilices el “stream” del usuario para publicitar inadecuadamente tu aplicación

- “You must not incentivize users to use (or gate content behind the use of) Facebook social channels, or imply that an incentive is directly tied to the use of our channels.”

No “sobornes” a los usuarios para que promocionen tu aplicación entre sus amigos. Por ejemplo esto sería incorrecto:

- “You must not pre-fill any of the fields associated with the following products, unless the user manually generated the content earlier in the workflow: Stream stories (user_message parameter for Facebook.streamPublish and FB.Connect.streamPublish, and message parameter for stream.publish), Photos (caption), Videos (description), Notes (title and content), Links (comment), and Jabber/XMPP”.

Aunque la redacción parezca confusa, la idea es simple “no hables por boca del usuario”, deja que él escriba personalmente lo que quiere que aprezca en su “stream”. El siguiente ejemplo gráfico nos los explica claramente:

Por cierto cabe destacar también dos cosas al respecto:

- Esta publicación por parte del usuario debe ser optativa

- Se debe facilitar claramente una opción para evitarlo (botón “skip”)

Recuerdo de mis tiempos escolares que en clase de biología nos explicaban un fenómeno que se produce en la naturaleza llamado simbiosis, mediante el cual dos especies animales muy distintas colaboran entre si, porque obtienen beneficios mutuos. Nos ponían como ejemplo los rinocerontes que permitían que pequeñas aves se posaran en sus lomos porque así estas últimas  mientras se alimentaban les liberaban de insectos y garrapatas . Viene esto a colación porque entre Facebook y los desarrolladores de aplicaciones basados en esta plataforma se produce una relación simbiótica similar (queda claro en este caso quien es en este caso quien es el rinoceronte y quienes son los pequeños pajarillos).

Es una relación en la que ambas partes ganan, Facebook porque así aun populariza aun más su plataforma, y los desarrolladores porque pueden conseguir nuevas líneas de negocio. El problema es que se trata de una relación  simbiótica asimétrica, donde el poder de ambas partes no está distribuido equitativamente, y es Facebook el que actúa como juez y parte marcando las normas de la relación. No digo que esto sea injusto, entre otras cosas porque la situación de partida de ambas partes no es la misma, pero es un hecho que obliga a los desarrolladores a estar muy atentos a las regulaciones cambiantes que dicta Facebook al respecto.

Vamos a ver en este post algunas reglas básicas que deben tener en cuenta los desarrolladores en Facebook. Para ello es imprescindible leer en detalle este documento de Facebook, que comentaremos someramente a continuación, centrándonos en los puntos más importantes (nota previa, según se rumorea algunas de las reglas impuestas por Facebook, son la respuesta a diversas acusaciones que se han hecho a esta red social por no proteger suficientemente los datos personales de los usarios, ver este interesante artículo al respecto):

- Principios:Las normas expresadas en el documento se basan en los siguientes conceptos:

- Prioriza el interés del usuario final

- No hagas spam y respeta la privacidad de los datos personales de los usuarios

- Consecuencia de lo anterior, se exponen las siguientes políticas (mencionamos sólo las más relevantes):

- No violes los derechos de los usuarios ni de Facebook (ello incluye por ejemplo no alterar las funcionalidades básicas de Facebook, no utilizar los iconos de Facebook que puedan provocar confusión en el usuario…)

- No almacenes logins y passwords de los usuarios

- Se requiere autorización previa, para las grandes aplicaciones que superen los siguientes límites: >(5M MAU) o (>100M API calls per day) o(>50M impressions per day).

- Debes ofrecer a los usuarios una opción de “log out” que desconecte simultáneamente al usuario de Facebook

- Limítate a pedir los datos imprescindible de los usuarios que necesites.

- Debes tener una política de privacidad que explique que hará con los datos recabados

- Atención con este punto que es importante y que transcribimos literalmente “A user's friends' data can only be used in the context of the user's experience on your application” y que complementa con los siguientes “For all other data obtained through use of the Facebook API, you must obtain explicit consent from the user who provided the data to us before using it for any purpose other than displaying it back to the user on your application.” y “You will not directly or indirectly transfer any data you receive from us, including user data or Facebook User IDs, to (or use such data in connection with) any ad network, ad exchange, data broker, or other advertising or monetization related toolset, even if a user consents to such transfer or use. By indirectly we mean you cannot, for example, transfer data to a third party who then transfers the data to an ad network. By any data we mean all data obtained through use of the Facebook API, including aggregate, anonymous or derivative data”. De todo ello, interpreto lo siguiente (sujeto evidentemente a opiniones distintas), los datos recabados del usuario, solo se pueden utilizar en el marco de la aplicación y no pueden ser almacenados para un uso distinto, por lo que si por ejemplo queremos el email del usuario para enviarle información de cualquier tipo, deberemos pedirle al usuario que lo escriba (aunque de hecho lo pudiéramos obtener directamente mediante la api de Facebook). Ya se que todo ello parece bastante confuso, pero lo explicaré mediante un nuevo ejemplo, desarrollamos una aplicación que da una determinada funcionalidad al usuario de Facebook, un usuario se conecta a la aplicación mediante su login de facebook, en ese momento ya estamos obteniendo acceso a sus datos personales, pero solo los podemos utilizar mientras el usuario esté dentro de la aplicación, si queremos guardar uno de esos datos para otro uso (por ejemplo mandarle emails) debemos pedirle al usuario que lo escriba (informándole evidentemente de que uso se hará de él). Apreciado lector en este momento no debe preocuparse si necesita leer este apartado nuevamente para entenderlo, por experiencia propia le puedo asegurar que no será el primero en hacerlo.

- El desarrollador exime de cualquier responsabilidad a Facebook del contenido de la aplicación y del contenido aportado por los usuarios que se genere mediante ella. Se prohíben específicamente cierto tipo de actividades (relacionadas con el alcohol,tabaco,apuestas…)

- Las normas expresadas por Facebook pueden cambiar sin previo aviso (recuerden lo de relación  simbiótica asimétrica)

Un recursos práctico interesante para los desarrolladores el siguiente checklist proporcionado por el mismo Facebook, que nos ayudará a comprobar que le aplicación que queremos lanzar se ajuste a la normativa de dicha plataforma:

Este checklist es una forma rápida, pero no exhaustiva de analizar los principales punto que como veíamos anteriormente se detallan en el developers policy. Otro recurso interesante también lo podemos encontrar en el siguiente enlace de facebook. En él podemos ver de forma gráfica algunos ejemplos de lo que se considera ajustado o no a la reglas de esta red social.No quiero extenderme demasiado en este post, por lo que os remito a un posterior artículo donde hablaremos más detalladamente sobre estos ejemplos. Finalmente otro recurso que puede ayudar a los interesados, y perdón por la autocita, es el artículo que escribí en este blog referente a las promociones en facebook, en el se explicaba ciertos conceptos que también son interesantes paara los desarrolladores de aplicaciones.

En un artículo anterior veíamos una buena herramientas para analizar de forma bastante exhaustiva que nuestra web cumpliera de una forma adecuada una serie de parámetros relevantes. Pues bien, de la misma familia de herramientas existe una especializada en análisis de blogs: Blog grader

Según sus creadores ya han analizado hasta la fecha más de 300.000 blogs. He probado para obtener datos reales el microblog de Canal IP www.wwwisibility.com

Hmmm no me acaba de convencer

no me creo los resultado (una puntuación de 100 sobre 100, que lo coloca en el top 1 de blogs).

En cualquier caso, si obviamos este extraño resultado, continua valiendo la pena utilizar la herramienta ya que se analizan diversos factores que nos pueden ayudar a mejorar nuestro blog, en concreto las áreas de factores analizados son:

- Características del blog

- Contenido del blog

- Compromiso del blog (engagement)

Una herramienta menos completa que su alternativa genérica para webs que veíamos en el anterior articulo, pero no perdemos nada echándole un vistazo.

Grader es un interesante conjunto de herramientas que nos permiten medir un amplio espectro de información relevante sobre nuestra web o nuestras cuentas en diversas redes sociales. En posteriores artículos sus diferentes componentes, pero empecemos hoy con website grader, que fue (si no ando equivocado) el primer miembro de la familia.

Esta herramienta permite un análisis completo de una web, es interesante para ver como de optimizada esta nuestra página, y además nos permitirá hacer un repaso de diversos temas SEO y convertibilidad que siempre viene recordar. Utilizaremos como prueba nuestra web www.canalip.com. El informe se divide en diversas áreas:

Área de contenido:

Mide aspectos tales como el número de páginas indexadas en Google, si disponemos de blog…La puntuación en nuestro ejemplo de Canal IP es bastante elevada, y el único defecto encontrado es que no puede acceder a los artículos del blog (error imputable a la plataforma, seguramente porque el blog está hecho en joomla no en wordpress y no lo debe detectar)

Área de optimización

Bajo este epígrafe se encuentran variables como la existencia de metatags, optimización de las imágenes, número de links entrantes…

La mayoría de variables que analiza son relevantes. Aunque en este tema siempre puede haber discrepancia sobre la importancia de tal o cual variable(cada maestrillo tiene su librillo )

Área de promoción

Vemos aquí diversos factores como la presencia de la web en marcadores sociales y redes sociales con el afán de medir la popularidad de nuestro site:

Área de conversión

Es imprescindible que nuestra web tenga elementos que ayuden a conseguir conversiones (por ejemplo un formulario) y esta área controla precisamente su presencia.

Area de análisis

Finalmente este apartado nos muestra una breve comparación con los sites que le indiquemos y nuestra posición en índices generales de popularidad (e.g. alexa)

Se trata en definitiva de una herramienta gratuita bastante completa que puede hacer un buen resumen de nuestra web, existe además si la encontramos insuficiente una versión de pago aun más potente.

Ciertamente existen muchos tipos de licencias open source (creo que actualmente hay más de 60 aprobadas por la Open Source Initiative). Cada una de ellas confiere a los usuarios una configuración distinta de derechos y obligaciones.

Algunas de las más populares son:

- GNU General Public License (GPL), esta es una de las más populares (la utiliza por ejemplo wordpress) y tal como veremos después es una de las más polémicas.

- GNU Lesser General Public License (LGPL), variante menos restrictiva de la anterior

-  Mozilla Public License (MPL), licencia respaldada por la Fundación Mozilla

- Apache License Respaldad por la Fundación Apache Software es una de la que otorga a los usuarios más derechos

- BSD license, apoyada por la Berkeley Software Distribution, es una de las licencias más liberales y se acerca mucho al concepto de dominio público.

No voy a entrar a valorar y comparar los distintos tipos de licencias, pero si que quiero remarcar una de las principales diferencias entre el grupo de las licencias más restrictivas como por ejemplo la GPL y el grupo formado por las llamadas licencias liberales, como por ejemplo la BSD. Pues bien, esta diferencia es la obligación de distribuir cualquier software open source y sus trabajos derivados bajo el mismo tipo de licencia (este es el modelo de la GPL), frente a la ausencia de dicha obligación (como pasa en la BSD). Es evidente que esto tiene un enorme impacto para los creadores de software, puesto que si utilizan en su creación partes provenientes de software gpl de terceros, se verán a distribuir todo su trabajo en forma también como codigo abierto con licencia GPL. Es lo que algunos han venido a llamar el “virus GPL”.

La creciente popularización del Saas (software as a service) y el cloud computing

han tenido un gran impacto en el tema de las licencias más restrictivas, ya que ha propiciado un enorme agujero “de facto” en su aplicación (loophole). La clave está que estas licencias prohíben la distribución del software si no se hace bajo el mismo tipo de licencia, pero no dicen nada cuando ese software es ofrecido como saas, en el que el usuario final no tiene acceso al código.

Ante esta situación aparecieron las llamadas licencias Affero GPL, que son una variante de la GPL pero con una cláusula específica para remediar esta situación, la más reciente de ellas es la  GNU Affero General Public License, versión 3, aprobada por la OSI en 2008. Aunque su difusión es menor que la GPL genérica y es fuente de numerosas discusiones sobre su idoneidad.

Si queréis seguir profundizando en el tema los siguientes enlaces os serán de utilidad:

En esta dirección hay un completísimo faq, sobre las licencias GNU

y en esta otra dirección podéis ver todas las licencias aprobadas por la OSI

Finalmente si aun tenéis más dudas también os recomiendo estos recursos:

Licencias de software libre

Copyright and Open Source Software Licensing,

Estudio sobre la licencia GPL v3 y otras licencias open source,

Eligiendo licencia para el código

Tweetdeck es una gran aplicación gratuita que nos permite gestionar de una forma eficiente nuestra cuentas de Twitter, Facebook, Myspace y Linkedin.

La aplicación tiene tres modalidades: para escritorio (es la que yo uso habitualmente), para iphone y para ipad.

Una vez descargada e instalada la herramienta, el primer paso es tan fácil como configurar las cuentas que queremos gestionar:

Posteriormente podemos configurar todas las columnas que queramos, con la información deseada (por ejemplo, menciones de nuestra cuenta en Twitter, mensajes directos, los tweets de las persona que seguimos…):

Tweetdeck no solo permite ordenar la información relevante de nuestra cuentas, si no que nos permite además una comunicación bidireccional con nuestra cuentas sociales (por ejemplo podemos twittear directamente, incluso utilizando un acortador de urls automático):

Dar respuesta a la información que recibamos es muy fácil y rápido, y con un solo click podemos por ejemplo hacer un retweet, consultar un profile, responder al autor…

La plataforma dispone de múltiples opciones de configuración, pero os aconsejo deshabilitar la opción de notificaciones en modo de pop-up y alarmas, de lo contrario es muy posible que no consigáis trabajar en todo el día con las constantes distracciones que aparecerán en vuestro escritorio cuando se actualice la información seleccionada.

Realmente una aplicación muy recomendable y fácil de usar, y en caso de cualquier duda, tenemos un completa información de soporte a nuestra disposición:

Twittercounter es una buena herramienta para controlar la evolución estadística de nuestra cuenta en Twitter.

Su uso es realmente simple, para registrarnos tan solo debemos indicar nuestra cuenta de Twitter y permitir el acceso a la misma por parte de dicha herramienta.

Una vez registrados, podremos acceder inmediatamente a las principales estadísticas de nuestra cuenta, como por ejemplo el número de followers que tenemos:

y compararla con otras cuentas de nuestro interés.

También es interesante ver cual ha sido nuestra actividad diaria de tweets, ..y poder analizar objetivamente si nos estamos volviendo demasiado perezosos o hiperactivos en nuestra relación con Twitter

… y comparar nuestra humildes cifras con las de los twitteros más famosos

Para mayor comodidad también es posible la recepción por email de los resultados. En definitiva, una herramienta que os recomiendo.