API de ofertas para promocionar Apps

Si te dedicas al mundo de la promoción de Apps (como hacemos en Geenapp) y no trabajas con una plataforma que tiene su propia API y has de crearla, lo más probable es que te preguntes qué necesita el que vaya a recibir los datos. La combinatoria puede se muy grande (intentaré cubrir la mayoría de posibilidades) aunque en realidad hay que adaptarla a los datos que tú mismos tengas.

También hay que tener en cuenta que cuando se prepara una oferta al anunciante hay que pedirle un mínimo de elementos:

  • App y su URL en Google Play / iTunes.
  • Dinero Total / por instalación.
  • Limitaciones (puede darlas el cliente o se pueden incluir si el presupuesto es mensual para mantener instalaciones a lo largo del periodo).
  • Tipo de calidad.
  • Países y dispositivos.

A partir de aquí se pueden crear varias campañas según combinaciones de estos datos.

Cuando vayamos a crear la API como agencia, debemos tener en cuenta los siguientes elementos (para ofrecer un buen servicio y sencillo):

  1. Con una llamada a un fichero se debe procesar todo.
  2. Se puede hacer llamada individual por cada oferta.
  3. Siempre ha de haber al menos una oferta (aunque sea una App / Campaña propia de ejemplo a precio 0)

Otro elemento importante para aumentar la sencillez es que se haga una API REST, en la que sólo haya un identificador de validación (algo tipo una API key). Este sistema funciona para cualquier lenguaje de programación e incluso se puede comprobar desde un navegador de Internet.

Comenzando por los datos a publicar. Los básicos son los siguientes:

  • Identificador de la oferta [offerid]: Normalmente un número único que identifique inequívocamente a la oferta.
  • Nombre de la oferta [name]: El título de la oferta, normalmente con la App, lista de IDs de países, dispositivo…
  • Dinero [payout]: La cifra que se pagará por la instalación o acción.
  • Moneda [currency]: El ISO 4217 de las monedas. Algo del estilo a EUR o USD. En este mundo las ofertas suelen ser en euros o dólares, por lo que cualquier otra moneda suele limitar completamente la promoción.
  • País [country]: Normalmente es un array (o un texto, separado por comas) con la lista de países en ISO 3166-2 del estilo a ES, GB, DE
  • Dispositivos [device]: Esto se puede hacer de muchas maneras, aunque lo más simple es un array que incluya conceptos como iPhone, iPad, Android Phone, Android Tablet… Normalmente lo mejor es no mezclara sistemas y separar las ofertas de iOS de las de Android.
  • Calidad [incent]: Un indicador que identifique claramente si la oferta es incentivada (tráfico de baja calidad) o no incentivada (alta calidad). El valor puede ser booleano con 0 y 1.
  • Limitación de volumen [capping]: Aquí se pueden dar varias soluciones, ya que el capping puede ser diario, mensual, total… la opción más sencilla puede ser la de tener 3 valores, [capping_day], [capping_month], [capping_total], que por defecto esté a null, excepto cuando haya alguno disponible. Además, en caso de que sea posible, también es interesante indicar el capping disponible en ese momento, por ejemplo con 3 valores más: [capping_day_left], [capping_month_left], [capping_total_left]. El capping, se debería resetear a las 00:00 UTC de cada día / mes.
  • Preview URL [preview]: URL donde poder visualizar dónde llegará el usuario al hacer clic. Puede ser una URL de Google Play, iTunes…
  • Offer URL [url]: URL donde se ha de enviar el tráfico. No es necesario añadir parámetros extra, que sea la URL mínima para funcionar (aunque añadamos un documento adjunto donde se expliquen qué parámetros extra añadir… luego lo explicaré con más detalle).
  • Descripción de la oferta [description]: No es necesario indicar la descripción de la App, sino algún elemento más clave de la oferta que no esté en ningún campo.

Si tenemos ofertas de múltiples tipos, podemos mostrarlas de forma adecuada:

  • Tipo de oferta [type]: Las ofertas no tienen porqué ser sólo CPI, pueden ser CPE o CPA… enviar valores como cpa, cpe o cpi.

En caso de que queramos tener un sistema en el que haya que solicitar las ofertas para que un manager las apruebe, se pueden añadir varios campos más:

  • Estado de la oferta [status]: Puede ser tan simple como un booleano de 0 y 1, o algo más elaborado con opciones como request, pending, approved o rejected.
  • URL de Solicitud [request]: Una URL en la que llamándose automáticamente se haga el request y la oferta quede pendiente. Por ejemplo, si se ha hecho ya el request, esto podría quedar vacío.

Por otro lado tenemos la URL a la que llamar y los parámetros que podríamos pasar para filtrar. De la misma manera, podemos dar mucha cantidad o poca. Lo que sí que será obligatorio es un campo de API Key, un identificador único complejo.

  • API Key [apikey]: Identificador de al menos 32 bytes (un alfanumérico sería suficiente) que te identifique como usuario.

Con esto podríamos tener una URL del estilo a https://www.example.com/offers.json?apikey=xXxX0123 que te devolvería todas las ofertas.

Además podríamos incluir varios parámetros para filtrar resultados:

  • Punto de inicio [start]: Página por la que comenzar. Por ejemplo, 0, 100, 200…
  • Cantidad de ofertas a mostrar [limit]: Un número de ofertas, por ejemplo, 100.
  • Ordenación de resultados [order]: Con posibilidad ascendiente o descendiente, asc o desc según las ofertas sean nuevas o viejas.
  • Oferta [offerid]: Sólo te mostraría esa oferta en concreto
  • Un país en concreto [country]: Le pasas un país y sólo te devuelve de ese país.
  • Un sistema operativo en concreto [device]: con un par de opciones del tipo ios o android.

Estos valores de país y dispositivo podrían combinarse para mostrar por ejemplo sólo las ofertas de Estados Unidos con iPhone o de Francia con Android.

Para solicitar una oferta podemos tener una URl en la que le pases obligatoriamente dos parámetros: la oferta y un aviso de request.

  • Oferta [offerid]: Sólo te mostraría esa oferta en concreto
  • Activar solicitud [request]: con un valor de 1 sería suficiente

De forma que una llamada a https://www.example.com/offers.json?apikey=xXxX0123&offerid=123&request=1 activaría la solicitud de esa oferta. La respuesta sería la información de esa oferta en concreto. El resultado en JSON podría quedar algo parecido a esto:

URL de llamada: https://www.example.com/offers.json?apikey=yYZBq4a7zG9QePusTJNzFZRdvmMEAfkr

Respuesta:

[{
  "offerid": 12345,
  "name": "WhatsApp - US - Android - non-incentivated",
  "payout": 0.45,
  "currency": "USD",
  "country": [{
    "ES",
    "FR"
  }],
  "device": [{
    "iPhone",
    "iPad"
  }],
  "incent": 0,
  "capping_day": 2500,
  "capping_day_left": 2157,
  "capping_month": null,
  "capping_month_left": null,
  "capping_total": null,
  "capping_total_left": null,
  "preview": "https://play.google.com/store/apps/details?id=com.whatsapp",
  "url": "https://www.example.com/tracking/?offerid=12345&publisher=12345",
  "description": null,
  "type": "CPI",
  "status": "request",
  "request": "https://www.example.com/offers.json?apikey=yYZBq4a7zG9QePusTJNzFZRdvmMEAfkr&offerid=12345&request=1"
}]

Ley de Cookies y DNT

Últimamente en Europa todas las webs por las que navegas tienen un mensaje que te dice que esa web tiene cookies. Esto es debido a un cambio en una ley que obliga a los sitios que usan “cookies de terceros” a informar de ello. Para empezar, no existen las “cookies de terceros” ya que todas las cookies son de primeros, porque las genera el propio sitio (otra cosa es que las puedan leer terceras herramientas). Volviendo al tema, el problema de esta ley es que tal y como está planteada tienes las siguientes opciones:

– Entras en la web y te aparece el mensaje. Tienes dos opciones, aceptar las cookies, y seguir navegando, o no aceptar cookies y probablemente no poder seguir navegando, ya que si desactivas las cookies es probable que muchos sitios dejen de funcionar.

– Si no desactivo las cookies estoy dejando que me espíen con esas “cookies de terceros”, y si no lo acepto, no puedo navegar, porque incumplo una ley… algo que personalmente creo que va en contra de la competencia.

Independientemente de todo esto, creo que todo este tema está muy mal planteado, ya que el asunto de fondo no son las cookies, sino la privacidad. Esta ley se hizo pensando en que la culpa de que “nos espíen” son las cookies, cuando las cookies son parte de los sitios web y no un “problema”. Lo que no acabo de entender es porqué no se dieron pasos más allá para la mejora de este asunto y se hizo una ley que está hecha por gente inculta en la materia.

¿Existe una solución a todo este fregao? Sí. Se llama Tracking Preference Expression (DNT) y es un estándar web. Y es que desde hace bastante tiempo que los navegadores suelen llevar una opción en la zona de Seguridad o de Privacidad que te dice si quieres que te rastreen o no. Sólo hay dos opciones: Sí o No (¡para qué más!).

La cuestión es la siguiente… si el problema de fondo de todo esto es la privacidad ¿por qué no dejar al usuario que elija su privacidad y dejamos a los desarrolladores que puedan usar tranquilamente las cookies? Pues de eso se trata el DNT, de separar las cookies de la privacidad.

El protocolo DNT es una cabecera HTTP y tiene dos partes, la primera de ellas es la que el navegador le dice al servidor si quiere ser trackeado o no; la segunda de ellas es que la web conteste al navegador qué tipo de seguimiento se está haciendo.

En el primer caso se dan, en principio, dos opciones:

  • DNT: 0 – El usuario indica que se le puede hacer seguimiento.
  • DNT: 1 – El usuario indica que no se le puede hacer seguimiento.

Existe otra opción y es que exista la cabecera DNT pero que no lleve valor. En este caso se ignoraría el sistema, lo que se daría como DNT: 0.

La web de destino, cuando recibe esto ha de hacer lo que ha de hacer (o sea, se supone que cumplir las reglas) y debe devolver una cabecera en la que se informa qué se ha hecho. Existen varios valores, aunque ciertamente sólo hay 4 realmente útiles. Voy a centrarme en los útiles:

  • Tk: ! – El sistema está en desarrollo o pruebas.
  • Tk: N – No se hace seguimiento del usuario.
  • Tk: T – Sí se hace seguimiento del usuario.
  • Tk: D – No se puede respetar la decisión del usuario.

Hay herramientas del estilo a Ghostery que son capaces de interpretar estos datos.

Un ejemplo de esta implementación la podemos encontrar en gran parte de Geenapp (en el momento en el que estoy escribiendo esta entrada, se le da soporte a todos los paneles y herramientas, pero no a las “webs corporativas” o “de ayuda”) y se puede encontrar un resumen de ello en los documentos públicos accesibles. Por ejemplo, el panel de Publisher lo cumple, y dispone de su fichero informativo. En este caso, cuando el usuario tiene activo este valor, cargamos cookies y trabajamos normalmente, pero las herramientas externas de medición como Google Analytics, Hotjar y similares quedan automáticamente inhabilitadas (no se cargan los códigos) por lo que no hay herramientas de terceros que hagan seguimiento, y nosotros internamente tampoco lo hacemos a menos que sea estrictamente necesario para el funcionamiento de la plataforma.

¿Tiene sentido pues una ley que realmente no hace su trabajo, que es incómoda para los usuarios y que no tiene utilidad ya que sigue permitiendo que los usuarios sigan siendo invadidos por empresas que recogen sus datos?

Jerga Twittera

Seguramente en alguna ocasión te has encontrado con letras al principio de un Tweet, o al final, o gente que pide RT. ¿Qué significan las siglas que nos podemos encontrar en un Tweet?

RT (Retweet)

Un Retweet (o RT para acortar) es una de las funcionalidades creadas por los usuarios de Twitter en sus inicios que ahora es una de las funcionalidades clave de la plataforma. Básicamente es lo mismo que decir que “re publiques” eso en tu cuenta. Ahora Twitter tiene el icono para hacerlo con un clic, aunque siempre puedes hacer RT con un comentario añadido.

Fav (Favorito)

Pedir un Tweet como favorito simplemente es que se marque como tal. Los favoritos básicamente se indican por tres razones: porque te gusta el Tweet y quieres guardarlo, porque quieres hacer un guiño a la persona que lo ha escrito o simplemente porque te quieres guardar ese contenido para leerlo después con más calma (porque lleva una imagen, un enlace o similar).

#FF (Follow Friday)

Aunque hay muchos #hashtags similares al Follow Friday, quizá este sea el más conocido. Este hashtag básicamente se indica al principio o final de un Tweet en el que hay una serie de nombres de usuario de Twitter a los que deberías seguir. Otras veces se pone un texto explicando el porqué de seguir a esa o esas cuentas.

Hasta aquí quizá tenemos los elementos más habituales de Twitter, pero no son los únicos.

MT (Modified Tweet)

Similar a los RT, básicamente son menciones de un Tweet original pero que se han modificado. Normalmente son Tweets recortados para que el que lo reescribe pueda hacer algún comentario.

RLRT (Real-Life Retweet)

¿No te ha pasado alguna vez que alguien dice algo y dices: voy a twittear esto? Pues un RLRT básicamente es eso, es poner en un Tweet lo que otra persona ha dicho, indicando quién (si pones el usuario, mejor que mejor).

OH (Overheard)

Es muy similar al RLRT pero en el que no mencionas a la persona que lo dice. Además, decirlo, quedaría feo. Normalmente estos mensajes se dejan como un guiño al grupo de personas que estaba en el momento en el que se dijo “y que ellos saben qué significa”.

Los siguientes son cosas que ocurren más que acciones concretas. Algunas de ellas demasiado habituales.

Twitter Canoe

Seguro que alguna vez ves que de golpe alguien te hace una mención. A ti y a otros pocos más. Esa conversación sigue y sigue. Si miras el origen tú ni siguiera estabas, y es una conversación de la que no puedes salir pero en la que tienes que decidir si entrar o no (por algo te han añadido)… Ese arrastre es el llamado Twitter Canoe.

Subtweet

Un Subtweet (subliminal Tweet) es eso, un Tweet subliminal. Similar al OH pero que en realidad dices tú por ti mismo. Simplemente lo sueltas “y quien quiera que lo entienda”, sin decir nombres, sin hacer referencia alguna a alguien… un Tweet de esos que atraviesan con la mirada.

Tweetstorm (Twitterstorm)

Una tormenta de Tweets es lo que ocurre por la limitación de los 140 caracteres y alguien tiene mucho que decir. Es por esto que delante del Tweet se indica que es como un tweet múltime de forma que tenemos algo como [1/3 blah blah blah] [2/3 muah muah muah] y [3/3 buh buh buh] quedando una conversación larga de un tweet. En caso de tener que hacer RT de ello, lo mejor es hacerlo del primero.

Seguro que hay muchas más cosas por Twitter de las que desconocemos… pero esto es simplemente un pequeño resumen de lo más habitual.

Esta entrada está basada en Twitter Demystified: How To RT, MT, #FF And Fave Like A Pro.

Crea una web-app de forma rápida y sencilla

Muchas veces en nuestro navegador de escritorio nos hemos guardado una página en la barra de favoritos para que en un clic esté disponible. En los dispositivos móviles esto también es posible y, para que quede bien tan sólo hemos de añadir unas pocas líneas en la cabecera de nuestra página.

<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-barstyle" content="black-translucent">
<meta name="apple-mobile-web-app-title" content="My web name">
<link rel="apple-touch-icon" href="http://www.example.com/icon-152.png">
<meta name="mobile-web-app-capable" content="yes">
<meta name="application-name" content="My web name">
<link rel="shortcut icon" sizes="196x196" href="http://www.example.com/icon-196.png">

¿Cómo se puede añadir el iciono al escritorio de nuestro dispositivo?

En Firefox, si nos vamos al Menú de Opciones -> Página -> Añadir a la Pantalla de Inicio.

En Chrome, si nos vamos al Menú de Opciones -> Añadir a pantalla inicio.

Cada navegador tiene su propia forma de añadirlo, pero todos los permiten así que ya sabes, si visitas con cierta frecuencia un sitio y quieres un enlace directo, o si tienes un sitio web y quieres que tus usuarios tengan unos iconos de calidad…

Tipos de analítica para Apps

Quizá estamos muy acostumbrados al uso de Google Analytics para la medición de los sitios web, pero esto no siempre se está aplicando a las Aplicaciones móviles, tanto nativas como híbridas. Y es que la analítica de Apps todavía es algo compleja ya que a veces requiere de varios servicios para analizar todo lo que se debe analizar.

¿Y qué es lo que se debe analizar? Pues podríamos decir que hay 3 tipos de elementos a analizar y que, probablemente, cada uno de ellos requiera de una herramienta o sistema distinto.

Analítica de Marketing

Hay una serie de datos importantes a la hora de tener en cuenta en marketing y/o publicidad, y es principalmente saber cómo se ha conseguido que el usuario se instale la App, es decir, su origen y, a partir de aquí, todo lo que puede suponer esa fuente a la hora de analizar beneficios.

Esto podría suponer la medición de indicadores como instalación, aperturas de la App, compras, registros y otros eventos. Lo importante de aquí es más poder asignarlo a una fuente y saber dónde conseguir el mejor tipo de usuarios posible. Este tipo de inform,ación nos puede dar el ROI y/o el LTV de una campaña y de sus usuarios.

Sin este tipo de herramientas no hay ninguna forma fiable de saber qué anuncios o desde dónde viene el tráfico que está consiguiendo nuestros objetivos. En general a este tipo de sistemas se le llaman herramientas de tracking.

Analítica de Uso

Esta es la más parecida a la analítica “tradicional” de los sitios web, aquella que nos permite ver qué hace el usuario dentro de una App, cómo navega y nos permite mejorar la App en sí y no focalizarse tanto en la calidad de sus usuarios.

Aquí podremos analizar el funnel de uso de la aplicación, ver desde dónde comienza el usuario a utilizar, dónde deja de usarla, cuándo podríamos aplicar un mensaje de aviso para alguna acción.

Además, este tipo de analítica nos da información sobre el dispositivo (Sistema Operativo, Marca, Modelo), configuración del mismo (País, Idioma, Geolocalización) y eventos dentro de la aplicación (que se pueden combinar con los del paso anterior).

Analítica de Rendimiento

Quizá este es el punto al que menos desarrolladores llegan, y es saber el estado de la App desde el punto de vista de rendimiento. ¿Qué significa esto? Pues por ejemplo si la App se abre y funciona correctamente, si tiene conexión a Internet (si la necesita) o si ha sufrido cortes y, principalmente, si la App funciona en el dispositivo en cuestión.

¿Qué se debería tener en cuenta en estos casos? Para empezar la dependencia de servicios externos, como por ejemplo el acceder con una cuenta de Facebook o twitter, las diferentes versiones de hardware que disponen los dispositivos Android (en iOS o Blackberry es más sencillo ya que los dispositivos son siempre iguales) o los distintos tipos de conectividad según cada operador (no es lo mismo un GPRS que un 4G o WiFi, ni la conexión de un operador u otro).

Y hasta aquí los tres grandes grupos de analítica para Apps. Te recomiendo darle una ojeada a estas dos entradas que publiqué hace un tiempo: Tracking de Instalaciones en Apps y Atribución en App móvil.

Cómo conseguir instalaciones para mi App

Read this entry in english: How to get Installs for my App.

Existen millones de Apps, algunas sólo para Android, otras sólo para iOS, otras para todos los sistemas; esto es así y cada vez va a ir a más. Y de aquí sale la pregunta: si existen tantas Apps ¿cómo va a conocer la gente mi App?

Existen muchas formas de promocionar una App. Sin un orden concreto: auto-promoción, intercambio, publicidad in-app, App Discovery, ASO, Pago por Instalación… Voy a intentar explicar, antes de nada, qué es cada una de ellas y más o menos cómo funciona, ya que, al final, no olvidemos que nuestro objetivo es conseguir instalaciones de nuestra App, que es la única forma de, después, monetizarla de alguna manera.

Auto-Promoción

Básicamente es que dentro de tus propias Apps lanzas algún tipo de mensaje que incita a instalar otra App tuya. En general esto se ve mucho en los juegos que, antes o después, te sale un splash en el que se promociona otro juego. También se ve bastante con una App gratuita que promociona su versión premium que suele ser de pago.

Intercambio

Existen varias empresas en el mundo que ayudan a esto. El sistema es sencillo: donde aparece la publicidad in-app en realidad no hay publicidad sino que aparecen anuncios de otras Apps. Si tu muestras 100 impresiones de otras Apps, otras Apps de la red mostrarán 100 anuncios de la tuya. El secreto de este sistema es hacer muy buenas promociones. Con esto no ganas dinero porque ocupas el espacio publicitario con promociones.

Publicidad In-App

Como no podía ser de otra manera tenemos la posibilidad de hacer campañas de publicidad dentro de las Apps. Principalmente a través de iAd (Apple) o de Admob (Google). Esto es lo más parecido a la publicidad de Internet, en la que funcionan los banners. Este sistema está bien, pero en general es más para hacer branding que para conseguir instalaciones, ya que en general la conversión suele estar entre el 0% y el 1%.

App Discovery

El sistema de descubrimiento de Apps puede consistir en una App que te recomiende otras Apps, o una web que lo haga.

ASO (App Store Optimization)

Es el “SEO para Apps” y se basa principalmente en hacer cambios “on-page” en la tienda de aplicaciones, donde mejorando el título, los textos, las imágenes y haciéndolas más atractivas y buscables aparecen mejor en las búsquedas de Apps de los usuarios y por tanto obtienen más posibilidades de conversión.

CPI (Coste por Instalación)

Y por último, y casi diría que más importante, el CPI o Pago por Instalación, que es donde se va a encontrar el mercado de las Apps en el mundo del marketing de Apps. El sistema es sencillo, tu propones un precio por cada instalación que se consiga (por ejemplo 1 dólar) y cada vez que alguien consiga una instalación se le paga esa cantidad. Lo más interesante de este sistema es que funciona por objetivos, por lo que únicamente pagas por lo que consigues y vas a rendimiento.

Ahora que ya conocemos los diferentes sistemas de conseguir instalaciones, hay otro detalle importante: tener instalado un sistema de medición (también conocido como tracker). Hay dos tipos de trackers, los que permiten hacer “postback” y los que no. El postback es un sistema que cada vez que alguien nuevo se instala una App el sistema avisa a un lugar diciendo que se ha conseguido esa instalación. Esto permite crear publicidad basada en rendimiento. Pongo un ejemplo:

Imagina que lanzas una campaña de publicidad de tu App. La promocionas en un código QR de una parada del autobús y en un anuncio en televisión. Los usuarios se instalan tu aplicación pero ¿desde dónde han llegado esas instalaciones? Qué es lo que ha funcionado mejor, la parada de autobús o la televisión?

En este punto hay que marcar una parada, ya que hay que tener en cuenta que los servicios como Google Analytics y otros no son capaces de medir la información en iOS ya que Apple, cuando llega la información a iTunes corta todo sistema de seguimiento. Es por esto que un simple Google Analytics no te va a servir para las campañas de publicidad porque no sirve para medir correctamente. Para ello debes utilizar alguna de las herramientas de seguimiento que hay en el mercado, además de leer sobre el funcionamiento de las formas de hacer seguimiento y de la forma de atribución.

Ahora que tenemos las formas de promocionar la App y las formas de medición nos aparece otra situación y es si realmente podemos conseguir instalaciones con los sistemas propuestos anteriormente.

En el caso de la auto-promoción se pueden conseguir, pero necesitas que tu App tenga muchas visitas, que no es la norma general, así que queda bastante descartado.

El sistema de intercambio puede servir para los inicios, pero también dependes de que tu App tenga mucho uso, y seguramente si tienes una App de éxito lo que quieres es ganar dinero con publicidad y no promocionar otras Apps mediante intercambio, así que, para los inicios bien, pero tampoco asegura instalaciones.

La publicidad in-app es una forma de conseguir instalaciones que funciona, pero que hay que meter en el saco y verificar que las conversiones, el ITR (Install Through Rate) es razonable y que no perdemos dinero invirtiendo en publicidad y luego no consiguiendo instalaciones (es básico saber el Coste de Instalación para poder medirlo).

El App Discovery es un concepto que sigue anclado en el marketing tradicional y que funciona en base a clics, lo que supone que los ITR nunca acaban de funcionar ya que el coste de una instalación se puede multiplicar entre 5 y 25 veces más de lo que se puede conseguir de otras maneras, y principalmente es debido a que estas plataformas no miden.

El ASO es un sistema que, independientemente de conseguir o no instalaciones deberíamos tener siempre presente ya que es clave tener una buena página en la tienda de aplicaciones, consigamos o no instalaciones. El ASO es una profesión muy nueva y sin duda te recomendaría hablar con el equipo de PickASO.

Para acabar, el CPI es el sistema que principalmente está funcionando en el sector y que parte de la base de que es por objetivos, de forma que pagas por lo que consigues. Lo único es que poco a poco va a requerir de muchos servicios de RTB, porque comienza a encontrarse que varias agencias quieren promocionar la misma App en los mismos países y dispositivos y cada uno haga diferente, de forma que habrá herramientas que ordenen esas campañas por las que los anunciantes tendrán que competir. Este es el sistema que utilizamos en Geenapp.

Otro detalle interesante es que muchas agencias y anunciantes están planteando las limitaciones diarias de instalaciones. Esto hoy en día sin una plataforma que lo haga o unos sistemas de integración complejos gracias a los postback difíciles de conseguir, es muy complicado de conseguir.

También es muy importante, antes de promocionar una App, saber cuál es el público objetivo al que podemos llegar, ya que si nuestra App sólo funciona en la última versión del sistema operativo, tenemos muchas posibilidades de que la App no convierta y la campaña sea un fracaso, no porque no se esté promocionando correctamente, sino porque la App no es compatible con el mercado actual, por lo que es importante revisar bien qué tipos de dispositivo y versiones existen en cada país.

Ahora que conoces las formas de conseguir instalaciones, la necesidad de tener un sistema de tracking instalado en la App y la necesidad de estudiar el mercado ¿a qué esperas para lanzar tu campaña? Si necesitas ayuda o quieres más información, no dudes en ponerte en contacto conmigo.

How to get Installs for my App

Lee esta entrada en español: Cómo conseguir instalaciones para mi App.

There are million of Apps, some only for Android, some only for iOS, some for all systems; This is so and it will go far. So, that is the question: if there are so many Apps, how people are gonna know my App?

There are many ways to promote an App. Without any order: self-promotion, cross-promoting, in-app advertising, App Discovery, ASO, Pay per Installation… I’m going to try, before anything, what are everyone and more or less how it works so, at the end, we can’t forget that our focus is to get installs for our App, which is the only way to monetize it in some way.

Self-Promotion

It is basically that within your own App you launch some kind of promotional message to install another App of yours. In general I saw this in games, before or after, you get a splash that promotes another game. Also you can see it in free Apps that promotes its premium version, which is usually a paid one.

Cross-Promoting

There are several companies in the world to help this method. It’s simple: where an ad appears actually there is no advertising but that are ads for other Apps. If you promote 100 other App impressions, other Apps in the networks will show 100 ads of yours. The secret of this system is to make the best display ads. With this method you don’t earn any money because your display slot is full of other cross-promotion ads.

In-App Advertising

As it could not be otherwise we have the possibility of making advertising within Apps. Mainly through iAd (Apple) and Admob (Google). This is the closest thing to the actual Internet advertising, with banners display ads. In-App Advertising is OK, but in general is more focused to branding than to get installs since, in general, the conversion tends to be between 0% and 1%.

App Discovery

App Discovery may consist of an App that recommends you other Apps, or a web that makes also that.

ASO (App Store Optimization)

It’s the “SEO for Apps” and relies mainly on making changes “on-page” in the app store where improving the title, texts, images and making them more attractive and searchable maks to appear better in searches for Apps and increases the chances of conversion.

CPI (Cost per Installation)

Finally, and I would say that is the most important, CPI or Pay for Installation which is where the Apps market is going. You propose a price for each install that has been achieved (for example 1 dollar) and whenever someone gets an installation is paid that amount. The most interesting thing about this system is that it works by objectives, so you only pay for what you get and you can get performance.

Now that we know the different methods to get installations, there is another important detail: you need a measuring system (also known as tracker). There are two types of trackers that allow “postback” and those who do not. The postback is a system that everytime someone new installs an App the system notifies somewhere saying that installation has been achieved. This allows to create performance-based advertising. I put an example:

Imagine that you launch an App advertising campaign. You promote it in a QR code from a bus stop and in a television ad. Users installs your application but, what are the source from this installations? What ad had worked better, the bus stop or the television one?

At this point we need to make a little stop, as must be taken into account that services like Google Analytics and others are not capable of measuring information in iOS since Apple, when the campaign arrives to iTunes, all the information is blocked to tracking methods. Therefore Google Analytics will be use useless to advertising campaigns because it does not measure correctly. For this you should use any tracking tools that are on the market, as well as read about the functioning of ways to track (in spanish) and attribution methods (in spanish).

Now that we have the ways of promoting Apps and ways of measuring it, appears to us the question about if it’s possible to get installs with thos previously proposed methods.

In the case of self-promotion you can get installs, but you need that your App has many visits, that is not the norm, so it is quite out of the question.

The cross-promotion method can be used when you launch an App, but you also depend that your App have much use, and surely if you have a successfull App what you want is making money with advertising and not promote other Apps through cross-promotion, so for starters is gonna go well, but neither secures installations.

In-app advertising is a way to get installs that works, but you need to put tehm in a bag and check that conversions, that its ITR (Install Through Rate) is reasonable and not lose money investing in advertising and then not getting installations (it’s essential to know the Cost of installation to be able to measure it).

App Discovery is a concept that is anchored in traditional marketing and works based on clicks, which means that ITR do never work since the cost of an installation can be multiplied between 5 and 25 times more than what can be achieved in other ways, and is mainly due to the fact that these platforms do not measure.

ASO can get or not installations, but you should always bear in mind since it’s key to have a better page in app stores, getting or not installations. ASO is a very new profession and would definitely recommend you to speak with the PickASO team.

Finally, the CPI is mainly operating in the sector and part of that is because is focused in objectives, in such a way that you pay for what you get. The only thing is that it will gradually require many services of RTB, because it begins that various agencies want to promote the same App on the same countries and devices so, in such a way that there will be tools that sort these campaigns that advertisers will have to compete. This is the system we use at Geenapp.

Another interesting detail is that many agencies and advertisers are thinking about daily limitations of installations. Today, without a platform that does it or complex integration systems with some complex integrations with postbacks, is very difficult to get.

It’s also very important, before promoting an App, know what the target audience that can be reached, if our App only works in the latest version of the operating system, we have many possibilities that the App does not generate installations and the campaign become a failure, not because is not at successfull promoting, because the App is not compatible with the current market, so it is important to review all types of device and versions existing in each country.

Now that you know the ways to get installations, the need having a tracking installed on the App and to study the market, what are you waiting to launch your campaign? If you need help or would like more information, do not hesitate to get in touch with me.