, ,

Performance marketing main problem is fraud

People/Machines imitating real users behaviour (clicking, installing or even registering into apps) to earn money from the advertiser’s budget. Those users are not real and are draining everybody’s patience in this industry.

Fraud has evolved for quite those 3 years that we have been in the industry.

Mainly, fraud is linked to robot leads generator. The most efficient method of producing low-quality leads or even fraudulent conversions with state-of-the-art or clumpsy tecnology. This is pretty easy to detect with Geenapp, but advertisers can fall into those tricks if they do not have the experience or work with serious partners.

Other problems about fraud are affiliates, networks or other players not following the rules set by advertisers. Big companies promoting on soft incent traffic when advertiser has asked no incent at all, or when advertiser has only asked for only direct sources and this campaign is being promoted by everyone.

But, even though is not that huge, advertisers can be fraudulent too.

– The “Pixel Shaving”: When an advertiser only fires your pixel part of the time. Monitoring the rise and fall of your conversion rates and EPC, while conducting random checks for pixel placement, is your best bet to keep pixel shaving at bay.

– The “It’s All Fraud”: Even conversions from high-quality, transparent traffic will be deemed as “all fraud” at times, usually at the hands of jaded marketers. To deal with this, both advertisers and publishers must be very clear on what is allowed as a return, what consequently defines a conversion, and also what constitutes “fraud.” It helps if your tracking platform can enter with its data and work both sides toward resolving these definitions.

Is as our parents use to tell us: keep good company. Though there’s no bulletproof solution to mobile fraud, you can better protect yourself by working with serious people and stay alert of those signs that trigger your app-owner nose.


Tips for creating a GREAT Burst Campaign

If you still don’t know what we are talking about, please read our previous post about boost campaigns, in order to understand plainly what you are getting into.
If you have already read it and still want to move forward, these will be super helpful tips in the creation and execution of your next user acquisition strategy:

1. Have your numbers clear and defined.

Remember your goal is to be in the rankings, and in order to get there you will need to achieve a minimum daily number of installations. If you plan a campaign without a defined strategy or thinking that undergoing won’t make a difference, all of it will be a waste of money. Plan how many installations you’ll get everyday, as well as the budget you will destin to this purpose.

For certain countries and categories you’ll need bigger budgets to see results, because the higher the smartphone penetration is in the market, the more installs are needed to reach a particular rank. Also, if you have a lot of competition, it is going to mean a lot more installations. Consider if it’s worth or not spending your budget targeting large countries or categories.


2. Try and get potential quality users.

Even though you are going for volume, pick an ad-network that can provide possible engageable users with a targeted audience. It doesn’t matter if you don’t get a high retention rate, you can at least try and see if you can get something else out of this. Meaning, possible loyal users. Some networks will offer you fake installations in order to help your numbers: I know it’s tempting, but lets be clear: these ones are not going to help your long-term strategy.

aso3. Ensure you have all your ASO strategy finished and polished.

This is also one of the strong points in boost campaigns. With all the acquired traffic you will be receiving, your visibility will be increased and your app will rank higher for certain keywords and categories.

Keep in mind that an attractive app will be more likely to be downloaded that one that doesn’t look neat. Find the most competitive and attractive keywords, analyze suitable categories for your app, optimize app name, description and visuals, etc.


4. Do not launch a bugged app that doesn’t work or crashes.

Users are cruel and impatient: if your app crashes, the results can be nasty. Is your app dependant on the communication with your servers? Make sure you have the capability to sustain tens of thousands of installations and users testing your app! It won’t matter to appear on the top if you start receiving a lot of bad reviews from the acquired users!

5. Run tests in smaller countries or categories.

It’s an interesting practice to try a burst campaign on asmaller country, where your ad-spend wont be as big. Besides acquiring a significant audience in that other country you will be able to learn what’s the user’s response, if there was a technical problem to be solved, etcétera. If you see good results and think you’re ready for the big play, move onto more important targets.

6. Combine burst campaigns with additional activities.

Such as PR, social promotions, etc. Since PR is usually connected to specific events, deciding on a burst campaign is usually part of a wider plan.


, ,

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.

, ,

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.