What is fraud in the mobile industry?

The mobile sector of CPI is very simple and yet very complex. It’s simple because it’s based on a very clear and simple concept: the client pays for each installation you generate from their app. It is complicated because of all of actors involved in it.

Before we start talking about fraud, let’s clear up these concepts:


“Cost Per Download,” something that can only measure the “store” downloads (Google Play, iTunes…), but doesn’t allow you to know who has generated the downloads or where they come from.


“Cost Per Installation”, making an installation is when an App is opened for the first time on a particular mobile device.


“Cost Per Engagement” is a step further and it’s when a specific action within the installed app is done, such as finishing the first level of a game.

I would like to emphasise that in this article we’re not talking about the quality of the installations (which involves CPE), but only if the installation is correct and valid or when it isn’t. Therefore it’s important that campaigns make it clear whether they are CPE or CPI and explain that the conversion flow for the App just has to be opened or if there is some type of engagement needed later in the App.

From here on we’ll tell you about the simplest and most complex situations. For this I recommend you look at the post about the life cycle of the offer if you do not know how it works.

The simplest case is when the developer of an App gives you a URL with a tracker. When clicked, this link synchronises all the information the moment the installation is made. The tracker decides if the installation that was made is a valid one or not.

Every installation accounted have a set of basic rules: The installation can only be accounted after the first installation of an app on a device. If a user uninstall and reinstall the app, the download only will be counted the first time.

Technologically speaking, the trackers verify a series of unique device identifiers, which leaves it in the tracker’s hands to decide whether the installation is successful or not.

For this reason, there are trackers used by companies that certify the installation and other events.

Only a tracker is able to decide if an installation is valid or not. Not other external service can decide. The tracker system reflects whether or not the installation is valid.

So far we’ve only spoken of the instillations and not of the clicks on the links that redirect to consumers to the offer. Why? Basically because no matter where the traffic comes from, if it is a click from a machine/server and not from a user, the tracker will not count this as correct of give it any value.

At this point we can add the S2S System (Server-to-Server)/Postback, which sends information between machines only when the installation was successful. With this, companies now know in real time when an instillation is generated/installed and don’t need access to the original reports of the tracker.

If an advertiser left it to another agency to do the promotional work, the agency will receive (through the S2S System) a notification of the tracker, so you know at the exact moment if the install is valid or not and it’s never possible to commit fraud because the tracker, that certifies the install, approved it.

From this moment on we’ll enter the world of rebrokering. When an offer is in line it’s practically available worldwide, and this is where the networks enter the game. Simply put, networks are affiliation platforms that put a level between user-generated installations and agency’s or developers without adding value in the chain. Some of these networks hire external services for the “anti-fraud” fight, but what do these companies analyse? They do not test facility information, they only analyse the information clicks.

If they generate 100 installs, they see the clicks of these 100 facilities (which are valid because the tracker said they are valid and is the only one who can certify it) and if the anti-fraud company believes that the origin of those clicks is not OK, the network does not pay them, although they have been counted as valid (because yes they are). This means that the developer of the App has paid for the installation and if there is an agency, it has also gained an installation, but after the intermediaries do not pay their affiliates.

It makes sense that developers of Apps look in detail at the quality of the facilities, so there are incentivized offers (for those who want volume without looking at the quality facilities) and no incentive (for those who are more concerned with the quality and not volume), but it is your job to decide the price of the CPI offers based on your acquisition cost and the work with these metrics.

, ,

What Is Happening In The Mobile Industry

Welcome to the weekly mobile news update, we give you essential information you need to know to keep on top of the hottest stories in the business. This week you can read all about, Pepsi building a smartphone, the biggest tech deal ever and the guy who ‘bought Google’!

Pepsi confirms it’s building a smartphone

A spokesperson for the company told techradar “We are pleased to share that Pepsi is working with a licensing partner to bring a line of mobile phones and accessories to market in China in the next few months.”

Read all about it here!

The biggest tech deal ever: Dell buys EMC for $67 billion

In the biggest tech deal of all time, Dell announced Monday that it had agreed to buy corporate software, storage and security giant EMC for $67 billion.

Read all about it here!



, ,

Geenapp Quality System Analysis: Adding value to business

Geenapp is a tech company even though it is working in the mobile marketing industry. One of our products is Quality SystemAnalysis, which we implement in our platform.

Quality System Analysis was created to solve a common problem in the industry. When a user clicks a URL that links to an app (Whatsapp, for example) but is not going to iTunes or Google Play, what do we do? First thing is to warn the advertiser that this offer is not working anymore.



In those cases we would receive “it’s working on my side” in response. But if a german company is telling us that a Brazil offer was working for them, “Sorry, I don’t believe it”. To avoid this situation we created a system that revises all the active offers at Geenapp twice a day.

A simple approach: a provider gives us a URL, this URL works only for a country and specific device. For example, Whatsapp for Android in Germany. Our system sends our german Android to that URL and send us the answer. So, you only have to multiply this for 250 countries and 4 different devices: iPhone, iPad, Android and Windows Phone.

The answer gets us a lot of information, but we only use 2 types:

  1. Where this click has been, meaning that who is rebrokering who, until it gets to the final owner of the original campaign and the tracker.
  2. If the campaign ends where it has to end (in Google Play, iTunes, Windows Store …).

The first point is useful for other type of tools, not just for quality. Anyway, we have a blacklist networks and if we detect that an offer is from them, we don’t serve that offer.

The second point is important because it says if a campaign is working or not. This is an easier case: if the final URL is the app’s URL, it works. Easy peasy.

But if the URL doesn’t finish at the right app, then we send several alerts to our providers:



Internally we call this 404, but it is any error that brings back a non working website. Maybe is a blank page or a website with a “this campaign no longer exist” page.



We couldn’t find a better name for these trash websites. They can be very different: SMS subscription websites, adult’s sites, OfferWalls, Price rewards websites, and any other site that is not iTunes, Google Play or similar.



Another situation is where the limit of the amount if installs per day, month or campaign is already capped. In those cases they should turn off the offer (Geenapp does it this way), but this only works properly when the campaign provider is a direct advertiser. When you have a third party provider it is very difficult to turn it off on time, so those campaigns are still on for a day or two, so we send them an e-mail telling them about it. It’s pretty similar the 404 error.



One of the most common cases is when you click an app and you get to another app that is not the one you were looking for. For example, you click Whatsapp and end at Candy Crush Saga. And then Candy Crush Saga developers claim that they are getting bad quality traffic (that’s normal!).  Agencies and developers don’t have to decide if the user is going to another app, even if they are similar, but publisher should have to decide it.

For the rebrokering, this should not happen because they are generating installs to Apps that the publisher will never earn.




Android users have Google Play, iOS user have iTunes and Windows Phone users have Windows Store, so why would a user want to install an App from an APK? Our wide experience with the APK files (the Android App files) are pretty bad. First of all because most of the phones and tablets don’t allow them due to security reasons. Tons of malware and viruses enter thousands of phones and tablets daily because of this without the user knowing. That’s why we don’t allow APK campaigns into the platform.


We are very lucky to work with plenty of networks, but some of them fail because they don’t pay, complain about quality traffic without any report, or simply disappear. In this case, any offer that use our blacklisted networks will simply be rejected automatically by the Quality System Analysis. We don’t work with companies that don’t follow their IO.


As you see, those Quality Analysis are vital for an industry that works this way. With this philosophy we try to offer the best quality to assure that no click goes to waste.


, ,

Geenapp Quality: añadiendo valor

Geenapp es una empresa tecnológica aunque se dedique al marketing móvil. Y una de las formas de verlo es por ejemplo con el sistema de calidad implementado internamente en la plataforma.

Geenapp Quality surgió de la necesidad de corregir una situación habitual. Un usuario pulsa en un enlace hacia una App (por ejemplo Whatsapp) pero no le aparece la página de iTunes o Google Play de Whatsapp. ¿Qué hacer antes estos casos? Lo primero era avisar a la empresa que nos proveía de la oferta y decirle que no funcionaba.


En estos casos surgía siempre una respuesta que era “a mí sí que me va”. Una empresa alemana diciendo que sí que le va una oferta para Brasil. Pues perdona, pero no me lo creo. Y ante esta situación decidimos crear un sistema interno que revisa cada día dos veces todas las ofertas que tenemos en Geenapp.

El planteamiento es sencillo: un proveedor me da una URL, esta URL funciona en un país y un dispositivo concreto. Por ejemplo, Whatsapp para Alemania en Android. Nuestro sistema manda esa URL a un Android que tenemos en Alemania y nos devuelve la respuesta. Esto con varios miles de ofertas en 250 países y 4 dispositivos distintos (iPhone, iPad, Android y Windows).

La respuesta que nos llega nos devuelve mucha información, aunque básicamente aprovechamos 2 tipos de datos:

  1. Por dónde ha ido ese clic, es decir, quién revende a quién (rebrokering), hasta llegar finalmente al propietario de la campaña y al tracker que tiene instalado.
  2. Si la campaña acaba donde tiene que acabar (en Google Play, iTunes, Windows Store…).

Los primeros datos nos sirven para otro tipo de herramientas, no tanto por calidad. Aun así, tenemos una lista de redes en lista negra y si detectamos que pasa por ellas esas ofertas nos las servimos.

El segundo dato es el importante, porque es el que nos dice si una campaña funciona o no. El caso más sencillo es fácil: la URL final es la URL de la App a la que corresponde la campaña. Si pulsas en Whastapp de Android, acabas en la ficha de la App Whatsapp de Google Play. En este caso se marca la oferta como correcta y todo continúa.

La situación cambia cuando la página en la que acaba esa campaña no corresponde con la App. En este caso pueden pasar muchas situaciones que se resumen en las alertas que mandamos a nuestros proveedores:


Aunque internamente lo llamamos 404, es cualquier error en el que la página final nos da un error de una página no existente. Puede ser que la pantalla se queda en blanco, que nos aparezca un mensaje diciendo que “la campaña no existe” y un sinfín más de combinaciones.



En su momento no supimos encontrar un mejor nombre para llamar a las páginas “basura” a las que se enviaban las ofertas. Estas páginas son y pueden ser de muchos tipos, desde páginas en las que te piden suscribirte a un SMS, páginas de adultos, OfferWalls, páginas de premios y en general cualquier página que se pudiera considerar una página que no es iTunes, Google Play o similar…



Otra situación habitual que tienen las ofertas es la limitación de instalaciones. En estos casos se deberían apagar las ofertas de forma automática (Geenapp lo hace así al trabajar de forma programática), pero esto sólo funciona cuando el proveedor de la campaña es directo. Cuando tienes campañas de terceros es muy difícil que te avisen a tiempo, por lo que aquellas ofertas que acaban con un mensaje diciendo que se han acabado las instalaciones por ese día, también las detectamos y avisamos. Es parecido al sistema de 404.



Uno de los casos habituales y más complejos de trabajar, y es que pulses en una App y acabes llegando a la ficha de otra App que no tiene nada que ver. Por ejemplo, pulso en el Whatsapp y acabo en el Game of War. Luego los desarrolladores del Game of War se quejan de que se les manda tráfico de baja calidad: pues no me extraña. Que quede constancia de que no me importa que a un usuario se le mande a una App relacionada (con cierta similitud) pero eso es algo que debería decidir el cliente final. En el caso de hacer de intermediario (rebrokering) esto no debería ocurrir, porque se están generando instalaciones de Apps que quien tiene el tráfico nunca cobrará.



Los usuarios de Android en general tienen Google Play, los de iPhone tienen iTunes y los de Windows tienen la Store… ¿por qué un usuario va a querer instalarse una App desde un APK? Nuestra experiencia con APK (los ficheros de Apps de Android) son bastante malos, para comenzar porque los teléfonos suelen quejarse de la inseguridad de estos ficheros. Además, en muchos casos aunque la App sea la correcta, han podido ser tratados con malware, lo que los convierte en aún más inseguros. En estos casos descartamos la oferta.


Tenemos la suerte de poder trabajar con muchas redes, pero algunas tras un tiempo trabajando fallan, principalmente porque no pagan o simplemente te dan razones que son falsas sobre el tráfico que les mandas. En estos casos cualquier oferta que pase por alguna de estas redes es automáticamente rechazada ya que no trabajamos con empresas que no cumplen sus contratos. Incluso nos ha pasado que empresas con las que nunca hemos trabajado dicen a nuestros proveedores que no trabajan con nosotros, repito, empresas con las que nunca hemos trabajado…


Como veréis ninguno de estos elementos es algo que queremos para nuestros clientes. Si un usuario quiere bajarse el Whatsapp… ¿por qué voy a ofrecerle otra cosa o voy a darle una pantalla de error?

Con esta filosofía repasamos todas las ofertas de forma automática y posteriormente de forma manual para ofrecer la mayor calidad que podamos, para asegurarnos que todo aquel que utilice nuestras campañas va a conseguir que si un usuario pulsa en ellas, acabe descargándose la App que estaba esperando.

, ,

How a Geenapp’s offer works

If I have to find the easiest way to explain how Geenapp works in the ad-tech industry, I would tell you to think about Google Adwords / Google Adsense. The main idea is the same, but internally it is completely different. We are a platform, we are in the middle and we “do things” there.

Geenapp is formed by two main blocks. The first one is the advertiser’s side, and the other one the publisher’s side.

Offer life cycle

We need advertising campaigns, so we work with more than 200 different networks. This is a programmatic system so it’s 99% automatic and 1% manual to make sure everything is going smoothly.

When we retrieve the offer from the advertiser we assign that offer to an App. Geenapp is App-Centric, meaning that all our campaigns are associated to a specific app (Android, iOS, Windows Phone…). At this time, through our panel, we can see all the information related to that offer: CPI, currency, description, country, devices, capping…) and a real person decides if this offer should be approved or not. This is our first filter where we “accept” or “reject” a campaign. From now on, every change an advertiser makes in their panel is going to be changed in ours: they can change the payout at their end and get more downloads for that campaign.

Once the offer is in the platform, our Quality System Analysis can start working with it.

What publishers see

If we go to the other end, the publisher’s side, they can see a lot of tools and systems to promote. Two very important tools are the Apps list with the Smart-Link system and the Offers List, which is only for publishers that have affiliates.

Smart-Link Tool is a unique URL for an App. This link works for every mobile device and any country, and when you click on it, it detects the device and country and looks for the best campaign for that combination in that exact moment.

This means that, in real time, we calculate that the capping is not over, look for the best price (managing the boost), separate the incent and non incent campaigns, in addition to detecting the country and device. Also, we detect the quality of the publisher’s traffic because we score their campaigns according to their quality. This system has pros and cons: we are always going to serve the best offer in every moment, but we can’t calculate the price until the user has clicked on the offer.

Offers List is a flat list with all the offers that we have (several thousands). This list offers a URL for every campaign, so it is better to control the price fluctuation because there are less changes. But you have to always check if the offer is still live, if the price changed or if it reached the cap. You have to manage it manually because our system won’t redirect to another offer if it doesn’t work.

Unlike other services, we don’t redirect traffic to other campaigns or scam websites once the campaign stops. We believe in a good service and we act accordingly.

Geenapp’s complexity

As you can imagine, this is a short recap of how an offer works at Geenapp, because there are a lot of complex processes during the lifetime of a campaign and its maintenance. We work with more than twenty different API’s with different models so we need to standardize every piece of information that arrives to us for our Publishers and Networks in order to provide a good quality service.


, ,

Cómo funciona una oferta en Geenapp

Si tuviera que encontrar la forma más sencilla de explicar el funcionamiento de Geenapp a alguien del sector ad-tech le diría que piense en Google Adwords / Google Adsense. El concepto es el mismo, aunque internamente nos parecemos en poco. Somos una plataforma, estamos en medio y “hacemos cosas”.

Geenapp está formado por dos bloques principales, que internamente se subdividen. El primer bloque es el de “tener” las ofertas (anunciantes) y el segundo es el de “servir” las ofertas (publishers).

Cómo es el ciclo de vida de una oferta

Lo primero que necesitamos son campañas de publicidad. Por ello tenemos contactos con más de 200 anunciantes que nos sirven de fuente. En este caso todo el sistema es programático, es decir, se gestiona 100% por máquinas, aunque tenemos varios procesos manuales para mejorar la calidad.

Cuando nos traemos las ofertas de un anunciante lo primero es asignarlo a una App. Geenapp es App-centric lo que significa que todas nuestras campañas están asociadas a una App (ya sea de Android, iOS, Windows…). En este momento, mediante un panel vemos todos los datos de la oferta (CPI, moneda, descripción, países, dispositivos, capping…) y una persona decide si esa oferta ha de entrar en el circuito de Geenapp. Este es nuestro primer filtro donde “aceptamos” o “rechazamos” ofertas. En el momento en el que se acepta la oferta pasa automáticamente a nuestra plataforma. A partir de aquí las ofertas se actualizan automáticamente, de forma que los anunciantes pueden realizar los cambios que consideren necesarios, pudiendo mejorar las pujas y tener más posibilidades de servir la campaña.

En este momento en el que la oferta está en la plataforma ocurren varias cosas. Una de ellas es el proceso de Geenapp Quality del que ya os hablamos en otra ocasión.

Qué ven los publishers

Si nos vamos al otro extremo, al de los publishers, desde tu Panel de Publisher puedes ver muchas herramientas y sistemas, aunque hay dos que permiten mostrar las ofertas (sin banners o plugins). Uno es el del listado de Apps, que funciona mediante nuestro sistema de Smart-Link. El otro, que sólo ven publishers que tienen afiliados, es el de las “ofertas”.

Si vamos al primero de los casos (y en el que se basan prácticamente todas las herramientas que tenemos), el del Smart-Link, lo que ofrecemos es un único enlace para una App. Este enlace funciona en cualquier dispositivo móvil y cualquier país, y cuando se pulsa en él detecta que dispositivo tienes y en qué país estás y busca en nuestra plataforma la mejor oferta para esa combinación en ese momento. Esto implica, en tiempo real, calcular que no se haya superado el capping, buscar el mejor precio (teniendo en cuenta sistemas internos de potenciación o boost), si es incentivado o no y que la campaña coincida con esa App, País y Dispositivo. Además revisamos que ese Publisher pueda ofrecer esa aplicación, ya que tenemos scoring de publishers según su calidad de tráfico. Este sistema tiene cosas buenas y malas. Las buenas se centran en principalmente que siempre vamos a servir la mejor oferta posible en todo momento, las malas es que no podemos pre calcular un precio hasta que el usuario haya generado el clic.

En el segundo de los casos lo que ofrecemos es un listado más plano con todas las ofertas que tenemos, que son varios miles. Este listado ofrece una URL para cada App en un país y en un dispositivo concreto, de forma que es más sencillo controlar la fluctuación de precios, ya que este cambio es menor. Eso sí, en este caso hay que estar pendiente de que si la oferta cambia, se pausa, se reanuda o llega al capping, hay que gestionarla manualmente, ya que nuestro sistema no sirve nada si la campaña deja de funcionar. Nosotros, a diferencia de muchos otros no redirigimos el tráfico a otra campaña o intentamos servir páginas basura a los usuarios.

La complejidad de Geenapp

Como puedes imaginarte esto es un resumen del funcionamiento de una oferta, ya que hay procesos muy complejos a lo largo de la vida de la oferta y de su mantenimiento, teniendo en cuenta que trabajamos con una veintena de APIs diferentes, con sus modelos de datos distintos, pero que a lo largo del tiempo hemos conseguido estandarizar y poder ofrecer un resultado de calidad.