A Singular rastreia as campanhas do Google Ads por meio de uma integração server-to-server auto-atribuível com a App Conversion API do Google Ads , que inclui:

• Rastreamento de todas as instalações e re-engajamentos gerados por qualquer uma das suas campanhas do Google Ads
• Atribuição tanto de click-through quanto de view-through

A integração utiliza um Link ID , que é gerado no Google Ads e exclusivo para cada app. Uma vez que seu Link ID tenha sido configurado na Singular, a Singular começará a enviar ao Google todas as instalações, sessões e eventos de conversão in-app configurados.

Usando as informações de clique atribuído retornadas pelo Google, a Singular pode realizar a atribuição de último toque (Veja o processo de atribuição da Singular ) e oferecer relatórios sobre o desempenho das suas campanhas usando as mesmas informações granulares de campanha que você recebe no seu painel do Google Ads.

Para começar a rastrear conversões e eventos relacionados às campanhas do Google Ads, primeiro você precisa acessar sua conta do Google Ads para configurar suas ações de conversão - também conhecido como importar eventos .

Veja Integração de Atribuição do Google Ads: Como Importar Eventos para instruções detalhadas.

Em seguida, você pode configurar e iniciar suas campanhas do Google Ads. Siga as instruções do Google para saber mais sobre suas opções e como configurá-las.

Uma vez que uma atribuição é rastreada, suas campanhas do Google Ads aparecerão na sua interface de Relatórios da Singular.

A Singular oferece suporte a relatórios de dados atribuídos de campanhas de app do Google Ads para instalações e re-engajamentos de click-through e view-through. Atualmente, os dados disponíveis incluem o Google campaign ID , campaign name e ad group ID, além do canal do Google (YouTube, Display, Search). Esses dados são mapeados na Singular como "Campaign ID", "Campaign Name", "Sub Campaign ID" e "Sub Ad Network", respectivamente.

Observe que as "conversões" no Google Ads referem-se tanto às instalações quanto aos re-engajamentos na Singular.

Além disso, existem discrepâncias inerentes entre o Google Ads e todos os terceiros, conforme descrito na documentação do Google Ads .

A partir de janeiro de 2020, as App Campaigns for Installs para Search não são mais atribuídas pelo Google Ads e, portanto, não aparecem nos relatórios de nível de usuário. Para mais informações, veja o comunicado do Google.

Verifique se a sua implementação do SDK da Singular inclui o suporte a deep link e deferred deep link .

Uma vez implementado, sua integração da Singular com o Google habilita automaticamente o deferred deep linking para campanhas do Google que utilizam feeds .

As conversões de app reportadas pelo Google Ads podem conter uma mistura de fontes determinísticas e modeladas. Veja a Documentação do Google para entender como as conversões modeladas podem impactar suas campanhas.

Como as conversões modeladas não estão vinculadas a uma interação de anúncio específica, o Google não consegue fornecer uma resposta determinística correspondente para a Singular ou para qualquer um dos App Attribution Partners do Google. Isso pode causar discrepâncias nas conversões reportadas entre o Google e os 3Ps.

A atividade no app de usuários que fizeram opt-out é reportada ao Google com os advertising IDs zerados, de modo que o Google não recebe nenhuma informação individualmente identificável.

Quando o Google veicula um anúncio, ele também anexa "IDs" quando o auto-tagging está habilitado:

• Gbraid (iOS): Um identificador anexado aos cliques no iOS 14.5+
• Gclid (Android, iOS): Um Google click ID

Nos casos em que esses anúncios têm deep link habilitado, os IDs são capturados pela integração SDK/S2S da Singular quando o usuário é direcionado para o app via deep link. A Singular encaminha quaisquer IDs disponíveis ao Google, que são auto-atribuídos e reportados na Singular como re-engajamentos. No caso do "gbraid", essas atribuições de re-engajamento têm granularidade reduzida. As atribuições de re-engajamento baseadas em "Gbraid" têm:

• Campaign ID
• Campaign Name

Uma engaged view é uma impressão de um anúncio em vídeo que durou mais de 10 segundos pelo usuário. As engaged views são contabilizadas como atribuições de click-through nos relatórios do Google e da Singular.

Nos logs de nível de usuário da Singular, as conversões de engaged view são reportadas como "interaction_type" = "engagement" no campo "passthrough" para dados de conversão/evento atribuídos ao Google.

Nos relatórios agregados, as conversões de engaged view são reportadas como "conversion type" = "click-through".

O Integrated Conversion Measurement do Google oferece uma atribuição mais em tempo real, abrangente e precisa para suas campanhas de app do Google nas interfaces dos seus App Attribution Partners terceiros. Ele incorpora tecnologias inovadoras, como a medição de conversões on-device usando dados de eventos, para melhorar a precisão da medição, tudo sem comprometer a privacidade do usuário. O resultado é insight em nível de evento mesmo quando os identificadores em nível de usuário estão ausentes.

Ele abrange:

• Usuários do iOS 14.5+ que recusaram a App Tracking Transparency (ATT)
• Usuários do Android no Espaço Econômico Europeu (EEA), usuários que fizeram opt-out da configuração de personalização de anúncios no Android.
• O ICM é suportado para apps infantis (Kids).

O que ele não abrange

• O ICM não é suportado em dispositivos iOS localizados na região do EEA/Reino Unido.

O Integrated Conversion Measurement do Google Ads oferece suporte apenas à medição de instalações por click-through.

As atribuições do Integrated Conversion Measurement são reportadas na Singular como

• Click-through
• Instalações
• Atribuídas como probabilísticas (detalhamento disponível apenas nos relatórios de nível de usuário da Singular)
• O Sub Network Type não está disponível

O Integrated Conversion Measurement no iOS usa medição on-device com dados de eventos e exige a integração do ODM SDK do Google, bem como atualizações do SDK da Singular (ou da S2S API).

1. Integre a medição on-device do Google com dados de eventos (ODM SDK) usando qualquer uma destas três opções:

   Google Analytics for Firebase Swift Package Manager Cocoapods

   Veja o Guia do Google

   1. No Xcode, navegue até File > Add Packages .
   2. No prompt que aparece, insira o repositório do GitHub do GoogleAdsOnDeviceConversion : https://github.com/googleads/google-ads-on-device-conversion-ios-sdk
   3. Após concluir, o Xcode começará a resolver as dependências do seu pacote e a baixá-las em segundo plano.

   1. Ao seu Podfile, adicione o pod GoogleAdsOnDeviceConversion .

      pod 'GoogleAdsOnDeviceConversion'

   2. Execute

      pod install --repo-update

2. Atualize a Implementação do SDK da Singular ou da S2S API

   SDK do iOS SDK do Unity Flutter, React-Native, Cordova REST S2S API

   • Versão mínima do Native SDK 12.8.1
   • Certifique-se de adicionar “ -ObjC ” em “ Other Linker Flags ” no target do app

   • Permita que a Singular colete informações de ODM adicionando a opção de configuração enableOdmWithTimeoutInterval ao SingularConfig ao inicializar o SDK da Singular.
     
     enableOdmWithTimeoutInterval é definido com um valor de timeout em segundos. Recomenda-se usar um valor de timeout de 5 segundos. O valor de timeout define o tempo máximo que o SDK da Singular atrasará a inicialização para aguardar as informações de ODM do ODM SDK, no primeiro lançamento após a instalação.

     Importante: O processo de aguardar as informações de ODM do ODM SDK atrasa os callbacks do SDK da Singular, como o handler de callback de deep link da Singular. Portanto, os deep links podem ser atrasados

     
     Swift:

     config.enableOdmWithTimeoutInterval = 5

     Objective C:

     config.enableOdmWithTimeoutInterval = 5;

   • Versão mínima do SDK do Unity v5.5.0

   • Permita que a Singular colete informações de ODM adicionando a opção de configuração Enable ODM With Timeout Interval no seu SingularSDKObject .
     
     Enable ODM With Timeout Interval é definido com um valor de timeout em segundos. Recomenda-se usar um valor de timeout de 5 segundos. O valor de timeout define o tempo máximo que o SDK da Singular atrasará a inicialização para aguardar as informações de ODM do ODM SDK, no primeiro lançamento após a instalação.

     Importante: O processo de aguardar as informações de ODM do ODM SDK atrasa os callbacks do SDK da Singular, como o handler de callback de deep link da Singular. Portanto, os deep links podem ser atrasados

     
     

   • Versão mínima do SDK do Flutter v1.8.0
   • Versão mínima do SDK do React Native v3.9.0
   • Versão mínima do SDK do Cordova v1.8.0
   • Certifique-se de adicionar “ -ObjC ” em “ Other Linker Flags ” no target do app

   • Permita que a Singular colete informações de ODM adicionando a opção de configuração enableOdmWithTimeoutInterval ao SingularConfig ao inicializar o SDK da Singular.
     
     enableOdmWithTimeoutInterval é definido com um valor de timeout em segundos. Recomenda-se usar um valor de timeout de 5 segundos. O valor de timeout define o tempo máximo que o SDK da Singular atrasará a inicialização para aguardar as informações de ODM do ODM SDK, no primeiro lançamento após a instalação.

     Importante: O processo de aguardar as informações de ODM do ODM SDK atrasa os callbacks do SDK da Singular, como o handler de callback de deep link da Singular. Portanto, os deep links podem ser atrasados

     config.enableOdmWithTimeoutInterval = 5

   1. Busque as On Device Information logo após o primeiro lançamento do app
      
      Swift:

      import GoogleAdsOnDeviceConversion
      
      // Set the time when the app was first launched.
      ConversionManager.sharedInstance.setFirstLaunchTime(Date())
      
      // Fetch the conversion info.
      ConversionManager.sharedInstance.fetchAggregateConversionInfo(for: .installation)
      { aggregateConversionInfo, error in
         guard error == nil else { return }
         guard let info = aggregateConversionInfo else {
            // Troubleshoot:
            // 1. Check that the Date passed to setFirstLaunchTime() was when the app
            //    first launched.
            // 2. Check that your app is running in an approved region.
            return
         }
         guard info.count  0 else { return }
      
         print("Conversion info \(info)")
         // Use info as the value in the odm_info query parameter in
         // the App Conversion API detailed in Step 6.
         // For example, if info is "abcdEfadGdaf", then odm_info=abcdEfadGdaf.
      }

      
      Objective C:

      @import GoogleAdsOnDeviceConversion;
      
      // Set the time when the app was first launched.
      [[ODCConversionManager sharedInstance] setFirstLaunchTime:[NSDate date]];
      
      // Fetch the conversion info.
      [[ODCConversionManager sharedInstance]
         fetchAggregateConversionInfoForInteraction:ODCInteractionTypeInstallation
         completion:^(NSString * _Nullable aggregateConversionInfo,
                      NSError * _Nullable error) {
         if (error) {
            return;
         }
         if (aggregateConversionInfo.length == 0) {
            // Troubleshoot:
            // 1. Check that the NSDate passed to setFirstLaunchTime() was when the app
            //    first launched.
            // 2. Check that your app is running in an approved region.
            return;
         }
      
         NSLog(@"Conversion info %@", aggregateConversionInfo);
         // Use aggregateConversionInfo as the value in the odm_info query parameter in
         // the App Conversion API detailed in Step 6.
         // For example, if aggregateConversionInfo is "abcdEfadGdaf",
         // then odm_info=abcdEfadGdaf.
      }];

      Importante:

      • Esta etapa é uma operação assíncrona, portanto pode ser necessário evitar o envio de um evento de Session antes que ela seja concluída.
      • Colete o odm_info e compartilhe-o com o armazenamento do seu app para que você possa anexá-lo na primeira sessão. Esse valor será passado para a S2S API da Singular por meio do parâmetro “odm_info”
      • Se houver um erro, colete o erro. Esse valor será passado para a S2S API da Singular por meio do parâmetro “ odm_error ”
      • Observe que o timestamp da data passado com setFirstLaunchTime não deve diferir significativamente do timestamp de instalação passado para a S2S API da Singular por meio do parâmetro “ utime ”.
   2. Passe as On Device Information para a S2S API da Singular
      
      Para cada sessão de instalação do app (install=true), inclua as informações de ODM e o erro de ODM no endpoint Singular S2S /launch .

Quando e como coletar sinais de consentimento para usuários do EEA deve estar em conformidade com os requisitos de privacidade do usuário da sua empresa e dos seus apps. Consulte o departamento jurídico da sua empresa para entender como o seu app precisa aderir às políticas de privacidade internas e às regulamentações de privacidade, como o GDPR, a ePrivacy Directive e o Digital Markets Act.

Se você decidir coletar sinais de consentimento do usuário, geralmente é recomendado que:

• Os sinais de consentimento do usuário sejam definidos apenas quando o usuário tiver explicitamente feito opt-in ou opt-out. Recomenda-se deixar o LDS sem definição se o usuário não tiver feito uma escolha. A ausência de um sinal do usuário pode ser importante.
• Os sinais de consentimento do usuário são comumente coletados em "Privacy Choices" ou "Privacy Settings" durante a experiência no app.
• Quando possível, e dependendo do design e da estratégia do prompt de consentimento do seu app, apresente os prompts de privacidade no início dos fluxos do app para garantir que a Singular e outros SDKs possam coletar o sinal de consentimento do usuário o mais cedo possível
  

Se a sua empresa determinar que as regulamentações de privacidade da UE para usuários do EEA se aplicam ao seu app: Implemente o recurso "Limit Data Sharing" do SDK/S2S da Singular com base nos prompts de consentimento que seu app apresenta a esses usuários.

Se a sua empresa determinar que as regulamentações de privacidade da UE não se aplicam ao seu app , você pode fazer opt-out dos sinais de consentimento de usuários do EEA na Singular. Marque a opção "EEA opt-out" na seção "User Privacy" na configuração de parceiro. O LDS e os sinais de consentimento do usuário não são usados pelo Google com esta opção.

• A implementação do LDS para usuários do EEA não é obrigatória se você usar esta opção
• Esta opção pode ser habilitada antes que as atualizações de março do Google entrem em vigor

O Limit Data Sharing (LDS) da Singular é um recurso que permite aos desenvolvedores de apps passar os sinais de consentimento de cada usuário para a Singular. O LDS é definido por usuário e pode ser definido antes ou depois da inicialização do SDK. O LDS é usado nos Singular User Privacy Postbacks e passado para certos parceiros como o Google, que o utilizam para estar em conformidade com suas próprias práticas de dados.

Veja " FAQ sobre Suporte às Escolhas de Privacidade do Usuário com o Limit Data Sharing "

O Google lista as Consent Management Platforms (CMPs) que oferecem suporte aos sinais de consentimento do usuário exigidos. Se você usar uma dessas CMPs, pode extrair os sinais de consentimento do usuário e passá-los pelo recurso LimitDataSharing da Singular .

Para usuários do EEA que fazem opt-out do consentimento do usuário:

• A atribuição de nível de usuário às campanhas do Google Ads não estará disponível na Singular. O Google não conseguirá reportar essas atribuições aos MMPs
• O Google Ads modelará as conversões para esses usuários, o que é refletido nas métricas de rede agregadas que a Singular extrai do conector de dados do Google Ads.
• O Google Ads não conseguirá usar os dados desses usuários para fins de publicidade

Para usuários do EEA que fazem opt-in do consentimento do usuário:

• A atribuição de nível de usuário às campanhas do Google Ads é possível
• O Google Ads usará esses dados para fins de publicidade