Brave, no solo un navegador

Hace unos días me había cruzado con Brave, un navegador mas, pensé.

Hasta que con todas las noticias sobre ICO, me encuentro con que Brave lanzó su propio token y que en 24 segundos alcanzó los 30 millones de dólares.

Lo extraño, es que el token no es por un navegador, sino por una plataforma publicitaria denominada BAT, Basic Attention Token.

El BAT lo que hace es distribuir la riqueza generada por la publicidad directamente a los publishers y los usuarios utilizando como unidad de medida algo que cada vez tiene mas sentido: la atención del usuario (para qué entrar en discusiones de impresiones o clicks cuando lo que importa es la atención).

bat_triad_diagram

La idea no es nueva, pero esta vez cuenta con el capital de credibilidad necesario para algo de esta envergadura, Brendan Eich creador de Javascript y co-fundador de Mozilla y Firefox. Sumado a una evolución tecnología capaz de procesar estos millones de micro-pagos en todo el mundo, ahi es donde entra en juego Ethereum.

Articulando a esa trinomia de advertiser, publisher y user, entran en juego soluciones que eran impracticables, como la posibilidad de un publisher de poner un paywall que sea realmente efectivo y que el usuario tenga un método de pagar por leer un artículo.

El navegador Brave en sí mismo, no tiene mayores cosas a destacar y hasta me parece tosco, pero es su primer versión. Ahora, si existía una compañía en una mejor situación para hacer realidad esta idea, era Opera.

Initial Coin Offering

Hace mas de dos años escribía una idea sobre cómo lanzar una compañía pública virtual, una idea que se trataba de lanzar un fork de Bitcoin, con una emisión de criptomoneda propietaria en la que cada moneda se corresponde a una acción de la compañía.

Tiempo después, y con los recientes picos de Bitcoin, veo que esta idea se hizo realidad, con un nombre infinitamente mas atractivo: Initial Coin Offering, o ICO.

Lo que no había imaginado es que la implementación viniera como una evolución del crowdsourcing y tiene todo el sentido del mundo ya que democratiza el fondeo de nuevos proyectos y los hace mucho mas accesibles aprovechando la disponibilidad de las criptomonedas.

Otra cosa que tuvo que suceder para que esto se vuelva realidad es una evolución del BlockChain. Estos ICOs se están plasmando sobre Ethereum, otra criptomoneda con transacciones mas rápidas que Bitcoin y diseñada para desarrollar smart contracts.

El ecosistema se está acelerando nuevamente y toda este movimiento arroja mucha mas luz y usos prácticos sobre el verdadero avance nacido en Bitcoin: el blockchain.

En plataformas como Token Market ya podemos ver los proyectos y la agenda de ICOs que están por salir y de los que podemos ser inversores si disponemos de Ethereum.

Conversiones Server Side

En el post previo de conversiones entendimos cómo funciona una conversión client side, es decir, mediante el uso de cookies. Se denomina client side, porque la mayoría de la acción transcurre en el navegador del usuario y es una práctica común en el desarrollo web referirse a este entorno como el entorno del cliente.

Esquema cliente  servidor
Esquema cliente servidor

Ahora, hay situaciones en las que no podemos contar con que la conversión la inicie el navegador del usuario. Supongamos por ejemplo un caso en el que la conversión es concretada días después, o mediante un pago en un medio que no sea digital como un banco o Pago Fácil. O bien que el pago sea en un medio digital, pero que la plataforma de pagos no nos brinde la opción de redirigir al usuario al thank you page para poder mostrar el pixel de conversión.

La solución para estos casos, que son muy comunes en las campañas sobre dispositivos móviles, es con una conversión Server To Server, o Server Side o de Postback, tiene muchos nombres, pero todos se refieren a lo mismo: A una conversión disparada entre servidores.

Esta integración siempre genera dudas porque hay una parte del proceso que no se ve, que es intangible. Precisamente, la ejecución de la conversión entre servidores, pero si seguimos el paso a paso es realmente muy simple de entender.

Olvidemonos por un momento de los adservers, trackers y demás. Y supongamos que tenemos algo tan tangible como una heladería. Para promocionar nuestra heladería, contratamos a unos cuantos empleados que se ocupan de dar folletos a las personas que pasan por la calle.

Como queremos ser una heladería eficiente, queremos medir la las ventas que genera cada uno de nuestros empleados. Para eso, imprimimos en los folletos los nombres de los cada uno de ellos.

De esta manera cuando venga un nuevo cliente, con solo leer el folleto que trajo sabremos gracias a qué empleado se generó el lead, y así poder atribuir las ventas al esfuerzo de cada empleado.

Una conversión Server To Server es el mismo concepto, pero en lugar de empleados, tendremos clicks, y en lugar de ventas, tendremos conversiones.

El paso a paso es el siguiente

  1. Cada vez que nosotros recibamos un click, le asignaremos un número único
  2. Este número lo enviaremos al cliente
  3. El cliente guardará todos los números que nosotros le enviemos
  4. Cuando se genere una conversión, el cliente nos indicará el número de click que generó la conversión
Flujo de conversión Server-To-Server
Flujo de conversión Server-To-Server

Lo atractivo de este modelo, es que no está sujeto a las discrepancias que son tan comunes en las conversiones client side, porque la comunicación entre servidores es mucho mas estable y el servidor que emite el request de conversión espera una respuesta del que la recibe.

Paso a paso del click

  1. Se genera un click en el sitio web example.com
  2. El adserver de example.com le asigna el ID de click #4 y redirige al usuario a nuestro tracking URL
  3. Nosotros recibimos su ID de click, lo guardamos, le asignamos nuestro propio ID de click #ABC y redirigimos al usuario al landing page del cliente
  4. El cliente recibe nuestro click ID #ABC y lo guarda.

Se genera la conversión y se sucede el circuito a la inversa:

  1. El cliente dispara nuestro postback URL indicandonos que el click ID #ABC ha convertido
  2. Recibimos la conversión del cliente, y nuestra plataforma busca en qué sitio se generó el click ID #ABC
  3. Nuestra plataforma identifica que esto se generó en el sitio example.com y dispara su postback indicando que su click ID #4 ha convertido
  4. El adserver de example.com recibe la notificación que su click ID #4 ha convertido

Los problemas más comunes

  • Si nosotros no recibimos la conversión del anunciante: Verificar en qué parámetro de la URL del anunciante estamos enviando nuestro click ID y a qué URL está reportando el anunciante la conversión.
  • Si el publisher no ha recibido la conversión: Revisar a qué URL de postback hemos envíado la notificación
  • Cuando todo falla: hacer el proceso a mano y ver las respuestas que dan los servidores al recibir la conversión
  • Recordar que no hay nada esotérico en el proceso, es tan solo el click ID de una plataforma siendo enviado a la otra. En el click pasa por la URL del landing page y en la conversión vuelve por la URL de postback

Rangos de IPs

Hay cosas que son realmente difíciles de entender y los rangos de IPs son una de ellas, pero con saber un par de tips, va a ser suficiente para poder trabajar.

Un rango de IPs, es un conjunto de IPs, y se lo puede escribir de dos maneras diferentes:

  1. IP mínima – IP máxima
  2. IP/rango

La primera es muy sencilla y bastante legible, aunque poco práctica para cargar de a cientos en una plataforma. Mientras que la segunda es mas práctica para trabajar en cantidad pero mucho mas compleja de interpretar.

Dependiendo la plataforma donde debamos subir el listado de rangos de IPs, vamos a tener que trabajar con un formato u otro. Lo bueno, es que hay un conversor online de IPs a rango de IPs y eso es todo lo que necesitamos saber para evitar dolores de cabeza.

One more thing

Como regla general, no tiene sentido apuntar a un número menor de 1.000 direcciones IPs. ⁄¡Ojo! Mil direcciones IPs individuales, no mil rangos.

Pensemos que cada IP es una conexión a internet, si el número de IPs es muy pequeño, las chances que encontremos a alguien conectado va a tender a cero.

De trackers

La publicidad en teléfonos móviles nació muy fragmentada. Nunca hubo una plataforma o exchange líder que acapare el mercado, como lo era para desktop Yahoo! Rightmedia.

Esto generó que existan soluciones para unificar la gran cantidad de plataformas donde se debían correr las diferentes campañas, y hasta a veces diferentes plataformas para una misma campaña.

La solución que la mayoría de las ad-networks utilizaron vino del mundo de los afiliados. Las plataformas de tracking de conversiones.

Hace mucho tiempo, allá por el 2008, recuerdo que corría campañas de una empresa de afiliados llamada Adsmarket, que luego sería comprada por Matomy. Si mal no recuerdo, esta compañía tenía todas sus ofertas sobre una plataforma que luego se transformaría en lo que hoy es Has Offers, de Tune.

Estas plataformas de afiliados eran adservers muy sencillos diseñados para medir clicks y conversiones. Al ahorrarse el trabajo de medir las impresiones, la dimensión de su problema era mucho menor y podían ofrecer mejores precios además de lentamente comenzar a enfocarse en algo que hoy es clave como la atribución.

Entonces, las ad-networks que comenzaban a comprar media sobre dispositivos móviles en el ecosistema fragmentado de DSPs, exchanges, publishers y demás, fueron contratando este tipo de plataformas para unificar sus campañas en un único lugar.

Como resultado residual de esto, comenzaron a surgir nuevas redes de afiliación ya que no era mucho mas esfuerzo habilitarle las ofertas (campañas) ya subidas a un nuevo afiliado y que la corra a su criterio.

Así fue como nació Mobusi, ex Impresiones Web. Glispa dejó de ser una network para transformarse en un gigante de afiliación, Matomy en un camino similar, entre otras.

Al mismo tiempo que esto sucedía, alrededor del año 2010 a 2011. Comenzaba a estallar el mercado de aplicaciones.

statistic_id263794_apple-app-store_-number-of-downloads-as-of-september-2016.png

Cientos de miles de publishers ahora estaban creando aplicaciones y pagando por descargas de sus apps. Lo cual generó una nueva necesidad en el mercado: Los trackers de app installs.

Y acá es donde una nueva confusión nació. Tune, que tenía su plataforma de afiliación hace años, lanza Mobile App Tracking, o MAT, una plataforma de atribución de descargas de aplicaciones para que los developers puedan saber de qué fuente provenía cada descarga.

Y digo que nació una nueva confusión, porque para los que llegaban al mundo mobile escuchaban Tune y no se sabía a qué producto se referían, ¿las apps usaban HasOffers? ¿Las AdNetworks usaban MAT? ¡Tampoco había a quien preguntarle! Era una industria realmente muy nueva.

Casi al mismo tiempo surgieron Appsflyer, Adjust, Kochava, Apsalar como alternativas a MAT y tambien varios exchanges y DSPs móviles lanzaron sus propios SDKs, interpretando que el SDK era el pixel de conversión de las aplicaciones móviles, pero hoy sabemos que no iba a ser así.

Sobre Device IDs

Hace ya varios años el tráfico de internet accedido de teléfonos móviles superó al de dispositivos de escritorio como laptops y PCs. Esto, entre muchos cambios, trajo la de un nuevo integrante a la familia, las apps.

Ahora, por qué hablo de apps en un post titulado device IDs… y para que todo tenga sentido, vamos a tener que saber qué son, cómo funcionan y para qué se utilizan las cookies.

Recordamos que uno de los principales usos de las cookies, era para hacer retargeting. Ahora bien, las cookies se alojan dentro de un navegador. Si cambiamos de navegador, las cookies que se nos instalaron en el previo, ya no son relevantes aquí.

2016: 90% del tráfico móvil proviene de aplicaciones

Y sumado a esto, cuando entendemos que cada aplicación, se comporta como un navegador diferente, vamos a darnos cuenta que va a ser imposible identificar a un mismo usuario a través de diferentes apps. Para hacerlo mas complejo aún, en mobile la mayoría del tráfico transcurre en aplicaciones, con lo que no podemos descartarlo.

Y aca es donde se vuelven relevantes los devices IDs, ya que es el único dato que vamos a tener disponible entre diversas aplicaciones para poder identificar a un usuario.

Pero, siempre hay un pero, hay una mala noticia: En mobile web, así se denomina al tráfico proveniente de navegadores web móviles, no vamos a tener disponible el dato de device ID. Con lo que igual va a ser difícil que logremos identificar a un usuario entre web y apps.

Hay algunas compañías que se dedican a hacer fingerprints o análisis estadísticos para poder vincular cookies con device IDs, esto se llama también cross-device, pero la realidad es que es algo imposible de comprobar. Solo las compañías con una base de usuarios enormes, como Google o Facebook, pueden darse el lujo de vincular estos datos con certeza, y ambas son muy celosas de esta información.

¿Y qué es un device ID?

La definición varía ligeramente dependiendo de la plataforma, Android o iOS, e incluso varía según la versión, con lo que apuntando a algo mas general, digamos que el device ID, es lo que nos va a permitir identificar a un dispositivo.

En Android, actualmente, el device ID es el GAID, siglas de Google Ad ID, y es algo similar a esto e4fe9bde-caa0-47b6-908d-ffba3fa184f2.

Mientras que en iOS, el device ID es el IDFA, y es algo similar a esto AEBE52E7-03EE-455A-B3C4-E57283966239.

Lo que debe quedar claro de todo esto es que si queremos hacer retargeting a usuarios en tráfico en aplicaciones móviles, deberemos utilizar listados de device IDs y nunca, jamás, a un pixel de audiencia.

Extra tip: Para poder obtener el device ID de tu teléfono podes descargar la aplicación de Tune my device para iOS y para Android.

CPAPI de Affise

Hace poco me enteré de este nuevo tracker o plataforma de afiliados, que tiene como novedad que no cobra por click, sino por conversión.

Su plan mas económico parte de 0.02 USD la conversión y a medida que enviamos mas volumen, el precio unitario decrece, como suele suceder.

Estoy esperando a que me activen la cuenta para probarlo, pero en el mientras tanto me encontré con este subproducto de ellos llamado CPAPI, que lo que hace es conectarse a las APIs de distintas plataformas de afiliados para tomar sus ofertas y luego las podemos exportar en un CSV unificado, y claramente, importarlas en Affise, que es la plataforma que lo desarrolló.

CPAPI de Affise

Actualmente están integrados con las siguientes plataformas y networks: Affise, Appthis, Avazu, Axonite, Cake, Dcypher media, Fuseclick, Ironsource, HasOffers, Minimob, Mobidea, Mobusi y Offerslook.

La idea me parece excelente, que yo sepa solo Epom en su plataforma de afiliados tiene algo similar, aunque con diferentes networks.