Posts

, , ,

Discrepancies between 3rd Party Tracker’s data…

and the stores.

Sometimes there are discrepancies between the tracker’s information and the iTunes App Store or Google Play reports. Don’t freak out, this is what could be happening.

Install Record Date
App Stores record downloads, while trackers record Installations and opens. Also, the time zone is set by the stores, meanwhile in the making of your campaign with the tracker, you get to choose the time zone. This time difference can influence the numbers.

Examples:

A user downloads candy crush but later on decides not to open it and get addicted to it for life. User deletes the app immediately >>> The stores will register one download, while the tracker wont show any numbers at all.

A user downloads an app but doesn’t get the chance to launch it. He forgets he has it on his mobile until 2 weeks later, while on holidays, opens the app and starts playing >>> The stores will register one download, while the tracker wont show any numbers at all until the user launches the app.

Lucky user gets a new mobile device. He synchronizes the new device with his iTunes or Google Play account and re-install all apps on his previous device >>> The stores will not take this new installations into account, but the tracker will record it as an organic installation.

Installation Uniqueness
App Stores record one install per unique new user, taking into account app uninstalls, users with multiple devices and upgrades. The tracker usually records new users install the app AFTER the SDK has been integrated. Users that have had the app before will be re-counted, as well as re-installations in different devices with different accounts.

A user installs and app he really likes on both: his smartphone and tablet >>> The stores will count only one installation, but the tracker will record 2 different ones.

Please take into account that some stores show unique users, while trackers show unique devices.

Google ads usually has a 72 hour delay in processing 3rd party install notifications, so sometimes the discrepancy between this numbers will be solved after this period of time. Between 10% to 20% of discrepancies happen between Google and the tracker.

SDL Modifications
In some cases these updates will result in discrepancies. Also, shortening your SDK attribution delay may cause your SDK to miss outlying attributions whose referrers are not received during your adjusted delay window. These late attributions will still be reflected in your callbacks and dashboard. This is because adjust still wait for and subsequently attribute all reftag-based clicks regardless of how the length you set your SDK attribution delay.

and Facebook Mobile Ads Dashboard.

Facebook uses a 1-day view with a 28 day lookback window. Trackers only report installations generated during this 28 day period. Also, Facebook Ads Manager shows results taking into account impressions or click-times, instead of installations or conversions, as configured with your tracker.

Keep in mind that trackers do not report ad-view installations on CPI / CPA campaigns.

If you notice a very big discrepancy in numbers do not hesitate to ask your 3rd party tracker, who is the certified authority to determine valid installations, or ask your Geenapp’s account manager.

They will be glad to help you.

, ,

Qué es fraude en el negocio CPI móvil

El sector del CPI móvil es muy simple y a la vez muy complejo. Es simple porque se basa en un concepto muy claro y sencillo: el cliente paga por que se consiga la instalación de su App en un dispositivo móvil y el cliente cobra por cada una de esas instalaciones. Es complejo por todos los actores que intervienen en el mismo.

Antes de empezar a hablar sobre fraude, dejemos claros estos conceptos:

  • CPD es Coste por “Descarga”, algo que sólo pueden medir las “store” (Google Play, iTunes…), pero que no permite saber quién ha generado esa instalación o desde dónde viene.
  • CPI es Coste por “Instalación”, lo que hace que una instalación es ese momento en el que una App se abre por primera vez en un dispositivo móvil concreto.
  • CPE es Coste por “Engagement” es un paso más allá y es ese momento en el que se realiza una acción determinada dentro de la App ya instalada, como por ejemplo acabar el primer nivel de un juego.

Quiero destacar que en este artículo no estamos hablando de la calidad de la instalaciones (por eso comentaba sobre el CPE), sino sólo si la instalación es correcta y válida o no. Por eso es importante que las campañas dejen claro si son CPI o CPE, ya sea explicando el flujo, si se lanza cuando se abre la App o si tiene en cuenta algún tipo de retención o evento posterior.

A partir de aquí vamos a ir poniendo casos de lo más sencillo a lo más complejo. Para ello recomiendo, si no sabes cómo es el ciclo de vida de una oferta, que lo hagas.

El caso más sencillo es el aquel en el que el desarrollador de una App te da una URL de un tracker para promocionar. Este enlace cuando se hace clic va por los servidores del tracker, y sincroniza la información cuando se genera la instalación. Quien decide si la instalación es válida o no es el tracker, y esa es su tarea en este sector.

Las instalaciones para que se contabilicen ya llevan una serie de reglas básicas, como por ejemplo que sólo se cuenta una vez la primera instalación de una App en un dispositivo. Si un usuario la desinstala y la vuelve a instalar ya no lo cuenta. Tecnológicamente hablando, los trackers verifican una serie de identificadores únicos del dispositivo lo que deja en sus manos el decidir si la instalación es correcta o no. Por esto existen los trackers y es el negocio de estas empresas: ser la empresa que certifica la instalación y otros eventos. Sólo un tracker es capaz de decidir si una instalación es válida o no, ningún servicio externo puede decidirlo. Si la instalación es válida queda reflejado en los sistemas del tracker, si no lo es, no queda reflejada.

Hay que fijarse que hasta ahora hemos hablado únicamente de las instalaciones y no de los clics en los enlaces a la oferta… ¿por qué? básicamente porque da igual de dónde venga el tráfico (siempre que cumpla las reglas de país y dispositivo si la oferta tuviera esas limitaciones) ya que si viniera un clic desde una máquina / servidor y no desde un usuario, en principio esa máquina aunque se descargue la App, cuando se instala el tracker no la contabilizaría como correcta y no se tendría en valor.

En este punto podemos añadir todo el sistema de S2S (Server-to-Server) / Postback, que envía información entre máquinas sólo cuando la instalación se ha realizado correctamente. Con esto las empresas saben en tiempo real cuando se ha generado un evento (por ejemplo la instalación) y no necesitan acceder a los informes originales del tracker.

Si por ejemplo un anunciante ha dejado en manos de una agencia el trabajo de promoción, esta agencia recibirá mediante S2S el aviso desde el tracker, por lo que en este momento sí o sí la instalación es válida y no puede considerarse nunca fraudulenta ya que el tracker, que certifica la instalación, ha dado su aceptación.

A partir de este momento entramos en el mundo del rebroketing. Cuando una oferta está en línea está disponible prácticamente al acceso de todo el mundo, y aquí es donde las networks entran en juego, plataformas de afiliación que simplemente ponen un nivel entre el usuario que genera la instalación y la agencia o el desarrollador sin aportar valor en la cadena. Algunas de estas redes contratan servicios externos “anti-fraude”… pero, ¿qué es lo que analizan estas empresas? No, no analizan la información de las instalaciones, analizan la información de los clics.

Si se generan 100 instalaciones, se miran los clics de estas 100 instalaciones (que son válidas porque el tracker ha dicho que son válidas y es el único que puede certificarlo) y si la empresa anti-fraude considera que el origen de esos clics no es correcto, la network no las paga, aunque sí que se han contabilizado como válidas (porque sí que lo son). Esto hace que el desarrollador de la App haya pagado por la instalación y si existe una agencia, también lo ha cobrado, pero después los intermediarios no pagan a sus afiliados.
Tiene cierto sentido que los desarrolladores de las Apps miren con detalle la calidad de las instalaciones, por eso existen las ofertas incentivadas (que buscan volumen de instalaciones sin mirar la calidad) y no incentivadas (que miran la calidad y no el volumen, aunque si lo hay, mejor), pero es su trabajo decidir el precio de las ofertas CPI en base a su Coste de Adquisición y trabajar con esas métricas.

,

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:

CPD:

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

CPI:

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

CPE:

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