Guia de integração de servidor para servidor
Caso de uso de servidor para servidor
Como alternativa ao Singular SDK, que deve ser embutido em suas aplicações, o Singular também fornece uma API REST que pode ser usada para construir uma integração completa que roda a partir do seu próprio servidor sem o Singular SDK. Este guia explica os conceitos por trás da construção de uma integração completa de servidor para servidor e destaca todos os recursos avançados.
Caso de uso híbrido
Como alternativa a uma integração 100% servidor a servidor, pode utilizar uma abordagem híbrida usando o SDK Singular para tratar da gestão de sessões e de todas as funcionalidades avançadas e requisitos de recolha de dados. Além disso, aproveitando a API EVENT de servidor para servidor para enviar eventos do seu servidor backend.
Detalhes do caso de uso híbrido
Ao enviar eventos móveis fora do aplicativo ou dados de eventos do site do seu servidor para Singular, é essencial incluir o identificador correspondente do Singular Mobile SDK ou Web SDK. Isso garante que a atividade do evento seja atribuída com precisão ao dispositivo correto.
Fluxo de dados
Existem dois métodos principais para recuperar esses dados do dispositivo:
- Fluxo de dados gerido pelo cliente: Esta opção consiste em capturar todos os pontos de dados necessários no cliente e transmiti-los ao servidor através da sua própria API. Essa abordagem permite coletar identificadores de dispositivos, dados de eventos e outros atributos necessários diretamente do lado do cliente (por exemplo, aplicativo móvel ou site) e encaminhá-los para o seu servidor, onde você pode processá-los e enviá-los para o Singular usando a API Server-to-Server EVENT.
- Postback: Essa opção é para configurar o postback do BI interno da Singular, que permite que a Singular envie um postback para o ponto de extremidade designado com um payload JSON. Esse postback é entregue em tempo real após a ocorrência de uma instalação, reengajamento e/ou eventos in-app. A carga incluirá todos os pontos de dados necessários para enviar com êxito eventos do lado do servidor fora do aplicativo. Para obter instruções detalhadas sobre como configurar o postback do BI interno, clique[AQUI].
Ambas as opções podem exigir alguma lógica do lado do servidor para manter um gráfico do dispositivo. Se o Singular SDK detetar uma alteração no identificador do dispositivo, é fundamental que o servidor seja atualizado em conformidade para garantir um acompanhamento e uma atribuição precisos.
Para implementar a primeira opção, em que você captura identificadores e parâmetros de dispositivo do aplicativo e os envia para o servidor para uso com os pontos de extremidade da API Singular, consulte os artigos a seguir para obter orientação:
- Examinar os parâmetros necessários do Ponto de extremidade de evento.
- Examine o Guia de recuperação de dados do dispositivo de servidor para servidor para amostras de código do iOS e do Android para ajudar na recuperação de identificadores de dispositivo específicos e pontos de dados do dispositivo.
Reveja as diretrizes gerais abaixo para seguir as diretrizes gerais de uma configuração de servidor para servidor. Com um caso de utilização híbrido, pode omitir o ponto de extremidade SESSION, uma vez que o SDK Singular irá geri-lo por si.
Pontos principais
- Flexibilidade: Controlo total sobre a recolha e transmissão de dados.
- Paridade de recursos: Suporta todas as funcionalidades do SDK quando os dados adequados são fornecidos.
- Caminho de integração: Cliente → Seu Servidor → API Singular
- Processamento em tempo real: Um pedido de cada vez, sem processamento em lote.
- Fluxo de dados sequencial: Os eventos devem ser processados em ordem cronológica.
- Deduplicação de dados: O Singular não deduplica os dados recebidos. Recomenda-se o envio de uma (1) solicitação bem-sucedida e a gravação de registos para o caso de uma solicitação ser reproduzida.
- Validação de dados: Os dados no nível do dispositivo são permanentes e não podem ser excluídos após a ingestão. Implemente uma validação completa dos dados antes de enviá-los à Singular para garantir a precisão.
Requisitos
Enquanto o SDK recolhe automaticamente os dados do dispositivo e da aplicação, a abordagem S2S requer que o utilizador:
- Colete os pontos de dados necessários do seu aplicativo.
- Encaminhar esses dados para seu servidor e armazená-los em um gráfico de dispositivo.
- Enviar solicitações de sessão para o Singular por meio do ponto de extremidade da API SESSION.
- Passar a resposta do Singular de volta para o aplicativo.
- Encaminhar solicitações de evento para o Singular através do ponto de extremidade da API EVENT.
Pontos de extremidade da API REST
Ponto de extremidade Session
GET https://s2s.singular.net/api/v1/launch
Referência da API do ponto de extremidade Session
Ponto de extremidade de evento
GET https://s2s.singular.net/api/v1/evt
Referência da API do ponto de extremidade de evento
Primeiros passos
Para integrar com sucesso a API REST do Singular para rastrear sessões e eventos de aplicativos, é necessário implementar um pipeline de dados abrangente que consiste em quatro fases principais.
- Estabelecer uma estratégia robusta de coleta de dados em seu aplicativo que capture e armazene interações relevantes do usuário e os pontos de dados exigidos pela Singular em seu banco de dados do lado do servidor.
- Criar um mecanismo de streaming de dados em tempo real que encaminhe instantaneamente os eventos capturados do seu servidor para os pontos de extremidade da API REST do Singular.
- Implementar o tratamento adequado de respostas para processar as respostas da API da Singular, garantindo a transmissão bem-sucedida de dados e o gerenciamento adequado de erros.
- Realizar testes completos em todos os fluxos de dados para validar a precisão e a confiabilidade da integração.
Essa abordagem sistemática garante uma transmissão de dados perfeita, mantendo a integridade dos dados e a sincronização em tempo real entre sua aplicação e a plataforma de análise da Singular.
Coleta de dados
A Singular requer pontos de dados específicos em cada endpoint, que são necessários para fornecer a funcionalidade de recursos da plataforma Singular. Todos os parâmetros necessários são obrigatórios e, se omitidos, resultarão em discrepâncias de dados ou funcionais.
Dica: Quando você coleta dados do lado do cliente para serem enviados de volta ao seu servidor, para uso com as APIs Singular, certifique-se de aguardar o retorno das funções assíncronas e lidar com vários casos extremos. Esse é um problema comum que pode causar dados ausentes e atribuição parcial.
- Reveja os parâmetros necessários do Session Endpoint.
- Reveja os parâmetros necessários do Event Endpoint.
- Reveja o Guia de recuperação de dados do dispositivo de servidor para servidor para amostras de código iOS e Android para ajudar na recuperação de identificadores de dispositivos específicos e pontos de dados do dispositivo.
- Reveja o Server-to-Server SKAdNetwork 4 Implementation Guide (Guia de implementação de SKAdNetwork 4 de servidor para servidor ) para obter exemplos de código iOS para ajudar na recuperação de pontos de dados de dispositivos SkAdNetwork 4 específicos.
- Reveja e identifique a secção de opções avançadas pretendidas abaixo.
Com os pontos de dados necessários capturados e fornecidos ao seu servidor, está pronto para transmitir pedidos de sessões e eventos para a Singular.
Fluxo de dados em tempo real
O fluxo de dados em tempo real é crucial para manter a atribuição precisa e a medição do desempenho da campanha. Ao implementar o rastreamento do lado do servidor, o tempo e a sequência da transmissão de dados impactam diretamente a qualidade das capacidades de análise e otimização fornecidas pela Singular.
Considerações Críticas sobre o Tempo
- Precisão da atribuição: Os relatórios de sessão atrasados podem afetar gravemente a precisão da atribuição, pois o sistema exige dados temporais precisos para associar corretamente as ações do usuário às campanhas de marketing.
- Implicações da SKAdNetwork: A natureza sensível ao tempo dos valores de conversão da SKAdNetwork para iOS torna a transmissão de dados em tempo real particularmente crítica. Com uma janela de tempo rigorosa no dispositivo para actualizações dos valores de conversão, qualquer atraso na comunicação de eventos pode levar à perda de oportunidades de atualização dos valores de conversão, resultando em dados incompletos ou imprecisos sobre o desempenho da campanha.
Algumas práticas recomendadas a ter em mente ao criar seu fluxo de dados:
- Implemente ouvintes de eventos do lado do servidor para iniciar a sessão do aplicativo.
- Encaminhe os dados da sessão para a API REST da Singular imediatamente com todos os pontos de dados necessários.
- Implementar ouvintes de eventos do lado do servidor para eventos in-app.
- Encaminhe os dados do evento para a API REST da Singular imediatamente com todos os pontos de dados necessários.
- Use a arquitetura webhook para uma transmissão de dados confiável.
- Implementar mecanismos de repetição para solicitações com falha.
- Monitorar o fluxo de dados para garantia de qualidade.
Com o fluxo em tempo real configurado, passe para o tratamento de respostas.
Tratamento de respostas
O tratamento de respostas é outro componente crítico que faz a ponte entre as interações da API do lado do servidor e a funcionalidade do lado do cliente. Essa comunicação bidirecional garante que os dados de resposta valiosos da API da Singular cheguem ao aplicativo móvel, permitindo recursos importantes, como deep linking diferido e atualizações de valor de conversão.
Principais tipos de resposta
- Deferred Deep Links: Quando uma nova sessão é iniciada, a resposta da API pode conter dados de deep link pendentes que precisam ser retransmitidos imediatamente para o aplicativo para o roteamento adequado do usuário e personalização da experiência.
- Valores de conversão: Para campanhas iOS, o endpoint de conversão fornece valores de conversão SKAdNetwork atualizados que devem ser prontamente encaminhados para o aplicativo para manter a medição precisa da campanha.
Algumas práticas recomendadas para ter em mente ao criar seu fluxo de tratamento de respostas:
- Implementar o tratamento de respostas no servidor do cliente.
- Analisar e validar as respostas da API Singular.
- Encaminhar dados de resposta relevantes para o aplicativo cliente. Essencial para atualizações de valores de conversão SKAdNetwork para iOS.
- Implementar o processamento de respostas no lado do cliente.
- Tratar os erros de forma adequada com códigos de estado apropriados.
- Registrar respostas com falha para mecanismos de nova tentativa.
Agora que o processamento de respostas está concluído, é hora de testar o pipeline de dados e validar se todos os fluxos de dados funcionam como esperado e fornecem os dados corretos.
Teste de fluxos de dados
A fase de teste é fundamental para uma implantação bem-sucedida. A integração mais básica com o Singular envolve a notificação do Singular quando ocorre uma sessão de usuário, permitindo que o Singular acione vários processos internos:
- Se for a primeira sessão do aplicativo no dispositivo específico, a Singular reconhece uma nova instalação e aciona o processo de atribuição de instalação.
- Se a sessão se qualificar como uma sessão de reengajamento, o Singular aciona o processo de atribuição de reengajamento (saiba mais nas Perguntas frequentes sobre reengajamento).
- Caso contrário, o Singular marca a sessão como uma sessão, que é usada para rastrear a atividade do usuário e as métricas de retenção.
O tempo de uma solicitação de sessão e as solicitações de eventos subsequentes para os servidores do Singular são críticos:
-
Uma única sessão deve ser recebida antes de qualquer evento.
Por exemplo, o SDK do Singular acionará uma sessão na abertura do aplicativo quando um usuário começar a usar o aplicativo e, em seguida, os eventos no aplicativo poderão ser enviados após a sessão. Se o utilizador colocar a aplicação em segundo plano durante um período de tempo prolongado (superior a 1 minuto), a sessão será encerrada. Outra sessão seria enviada quando a aplicação voltasse ao primeiro plano. É recomendável usar eventos do ciclo de vida do aplicativo e um timer para ajudar a gerenciar o gerenciamento de sessões e regular as solicitações de sessão para o Singular. - Os eventos que ocorrem na aplicação devem ser enviados em tempo real e após a respectiva sessão.
- Teste o fluxo de dados da sessão e valide se a primeira sessão e as sessões subsequentes têm seus respectivos pontos de dados e valores corretos.
- Confirme que os eventos só são recebidos após a sessão ser reportada à Singular. Se os eventos forem recebidos antes da sessão, será criada uma atribuição orgânica para o dispositivo, o que pode causar resultados indesejados nos relatórios.
- Confirme que a resposta da sessão é tratada e passada de volta para o aplicativo cliente. Isso é fundamental ao oferecer suporte a deeplinks diferidos com campanhas Singular.
Sucesso:
- Validou a recolha de dados e o armazenamento dos pontos de dados necessários!
- Validou o fluxo de dados em tempo real para o Singular!
- Validou o tratamento de respostas e o registo de pedidos para Singular!
- Validou todos os fluxos de dados de teste!
Opções avançadas
Para aproveitar as opções avançadas da integração Server-to-Server (S2S) do Singular, é necessário aprimorar o Session Notification Endpoint com parâmetros adicionais.
Esse processo envolve:
- Identificar os recursos avançados desejados.
- Localizar os parâmetros especiais correspondentes.
- Incorporar esses parâmetros na configuração do ponto de extremidade existente.
Analise as opções avançadas disponíveis abaixo:
Tratamento de atribuição adicional
Atribuição para campanhas de anúncios de pesquisa da Apple (iOS)
O Apple Search Ads é considerado uma rede de atribuição automática (SAN). A partir do iOS 14.3, a integração do Apple Search Ads é suportada por meio de duas estruturas do iOS:
- Para o iOS 14.2 e inferior, o Apple Search Ads é suportado através da estrutura iAd.
- Para o IOS 14.3 e superior, o Apple Search Ads é suportado através da estrutura AdServices.
Recomendamos que sejam implementadas as estruturas iAd e AdServices até que a estrutura iAd seja descontinuada numa data futura. Como o AdServices ainda é um novo serviço da Apple, a Singular utilizará os dois serviços, mas dará prioridade ao AdServices em relação aos sinais do iAd para atribuição e geração de relatórios.
Para obter mais informações, consulte a documentação de integração do Apple Search Ads.
Implementação dos anúncios de pesquisa da Apple através do iAd (iOS 14.2 e inferior)
1. Recuperação dos dados de atribuição:
Para recuperar os dados de atribuição, utilize a API iAd do Apple Search Ads. Chamar requestAttributionDetails(_:): devolve um objeto JSON que contém os dados de atribuição.
Por exemplo:
#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
}
}];
}
}
- Definir um atraso de alguns segundos antes de recuperar os dados de atribuição.
- Implementar uma lógica de repetição se a resposta for Falso ou um código de erro (0, 2, 3). Chame novamente a API de atribuição da Apple 2 segundos depois.
2. Enviando os dados de atribuição para a Singular:
Para compartilhar os dados de atribuição com o Singular, use o ponto de extremidade Notificação de evento para relatar um evento com o nome de evento reservado __iAd_Attribution__. Passe o objeto JSON que você recuperou na etapa anterior como o valor do parâmetro e , como no exemplo abaixo.
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()
https://s2s.singular.net/api/v1/evt?n=__iAd_Attribution__&e=%7B%22Version3.1%22%3A%7B%22iad-purchase-date%22%3A%20%222016-10-25T22%3A24%3A35Z%22%2C%22iad-keyword%22%3A%20%22ballon%22%2C%22iad-adgroup-id%22%3A%20%221234567%22%2C%22iad-campaign-id%22%3A%20%221234567%22%2C%22iad-lineitem-id%22%3A%20%221234567%22%2C%22iad-org-id%22%3A%20%224070%22%2C%22iad-org-name%22%3A%20%22Cool%20Company%22%2C%22iad-campaign-name%22%3A%20%22Search%20Campaign%22%2C%22iad-conversion-date%22%3A%20%222016-05-21T12%3A19%3A41Z%22%2C%22iad-conversion-type%22%3A%20%22Redownload%22%2C%22iad-click-date%22%3A%20%222016-05-21T12%3A19%3A31Z%22%2C%22iad-attribution%22%3A%20%22true%22%2C%22iad-adgroup-name%22%3A%20%22Ad%20Group%20Name%22%2C%22iad-lineitem-name%22%3A%20%22Line%20Item%20Name%22%7D%7D&a=SDK_KEY&p=iOS&i=com.singular.app&ip=10.1.2.3&ve=9.2&ma=Apple&mo=iPhone8%2C1&lc=en_US&idfa=8ECD7512-2864-440C-93F3-A3CABE62525B&idfv=38548D9F-3F73-4D4B-8545-9A920CC89191&utime=1568948680
Notas:
- Para o iOS 13+, tem de enviar o evento __iAd_Attribution__ imediatamente após a primeira sessão após a instalação ou reinstalação. Caso contrário, os dados do Apple Search Ads não serão considerados para atribuição.
- No iOS 14+, as respostas de atribuição do Apple Search Ads só estão disponíveis em determinadas condições e não estão disponíveis se o estado de AppTrackingTransparency for ATTrackingManager.AuthorizationStatus.denied.
Implementação do Apple Search Ads através de AdServices (iOS 14.3 e superior)
1. Recuperar o token de atribuição:
Recupere o token de atribuição utilizando attributionToken() assim que a aplicação for inicializada pela primeira vez após uma instalação ou reinstalação.
Por exemplo:
#import <AdServices/AdServices.h>
NSError *error = nil;
Class AAAttributionClass = NSClassFromString(@"AAAttribution");
if (AAAttributionClass) {
NSString *attributionToken = [AAAttributionClass attributionTokenWithError:&error];
if (!error && attributionToken) {
// Handle attributionToken
}
}
Notas:
- O token de atribuição é gerado no dispositivo.
- Após a geração, o token é armazenado em cache por 5 minutos no dispositivo. Após 5 minutos, um novo token é gerado se attributionToken() for chamado.
- O token gerado é válido por 24 horas.
2. Envie o token de atribuição para o Singular:
A URL codifica o token e envia o token para o Singular através do ponto de extremidade de notificação de sessão, anexado ao parâmetro &attribution_token=. Este token deve ser enviado na primeira sessão após cada instalação e reinstalação para permitir que o Singular rastreie os downloads e re-downloads do Apple Search Ads.
Importante: envio do referenciador de instalação do Google Play (Android)
O referenciador de instalação contém informações sobre quem enviou um utilizador para a Google Play Store. Quando o referenciador de instalação está disponível para o Singular, ele fornece a maneira mais precisa de atribuir instalações. Recupere esse valor e passe-o para o Singular na primeira chamada de notificação de sessão. Ele é necessário para alguns recursos importantes do Singular, como receber dados do Facebook em nossas Exportações de nível de usuário, compartilhá-los com Destinos de dados e enviar postbacks.
O Google Play recolhe informações de referenciador quando um utilizador chega à loja. Se o utilizador instalar posteriormente a aplicação para a qual foi direcionado, o Google Play disponibiliza as informações à aplicação. Para mais informações, consulte a documentação do Google para programadores.
Para partilhar o referenciador de instalação com o Singular:
- Quando o aplicativo for aberto pela primeira vez, recupere o referenciador de instalação usando a API Play Install Referrer.
-
Relate uma sessão para o Singular usando o ponto de extremidade Notificação de Sessão, incluindo o parâmetro install_ref. Esse parâmetro é codificado em JSON e tem os seguintes atributos:
Atributo Descrição referrer
O valor do referenciador conforme recuperado da API Play Install Referrer. Este é um objeto JSON, por isso certifique-se de que o codifica como uma cadeia de caracteres. referrer_source
Especifique "service". clickTimestampSeconds
O carimbo de data/hora do clique, conforme recebido da API Play Install Referrer (por exemplo, "1550420123"). installBeginTimestampSeconds
A hora em que a instalação foi iniciada, conforme recebido da API Play Install Referrer. current_device_time
A hora no dispositivo atual, em milissegundos (por exemplo, "1550420454906").
Segue-se um exemplo de código para comunicar o evento de referenciador de instalação:
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()
https://s2s.singular.net/api/v1/launch?aifa=8ecd7512-2864-440c-93f3-a3cabe62525b&andi=fc8d449516de0dfb&p=Android&a=SDK_KEY&i=com.singular.app&ip=10.1.2.3&ve=9.2&dnt=0&n=MyCoolApp&dnt=0&c=wifi&cn=Comcast&lc=en_US&bd=Build%2FMMB29K&ma=samsung&mo=SM-G935F&custom_user_id=123456789abcd&install_ref=%7B%22installBeginTimestampSeconds%22%3A%221568939453%22%2C%22referrer%22%3A%22utm_source%3Dgoogle-play%26utm_medium%3Dorganic%22%2C%22clickTimestampSeconds%22%3A%220%22%2C%22referrer_source%22%3A%22service%22%2C%22current_device_time%22%3A%221568944524%22%7D%0A
Atribuição do referenciador da instalação do Meta (Android)
O "Meta Referrer" é uma solução de medição específica para Android introduzida pelo Facebook para permitir aos anunciantes o acesso a dados de atribuição granulares ao nível do utilizador para instalações de aplicações Android (consulte as políticas de dados do Facebook). Ela é composta pela implementação das tecnologias "Google Play Install Referrer" (consulte "Passando o Google Install Referrer") e "Meta Install Referrer" para a mensuração da instalação do aplicativo. Leia mais sobre o Meta Referrer nas Perguntas frequentes sobre o tópico.
Para compartilhar informações do Meta Install Referrer com o Singnular:
- Quando o aplicativo for aberto pela primeira vez, recupere o Referenciador de instalação do Meta de acordo com a documentação do Meta.
-
Relate uma sessão para a Singular usando o ponto de extremidade da Notificação de Sessão, incluindo o parâmetro meta_ref. Este parâmetro é codificado em JSON e tem os seguintes atributos:
Atributo Descrição is_ct
O "is_ct" como recebido do Referenciador de Instalação Meta. (por exemplo, 0 ou 1) install_referrer
O "install_referrer" como recebido do Referenciador da Meta-Instalação actual_timestamp
O "actual_timestamp" tal como recebido do Referenciador da Meta-Instalação (por exemplo, 1693978124).
Suporte a links singulares
Os deep links são links clicáveis que levam os utilizadores a conteúdos específicos dentro de uma aplicação. Quando um utilizador clica numa ligação profunda num dispositivo que tem a aplicação instalada, a aplicação abre-se e mostra um produto ou experiência específica.
Os links de rastreamento singulares podem incluir links diretos e links diretos adiados (consulte as Perguntas frequentes sobre links diretos e as Perguntas frequentes sobre links singulares para obter mais informações).
Ativando o Deep Linking
Pré-requisitos do Deep Linking
O aplicativo cliente deve ser configurado para reconhecer o Singular Link como um iOS Universal Link ou um Android App Link. Siga o guia Pré-requisitos de links singulares para habilitar o link profundo para iOS e Android.
Implementando links diretos
Quando o aplicativo for aberto por meio de um link profundo, capture e adicione o openURL à solicitação de Notificação de Sessão enviada ao Singular, anexando o valor da URL ao parâmetro openuri. Isso é necessário ao usar Links Singulares.
O código do aplicativo cliente deve ser atualizado para analisar e tratar os parâmetros de deep link do URL de links singulares. No caso de uma ligação profunda bem sucedida causada por uma ligação singular, os seguintes parâmetros podem estar presentes no openURL:
_dl, _ios_dl, _android_dl, _p
- _ios_dl e _android_dl estarão presentes numa hiperligação quando esta tiver sido gerada para uma hiperligação profunda tanto no iOS como no Android com valores de hiperligação profunda diferentes para cada plataforma.
- Se os valores de deep link forem os mesmos para iOS E Android, apenas _dl estará presente.
- Se dados adicionais forem passados no parâmetro passthrough, o _p estará presente.
Exemplo de código do manipulador de deep link
O aplicativo deve ter um código manipulador capaz de analisar o openURL e tratá-lo adequadamente. Veja o exemplo abaixo para demonstrar como analisar os parâmetros do Singular Link.
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)
}
class DeepLinkHandler {
fun handleDeepLink(intent: Intent) {
val data: Uri? = intent.data
data?.let { uri ->
val params = mutableMapOf<String, String>()
// Parse query parameters
uri.queryParameterNames?.forEach { name ->
when (name) {
"_dl" -> params["deeplink"] = uri.getQueryParameter(name) ?: ""
"_android_dl" -> params["android_deeplink"] = uri.getQueryParameter(name) ?: ""
"_p" -> params["passthrough"] = uri.getQueryParameter(name) ?: ""
}
}
processDeepLinkParameters(params)
}
}
private fun processDeepLinkParameters(params: Map<String, String>) {
// Process the parameters as needed
println("Processed parameters: $params")
}
}
// In your Activity
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
// Handle deep link if activity was launched from a deep link
intent?.let { DeepLinkHandler().handleDeepLink(it) }
}
override fun onNewIntent(intent: Intent?) {
super.onNewIntent(intent)
// Handle deep link if app was already running
intent?.let { DeepLinkHandler().handleDeepLink(it) }
}
}
Suporte a Deep Link diferido
Quando o aplicativo for aberto pela primeira vez desde a instalação, habilite o fluxo de links diretos diferidos adicionando os seguintes parâmetros ao relatar a sessão ao Singular:
- install=true
- ddl_enabled=true
A Singular verifica se o aplicativo foi instalado por meio de um link de rastreamento que incluía um deferred deep link. Se tiver sido, a solicitação de Sessão retorna os seguintes valores na resposta ao seu servidor:
- deferred_deeplink - o endereço do deep link. É isto que precisa de analisar para mostrar aos utilizadores o produto ou a experiência certa.
- deferred_passthrough - quaisquer parâmetros de passagem adicionados à hiperligação profunda.
A aplicação cliente deve incluir código para tratar os parâmetros Deferred Deeplink e Passthrough fornecidos na resposta da API Singular SESSION e tratar os dados de forma adequada. A resposta JSON da notificação SESSION com um valor de deeplink diferido terá o seguinte aspeto:
{
"deferred_deeplink":"myapp://deferred-deeplink",
"status":"ok",
"deferred_passthrough":"passthroughvalue"
}
Uso de parâmetros de passagem dinâmicos
Os links de rastreamento singulares podem incluir parâmetros de passagem dinâmicos(saiba mais). Se a sua organização tiver configurado parâmetros de passagem dinâmicos para um link, o URL do deep link inclui o parâmetro _p seguido de um valor de cadeia de caracteres JSON codificado por URL ou uma cadeia de caracteres não estruturada que pode ser utilizada para mostrar ao utilizador o conteúdo ou a experiência adequada.
Resolver ligações curtas
Quando o aplicativo é aberto a partir de um link Singular encurtado, o parâmetro a seguir deve ser incluído na solicitação de inicialização para notificar o ponto de extremidade da sessão Singular que o openURL enviado no parâmetro openuri deve ser resolvido para o link longo Singular.
- singular_link_resolve_required=true
O Singular retornará o link longo não encurtado e o desenvolvedor de aplicativos poderá analisar os parâmetros deep link e passthrough no manipulador de link, conforme observado anteriormente.
Exemplo de resposta
{
"status":"ok",
"resolved_singular_link":"https://myapp.sng.link/A59c0/nha7?_dl=myapp%3A%2F%2Fdeeplink&_ddl=myapp%3A%2F%2Fdeferred-deeplink&_p=passthroughvalue"
}
Suporte a vários dispositivos
Ao implementar a solução de cross-device do Singular ou associar usuários a sessões no nível do dispositivo, é crucial aproveitar o parâmetro custom_user_id de forma eficaz. Esse parâmetro deve conter seu ID de usuário interno, mas é imperativo aderir às políticas de privacidade de dados, evitando a inclusão de informações de identificação pessoal (PII).
As melhores práticas envolvem o uso de um valor em hash derivado de um nome de usuário, endereço de e-mail ou uma cadeia gerada aleatoriamente que serve como identificador de usuário exclusivo do aplicativo. Ao implementar essa abordagem, você permite que o Singular utilize o custom_user_id para relatórios abrangentes entre dispositivos, exportações de dados ao nível do utilizador e postbacks de BI interno (quando configurado), aumentando assim a granularidade e o valor dos seus dados analíticos, mantendo a privacidade do utilizador.
Relatórios de receitas
A Singular pode recolher dados sobre a receita obtida através da aplicação para ajudar a analisar o desempenho e o ROI das suas campanhas. A Singular disponibilizará os dados em relatórios, registos de exportação e postbacks.
Para rastrear eventos de receita, use o mesmo ponto de extremidade de Notificação de evento que você usa para todos os eventos, mas inclua os parâmetros de Receita.
- is_revenue_event Isso marca o evento como um evento de receita. Você pode ignorar esse parâmetro se o nome do evento for __iap__ ou se o valor for maior que zero.
- purchase_receipt Este é um objeto retornado do processo de compra no aplicativo (IAP) do Android ou iOS. É altamente recomendável passá-lo para o Singular para fornecer ao Singular todos os detalhes sobre a transação e enriquecer seus relatórios do Singular com dados.
- receipt_signature (Apenas Android) Recomendamos vivamente que passe este dado para a Singular para validar a transação e combater a fraude in-app.
- amt Este é o valor da receita como um Double (exemplo: "amt=1,99").
- cur Este é o código de moeda ISO 4217, (exemplo: "cur=USD").
Utilize a secção Implementar gestão do estado da subscrição no código do cliente da aplicação como guia para obter o objeto de compra da biblioteca de faturação do Google Play e/ou do StoreKit da Apple. Também pode consultar informações de subscrição e gerir o estado da subscrição diretamente no dispositivo. Passe esses detalhes de volta ao seu servidor para inclusão na solicitação de evento para o Singular.
Exemplo de evento de receita personalizado
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())
GET /api/v1/evt
?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 HTTP/1.1
Host: s2s.singular.net
Accept: application/json
curl -G "https://s2s.singular.net/api/v1/evt" \
--data-urlencode "a=sdk_key_here" \
--data-urlencode "p=Android" \
--data-urlencode "i=com.singular.app" \
--data-urlencode "ip=10.1.2.3" \
--data-urlencode "ve=9.2" \
--data-urlencode "aifa=8ecd7512-2864-440c-93f3-a3cabe62525b" \
--data-urlencode "asid=edee92a2-7b2f-45f4-a509-840f170fc6d9" \
--data-urlencode "n=RevenueEventName" \
--data-urlencode "amt=2.50" \
--data-urlencode "cur=USD" \
--data-urlencode "is_revenue_event=true" \
--data-urlencode "purchase_receipt={\"orderId\":\"GPA.1234\",\"packageName\":\"com.example\",\"productId\":\"com.example.product\",\"purchaseTime\":1417113074914,\"purchaseState\":0,\"purchaseToken\":\"hakfcimbkargpM\"}" \
--data-urlencode "receipt_signature=TyVJfHg8OAoW7W4wuJtasr5agEDMnNXvhfrw==" \
--data-urlencode "purchase_product_id=com.example.product" \
--data-urlencode "purchase_transaction_id=GPA.1234-1234-1234-12345"
Rastreamento de desinstalações
A Singular pode rastrear desinstalações usando as Notificações push silenciosas do dispositivo. Para habilitá-lo, será necessário enviar o token push do dispositivo para o servidor Singular junto com cada notificação de sessão.
-
Certifique-se de seguir nossos guias para configurar o rastreamento de desinstalação na plataforma Singular e para seu aplicativo:
- Para iOS, anexe o Token APNS ao parâmetro apns_token parâmetro. Para Android, anexe o Token FCM ao parâmetro fcm parâmetro.
Recuperar o recibo de instalação do iOS
Ao relatar uma sessão para um aplicativo iOS, você deve passar o recibo de instalação no parâmetro install_receipt parâmetro.
Para recuperar este valor, adicione o seguinte código à sua aplicação:
// 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
import Foundation
import StoreKit
class ReceiptManager {
static func getInstallReceipt() -> String? {
if #available(iOS 18.0, *) {
// Synchronous wrapper for async code
let semaphore = DispatchSemaphore(value: 0)
var result: String?
Task {
do {
let transaction = try await AppTransaction.shared
result = transaction.jwsRepresentation
semaphore.signal()
} catch {
debugPrint("Failed to get app transaction: \(error.localizedDescription)")
semaphore.signal()
}
}
semaphore.wait()
return result
} else {
// Legacy receipt fetching
guard let receiptURL = Bundle.main.appStoreReceiptURL else {
debugPrint("Receipt URL not found")
return nil
}
do {
let receiptData = try Data(contentsOf: receiptURL, options: .uncached)
return receiptData.base64EncodedString(options: [])
} catch {
debugPrint("Failed to read receipt: \(error.localizedDescription)")
return nil
}
}
}
}
Conformidade com as leis de privacidade de dados
A Singular fornece uma funcionalidade de proteção da privacidade para o ajudar a cooperar com quaisquer parceiros que possam estar em conformidade com as leis de privacidade do consumidor, como o GDPR e a CCPA. Estes parceiros querem ser notificados se o utilizador final consentiu em partilhar as suas informações privadas.
Se tiver implementado uma forma de pedir o consentimento dos utilizadores para partilhar as suas informações, utilize o parâmetro data_sharing_options para notificar a Singular da escolha do utilizador:
- Passe "limit_data_sharing":false para indicar que o utilizador consentiu (optou por participar) na partilha das suas informações.
- Passar "limit_data_sharing":true se o utilizador recusar.
A Singular utiliza o endereço limit_data_sharing em"Postbacks de privacidade do utilizador", bem como para transmitir estas informações a parceiros que o exijam, a fim de cumprir os regulamentos relevantes. Consulte"Privacidade do utilizador e limitação da partilha de dados" para obter mais informações.
Nota:
- O parâmetro data_sharing_options é opcional, mas pode haver informações de atribuição que o parceiro partilhará com a Singular apenas se for especificamente notificado de que o utilizador optou por participar.