El retorno del Javi

Hacía unos 4 meses que estaba muy desaparecido. En realidad casi desde el comienzo del año (el 1 de septiembre del año pasado) que fue cuando comenzó todo. Oficiaosamente que ya no sigo en Geenapp (aunque de facto ya este último mes he estado fuera al 95%). Han sido 4 años justos desde que comenzamos aquel experimento poco antes del Mobile World Congress.

Este año cumplo 20 años del lanzamiento de mi primer sitio web. Aunque comencé a conectarme en 1994 en casa de un colega, siempre he marcado la fecha de 1997 porque es cuando realmente aporté algo a la red de redes. Desde aquel momento es posible que haya estado sin conectarme a Internet un máximo de 60 días.

Ahora toca dar un pequeño cambio a mi día a día. Por ahora colaboraré en BoatBureau (una de las empresas en las que participo como socio a través de Keep It Simple Lab) y comenzaré a recuperar mi ejercicio de consultor o como se le quiera llamar. En estos últimos años he estado ayudando de forma puntual a startups a montar su base digital, también en alguna que no era tan start y es que, no me cansaré de decir, que para trabajar en Internet hay que saber de Internet. No olvidemos que Internet es una red digital de datos, con servidores y servicios que son los que hacen que funcione. Y si quieres estar tranquilo y que todo funcione has de configurar todo correctamnente. Y por ahí voy a estar los próximos meses, trabajando en ese sentido.

Otra cosa que hacía tiempo que no esperaba recuperar es mi estado de autónomo; es una mezcla de libertad (poder trabajar en muchos temas distintos) y palo por la gestión que ello significa. Creo que estará bien volver al mercado con la visión mobile que he ganado en estos últimos años.

Estas dos cosas hacen que vuelva a estar disponible también para plantearme si lanzar mi propio proyecto; no es algo que tenga en mente a corto plazo y tampoco sé ahora mismo si me encuentro con las fuerzas suficientes para estar sin dormir un año 😉 pero un primer paso está siendo el de recuperar algunos sitios web y principalmente todos los textos que he encontrado en backups de bases de datos y que he ido publicando en casares.blog, desde mis primeros textos colaborativos en 1999 de la @RROBA es BELL@.

Como siempre, si alguien quiere contactar conmigo, sólo tiene que entrar en mi web y escribirme, llamarme o lo que quiera.

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.

Instalar Apache 2.4 en CentOS 6

Voy a ir bastante al grano. Es para instalar la versión Apache 2.4.7.

yum -y install rpm-build

mkdir -p ~/rpmbuild/{SOURCES,SPECS,BUILD,RPMS,SRPMS}

cd ~/rpmbuild/SOURCES

wget http://ftp.cixug.es/apache//httpd/httpd-2.4.7.tar.bz2

En general, si ejecutamos lo siguiente fallará (sino perfecto y te ahorrarás un montón de pasos siguientes…)

rpmbuild -tb httpd-2.4.7.tar.bz2

Para corregir esto hay que instalar un montón de cosas

cd ~/rpmbuild/SOURCES

wget http://ftp.cixug.es/apache//apr/apr-1.5.0.tar.bz2

wget http://ftp.cixug.es/apache//apr/apr-util-1.5.3.tar.bz2

cd ~/rpmbuild/SOURCES

Ahora tendremos un tema y es que hay que tocar cosas del kernel. Como eso suele estar bloqueado, deberemos hacer lo siguiente

sudo vi /etc/yum.conf

y aquí, en el fichero, debemos comentar o eliminar la línea correspondiente (vamos a comentarla)

#exclude=kernel*

A partir de aquí seguimos adelante

sudo yum install kernel-headers

yum -y install autoconf libtool doxygen

rpmbuild -tb apr-1.5.0.tar.bz2

Es probable que esto último falle. Si pasa esto, haremos una revisión de los rpm instalados anteriormente

rpm -qa | grep -i apr

Si existen paquetes anteriores, haremos un “update”, sino un “install”

# UPDATE:
rpm -U ~/rpmbuild/RPMS/x86_64/apr-1.5.0-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/apr-devel-1.5.0-1.x86_64.rpm

#INSTALL
rpm -ivh ~/rpmbuild/RPMS/x86_64/apr-1.5.0-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/apr-devel-1.5.0-1.x86_64.rpm

y continuamos:

yum -y install expat-devel libuuid-devel db4-devel postgresql-devel mysql-devel freetds-devel unixODBC-devel openldap-devel nss-devel

cd ~/rpmbuild/SOURCES

yum install sqlite-devel

rpm -ivh ftp://fr2.rpmfind.net/linux/dag/redhat/el6/en/x86_64/dag/RPMS/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

cd /etc/yum.repos.d/

wget http://rpms.famillecollet.com/enterprise/remi.repo

yum install freetds freetds-devel

cd ~/rpmbuild/SOURCES

rpmbuild -tb apr-util-1.5.3.tar.bz2

cd ~/rpmbuild/SOURCES

Aquí nos encontramos con la situación anterior… revisamos si existen los paquetes

rpm -qa | grep -i apr-util

Si existen paquetes anteriores, haremos un “update”, sino un “install”

#UPDATE
rpm -U ~/rpmbuild/RPMS/x86_64/apr-util-1.5.3-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/apr-util-devel-1.5.3-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/apr-util-ldap-1.5.3-1.x86_64.rpm

#INSTALL
rpm -ivh ~/rpmbuild/RPMS/x86_64/apr-util-1.5.3-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/apr-util-devel-1.5.3-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/apr-util-ldap-1.5.3-1.x86_64.rpm

y continuamos

cd ~/rpmbuild/SRPMS

wget http://www.gtlib.gatech.edu/pub/fedora.redhat/linux/releases/18/Fedora/source/SRPMS/d/distcache-1.4.5-23.src.rpm

rpmbuild --rebuild distcache-1.4.5-23.src.rpm

rpm -ivh ~/rpmbuild/RPMS/x86_64/distcache-1.4.5-23.x86_64.rpm ~/rpmbuild/RPMS/x86_64/distcache-devel-1.4.5-23.x86_64.rpm

cd ~/rpmbuild/SOURCES/

yum -y install pcre-devel lua-devel libxml2-devel

rpmbuild -tb httpd-2.4.7.tar.bz2

yum -y install mailcap httpd-mmn

Aquí hemos de revisar un par de cosas… la primera es si ya teníamos un Apache instalado anteriormente, y el PHP… en este último caso, deberíamos desinstalar PHP (luego reinstalarlo).

#UPDATE APACHE HTTPD
rpm -U ~/rpmbuild/RPMS/x86_64/httpd-2.4.7-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/httpd-tools-2.4.7-1.x86_64.rpm

#INSTALL APACHE HTTPD
rpm -ivh ~/rpmbuild/RPMS/x86_64/httpd-2.4.7-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/httpd-tools-2.4.7-1.x86_64.rpm

Para acabar, pondremos correctamente los ficheros de configuración (en caso de que hubiera una instalación anterior)

mv /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.old

mv /etc/httpd/conf/httpd.conf.rpmnew /etc/httpd/conf/httpd.conf

Y con esto debería estar vuestro Apache HTTPD 2.4.7 instalado y funcionando, aunque ahora toca configurarlo.

HTML 5.1: elementos contenedores

Una de las grandes novedades en HTML 5 fue la incorporación tras muchos años de distintos contenedores que no dejan de ser más que un div pero que implícitamente incorporan cierto significado. En los nuevos borradores de HTML 5.1 se incorporan mejoras sobre estos elementos. Los elementos de los que estoy hablando son los siguientes:

Antes de nada voy a intentar hacer un repaso de cada uno de ellos, por orden alfabético, y al finalizar intentar poner un ejemplo de cómo debería construirse una página en base a estas informaciones.

address

Este elemento cambió radicalmente su concepto entre HTML 4 y HTML 5, y en esta última versión mantiene este nuevo sentido. El address representa la información de contacto del article más cercano (o padre) o del body en sí. Si se encuentra en el body sin un contenedor padre, se aplica a todo el documento.

El elemento address no debe representar una dirección postal, sino que debe aportar información de contacto relevante (por ejemplo el nombre, dirección de correo, un twitter, una dirección de facebook o similar), del autor del contenido en el que se encuentra. Este elemento sólo debe usarse para esta acción, la de dar información de contacto.

article

El elemento article representa de forma completa un contenido que podría ser reutilizado de forma independiente. Para poner un ejemplo claro, en una página de un periódico de papel, cada noticia sería un artículo por sí mismo, ya que tiene independencia completa de cualquier otro.

El elemento article puede contener otros article (o sea, es anidable), lo que significa que cada uno de esos elementos “pequeños” son independientes, pero conjuntamente pueden formar otro gran contenido.

En caso de querer indicar la información del autor de un article hay que utilizar el elemento address, y este es sólo aplicable a los extremos (es decir, no funciona en elementos contenedores, sino en los contenidos).

aside

El elemento aside representa una zona de la página con contenido “tangencialmente relacionado” al contenido principal de la página, pero que puede considerarse separado del mismo.

Volviendo al ejemplo de los periódicos, vendría a ser esos pequeños textos que suele haber en una noticia pero que no son la noticia en sí. Este bloque puede ser para dar información en otro tipo de tipografía, anuncios, grupos de enlaces y navegación o similar, que pueden considerarse independientes del contenido principal de la página.

body

El elemento body representa el contenido del documento, y por tanto sólo puede haber uno en cada página. Este es uno de los elementos más históricos del HTML, por lo que no creo que necesite mucha explicación.

div

El elemento div no tiene un significado especial, es simplemente un contenedor que permite agregarle información semántica no implícita. Es uno de los elementos “comodín”.

Por ejemplo, si tuviéramos una noticia en la que hay varios fragmentos de texto en varios idiomas, podríamos usar este elemento para indicar dicho idioma, pero no afectaría a, por ejemplo, que en un article haya varios div, a nivel semántico.

footer

Este es otro de los elementos que se añadió en la anterior versión y que tiene algunas diferencias con lo que habitualmente se tiene presente. Este elemento no es para simplemente dar formato al pie de página, sino que tiene muchos otros significados.

El footer representa el pie de su elemento superior (ya sea uno de los contenedores o de todo el body). En general el footer incluye información del autor, enlaces a documentos relacionados, copyright y similares.

Cuando encontramos que en el footer tenemos secciones enteras, podemos considerar que representan índices, licencias y contenidos por el estilo.

La información del autor, aunque se encuentre dentro del footer habría que integrarla en el elemento address (aunque sea en el footer mismo). En general este elemento se podría intercambiar con el header, aunque suele dejarse para ampliar o dar interpretaciones del autor a los elementos principales.

También hay que tener en cuenta que el footer no tiene que encontrarse obligatoriamente al final de un contenedor.

header

El elemento header representa el contenido introductorio del contenedor en el que se aloja. En general encontramos elementos introductorios o navigacionales.

En general aquí encontramos elementos como encabezados (los h1h6), aunque también podría ser una “tabla de contenidos”, una caja de búsqueda o el logo.

Al igual que ocurre con el footer, se suelen utilizar únicamente como la cabecera y pie de una página (body) pero no se les da un uso habitual y debido en los article o section.

Este elemento no puede estar anidado en sí mismo, pero sí sobre sus diferentes padres, lo que permite que haya varios en una página.

main

Este es quizá uno de los elementos más esperados en HTML, y que se complementa de forma perfecta con los elementos incorporados en HTML 5.

El elemento main representa el contenido principal de un body. Digamos que el main es el contenido principal de la página, donde se encuentra la chicha, donde se encuentra la zona principal de la aplicación.

Hay que tener en cuenta que este elemento no permite ser parte de otros elementos como article o section, aunque sí del body, y que sólo puede haber un main por página.

El elemento main debería incorporar el contenido principal de la página, incluyendo elementos como los datos del autor, copyright, enlaces, logos, buscador, etc… siempre y cuando tengan relación con el contenido principal del documento.

nav

El elemento nav representa una zona de la página en la que hay enlaces a otras páginas o a otras zonas de la página.

Hay que tener en cuenta que esto, en principio, no debería ser un listado de elementos, sino una zona de navegación. Esto significa que no todos los enlaces de una página han de encontrarse dentro de este elemento.

Los sitios más habituales donde encontraremos este elementos son al final de la página, dentro de un footer, donde se va a los términos y condiciones, a la página principal… También los podemos encontrar de forma habitual dentro de los aside, enlaces relacionados con el contenido principal.

section

El elemento section hace referencia a cada uno de los bloques genéricos de un gran contenido. Por ejemplo, dentro de la noticia de un periódico que tenemos un titular (probablemente con un h1) y varios subtítulos (seguramente con varios h2h6), cada uno de estos bloques probablemente sea un section.

Ejemplos variados podrían ser los distintos capítulos, diferentes pestañas dentro de una página o las distintas partes de una tesis. En una página web podría ser la introducción, las noticias y la información de contacto.

En general el section queda bastante relegado al elemento article que le da más sentido al contenido en sí. La gran diferencia entre section y article es que el section forma parte de algo, y el article es el algo en sí mismo.

Llegados a este punto…

…podríamos decir que ya tenemos claro los distintos elementos contenedores que podemos encontrar en un documento HTML, y en general quedaría claro cómo organizar una página.

Un ejemplo sencillo es el de un blog. Un blog suele tener dos páginas principales para nuestro caso: los listados y los artículos. El caso de los listados la página debería tener algo como:

  • body
  • header
  • /header
  • main
  • section
  • /section
  • section
  • /section
  • section
  • /section
  • section
  • /section
  • section
  • /section
  • /main
  • section
  • nav
  • /nav
  • /section
  • footer
  • nav
  • /nav
  • /footer
  • /body

Tenemos un body principal que hace referencia a todo el documento. En él tenemos una cabecera header que sería el titulo del blog, un cajetín de búsqueda, logos, publicidad, etc…

A partir de aquí tenemos el contenido principal main que es el listado de los artículos, que vendían representados por cada uno de esos section. Dependiendo del formato de cada uno de estos, podríamos considerar añadir su propia cabecera (header), pie (footer) y otros elementos (aside, nav…), aunque teniendo en cuenta que, por norma general los listados no contienen los artículos completos como en su propia página, no tendría sentido.

Tras esto tendríamos otra sección section que puede corresponder al menú lateral de navegación, opciones o como lo queramos llamar, en el que entre otras cosas podemos tener un menú de navegación nav (o varios) a otros listados (últimos artículos, últimos comentarios, publicidad, etc…).

Para acabar tenemos un pie de página en el que indicar cierta información, por ejemplo legal, además de un bloque de enlaces a distintas zonas de la página, y finalmente cerramos el contenido de la página.

Siguiendo con el mismo ejemplo, en este caso ya sí que de la entrada en concreto, podríamos tener los siguientes elementos:

  • body
  • header
  • /header
  • main
  • article
  • header
  • /header
  • section
  • /section
  • aside
  • /aside
  • section
  • /section
  • footer
  • address
  • /address
  • nav
  • /nav
  • /footer
  • /article
  • section
  • /section
  • /main
  • section
  • nav
  • /nav
  • /section
  • footer
  • nav
  • /nav
  • /footer
  • /body

Al igual que en el caso anterior, tenemos el cuerpo del documento, con su cabecera (igual que en el listado) y me voy a enfocar en este caso sólo a la parte principal main que es lo que cambia.

En este caso tenemos el contenido principal main que incluye un artículo article en el que existe una cabecera header (con el título del documento, la fecha de creación… entre otras cosas) y un primer bloque de información section.

Junto a esto tenemos otro bloque de contenido relacionado aside, dentro del mismo artículo, y otra sección, al que se finaliza con un pie de artículo footer en el que se incluye información del autor address además de enlaces a otras etiquetas nav, una zona para compartir el artículo.

Cuando se acaba la entrada article tenemos un bloque de comentarios section.

A partir de aquí ya tenemos lo mismo que en la plantilla de los listados, un menú lateral y un pie de página general.

Conclusión

Sin duda los elementos que añadió HTML 5, más el elemento main añadido en HTML 5.1 hacen que a nivel de organización de una plantilla, de una página o de cualquier tipo de documento generado en HTML se disponga de un significado semántico que si se aplica correctamente ayuda de forma elegante a las máquinas a comprender qué queremos destacar dentro de cada documento.

Personalmente creo que teniendo un poco de cuidado, principalmente con la anidación de elementos, y no haciendo un uso abusivo de ellos, se pueden conseguir grandes mejoras a la hora de desarrollar para Internet.

Atribución en App móvil

Hace un tiempo comenté cuáles son los métodos de seguimiento que existen para poder medir las acciones de una App. Pero los sistemas de seguimiento no son universales, como vimos, sino que dependen de las plataformas, terminales, etc.

Tradicionalmente, en la publicidad de Internet, la forma de atribución era bastante sencilla, ya que se almacena la información en las cookies y a partir de aquí se va aplicando según el caso, pero esto en los dispositivos móviles no es posible. ¿Cómo hacerlo entonces?

Podemos comenzar por ejemplo con el funcionamiento de Google Play y Google Analytics. En este caso, Google Play tiene una integración absoluta con Analytics, y su funcionamiento es exactamente igual que en las campañas tradicionales, ya que se permite el paso de los parametros “utm”. Si la App tiene instalado el SDK de Google Analytics, esta información se pasará a la plataforma de analítica. Para facilitar esta tarea podemos crear URL con la herramienta Google Play Campaign Tracking URL Builder.

Este sistema sólo funciona con Google Play, ya que como bien sabemos, iTunes bloquea cualquier tipo de parámetro en las direcciones URL, así que se genera un agujero negro en el que se pierde la información.

¿Por qué existen los famosos “trackers” entonces? Pues para resolver este agujero, en cualquier tipo de plataforma de desarrollo de aplicaciones. Para esto tenemos dos posibles sistemas el llamado Unique Identifier Matching y el Device Fingerprint Matching.

El sistema de Unique Identifier Matching aprovecha la información de dispositivo único que ofrecen los dispositivos móviles. Entre ellos están la MAC Address (a partir de la cual se pueden generar varios códigos), el android_id, el device_id, el ios_ifa, ios_ifv e incluso, por ejemplo en las BlackBerry, los PIN. En general el problema de estos identificadores es que el inicio del clic ha de estar en una aplicación del propio dispositivo, ya que estos identificadores son únicamente accesibles desde aplicaciones y no desde un navegador web o una web-app. Al instalar la App, como tiene acceso al mismo identificador, es muy sencillo hacer el matching y saber el origen de dicha instalación y de todo lo que ocurra a partir de este momento. La fiabilidad de este sistema es muy elevado, ya que son identificadores únicos.

El sistema de Device Fingerprint Matching es el que permite hacer atribuciones prácticamente desde cualquier origen, aunque también es el menos fiable. En este caso se toman datos únicos en el momento del clic y datos únicos en el momento de la instalación. Entre esta información tenemos la dirección IP, la fecha y hora, el User-Agent y todo lo que sea posible encontrar en una cabecera HTTP. En este caso, y ya dependiendo del tracker, el tiempo para realizar el matching puede variar de entre unas horas a varios días. Uno de los mayores problemas de este sistema es que un usuario se descargue la aplicación en la WiFi de su casa, pero no abra la aplicación. Al salir a la calle, con su conexión 3G, cuando va en el bus, abre la aplicación y, en este caso la información no coincide, ya que la dirección IP ha variado debido al cambio de conexión (de WiFi a 3G).

En este segundo caso, la aplicación al ser abierta ya intentaría mandar la información del punto anterior (el identificador único) para no repetir instalaciones en un momento posterior, ya que sino el propietario de la App podría llegar a pagar en múltiples ocasiones por la instalación en un mismo dispositivo.

En resumen, tenemos tres procesos en paralelo. El primero de ellos haría el siguiente recorrido:

  1. Se pulsa en un anuncio in-app, o en un anuncio web.
  2. A través del tracker se genera y obtiene la información única del dispositivo.
  3. Se envía al usuario a la tienda de aplicaciones para que descargue la aplicación.

El segundo de ellos ocurre cuando el usuario instala la aplicación:

  1. El usuario abre la aplicación.
  2. Al abrir la aplicación se recuperan los identificadores únicos.
  3. Se envían esos identificadores gracias a la SDK del tracker.

Para acabar, el último paso es el más complejo (o más sencillo, según los datos) en el que se hace el matching:

  1. El tracker recibe la información del clic.
  2. El tracker recibe la información desde la App.
  3. Se hace el matching para cruzar los datos de un lado y de otro y generar la atribución.

A partir de aquí, como tenemos los identificadores únicos de la aplicación, cualquier evento es de atribución prácticamente 100% fiable.

Y es por esta razón por la que es tan importante disponer de alguno de los sistemas de tracking que existen en el mercado, como se hace con Google Analytics en los sitios web.

Tracking de Instalaciones en Apps

A la hora de elegir un sistema de rastreo, uno de los trackers, hemos de tener en cuenta, entre otras cosas, qué método van a utilizar a la hora de decidir cuál es la identificación del dispositivo. Al no existir un estándar entre las distintas plataformas, dependiendo del sistema operativo o de la storepodemos tener mayor facilidad para saber qué dispositivo único (parecido a los usuarios únicos en web) tenemos delante.

Device Fingerprint

Este sistema anónimo intenta detectar una serie de eventos en los que haya una alta probabilidad de concordancia. En base a estos elementos, podemos llegar a interpretar que si una persona pulsa un anuncio y un poco después se instala una aplicación, es el mismo dispsitivo el que ha realizado dicha instalación. Algunos datos pueden ser la IP, la fecha, el navegador, etc…

Este proceso es completamente transparente para el usuario y tárda unas décimas de segundo en procesarse, por lo que es poco probable que ningún sistema cierre esta forma de trabajar. Pero esto puede generar algunos duplicados o falsas huellas, ya que se pueden generar algunas discrepancias. la fiabilidad ronda el 95%.

UDID (obsoleto), IFA e IFV

Aunque el UDID (Identificador único de dispositivo) de Apple era el sistema para saber exactamente qué dispositivo teníamos entre manos, siendo un identificador único y por tanto fiable, este sistema llegó a un proceso de falta de privacidad altamente preocupante por lo que quedó obsoleto. Para ello Apple se sacó de la manga el IFA (identificador de la publicidad) que no es permanente, no es personal y las Apps tienen acceso a él de forma libre. De una forma similar tenemos el IFV (identificador de proveedor) para detectar aquellas Apps que ya vienen con el dispositivo o son Apps que incorpora la propia operadora de serie. Hay que tener presente que este identificador sólo funciona en iOS y que está previsto que en iOS7 se incorpore una opciónd e opt-out, para que no pueda ser utilizado.

Cookie Tracking

Es un sistema planteado para Safari en iOS y es similar al de las cookies tradicionales de cualquier navegador. Este sistema básicamente lo que permitía es que, al abrir un enlace de una App desde Safari se pasaba esta cookie a la App, pero esa era su completa limitación. Actualmente no es lo que más se utilice debido a su gran limitación y a la entrada de otros navegadores en iOS.

Android Referrer

Este es, como su nombre indica, el sistema elegido por el propio Google para Android. Es una evolución de Google Analytics y básicamente permite que Google Play recoja los parámetros tradicionales (UTM) y se hagan llegar a la propia App. pero, como su nombre indica y comento, sólo es válido para Android.

OpenUDID

Esta es la aplicación que plantea la comunidad libre, de uso gratuito y que pemite el paso de este identificador entre aplicaciones, de forma que sólo se genera un único código por dispositivo. Vendría a ser la idea de sustitución del UDID. Este sistema tiene la opción de opt-out y parece ser la alternativa óptima en estos momentos.

MAC Address

La dirección MAC (Media Access Control) es la herramienta que históricamente se ha utilizado para identificar las tarjetas de red en cualquier dispositivos. Este identificador es único por hardware y en general su uso va mediante encriptación. De la misma forma que pasaba con el UDID, este identificador no se puede cambiar, por lo que aunque el 100% fiable no permite una protección de privacidad.

ODIN

El ODIN (Open Device Identifier Number) tiene la misma filosofía del OpenUDID pero con la diferencia de que se plantea como un identificador multi dispositivo, de forma que, por decirlo de alguna manera, identifica un usuario pero de forma anónima al dispositivo. Este identificador es válido en todas las plataformas (iOS, Android, Windows Mobile…) pero no está, actualmente, muy en mente de los desarrolladores, por lo que tiene un bajo uso.

Aunque estos son los sistemas abiertos o cerrados más utilizados, existen otros tantos, principalmente proporcionados por plataformas publicitarias, pero que no están profundizando tanto como lo están haciendo estos anteriormente mencionados.