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.
- Los partners solo pueden recibir postbacks de reinstalación si admiten esta capacidad y AppsFlyer les ha concedido permisos explícitos. Los anunciantes pueden elegir enviar postbacks de reinstalación solo a este partner o a todas las fuentes de medios, incluidas las orgánicas, en la página Integración activa del partner, en la sección de postbacks de instalación.
- Consulta los eventos in-app para obtener información sobre cómo se atribuyen los eventos in-app
Reatribución
Después de la primera instalación de la aplicación, el usuario la desinstala, luego se involucra con una campaña de retargeting y la reinstala durante la ventana de 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
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.
Estado de atribución de los eventos posteriores a la reinstalación
| Atribución de reinstalaciones | Después de una reinstalación | Después de una reatribución |
|---|---|---|
| Atribuido como in-apps orgánicos | orgánico sin atribuir | Reorientación |
| 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 contabilizan como orgánicos o se descartan por completo según el método de reporte.
- 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
Nota
El modo de primera instalación se aplica automáticamente a las aplicaciones añadidas a AppsFlyer el 31 de julio de 2024 o después. Para las aplicaciones añadidas antes de esta fecha, te recomendamos que contactes con AppsFlyer para migrar tus aplicaciones existentes al modo de primera instalación.
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.
- Todos los eventos in-app generados a partir de las reinstalaciones se atribuyen a la instalación original. (1) La hora de instalación del evento in-app atribuido será la hora de la primera instalación, no la de la reinstalación. Por ejemplo, si hubo una instalación el 1 de marzo y luego una reinstalación el 5 de marzo, y si la opción «Atribución de eventos posteriores a la reinstalación» está habilitada, cualquier compra realizada después de la reinstalación se atribuirá a la hora de instalación del 1 de marzo.
- 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.
Prerrequisitos
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 de atribución en el modo de primera instalación.
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 |
instalar | día 0 |
| 111 | XXX | media_source_A |
af_compra | día 0 |
| 222 | XXX | orgánica |
Reinstalación | día 1 |
| 222 | XXX | media_source_A |
af_compra | 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 |
Reinstalación |
Atribución de eventos in-app |
media_source_A |
instalar | día 0 | media_source_A | |
media_source_A |
af_compra | día 0 | media_source_A | |
media_source_B |
Reinstalación | día 1 | media_source_B | |
media_source_B |
af_compra | día 1 | media_source_A |
Confirma que los eventos in-app se atribuyen a la instalación original
Puedes verificar en tu reporte de raw data que tus eventos in-app posteriores a la reinstalación están en modo de primera instalación siguiendo estos pasos:
- Comprueba el campo
install_timeen el evento in-app. Si refleja la hora de la instalación original (no la de la reinstalación), el evento se atribuye a la primera instalación. - Verifica el
device_id(GAID o IDFA). Sigue siendo el mismo en todas las instalaciones y reinstalaciones, por lo que puedes usarlo para hacer referencia al evento de la instalación original. - Ten en cuenta que el
appsflyer_iddel evento in-app difiere del valor de la instalación original. AppsFlyer genera un nuevo ID de AppsFlyer después de cada reinstalación.
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.
-
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.
- El SDK de Windows de AppsFlyer no mide las reinstalaciones.
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. Comunícate 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 | ✓ | ✓ |
| Casillero de datos | ✓ | ✓ |
| API push | ✓ | ✓ |
This article was translated using AI and may contain errors. For the most accurate information, please refer to the English version using the language selector.