Guía de integración de servidor a servidor

Guía de integración de servidor a servidor

Caso de uso de servidor a servidor

Como alternativa al SDK de Singular, que debe integrarse en sus aplicaciones, Singular también proporciona una API REST que puede utilizarse para crear una integración completa que se ejecute desde su propio servidor sin el SDK de Singular. En esta guía se explican los conceptos necesarios para crear una integración completa de servidor a servidor y se destacan todas las funciones avanzadas.

Caso de uso híbrido

Como alternativa a una integración 100% servidor a servidor, puede utilizar un enfoque híbrido utilizando Singular SDK para gestionar la sesión y todas las funciones avanzadas y requisitos de recopilación de datos. Además, puede aprovechar la API EVENT de servidor a servidor para enviar eventos desde su servidor backend.

Detalles del caso de uso híbrido

Detalles del caso de uso híbrido

Al enviar eventos móviles fuera de la aplicación o datos de eventos web desde su servidor a Singular, es esencial incluir el identificador correspondiente desde Singular Mobile SDK o Web SDK. Esto garantiza que la actividad del evento se atribuya con precisión al dispositivo correcto.

Flujo de datos

s2s_hybrid_device_data_capture.png

Existen dos métodos principales para recuperar estos datos del dispositivo:

  1. Flujo de datos gestionado por el cliente: Esta opción consiste en capturar todos los puntos de datos necesarios en el cliente y pasarlos a su servidor a través de su propia API. Este enfoque le permite recopilar identificadores de dispositivos, datos de eventos y otros atributos necesarios directamente desde el lado del cliente (por ejemplo, aplicación móvil o sitio web) y reenviarlos a su servidor, donde puede procesarlos y enviarlos a Singular utilizando la API EVENT de servidor a servidor.
  2. Postback: Esta opción consiste en configurar el postback de BI interno de Singular, que permite a Singular enviar un postback a su endpoint designado con una carga útil JSON. Este postback se envía en tiempo real después de que se produzca una instalación, un reenganche y/o un evento dentro de la aplicación. El payload incluirá todos los puntos de datos necesarios para enviar con éxito eventos del lado del servidor fuera de la aplicación. Para obtener instrucciones detalladas sobre cómo configurar el postback de BI interno, haga clic[AQUÍ].

Ambas opciones pueden requerir cierta lógica del lado del servidor para mantener un gráfico del dispositivo. Si Singular SDK detecta un cambio en el identificador del dispositivo, es fundamental que su servidor se actualice en consecuencia para garantizar un seguimiento y una atribución precisos.

Para implementar la primera opción, en la que se capturan los identificadores de dispositivo y los parámetros de la aplicación y se envían al servidor para su uso con los puntos finales de la API de Singular, consulte los siguientes artículos:

Revise las directrices generales a continuación para seguir las directrices generales de una configuración de Servidor a Servidor. Con un caso de uso híbrido, puede omitir el punto final SESSION, ya que Singular SDK lo gestionará por usted.

Puntos clave

  • Flexibilidad: Control total sobre la recogida y transmisión de datos.
  • Paridad de funciones: Soporta todas las funcionalidades del SDK cuando se proporcionan los datos adecuados.
  • Ruta de integración: Cliente → Su Servidor → API Singular.
  • Procesamiento en tiempo real: Una petición cada vez, sin procesamiento por lotes.
  • Flujo de datos secuencial: Los eventos deben procesarse en orden cronológico.
  • Deduplicación de datos: Singular no deduplica los datos recibidos. Se recomienda enviar una (1) solicitud con éxito y guardar los registros en caso de que deba repetirse una solicitud.
  • Validación de datos: Los datos a nivel de dispositivo son permanentes y no pueden borrarse una vez introducidos. Realice una validación exhaustiva de los datos antes de enviarlos a Singular para garantizar su exactitud.

Requisitos

Mientras que el SDK recopila automáticamente los datos del dispositivo y de la aplicación, el enfoque S2S requiere que usted:

  1. Recopilar los datos necesarios de su aplicación.
  2. Enviar estos datos a su servidor y almacenarlos en un gráfico de dispositivo.
  3. Enviar solicitudes de sesión a Singular a través del punto final de la API SESSION.
  4. Pasar la respuesta de Singular a la aplicación.
  5. Envíe solicitudes de eventos a Singular a través del punto final de la API EVENT.

Puntos finales de la API REST


Punto final de sesión

GET https://s2s.singular.net/api/v1/launch

Referencia de API de punto final de sesión


Punto final de eventos

GET https://s2s.singular.net/api/v1/evt

Referencia de la API del punto final de eventos


Cómo empezar

Para integrarse con éxito con la API REST de Singular para el seguimiento de sesiones y eventos de aplicaciones, es necesario implementar un canal de datos completo que consta de cuatro fases clave.

  1. Establezca una sólida estrategia de recopilación de datos dentro de su aplicación que capture y almacene las interacciones relevantes del usuario y los puntos de datos requeridos de Singular en su base de datos del lado del servidor.
  2. Cree un mecanismo de transmisión de datos en tiempo real que reenvíe instantáneamente los eventos capturados desde su servidor a los puntos finales de la API REST de Singular.
  3. Implemente una gestión de respuestas adecuada para procesar las respuestas de la API de Singular, garantizando una transmisión de datos correcta y una gestión de errores apropiada.
  4. Realice pruebas exhaustivas en todos los flujos de datos para validar la precisión y fiabilidad de la integración.

Este enfoque sistemático asegura la transmisión de datos sin problemas, manteniendo la integridad de los datos y la sincronización en tiempo real entre su aplicación y la plataforma de análisis de Singular.

Recogida de datos

Recogida de datos

Singular requiere puntos de datos específicos en cada punto final, que son necesarios para proporcionar la funcionalidad característica de la plataforma Singular. Todos los parámetros requeridos son obligatorios y si se omiten darán lugar a discrepancias de datos o funcionales.

Sugerencia: Cuando recopile datos del lado del cliente para enviarlos de vuelta a su servidor, para utilizarlos con las API de Singular, asegúrese de esperar a que las funciones asíncronas devuelvan y gestionen varios casos extremos. Este es un problema común que puede causar la falta de datos y la atribución parcial.

Con los puntos de datos necesarios capturados y proporcionados a su servidor, está listo para transmitir solicitudes de sesiones y eventos a Singular.

Transmisión de datos en tiempo real

Transmisión de datos en tiempo real

La transmisión de datos en tiempo real es crucial para mantener una atribución precisa y una medición del rendimiento de la campaña. Al implementar el seguimiento del lado del servidor, el momento y la secuencia de la transmisión de datos afectan directamente a la calidad de las capacidades de análisis y optimización proporcionadas por Singular.

Consideraciones críticas sobre la sincronización

  • Precisión de la atribución: El retraso en los informes de sesión puede afectar gravemente a la precisión de la atribución, ya que el sistema requiere datos temporales precisos para asociar correctamente las acciones del usuario con las campañas de marketing.
  • Implicaciones de SKAdNetwork: La naturaleza temporal de los valores de conversión de iOS SKAdNetwork hace que la transmisión de datos en tiempo real sea especialmente crítica. Con una ventana de tiempo estricta en el dispositivo para las actualizaciones de los valores de conversión, cualquier retraso en la notificación de eventos puede hacer que se pierdan oportunidades de actualizar los valores de conversión, lo que resulta en datos de rendimiento de campaña incompletos o inexactos.

Algunas de las mejores prácticas a tener en cuenta al construir su flujo de datos:

Con el flujo en tiempo real configurado, pase a la gestión de respuestas.

Gestión de respuestas

Gestión de respuestas

La gestión de respuestas es otro componente crítico que une las interacciones de la API del lado del servidor con la funcionalidad del lado del cliente. Esta comunicación bidireccional garantiza que los valiosos datos de respuesta de la API de Singular lleguen a la aplicación móvil, permitiendo funciones clave como la vinculación profunda diferida y las actualizaciones del valor de conversión.

Tipos de respuesta clave

  • Enlaces profundos diferidos: Cuando se inicia una nueva sesión, la respuesta de la API puede contener datos de enlaces profundos pendientes que necesitan ser transmitidos inmediatamente a la aplicación para el correcto enrutamiento del usuario y la personalización de la experiencia.
  • Valores de conversión: Para las campañas de iOS, el punto final de conversión proporciona valores de conversión actualizados de SKAdNetwork que deben reenviarse rápidamente a la aplicación para mantener una medición precisa de la campaña.

Algunas buenas prácticas a tener en cuenta cuando construya su flujo de gestión de respuestas:

  • Implementar la gestión de respuestas en el servidor cliente.
  • Analice y valide las respuestas de Singular API.
  • Enviar los datos de respuesta relevantes a la aplicación cliente. Esencial para las actualizaciones de valores de conversión de SKAdNetwork en iOS.
  • Implementar el procesamiento de respuestas del lado del cliente.
  • Gestión de errores con códigos de estado adecuados.
  • Registro de respuestas fallidas para mecanismos de reintento.

Una vez completada la gestión de las respuestas, es hora de probar el canal de datos y validar que todos los flujos de datos funcionan como se espera y proporcionan los datos correctos.

Probar los flujos de datos

Prueba de los flujos de datos

La fase de pruebas es fundamental para el éxito de la implantación. La integración más básica con Singular consiste en notificar a Singular cuando se produce una sesión de usuario, lo que permite a Singular desencadenar varios procesos internos:

  • Si es la primera sesión para la aplicación en el dispositivo específico, Singular reconoce una nueva instalación y activa el proceso de atribución de instalación.
  • Si la sesión se califica como sesión de reenganche, Singular activa el proceso de atribución de reenganche (más información en las preguntas frecuentes sobre reenganche).
  • De lo contrario, Singular la marca como una sesión, que se utiliza para realizar un seguimiento de la actividad del usuario y las métricas de retención.

La sincronización de una solicitud de sesión y las posteriores solicitudes de eventos a los servidores de Singular es fundamental:

  1. Debe recibirse una única sesión antes de cualquier evento.
    Por ejemplo, el SDK de Singular activará una sesión en la apertura de la aplicación cuando el usuario comience a utilizarla. Si el usuario deja la aplicación en segundo plano durante un largo periodo de tiempo (más de 1 minuto), la sesión expirará. Se enviará otra sesión cuando la aplicación vuelva al primer plano. Se recomienda utilizar eventos del ciclo de vida de la aplicación y un temporizador para ayudar a gestionar la sesión y regular las solicitudes de sesión a Singular.
  2. Los eventos que se produzcan en la app deben enviarse en tiempo real y después de su respectiva sesión.
  • Pruebe el flujo de datos de la sesión y valide que la primera sesión y las siguientes tengan sus respectivos puntos de datos y valores correctos.
  • Confirme que los eventos sólo se reciben después de que la sesión se notifica a Singular. Si los eventos se reciben antes de la sesión, se fabricará una atribución orgánica para el dispositivo, lo que puede provocar resultados no deseados en los informes.
  • Confirme que la respuesta de la sesión se gestiona y se devuelve a la aplicación cliente. Esto es fundamental cuando se admiten enlaces profundos diferidos con campañas Singular.

Éxito:

  • Ha validado la recopilación y el almacenamiento de los datos necesarios.
  • Ha validado la transmisión de datos en tiempo real a Singular.
  • Ha validado la gestión de respuestas y el registro de peticiones a Singular.
  • Ha validado todos los flujos de datos de prueba.

Opciones Avanzadas

Para aprovechar las opciones avanzadas de la integración de servidor a servidor (S2S) de Singular, debe mejorar el punto final de notificación de sesión con parámetros adicionales.

Este proceso implica:

  1. Identificar las características avanzadas deseadas.
  2. Localizar los parámetros especiales correspondientes.
  3. Incorporar estos parámetros a la configuración del endpoint existente.

Revise las opciones avanzadas disponibles a continuación:

Manejo adicional de la atribución

Compatibilidad con campañas de anuncios de búsqueda de Apple

Atribución para campañas de anuncios de búsqueda de Apple (iOS)

Apple Search Ads se considera una red de autoatribución (SAN). A partir de iOS 14.3, la integración de Apple Search Ads es compatible con dos frameworks de iOS:

  • Para iOS 14.2 e inferiores, Apple Search Ads es compatible a través del framework iAd.
  • Para iOS 14.3 y posteriores, Apple Search Ads es compatible a través del framework AdServices.

Recomendamos que se implementen tanto el marco iAd como el AdServices hasta que el marco iAd quede obsoleto en el futuro. Dado que AdServices es todavía un nuevo servicio de Apple, Singular utilizará ambos servicios pero dará prioridad a AdServices sobre las señales de iAd para la atribución y la generación de informes.

Para más información, consulte nuestra documentación sobre la integración de Apple Search Ads.

Implementación de los anuncios de búsqueda de Apple a través de iAd (iOS 14.2 y versiones inferiores)

1. Recuperación de los datos de atribución:

Para recuperar los datos de atribución, utilice la API de iAd de Apple Search Ads. Llamando a requestAttributionDetails(_:): devuelve un objeto JSON que contiene los datos de atribución.

Por ejemplo

Objective-C
#import <iAd/iAd.h>
  
    Class ADClientClass = NSClassFromString(@"ADClient");
  
    if (ADClientClass) {
        id sharedClient = [ADClientClass performSelector:@selector(sharedClient)];
        
        if ([sharedClient respondsToSelector:@selector(requestAttributionDetailsWithBlock:)]) {
            [sharedClient requestAttributionDetailsWithBlock:^(NSDictionary *attributionDetails, NSError *error) {
                if (attributionDetails && attributionDetails.count > 0) {
                    // REPORT attributionDetails FROM YOUR APP TO YOUR SERVER


                }
            }];
        }
    }
Atención: A menudo, los usuarios que hacen clic en un anuncio de Search Ads descargan y abren la aplicación inmediatamente. Si hay alguna latencia en las comunicaciones, es posible que un MMP como Singular no pueda recibir y procesar el clic en el anuncio a tiempo antes de que la aplicación se abra y llame a la Search Ads Attribution API. Para evitarlo, Apple recomienda
  1. Establecer un retraso de unos segundos antes de recuperar los datos de atribución.
  2. Implementar una lógica de reintento si la respuesta es False o un código de error (0, 2, 3). Volver a llamar a la API de atribución de Apple 2 segundos después.

2. Envío de los datos de atribución a Singular:

Para compartir los datos de atribución con Singular, utilice el punto final de notificación de eventos para informar de un evento con el nombre de evento reservado __iAd_Attribution__. Pase el objeto JSON que recuperó en el paso anterior como valor del parámetro e , como en el ejemplo siguiente.

Python HTTP
import requests
  import json
  
  SDK_KEY = '[sdk_key from Developer tools > SDK Integration > SDK keys]'
  EVENT_URL = 'https://s2s.singular.net/api/v1/evt'
  
  # !!! REPLACE WITH COLLECTED VALUE FROM APP !!!
  apple_attribution_data = {
    u'Version3.1': {
        u'iad-adgroup-id': u'1234567',
        u'iad-adgroup-name': u'Ad Group Name',
        u'iad-attribution': u'true',
        u'iad-campaign-id': u'1234567',
        u'iad-campaign-name': u'Search Campaign',
        u'iad-click-date': u'2016-05-21T12:19:31Z',
        u'iad-conversion-date': u'2016-05-21T12:19:41Z',
        u'iad-keyword': u'ballon',
        u'iad-lineitem-id': u'1234567',
        u'iad-lineitem-name': u'Line Item Name',
        u'iad-org-name': u'Cool Company',
        u'iad-purchase-date': u'2016-05-21T12:19:41Z'
    }
  }
  
  params = {
    'n': '__iAd_Attribution__',
    'e': json.dumps(apple_attribution_data),
    'a': SDK_KEY,
    'p': 'iOS',
    'i': 'com.singular.app',
    'ip': '10.1.2.3',
    've': '9.2',
    'mo': 'iPhone9%2C4',
    'lc': 'en_US',
    'idfa': '8ECD7512-2864-440C-93F3-A3CABE62525B',
    'idfv': '38548D9F-3F73-4D4B-8545-9A920CC89191',
    'utime': 1483228800
  }
  
  result = requests.get(EVENT_URL, params=params)
  print result.json()

Notas:

  • Para iOS 13+, debe enviar el evento __iAd_Attribution__ inmediatamente después de la primera sesión tras la instalación o reinstalación. De lo contrario, los datos de Apple Search Ads no se tendrán en cuenta para la atribución.
  • En iOS 14+, las respuestas de atribución de Apple Search Ads solo están disponibles en determinadas condiciones y no están disponibles si el estado de AppTrackingTransparency es ATTrackingManager.AuthorizationStatus.denied.

Implementación de los anuncios de búsqueda de Apple a través de AdServices (iOS 14.3 y versiones posteriores)

1. Recuperación del token de atribución:

Recupere el token de atribución mediante attributionToken() en cuanto la aplicación se inicialice por primera vez tras una instalación o reinstalación.

Por ejemplo:

Objective-C
#import <AdServices/AdServices.h> 

NSError *error = nil;
Class AAAttributionClass = NSClassFromString(@"AAAttribution");
if (AAAttributionClass) {
    NSString *attributionToken = [AAAttributionClass attributionTokenWithError:&error];
    if (!error && attributionToken) {
        // Handle attributionToken


    }
}

Notas:

  • El código de atribución se genera en el dispositivo.
  • Una vez generado, el token se almacena en caché durante 5 minutos en el dispositivo. Transcurridos 5 minutos, se genera un nuevo código si se llama a attributionToken().
  • El token generado es válido durante 24 horas.

2. Envíe el código de atribución a Singular:

Codifique la URL del token y envíelo a Singular a través del endpoint de notificación de sesión, anexado al parámetro &attribution_token=. Este token debe enviarse en la primera sesión después de cada instalación y reinstalación para que Singular pueda realizar un seguimiento de las descargas y re-descargas de Apple Search Ads.

Referencia de instalación compatible con Google Play

Importante: Envío del referente de instalación de Google Play (Android)

El referente de instalación contiene información sobre quién envió a un usuario a Google Play Store. Cuando el referente de instalación está disponible para Singular, proporciona la forma más precisa de atribuir instalaciones. Recupere este valor y páselo a Singular en la primera llamada de notificación de sesión. Es necesario para algunas funciones importantes de Singular, como recibir datos de Facebook en nuestras exportaciones a nivel de usuario, compartirlos con destinos de datos y enviar postbacks.

Google Play recopila información de referencia cuando un usuario llega a la tienda. Si el usuario instala más tarde la aplicación a la que fue dirigido, Google Play pone la información a disposición de la aplicación. Para obtener más información, consulte la documentación para desarrolladores de Google.

Para compartir la referencia de instalación con Singular:

  1. Cuando la aplicación se abre por primera vez, recupere la referencia de instalación utilizando la API de referencia de instalación de Play.
  2. Informe de una sesión a Singular utilizando el punto final de Notificación de Sesión incluyendo el parámetro install_ref. Este parámetro está codificado en JSON y tiene los siguientes atributos:

    Atributo Descripción
    referrer
    El valor de referencia obtenido de la API de referencia de instalación de Play. Se trata de un objeto JSON, así que asegúrese de codificarlo como cadena.
    referrer_source
    Especifique "service".
    clickTimestampSeconds
    La marca de tiempo de clic recibida de la API de referencias de instalación de Play (por ejemplo, "1550420123").
    installBeginTimestampSeconds
    La hora a la que comenzó la instalación, tal y como se recibió de la Play Install Referrer API.
    current_device_time
    La hora en el dispositivo actual, en milisegundos (por ejemplo, "1550420454906").

A continuación se muestra un ejemplo de código para informar del evento de referencia de instalación:

Python HTTP
import requests
  import json
  
  SDK_KEY = '[sdk_key from Developer tools > SDK Integration > SDK keys]'
  LAUNCH_URL = 'https://s2s.singular.net/api/v1/launch'
  
  referrer_values = {
        "referrer": "tracking_id%3D123456789&utm_source%3Dmdotm%26utm_medium%3Dbanner%26utm_campaign%3Dcampaign",
        "referrer_source" : "service",
        "clickTimestampSeconds" : 1550420123,
        "installBeginTimestampSeconds" : 1550420123,
        "current_device_time" : 1550420454906
      }

referrer_values = json.dumps(referrer_values, separators=(',',':'))
  
   params = {
       'a': SDK_KEY,
       'p': 'Android',
       'i': 'com.singular.app',
       'ip': '10.1.2.3',
       've': '9.2',
       'ma': 'samsung',
       'mo': 'SM-G935F',
       'lc': 'en_US',
       'aifa': '8ecd7512-2864-440c-93f3-a3cabe62525b',
       'andi': 'fc8d449516de0dfb',
       'utime': 1483228800,
       'dnt': 0,
       'install':'true',
       'n': 'MyCoolApp',
       'c': 'wifi',
       'cn': 'Comcast',
       'bd': 'Build/13D15',
       'fcm':'bk3RNwTe3H0CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1',
       'app_v':'1.2.3',
       'openuri':'myapp%3A%2F%2Fhome%2Fpage%3Fqueryparam1%3Dvalue1',
       'ddl_enabled':'false',
       'install_source': 'com.android.vending',
       'install_time': 1510040127,
       'update_time': 1510090877,
      'custom_user_id': '123456789abcd',
      'install_ref' : referrer_values
   }
  
   result = requests.get(LAUNCH_URL, params=params)
   print result.json()
Meta Install Referrer Attribution

Meta Install Referrer Attribution (Android)

"Meta Referrer" es una solución de medición específica de Android introducida por Facebook para permitir a los anunciantes acceder a datos de atribución detallados a nivel de usuario para las instalaciones de aplicaciones de Android (consulta las políticas de datos de Facebook). Consiste en implementar las tecnologías "Google Play Install Referrer" (ver "Pasar Google Install Referrer") y "Meta Install Referrer" para la medición de instalaciones de aplicaciones. Más información sobre Meta Referrer en las preguntas frecuentes sobre el tema.

Para compartir la información de Meta Install Referrer con Singnular:

  1. Cuando la aplicación se abre por primera vez, recupere el Meta Install Referrer de acuerdo con la documentación de Meta.
  2. Reporta una sesión a Singular usando el endpoint Session Notification incluyendo el parámetro meta_ref. Este parámetro está codificado en JSON y tiene los siguientes atributos:

    Atributo Descripción
    is_ct
    El "is_ct" tal y como se recibió de la Meta Install Referrer. (por ejemplo, 0 o 1)
    install_referrer
    El "install_referrer" recibido del Meta Install Referrer.
    actual_timestamp
    El "actual_timestamp" recibido del Meta Install Referrer (por ejemplo, 1693978124).

Soporte de enlaces singulares

Los enlaces profundos son enlaces en los que se puede hacer clic y que llevan a los usuarios a contenidos específicos dentro de una aplicación. Cuando un usuario hace clic en un enlace profundo en un dispositivo que tiene instalada la aplicación, ésta se abre y muestra un producto o experiencia específicos.

Los enlaces de seguimiento singulares pueden incluir enlaces profundos, así como enlaces profundos diferidos (consulte nuestras Preguntas frecuentes sobre enlaces profundos y las Preguntas frecuentes sobre enlaces singulares para obtener más información).

Activar la vinculación profunda

Activación de la vinculación profunda

Requisitos previos para la vinculación profunda

La aplicación cliente debe estar configurada para reconocer el Singular Link como un iOS Universal Link o un Android App Link. Siga la guía Prerrequisitos de Singular Links para habilitar el deeplinking de iOS y Android.

Implementación de enlaces profundos

Cuando la aplicación se abre a través de un enlace profundo, capture y añada la openURL a la solicitud de notificación de sesión enviada a Singular añadiendo el valor de la URL al parámetro openuri. Esto es necesario cuando se utilizan enlaces Singular.

El código de la aplicación cliente debe actualizarse para analizar y gestionar los parámetros de enlace profundo de la URL de Singular Links. En el caso de un enlace profundo correcto provocado por un Singular Link, los siguientes parámetros pueden estar presentes en la openURL:

_dl, _ios_dl, _android_dl, _p

 

  • _ios_dl y _android_dl estarán presentes en un enlace cuando el enlace se haya generado para realizar un enlace profundo tanto en iOS COMO en Android con valores de enlace profundo diferentes para cada plataforma.
  • Si los valores de enlace profundo son los mismos para iOS Y Android, sólo estará presente _dl.
  • Si se pasan datos adicionales en el parámetro passthrough, _p estará presente.

Ejemplo de código Deep Link Handler

La aplicación debe tener un código manejador capaz de analizar el openURL y manejarlo apropiadamente. El siguiente ejemplo muestra cómo podría analizar los parámetros Singular Link.

iOS - Swift Android - Kotlin
class DeepLinkHandler {
  func handleURL(_ url: URL) {
    guard let components = URLComponents(url: url, resolvingAgainstBaseURL: true) else {
      return
    }

    var params: [String: String] = [:]

    // Parse query parameters


    if let queryItems = components.queryItems {
      for item in queryItems {
        switch item.name {
        case "_dl":
          params["deeplink"] = item.value
        case "_ios_dl":
          params["ios_deeplink"] = item.value
        case "_p":
          params["passthrough"] = item.value
        default:
          break
        }
      }
    }

    // Handle the parsed parameters


    processDeepLinkParameters(params)
  }

  private func processDeepLinkParameters(_ params: [String: String]) {
    // Process the parameters as needed


    print("Processed parameters: \(params)")
  }
}

// In SceneDelegate or AppDelegate


func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
  guard let url = URLContexts.first?.url else { return }
  let handler = DeepLinkHandler()
  handler.handleURL(url)
}

Soporte de enlaces profundos diferidos

Cuando la aplicación se abre por primera vez desde la instalación, active el flujo de enlaces profundos diferidos añadiendo los siguientes parámetros cuando informe de la sesión a Singular:

  • install=true
  • ddl_enabled=true

Singular comprueba si la aplicación se instaló a través de un enlace de seguimiento que incluía un enlace profundo diferido. Si es así, la petición Session devuelve los siguientes valores en la respuesta a su servidor:

  • deferred_deeplink - la dirección del enlace profundo. Esto es lo que debe analizar para mostrar a los usuarios el producto o la experiencia adecuados.
  • deferred_passthrough - cualquier parámetro passthrough añadido al enlace profundo.

La aplicación cliente debe incluir código para gestionar el enlace profundo diferido y los parámetros passthrough proporcionados en la respuesta de Singular SESSION API y gestionar los datos adecuadamente. La respuesta JSON de la notificación de SESSION con un valor de enlace profundo diferido tendrá el siguiente aspecto:

{
 "deferred_deeplink":"myapp://deferred-deeplink",
 "status":"ok",
 "deferred_passthrough":"passthroughvalue"
}

Uso de parámetros de passthrough dinámicos

Los enlaces de seguimiento de Singular pueden incluir parámetros de traspaso dinámicos(más información). Si su organización ha configurado parámetros passthrough dinámicos para un enlace, la URL del enlace profundo incluye el parámetro _p seguido de un valor de cadena JSON codificado en la URL o una cadena no estructurada que puede utilizar para mostrar al usuario el contenido o la experiencia adecuados.

Resolución de enlaces cortos

Cuando la aplicación se abre desde un enlace Singular acortado, el siguiente parámetro debe incluirse en la solicitud de lanzamiento para notificar al punto final de Singular Session que la openURL enviada en el parámetro openuri debe resolverse en el enlace Singular largo.

  • singular_link_resolve_required=true

Singular devolverá el enlace largo no acortado y el desarrollador de la aplicación puede analizar los parámetros de enlace profundo y passthrough en el gestor de enlaces, como se ha indicado anteriormente.

Ejemplo de respuesta

{
   "status":"ok",
   "resolved_singular_link":"https://myapp.sng.link/A59c0/nha7?_dl=myapp%3A%2F%2Fdeeplink&_ddl=myapp%3A%2F%2Fdeferred-deeplink&_p=passthroughvalue"
}

Soporte entre dispositivos

Al implementar la solución multidispositivo de Singular o asociar usuarios con sesiones a nivel de dispositivo, es fundamental aprovechar el parámetro custom_user_id de forma eficaz. Este parámetro debe contener su ID de usuario interno, pero es imperativo adherirse a las políticas de privacidad de datos evitando la inclusión de información de identificación personal (PII).

Las mejores prácticas implican utilizar un valor hash derivado de un nombre de usuario, una dirección de correo electrónico o una cadena generada aleatoriamente que sirva como identificador de usuario único de su aplicación. Al implementar este enfoque, permite a Singular utilizar la custom_user_id para la generación de informes completos entre dispositivos, la exportación de datos a nivel de usuario y las devoluciones internas de BI (cuando esté configurado), mejorando así la granularidad y el valor de sus datos analíticos a la vez que mantiene la privacidad del usuario.


Informes de ingresos

Singular puede recopilar datos sobre los ingresos obtenidos a través de la aplicación para ayudar a analizar el rendimiento y el ROI de sus campañas. Singular pondrá los datos a su disposición en informes, registros de exportación y postbacks.

Para realizar un seguimiento de los eventos de ingresos, utilice el mismo punto final de Notificación de eventos que utiliza para todos los eventos, pero incluya los parámetros de Ingresos.

  • is_revenue_event Esto marca el evento como un evento de ingresos. Puede omitir este parámetro si el nombre del evento es __iap__ o el importe es mayor que cero.
  • purchase_receipt Se trata de un objeto devuelto por el proceso In-App Purchase (IAP) de Android o iOS. Recomendamos encarecidamente pasarlo a Singular para proporcionar a Singular todos los detalles sobre la transacción y enriquecer sus informes de Singular con datos.
  • receipt_signature (Solo para Android) Recomendamos encarecidamente pasar estos datos a Singular para validar la transacción y luchar contra el fraude dentro de la aplicación.
  • amt Este es el importe de los ingresos como doble (ejemplo: "amt=1.99").
  • cur Este es el código de moneda ISO 4217, (ejemplo: "cur=USD").

Utilice Implementación de la gestión del estado de suscripción en el código de cliente de aplicación como guía para obtener el objeto de compra de la biblioteca de facturación de Google Play y/o StoreKit de Apple. También puede consultar la información de suscripción y gestionar el estado de suscripción directamente en el dispositivo. Pase estos detalles a su servidor para incluirlos en la solicitud de evento a Singular.

Ejemplo de solicitud de evento de ingresos

Ejemplo de evento de ingresos personalizado

Python HTTP cURL
import requests

params = {
    "a": "sdk_key_here",
    "p": "Android",
    "i": "com.singular.app",
    "ip": "10.1.2.3",
    "ve": "9.2",
    "aifa": "8ecd7512-2864-440c-93f3-a3cabe62525b",
    "asid": "edee92a2-7b2f-45f4-a509-840f170fc6d9",
    "n": "RevenueEventName",
    "amt": "2.50",
    "cur": "USD",
    "is_revenue_event": "true",
    "purchase_receipt": {
        'orderId"': "GPA.1234",
        "packageName": "com.example",
        "productId": "com.example.product",
        "purchaseTime": 1417113074914,
        "purchaseState": 0,
        "purchaseToken": "hakfcimbkargpM",
    },
    "receipt_signature": "TyVJfHg8OAoW7W4wuJtasr5agEDMnNXvhfrw==",
    "purchase_product_id": "com.example.product",
    "purchase_transaction_id": "GPA.1234-1234-1234-12345",
}

response = requests.get("https://s2s.singular.net/api/v1/evt", params=params)
print(response.json())

Seguimiento de desinstalaciones

Singular puede realizar un seguimiento de las desinstalaciones utilizando las Notificaciones Push Silenciosas del dispositivo. Para habilitarlo, deberá enviar el token push del dispositivo al servidor de Singular junto con cada notificación de sesión.

  1. Asegúrese de seguir nuestras guías para configurar el seguimiento de desinstalaciones en la plataforma Singular y para su aplicación:

  2. Para iOS añada el APNS Token al parámetro apns_token al parámetro. Para Android, añada el token FCM al parámetro fcm al parámetro.

Recuperación del recibo de instalación de iOS

Al informar de una sesión para una aplicación de iOS, debe pasar el recibo de instalación en el parámetro install_receipt en el parámetro.

Cómo recuperar el recibo de instalación de iOS

Para recuperar este valor, añada el siguiente código a su aplicación:

Objective-CSwift
// ReceiptManager.h


@interface ReceiptManager : NSObject
+ (nullable NSString *)getInstallReceipt;
@end

// ReceiptManager.m


#import <StoreKit/StoreKit.h>

@implementation ReceiptManager

+ (nullable NSString *)getInstallReceipt {
    if (@available(iOS 18.0, *)) {
        dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
        __block NSString *result = nil;
        
        [SKPaymentQueue.defaultQueue addTransactionObserver:[[SKPaymentTransactionObserver alloc] init]];
        
        if (@available(iOS 18.0, *)) {
            [AppTransaction.shared fetchWithCompletionHandler:^(AppTransaction *transaction, NSError *error) {
                if (error) {
                    NSLog(@"Failed to get app transaction: %@", error.localizedDescription);
                } else {
                    result = transaction.jwsRepresentation;
                }
                dispatch_semaphore_signal(semaphore);
            }];
        }
        
        dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
        return result;
        
    } else {
        NSURL *receiptURL = [[NSBundle mainBundle] appStoreReceiptURL];
        if (!receiptURL) {
            NSLog(@"Receipt URL not found");
            return nil;
        }
        
        NSError *error = nil;
        NSData *receiptData = [NSData dataWithContentsOfURL:receiptURL 
                                                   options:NSDataReadingUncached 
                                                     error:&error];
        
        if (error) {
            NSLog(@"Failed to read receipt: %@", error.localizedDescription);
            return nil;
        }
        
        return [receiptData base64EncodedStringWithOptions:0];
    }
}

@end

Cumplimiento de las leyes de privacidad de datos

Singular proporciona funcionalidad de protección de la privacidad para ayudarle a cooperar con cualquier socio que pueda estar cumpliendo con las leyes de privacidad del consumidor, como GDPR y CCPA. Estos socios quieren ser notificados si el usuario final ha dado su consentimiento para compartir su información privada.

Si ha implementado una forma de solicitar a los usuarios su consentimiento para compartir su información, utilice el parámetro data_sharing_options para notificar a Singular la elección del usuario:

  • Pase "limit_data_sharing":false para indicar que el usuario ha dado su consentimiento (opted-in) para compartir su información.
  • Pase "limit_data_sharing":true si el usuario se negó.

Singular utiliza limit_data_sharing en"Postbacks de Privacidad del Usuario" así como para pasar esta información a socios que la requieren para cumplir con las regulaciones pertinentes. Consulte"Privacidad del usuario y limitación del uso compartido de datos" para obtener más información.

Nota:

  • El parámetro data_sharing_options es opcional, pero puede haber información de atribución que el socio compartirá con Singular sólo si se le notifica específicamente que el usuario ha optado por ello.