Atribución FAQ

Al utilizar Tenjin, verás que hay dos tipos de instalaciones: «Instalaciones notificadas» e «Instalaciones rastreadas».

Instalaciones declaradas son aquellas que la red publicitaria afirma haber generado para cada una de tus campañas. Instalaciones registradas son aquellas que un tercero imparcial atribuye a la campaña de una red publicitaria, teniendo en cuenta las demás campañas que estás llevando a cabo en otras redes publicitarias. Al analizar las «instalaciones rastreadas», estás analizando una métrica de instalaciones que es global: se basa en todas las campañas, incluso en aquellas que estás ejecutando en otras redes publicitarias. Las «instalaciones declaradas», por el contrario, las calcula de forma aislada la red publicitaria en la que te anuncias; se basan únicamente en lo que ve esa red publicitaria.

¿Se supone que las «instalaciones declaradas» deben coincidir con las «instalaciones rastreadas»? No siempre. El objetivo de la atribución NO es hacer que las «instalaciones rastreadas» sean iguales a las «instalaciones declaradas». De hecho, a veces la atribución debe hacer exactamente lo contrario. El objetivo de la atribución es ofrecer una visión global de TODA la actividad de las campañas en las distintas redes publicitarias que utilizas al mismo tiempo, y atribuir a los usuarios a la campaña más adecuada. Solo un tercero imparcial puede hacerlo.

Por ejemplo: Estás llevando a cabo campañas en dos redes publicitarias al mismo tiempo: Applovin y TikTok. Has establecido el CPI en $1,00 para cada campaña en cada red publicitaria. Un usuario único hace clic en tu campaña de Applovin; más tarde, ese mismo usuario hace clic en tu campaña de TikTok y, a continuación, instala la aplicación. ¿Qué ocurre? ¿Cómo se realiza el seguimiento de todo lo relacionado con ese usuario?

Dado que Applovin y TikTok no se comunican entre sí, no hay forma de que puedan conciliar los datos de un usuario único que interactúa con ambas campañas publicitarias en redes distintas al mismo tiempo. Como resultado, el recuento de instalaciones notificadas de Applovin sería “1” y el de TikTok también sería “1”. Esto es lo que tenemos hasta ahora:

¡Pero esto no tiene sentido! ¡Solo hemos captado a un único usuario! ¡Un usuario único solo debería estar asociado a una de las campañas!

Eso es precisamente lo que resuelve la atribución. Al utilizar un proveedor de atribución externo como Tenjin, este asignará al usuario a la campaña de TikTok como una “instalación rastreada” (basándose, en este caso, en el último clic). De este modo, el usuario único que hizo clic en Applovin y luego en TikTok se asociará a la campaña de TikTok y NO a la de Applovin. En este ejemplo, el recuento de «Instalaciones rastreadas» e «Instalaciones notificadas» quedaría así:

Ahora, el usuario único se encuentra en la campaña correspondiente de la red publicitaria, lo que permite realizar un análisis posterior de tus campañas. Si el usuario empieza a generar LTV, sabrás cuál es la eficacia de tu inversión. Esta es la única forma de medir tu ROI comparando elementos equivalentes.

Supongamos que el usuario captado genera un LTV a 90 días de $2,5. Tu análisis mostraría lo siguiente:

En este caso, el ROI = (LTV/gasto - 1).

Esto te permite saber que tu campaña de Google es más eficaz que tu campaña de Facebook para ese usuario concreto.

Por lo general, se espera una discrepancia de hasta 30% en el caso de las SAN y de 10% en el caso de las redes que no son SAN, por las razones que se indican a continuación:

• Las redes publicitarias ignoran la tecnología de atribución de terceros: Meta, Twitter, Google y algunas otras se basan en su propia tecnología interna para indicar a sus socios de atribución cuándo debe atribuirse una instalación a sus redes. Cuando los usuarios de estas redes se solapan, la tecnología de terceros no puede controlar si la red publicitaria reclama una instalación notificada, incluso cuando la tecnología de atribución solo selecciona una red publicitaria a la que asociar la descarga.
• Las URL de clic y las llamadas de instalación no están configuradas correctamente: el problema más fácil de solucionar es aquel en el que el anunciante ha configurado incorrectamente las URL de clic y las llamadas de instalación. Por lo general, esto se puede solucionar de inmediato comprobando que se estén utilizando las URL de clic correctas y que la llamada de instalación en la tecnología de atribución funcione correctamente.
• Los SDK de las redes publicitarias utilizan métodos imprecisos para el seguimiento de clics e instalaciones: cuando una red publicitaria no admite la recopilación de un identificador publicitario (IDFA o GAID), la tecnología de atribución de terceros suele basarse en la atribución probabilística.
• Duplicación de SDK de redes publicitarias y de atribución: los sistemas de atribución envían notificaciones de instalación a las redes publicitarias para informarles de que se ha producido una instalación. Si la aplicación cuenta con un SDK duplicado que envía notificaciones de instalación a una red publicitaria, puede producirse un doble recuento de las instalaciones notificadas.
• Las redes publicitarias utilizan una ventana de atribución diferente a la nuestra (normalmente para SAN).

“La ”retención“ es un concepto sencillo, pero hay varios detalles que hay que tener en cuenta a la hora de aplicarlo. Por defecto, en Tenjin calculamos la retención ”clásica»: un usuario retenido durante N días es aquel que vuelve el N.º día tras su captación. El día en que un usuario vuelve puede parecer claro y sencillo, pero en realidad hay dos formas de interpretarlo: (1) utilizando el tiempo absoluto o (2) utilizando el tiempo relativo. A modo de ejemplo de tiempo absoluto, un usuario captado el 1 de mayo y que vuelve el 2 de mayo se denomina usuario de 1 día. Sin embargo, si ese usuario fue captado a las 23:59 del 1 de mayo y volvió a las 00:01 del 2 de mayo, en realidad solo esperó 2 minutos para volver.

• En Tenjin, por defecto, utilizamos el tiempo relativo. Cada usuario tiene su propia “vida útil”, que se cuenta en días a partir del momento de la adquisición. Su “nacimiento” tiene lugar en el momento de la adquisición, el día 0, y el día 1 comienza 24 horas después. Un usuario retenido durante N días es aquel que vuelve entre las 24N horas y las 24(N+1) horas tras la adquisición.

Tasa de retención a N días = usuarios únicos retenidos a N días / usuarios únicos a 0 días

• Creemos que el uso del tiempo relativo sitúa a todos los usuarios en igualdad de condiciones, independientemente de la zona horaria en la que se encuentren o de cuál sea su ritmo circadiano. Además, nos permite “normalizar” nuestras otras métricas de ciclo de vida, como los ingresos acumulados, el ROI acumulado y el coste por usuario retenido. (NOTA) Tenjin ahora admite el cálculo de la tasa de retención mediante la estrategia de cohortes basada en UTC. Con este enfoque, el «Día 1» comienza a la primera medianoche UTC tras la marca de tiempo de instalación de cada usuario. Este método ayuda a armonizar los cálculos de la tasa de retención con otras plataformas que utilizan marcas de tiempo basadas en UTC, lo que reduce las discrepancias en las métricas.

Para activar esta función en tu cuenta, ve a «Mi cuenta» → «Gestionar usuario» → «Estrategia de cohortes» y selecciona la opción que desees.

Como hemos visto anteriormente, en la opción de retención relativa, un usuario retenido durante N días es aquel que vuelve entre las 24N horas y las 24(N+1) horas tras su captación.

Quizá la mejor forma de entenderlo sea ver un ejemplo.

• Los usuarios pertenecientes a la cohorte “1 de septiembre” se registraron entre las 00:00 del 1 de septiembre de 2015 y las 23:59 del 1 de septiembre de 2015.
• El último usuario “1 de septiembre” (llamémosle Joe) podría haberse registrado el 1 de septiembre de 2015 a las 23:59.
• El día 0 de Joe dura 24 horas y finaliza el 2 de septiembre de 2015 a las 23:59.
• Si Joe vuelve en cualquier momento entre las 23:59 del 2 de septiembre de 2015 y las 23:59 del 3 de septiembre de 2015, se le considerará un usuario retenido durante un día.
• Por lo tanto, la tasa de retención a 1 día de la cohorte “1 de septiembre” no se cerrará hasta el 4 de septiembre de 2015 a las 00:00.

En general, la tasa de retención a los x días de una cohorte determinada no se consolida hasta PASADOS (x+2) días COMPLETOS desde la adquisición. O, dicho de otro modo, en el día (x+3) se mantendrá constante.

Puede parecer extraño tener que esperar tres días enteros a que esta métrica se estabilice. ¿De dónde salen esos días y cómo los explicamos? En el peor de los casos, un usuario podría incorporarse al final del día (“Día #1”). Su día 0 (el periodo inicial de 24 horas) no cuenta a efectos de retención (“Día #2”). Y, en el peor de los casos, podría volver al final del periodo de 24 horas del día x (“Día #3”).

• Tenjin recauda los ingresos por compras dentro de la aplicación (IAP) directamente a través de tu SDK, mientras que iTunes Connect o Google Play Console muestran sus cifras directamente a través de las compras realizadas en la tienda. Según nuestra experiencia, esos ingresos podrían diferir en hasta un 20%.
• Estas son las posibilidades si observas una gran discrepancia.
• Los ingresos de Tenjin son netos (una vez deducida la comisión del 30% de Apple y Google Play Store).
• (Solo para iOS) Si no validás los recibos, Tenjin contabiliza todos los ingresos que pasan por nuestro SDK. Sin embargo, es posible que Apple rechace algunos de ellos. Para evitarlo, asegúrate de utilizar nuestra función de validación de recibos (SDK de iOS)
• Si acabas de integrar nuestro SDK y la actualización de la aplicación es opcional, es posible que algunos usuarios aún no tengan instalado el SDK de Tenjin. En ese caso, no verás todos los ingresos en Tenjin. Esto debería solucionarse con el paso del tiempo.

Cuando se habla de “ingresos” en general, hay dos tipos de ingresos: por cohorte y no por cohorte. En Tenjin, distinguimos claramente entre ambos. Los “ingresos” son siempre un valor no de cohorte, y el “LTV” es siempre un valor de cohorte por definición. Veamos un ejemplo. Supongamos que hoy es 20 de octubre:

En este ejemplo,

• Ingresos totales = $94,27
• LTV total a 90 días = $91,70

Esto significa que la aplicación generó $94,27 entre todos los usuarios (independientemente de cuándo se captaran) en septiembre (sin tener en cuenta la cohorte), y que la aplicación generó $91,70 a lo largo de toda la vida útil de los usuarios captados en septiembre (cohorte). Los ingresos suelen ser útiles a la hora de gestionar el flujo de caja diario, mientras que el LTV sirve para medir el ROI de tus campañas.

Ten en cuenta esta diferencia cuando compares las cifras de Tenjin con las que aparecen en otras herramientas. Además, separamos los ingresos por compras dentro de la aplicación (o LTV) de los ingresos publicitarios (o LTV), para que puedas ver de dónde proceden tus ingresos.

Los ingresos corresponden al flujo de caja diario durante el periodo seleccionado.

• En el intervalo de fechas comprendido entre el 1 y el 30 de septiembre, todos los usuarios generaron $94,27 en ingresos por la actividad de la aplicación (compras dentro de la aplicación o ingresos publicitarios) que tuvo lugar en ese intervalo de fechas.

El LTV a X días es la facturación generada por los usuarios captados (que han instalado la aplicación) durante el intervalo de fechas seleccionado, calculada como el total acumulado durante X días tras la instalación de la aplicación.

• Es importante saber qué se entiende por “hoy” en relación con el intervalo de fechas seleccionado, ya que necesitas saber cuán “antiguos” son los usuarios incluidos. Si hoy es 20 de octubre y el intervalo de fechas dado es del 1 al 30 de septiembre, tus usuarios “más antiguos” tienen 50 días de antigüedad (20 de octubre menos 1 de septiembre), y tus usuarios “más recientes” tienen 20 días de antigüedad. El LTV total a 90 días de $91,70 corresponde a todos los ingresos generados por los usuarios en 30 cohortes (cada día de septiembre). Por consiguiente, dado este intervalo de fechas del ejemplo, el LTV de 50 días, el de 51 días…, el de 89 días y el de 90 días tendrían todos el mismo valor, ya que tus usuarios más antiguos solo pueden generar ingresos durante 50 días tras la instalación.

¿Llegarán los ingresos a igualar alguna vez el LTV de x días?

Probablemente no. Para que eso ocurriera, sería necesario que TODOS los usuarios tuvieran EXACTAMENTE la misma fecha de instalación en un mismo día UTC (de 00:00 a 23:59). Esto es extremadamente improbable.

Es normal que haya discrepancias entre las cifras de usuarios activos diarios (DAU) de Tenjin y las de Firebase, ya que la lógica utilizada para contar y realizar el seguimiento de las instalaciones y los DAU es diferente en ambas plataformas. En Tenjin, utilizamos el primer evento «app_open» como evento de instalación y todos los eventos «app_open» posteriores se registran como sesiones. También se recomienda utilizar siempre la última versión del SDK de Tenjin e inicializarlo en cada llamada a OnResume. Si sigues observando grandes discrepancias en los datos, envíanos un correo electrónico a support@tenjin.com con los detalles para que podamos investigar el asunto más a fondo.

El UUID (identificador de instalación de Analytics) generado por Tenjin en el momento de la instalación no es persistente a nivel de dispositivo. Por lo tanto, cuando un usuario vuelve a instalar la aplicación, el identificador de instalación de Analytics se restablece, lo que da lugar a un recuento de nuevas instalaciones. Esto puede provocar un ligero aumento en el número de instalaciones registradas, dependiendo de la frecuencia con la que se vuelvan a instalar las aplicaciones.

Si deseas disponer de la métrica ‘Reinstalaciones rastreadas’ para tu aplicación, envía un correo electrónico a support@tenjin.com. Actualmente, dichas reinstalaciones solo se atribuirán al tráfico orgánico.

En el caso de los eventos de instalación: Meta suele gestionar automáticamente la deduplicación de las instalaciones. Por lo tanto, si tanto el SDK de Meta como Tenjin registran una instalación, normalmente solo se cuenta una vez.

En el caso de los eventos dentro de la aplicación (como compras, ingresos o impresiones publicitarias): estos no se deduplican automáticamente. Envía los eventos desde una sola fuente: elige entre Tenjin o el SDK de Meta para enviar tus eventos dentro de la aplicación; no selecciones ambos.

Desactivar el registro automático de eventos en el SDK de Meta: si utilizas el SDK de Meta, desactiva la opción «autoLogAppEventsEnabled» para evitar que envíe eventos de ingresos o compras de forma predeterminada.

¡Sí! Tenjin es compatible con la atribución para Meta Instant Games. Para conocer los pasos detallados sobre cómo configurarlo, ponte en contacto con el equipo de asistencia de Tenjin en support@tenjin.com