Aplicaciones y software


5
Dic 11

Hisocial: primeras impresiones

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.

 

image

 

y ya se han empezado a crear las primeras promociones…

image

 

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


23
May 11

Periodo de prueba y Saas

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.

image

 

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.

 

image

 

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.


16
May 11

¿Freemium como modelo de negocio?

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

 

image

 

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):

 

image

 

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:

image

image

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

image

image

image

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


9
May 11

Aplicaciones en Facebook, lo que se puede o no hacer

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

 

image

 

Anuncio incorrecto

 

image

 

– “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):

image

 

– 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.

 

image

 

– “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:

 

image

 

– “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:

image

 

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”)


2
May 11

Facebook y desarrolladores de aplicaciones

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:

image

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.