De un vistazo: Una reinstalación ocurre cuando un usuario instala una aplicación, la desinstala y luego la reinstala. Las reinstalaciones dan como resultado uno de los siguientes tipos de atribución: reinstalación no orgánica, reinstalación orgánica o reatribución (retargeting). Las reinstalaciones ayudan a evitar múltiples cargos para los usuarios que desinstalan e instalan de nuevo.
Qué es una reinstalación
Una reinstalación se produce cuando un usuario elimina una aplicación y luego la reinstala durante la ventana de reatribución.
La reinstalación puede provenir de una campaña de retargeting (reatribución), una fuente orgánica o una fuente no orgánica.
Las reinstalaciones que provienen de una fuente orgánica, o una fuente no orgánica, y se encuentran en la ventana de reatribución, se denominan reinstalaciones.
Las reinstalaciones que provienen de campañas de retargeting se denominan reatribuciones.
Se diferencian en cómo se atribuyen los eventos de reinstalación e in-app.
Si se produce una instalación fuera de la ventana de reatribución, la reinstalación se denomina nueva instalación. Una nueva instalación se atribuye a la fuente de medios (u orgánica si no se registra ningún engagement) y comienza una nueva ventana de reatribución.
La siguiente tabla muestra lo que AppsFlyer llamaría diferentes reinstalaciones
| Fuente de la reinstalación | ¿Es válida la ventana de reatribución? | ¿El usuario interactuó con una campaña de retargeting antes de reinstalar? | ¿El usuario interactuó con una campaña de UA antes de reinstalar? | Cómo se llama |
|---|---|---|---|---|
| De una campaña de retargeting | Sí | Sí | No | Reatribución |
| De una fuente orgánica o no orgánica | Sí | No | Sí o No | Reinstalación |
| De una fuente orgánica o no orgánica | No | No | Sí o No | Nueva instalación |
Por qué son importantes las reinstalaciones
Además de ser una buena indicación de que los usuarios están volviendo a tu aplicación y que tus campañas están funcionando, es importante realizar una atribución adecuada de las reinstalaciones para ayudar a evitar múltiples cargos para los usuarios que desinstalan e instalan nuevamente dentro de la ventana de reatribución.
Asimismo, la atribución de eventos in-app desde reinstalaciones a la fuente de medios original (primera instalación) proporciona a los anunciantes una mejor imagen de cómo se involucran los usuarios. También muestra cuán efectivas son las campañas de UA y los anuncios de retargeting. Para obtener más información, consulta los eventos in-app a continuación.
Flujo de reinstalación y resultado
Reinstalación
Después de la primera instalación de la aplicación, el usuario la desinstala y luego vuelve a instalarla durante la ventana de reatribución. Una reinstalación puede provenir de una campaña orgánica o de UA (ver ejemplos).
Sucede lo siguiente:
- La instalación NO se atribuye: no aparece en el panel de control, ni en los datos.
- NO se envía un postback de instalación a ninguna fuente de medios.
- Consulta los eventos in-app para obtener información sobre cómo se atribuyen los eventos in-app
Reatribución
Sucede lo siguiente:
- La instalación se atribuye a la fuente de medios de retargeting en la vista de retargeting y unificada del panel de control general.
- La vista de adquisición de usuarios no contiene reatribuciones.
- Todos los siguientes eventos in-app se atribuyen a la fuente de medios de retargeting (ver eventos in-app para más información).
- Se envía un postback de instalación a la fuente de medios de retargeting.
Para obtener más información sobre la atribución de retargeting, haz clic aquí.
Eventos in-app
Información general
Los eventos in-app realizados por un usuario después de una reinstalación se atribuyen como orgánicos, no orgánicos o no atribuidos, según el estado de atribución de los eventos posteriores a la reinstalación (consulta a continuación).
Un ejemplo de un evento in-app es un usuario que reinstala una aplicación y luego realiza una compra in-app.
Eventos in-app y cómo se atribuyen
| Estado de atribución de los eventos posteriores a la reinstalación | Después de una reinstalación | Después de una reatribución |
|---|---|---|
| Atribuido como in-apps orgánicos | orgánico sin atribuir | Retargeting |
| Atribuido a la primera instalación(1) | fuente de medios de la primera instalación | Retargeting (2) |
|
(1) Ver limitaciones a continuación (2) En el campo de fuente primaria. La fuente de medios de la primera instalación se enumerará en el campo de fuente secundaria (tú solo lo verás en el raw data). |
||
In-apps orgánicos sin atribuir
Reinstalación
- Todos los eventos in-app se cuentan como orgánicos o no se tienen en cuenta, dependiendo del panel de control.
- Los eventos in-app se reportarán con conversion_type y campaign_type como "unknown".
-
La fecha utilizada para agregar datos depende del evento:
- Para la mayoría de los eventos in-app originados en un SDK, se utiliza la fecha de descarga de la aplicación para agregar datos; no la fecha de la reinstalación.
- Para eventos de ingresos por publicidad (af_ad_revenue) enviados por el conector del SDK, se utiliza la fecha de la reinstalación para agregar datos.
Reatribución
- Todos los eventos in-app se atribuyen a la fuente de medios de retargeting.
Atribuido a la primera instalación
Prerrequisitos
Requiere habilitarlo. Comunícate con tu CSM para discutirlo.
Finalidad
Proporciona a los anunciantes una mejor imagen de cómo están involucrados los usuarios. Muestra cuán efectivas son las campañas de UA y los anuncios de retargeting al atribuir eventos in-app a la fuente original en lugar de orgánicos.
Reinstalación
- Todos los eventos in-app generados a partir de las reinstalaciones se atribuyen a la instalación original. (1)
Reatribución
- Todos los eventos in-app se atribuyen al anuncio de retargeting en la fuente primaria y a la instalación original en la fuente secundaria. (2)
(1) Ver limitaciones a continuación.
(2) Esto solo lo verás en el raw data.
Nota
Los datos de KPI orgánicos en el panel de control pueden mostrar un valor más bajo con la atribución de eventos posteriores a la reinstalación establecida en Atribuido a la primera instalación, ya que algunos de esos números ahora pueden atribuirse a una fuente de medios no orgánica.
Ejemplos
Con Atribuido a la primera instalación habilitado
Ejemplo 1
Un usuario instala la aplicación (día 0), realiza una compra por 10 USD y luego desinstala la aplicación.
Al día siguiente (día 1), el usuario reinstala la aplicación y realiza una compra de 5 USD.
Dado que el usuario ya realizó una compra antes de reinstalar, no habrá un recuento adicional de usuarios únicos.
|
Fuente de medios |
usuario(s) |
Af_purchase: Usuarios únicos Día 0 |
Af_purchase: Usuarios únicos Día 1 (acumulativo) |
Ingresos Día 0 |
Ingresos Día 1 (acumulativo) |
|
Media_source_A |
1 | 1 | 1 | $10 | $15 |
Veremos un incremento en los ingresos bajo el mismo device_identifier.
|
Appsflyer_id |
Identificador de dispositivo |
Fuente de medios |
Nombre del evento |
Fecha del evento |
| 111 | XXX |
media_source_A |
install | día 0 |
| 111 | XXX |
media_source_A |
af_purchase | día 0 |
| 222 | XXX |
organic |
Reinstalación | día 1 |
| 222 | XXX |
media_source_A |
af_purchase | día 1 |
Ejemplo 2
Un usuario instala la aplicación (día 0), realiza una compra y luego desinstala la aplicación.
Al día siguiente (día 1), el usuario reinstala la aplicación desde una campaña de UA y realiza una compra.
|
Fuente de medios |
Nombre del evento |
Fecha del evento |
Atribución de reinstalaciones |
Atribución de eventos in-app |
|
media_source_A |
install | día 0 | media_source_A | |
|
media_source_A |
af_purchase | día 0 | media_source_A | |
|
media_source_B |
Reinstalación | día 1 | media_source_B | |
|
media_source_B |
af_purchase | día 1 | media_source_A |
Limitaciones
-
Solo los usuarios que hayan dado su consentimiento para compartir su identificador de dispositivo (como el IDFA o GAID) con la aplicación, tanto para la instalación como para la reinstalación, tendrán sus eventos in-app atribuidos a la instalación original.
- Los identificadores de dispositivo en la primera instalación y la reinstalación deben coincidir.
- La reinstalación debe ocurrir dentro de la ventana de reatribución de la última instalación registrada.
- Los eventos de ingresos por publicidad se atribuyen como orgánicos.
- Cada instalación y reinstalación seguirá teniendo su propio
appsflyer_idúnico. -
Los paneles de control no diferencian entre un evento in-app después de la instalación o reinstalación.
- Es posible ver esto a través del raw data.
Cómo aparecen los datos en los paneles de control de AppsFlyer
| Reinstalación no orgánica | Reinstalación orgánica | Reatribución | ||
|---|---|---|---|---|
| La reinstalación en sí | No visto | No visto | Fuente de medios de retargeting* | |
| Atribuciones de eventos in-app en el futuro | Eventos posteriores a la reinstalación establecidos en Atribuidos como in-apps orgánicos | Orgánicos sin atribuir | Orgánicos sin atribuir | Fuente de medios de retargeting |
| Eventos posteriores a la reinstalación establecidos en Atribuidos a la primera instalación | Primera fuente de medios | Primera fuente de medios | Campaña de retargeting | |
| *Solo en el panel de control general. | ||||
Reportes de raw data de reinstalaciones
Prerrequisitos
Requiere habilitarlo. Ponte en contacto con tu CSM para discutirlo.
Cómo se atribuyen los eventos de instalación e in-app
| Reinstalación no orgánica | Reinstalación orgánica | Reatribución | Instalación no orgánica | Instalación orgánica | ||
|---|---|---|---|---|---|---|
| Atribuido a | Campaña de UA | Orgánico | Campaña de retargeting | Campaña de UA | Orgánico | |
| Atribución de eventos en el futuro | Eventos posteriores a la reinstalación establecidos en Atribuidos como in-apps orgánicos | Orgánico | Orgánico | Campaña de retargeting | Campaña de UA | Orgánico |
| Eventos posteriores a la reinstalación establecidos en Atribuidos a la primera instalación | Primera instalación | Primera instalación | Campaña de retargeting | Campaña de UA | Orgánico | |
Disponibilidad de reportes de reinstalación
- Los reportes de raw data de reinstalaciones están disponibles utilizando las herramientas de entrega detalladas en la tabla que sigue.
- Los reportes tienen la misma estructura y se rellenan de manera similar a los reportes de instalaciones, en que:
- Los campos de Fuente de medios se rellenan utilizando la fuente de medios que trajo la reinstalación u orgánica.
- Tiempo de instalación: se interpreta como tiempo de reinstalación, es decir, la hora de la primera apertura de la aplicación después de la reinstalación.
- Nombre del evento: Reinstall
| Método de entrega de reportes | Reinstalación no orgánica | Reinstalación orgánica |
|---|---|---|
| Exportar datos | ✓ | ✓ |
| API pull | ✓ | ✓ |
| Data Locker | ✓ | ✓ |
| API push | ✓ | ✓ |