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.

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

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

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

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.