UTMs y GTM (I): campañas en app y play store

Cualquiera que se dedique a alguna rama de analítica/marketing digital ha oído hablar de los utms. Muy posiblemente también los haya usado. Y es que nos los utms son una de las formas más elementales de poder hacer un seguimiento del rendimiento de tus campañas, así como de entender mejor a través de qué canales están llegando tus usuarios a tu activo digital. Pero, ¿qué son los utms?

Hagamos un poco de recorrido histórico: los utms aparecen de la mano del predecesor de Google Analytics: Urchin. De ahí viene su nombre (Urchin Tracking Module) y, hasta ahora, se trataba de 5 parámetros que podíamos añadir a una URL con la intención de identificar una campaña concreta a través de la cual el usuario había entrado en nuestra web. Y digo que hasta ahora había 5 parámetros porque no hace mucho Google Analytics anunció que introducía 3 nuevos (tras casi 20 años con la misma estructura!): utm_source_platform, utm_creative_format y utm_marketing_tactic.

Ahora que tenemos más contexto, pongamos un ejemplo para entender mejor el funcionamiento de los utms. Imaginemos que somos una empresa que se dedica a fabricar zepelines (algo ya habitual por este blog) y vamos a lanzar diferentes campañas de marketing en diversos medios para promocionar nuestro nuevo y deslumbrante modelo: el Rainbow. Nuestros medios principales van a ser Facebook y TikTok, vamos a ir con un modelo de cpc (cost per click) y nuestra campaña se va a llamar «brand_new_rainbow». Para que nuestra plataforma de analítica sea capaz de identificar cada una de estas campañas y estos medios deberemos generar los utms dedicados a esta tarea. De esta forma podremos ver qué medio genera más visitas a la web, por ejemplo. Las urls finales quedarían como algo similar a esto:

Facebook: https://www.zeppelin.com?utm_source=facebook&utm_medium=cpc&utm_campaign=brand_new_rainbow

TikTok: https://www.zeppelin.com?utm_source=tiktok&utm_medium=cpc&utm_campaign=brand_new_rainbow

En este caso sólo hemos variado la fuente a través de la cual las campañas se han generado, pero nos serviría para cualquier modificación (por ejemplo, si tuviéramos 3 campañas distintas cambiaríamos ese parámetro para cada una de ellas). Una vez tenemos la url con los utms correspondientes, la insertaremos en nuestro anuncio y empezaremos a recibir datos sobre las visitas de los usuarios.

Este sería el caso prototípico de utilización de utms. Pero, por supuesto, en este blog no nos gusta quedarnos en los casos más «normales», y es por eso por lo que he preparado un monográfico sobre utms, en el que este post será el capítulo 1. Y es que el mundo de los utms es tan vasto y -muchas veces- rebuscado, que pensé que lo mejor era dedicarle varios capítulos al mismo, viendo en cada uno de ellos una cosa distinta.

«¿Cuál va a ser el tema de este primer capítulo?» Os preguntaréis. Pues como dice el título vamos a hablar de cómo propagar los utms de manera fidedigna para que puedan seguir a los usuarios cuando viajen de nuestra web a su plataforma de preferencia (App Store para iOS, Play Store para Android) a instalarse nuestra app.

1. El Problema

¿Cuál es el problema exactamente cuando hablamos de «seguir a los usuarios hasta la descarga de la app»? Pues que si somos capaces de reconocer los utms de nuestra web y, gracias a ellos, entender cuáles son las campañas o los canales que tienen un mejor rendimiento, es gracias a que tenemos un código de análisis en esta web que nos permite recoger esta información. Es decir:

¿Qué ocurre con un usuario que salta de nuestra web a una de las «tiendas» de app para descargarse la nuestra? Pues que en esa «tienda» no podemos insertar nuestro código de análisis, porque es un dominio que no nos pertenece. Por tanto, una vez el usuario sale de nuestra web y se dirige hacia la descarga de la app, deberíamos darlo por perdido. ¿O no?

2. El camino hacia la solución

El sentido común nos dice que deberíamos dejarlo, pero los directivos de nuestra empresa de zepelines, como ya se ha visto en más de una ocasión, son gente testaruda y detallista, por lo que nos exigen tener la información de las campañas a través de las cuales los usuarios se han descargado nuestra(s) app. Debemos, sin duda, ponernos a trabajar.

Lo primero que hacemos es visitar la documentación de Google para ver si existe algo relacionado con esto (bueno, en realidad quizá nos demos una vuelta antes por el blog de simoahava.com o de adswerve.com), y resulta que encontramos una -sorprendentemente- bien detallada primera aproximación a nuestra problema. Si nos fijamos en lo que dice esta documentación, nos encontramos varios puntos importantes:

Primero y fundamental: se pueden generar urls con parámetros utms que puedan entender -y trasladar- las plataformas de descarga de app.

Segundo: podemos utilizar los creadores que nos facilita Google para generar estas urls con sus parámetros asociados.

Tercero: los creadores de urls son diferentes para iOS y para Android.

Cuarto: mientras que para GA4 no debemos realizar ninguna configuración extra, para Universal hay una serie de requisitos que se deben cumplir en nuestra App para que se puedan comprender de forma correcta los utms en la plataforma analítica de nuestra elección (sólo para el caso de android):

Este último punto es bastante importante, aunque en realidad no va a ser muy crítico: Google Analytics Universal no va a ser la opción preferente para recoger la información de nuestras apps. Bueno, y en general, de nada, debido a su desaparición de aquí a un año. En cualquier caso, si estamos realizando esta configuración y tenemos el SDK v3, deberemos añadir a nuestra app lo siguiente en el archivo AndroidManifest.xml:

<!-- Used for Google Play Store Campaign Measurement-->;
<service android:name="com.google.analytics.tracking.android.CampaignTrackingService" />
<receiver android:name="com.google.analytics.tracking.android.CampaignTrackingReceiver" android:exported="true">
  <intent-filter>
    <action android:name="com.android.vending.INSTALL_REFERRER" />
  </intent-filter>
</receiver>

Si, por el contrario lo que tenemos es el Google Analytics for Android SDK v4, las instrucciones son algo distintas para conseguir obtener los datos de atribución. Son estas de aquí. Pongo todo esto para que no quede ningún caso de uso fuera, pero para mí lo que tiene sentido es hacer toda esta configuración en GA4.

Viendo esto nos quedamos un poco más tranquilos, pero todavía falta un punto muy importante: cómo conseguir que se registren de forma dinámica los utms con los que los usuarios «llegan» hasta la app. ¿Por qué digo esto? Porque aunque el generador de URLs es una herramienta fantástica no nos sirve de mucho a la hora de extraer la info de este usuario que va de nuestra web a la app. Si generásemos una url con unos utms determinados (cómo los que hemos visto anteriormente) y los insertáramos en la URL que va de nuestra página a la app store obtendríamos la captura de esos utms efectivamente en nuestra herramienta de análisis, pero estos UTMs SIEMPRE serían los mismos. La realidad es que no queremos esto, sino que queremos propagar los utms con los que el usuario ha llegado a nuestra web hasta la descarga de la app.

3. La solución

Para que los directivos de la empresa de zepelines queden contentos debemos ir un pasito más allá de lo que la documentación de Google nos ofrece. Debemos ser capaces de recoger los utms con los que ha llegado el usuario a nuestra web (o identificar el canal si no ha llegado de ninguna campaña) y, cuando este usuario decida descargarse nuestra app, transformar esos utms de forma que sean entendibles según los requisitos marcados por Google.

Y aquí es donde, como un buen cocinero de la televisión, os enseño -además, literalmente- la receta del plato ya cocinado. Lo que os voy a ofrecer aquí es una receta completa de un contenedor de GTM con el que vamos a ser capaces de generar la solución para que nuestros directivos favoritos queden completamente satisfechos.

Vamos a ir poco a poco describiendo todo lo que este contenedor (valga la redundancia) contiene. Pero para entender completamente lo que estamos haciendo, necesitamos observar un poco más a fondo la documentación sobre la atribución de las campañas de marketing de Google. Dentro de la misma, nos encontramos con este punto sobre las instalaciones en el Play Store:

¿Esto qué quiere decir? Quiere decir que para que se puedan entender los parámetros que queremos generar en nuestra URL, tendrán que estar dentro del parámetro «referrer». Por tanto, esto nos impide utilizar la nomenclatura habitual. ¿Cómo lo hacemos entonces? Pues para esto nos podemos proveer del creador de URLs que hemos visto anteriormente. Veamos como funciona:

Para la Play Store podríamos usar una configuración como la que estamos mostrando, donde tendremos que averiguar la red de publicidad que estamos usando y el nombre del paquete de la app (será algo parecido a lo que hemos visto en la imagen). Usando todo esto, la url que se nos quedaría sería muy parecida a esta:

https://play.google.com/store/apps/details?id=com.zeppelin.app&referrer=utm_source%3Dfacebook%26utm_medium%3Dcpc%26utm_campaign%3Dbrand_new_rainbow%26anid%3Daarki%26aclid%3D{click_id}%26cp1%3D{app_id}

¿Veis que ahora todos los parámetros utms están contenidos dentro del referrer? ¿Y que no se usa ni el & ni el = cuando estamos dentro de este referrer? Pues esto es justo lo que debemos conseguir pero cogiendo dinámicamente los parámetros con lo que nuestro usuario interesado en zepelines ha llegado a nuestra web. El caso de iOS es algo diferente, pero la lógica viene a ser la misma (sólo tenemos más parámetros que rellenar).

Ahora que ya entendemos la lógica principal, vamos al contenido de nuestra receta. Lo primero y principal: las plantillas:

He desarrollado estas dos plantillas que nos van a permitir agilizar nuestro trabajo de forma exponencial. Estoy en proceso de convertirlas en plantillas de la comunidad, pero mientras tanto, aquí las tenéis. La primera de ellas genera una lógica a través de la cual vamos a obtener las utms de nuestro usuarios y las vamos a almacenar en una cookie con su nombre indicativo (utm_source, utm_medium, etc.). Esta lógica tiene en cuenta las casuísticas más estándar (canal orgánico, gclid, fclid, etc.) y genera las utms apropiadas. Por otro lado, tenemos el generador de UTMs para las instalaciones de App. Cómo habréis podido sospechar, esta plantilla va a generar una variable con el link que queremos insertar en el botón que lleve tanto a la Play Store como a la AppStore. Así, por la cara. Casi sin esfuerzo. Casi.

Sólo tenemos que hacer una pequeña configuración en base a nuestros deseos más íntimos. Pero ya veréis, nada grave. Si os habéis importado ya toda la receta a vuestro contenedor, veréis algunas variables nuevas. Vayamos a por ellas y entenderéis a qué me refiero:

Aquí ya está hecha prácticamente toda la configuración que necesitáis hacer, pero es bueno que tengáis claro a qué se refiere cada cosa. Por ejemplo, para conseguir el link para la Play Store tenemos esta variable:

Dentro de esta configuración sólo tendremos que tocar el Ad Network, si es que no es la que sale por defecto. La redirect URL la vamos a generar dinámicamente gracias a nuestra propia web, y el app ID es algo que tenemos que rellenar en su propia variable:

En el caso de iOS la cosa se nos complica algo más, pero ya he pensado en vosotros, no os preocupéis. La cosa es que en iOS necesitamos más parámetros y podemos generar un link para Universal y otro para GA4, de ahí que veamos dos variables distintas. La configuración es algo como esto:

Tal y como hemos visto antes, aquí sólo tenemos que tocar el Ad Network y tendremos que rellenar las variables propias de app_id_ios y ga4_property_id_for_ios. Importante aquí destacar que no queremos el identificador del Data Stream como solemos hacer, sino el de la propiedad de GA4.

Bien, una vez que todo está claro, ¿a qué me refería con lo de que vamos a conseguir las redirect URLs de nuestra propia página? Pues es sencillo, todo esto que estamos haciendo lo hacemos porque en nuestra web hay insertado un botón que va a ir a la descarga de nuestra App, algo así:

Esos botones tienen asociado un link, que normalmente tendrá la forma de:

Android: https://play.google.com/store/apps/details?id=com.zeppelin.app

iOS: https://apps.apple.com/es/app/zeppelin/id000000001

Lo que queremos conseguir es que esos links que están insertados en los botones en añadan de forma dinámica todos los utms con los que queremos identificar a ese usuario en concreto, algo como:

Android: https://play.google.com/store/apps/details?id=com.zeppelin.app&referrer=utm_source%3D%26utm_medium%3Dtester%26utm_campaign%3Dtesting%26anid%3Dadmob

iOS: https://click.google-analytics.com/redirect?tid=212121221&url=https://itunes.apple.com/es/app/zeppelin/id1600912620&aid=com.zeppelin.app&idfa={idfa}&cs=&cm=tester&cn=testing&anid=admob&hash=md5

Ya os había dicho que iOS es algo más especial, pero no os preocupéis que está todo cubierto. El tema es que estos links son los que va a generar automáticamente nuestra plantilla y lo va a hacer gracias a las URLs que ya están contenidas en esos botones que hemos visto, gracias a estas variables:

De nuevo, vemos como iOS se caracteriza por su simplicidad. Básicamente lo que hacemos con estas variables es recoger los links de estos botones y almacenamos esa URL. Estas variables serán nuestros redirect URLs en las plantillas. Si hemos hecho todo correctamente al rellenar las variables de identificación que hemos visto, al realizar un preview desde GTM a nuestra página con los botones de descarga, obtendremos algo parecido a esto en nuestras variables de generación de link:

Venga, ya falta poco. Ahora sólo tenemos que coger esos links que ya están insertados en los botones y ponerles nuestros nuevos y flamantes links autogenerados. ¿Cómo vamos a hacer esto? Gracias a nuestras etiquetas Custom HTML, que ya tendréis importadas. Si nos vamos al apartado de etiquetas, veremos estas 3 nuevas:

Mientras que la de Campaign_data_on_cookie es la que nos va a permitir que nuestra template que recoge las utms y las inserta en una cookie funcione, las otras dos son las que van a generar el cambio de link entre el existente en el botón y nuestro link con todos los datos de atribución. Debemos tener clara una cosa, sólo un link está permitido por botón (uno para iOS, otro para Android), por lo que en el caso de iOS deberemos elegir si queremos lanzar los datos para que funcionen con GA4 o con Universal. De nuevo, recomiendo GA4 y así está configurado por defecto. Veamos ambas etiquetas:

Aunque son bastante autoexplicativas, sí me gustaría aclarar una cosa. Puede que no haya sólo un botón en nuestra página con la descarga desde la tienda. Por lo que deberemos cambiar todos los links que tengan todos los botones. De eso se encarga este pequeño script, a través del cual cogemos todos esos links y los sustituimos por el nuevo que hemos generado. Si volvemos a hacer un preview con toda esta configuración en nuestra web e inspeccionamos los botones, veremos que ya no tienen la forma sencilla del vínculo a la Store, sino que se han transformado a justo lo que necesitábamos:

Y así llegamos al final de nuestra primera aventura con las UTMs. Para poder ver estos datos deberemos tener acceso a las diferentes consolas de las tiendas de cada plataforma, y consultarlo aquí, por ejemplo:

4. Conclusiones

En este primer capítulo del monográfico sobre UTMs nos hemos acercado a cómo realizar la atribución sobre la descarga de una app que viene referida a través de nuestra propia web, propagando todos los datos de campaña que vinieran asociados a ese usuario.

Esto nos ayuda a entender cuáles son las campañas con mejor rendimiento a la hora de generar instalaciones de nuestra App y conocer mejor a los usuarios que interactúan con las mismas. Para hacer esto nos ayudamos de las dos plantillas que he generado para este fin (recogida de utms en cookie y generador de link para Stores), así como de toda la configuración que se encuentra contenida en la receta que más arriba adjunto.

En un mundo en el que las apps cada vez más juegan un papel fundamental en el acercamiento de las empresas a sus usuarios omnicanal, una solución como la planteada se presenta casi como imprescindible.