Singular tracks Google Ads campaigns via a self-attributing server-to-server integration with Google Ads' App Conversion API, which includes:

• Tracking all installs and re-engagements driven by any of your Google Ads campaigns
• Both click-through and view-through attribution

The integration uses a Link ID, which is generated in Google Ads and unique to each app. Once your Link ID has been configured in Singular, Singular will start sending all installs, sessions, and configured in-app conversion events to Google.

Using the attributed click information returned from Google, Singular can perform last-touch attribution (See Singular's attribution process) and offer you reports on your campaigns' performance using the same granular campaign information you receive in your Google Ads dashboard.

To begin tracking conversions and events related to Google Ads campaigns, you first need to go to your Google Ads account to set up your conversion actions - also known as importing events.

See Google Ads Attribution Integration: How to Import Events for detailed instructions.

Next, you can configure and start your Google Ads campaigns. Follow Google's instructions to learn more about your options and how to configure them.

Once an attribution is tracked, your Google Ads campaigns will appear in your Singular Reporting interface.

Singular supports reporting attributed Google Ads app campaign data for click-through and view-through installs and re-engagements. Currently, the available data includes the Google campaign ID, campaign name, and ad group ID, along with the Google channel (Youtube, Display, Search). This data is mapped to Singular as "Campaign ID", "Campaign Name", "Sub Campaign ID", and "Sub Ad Network", respectively.

Note that "conversions" in Google Ads refer to both installs and re-engagements in Singular.

In addition, there are inherent discrepancies between Google Ads and all third parties, as outlined in the Google Ads documentation.

Starting January 2020, App Campaigns for Installs for Search are no longer attributed by Google Ads, and therefore aren't shown in user-level reporting. For more information, see Google's announcement. 

Verify your Singular SDK implementation includes deep link and deferred deep link support. 

Once implemented, your Singular integration with Google automatically enables deferred deep linking for Google campaigns utilizing feeds.

Google Ads reported app conversions may contain a mix of both deterministic and modeled sources. See Google's Documentation to understand how modeled conversions may impact your campaigns.

Because modeled conversions don't tie back to a single specific ad interaction, Google cannot provide a corresponding deterministic response to Singular or any of Google's App Attribution Partners. This may cause reported conversion discrepancies across Google and 3Ps.

Opt-out user's app activity is reported to Google with the advertising IDs zeroed out, so Google does not receive any individually identifiable information. 

When Google serves an ad, they also append "IDs" when auto-tagging is enabled:

• Gbraid (iOS): An identifier appended to iOS 14.5+ clicks
• Gclid (Android, iOS): A Google click ID

In cases where these ads are deep link enabled, the IDs are captured by the Singular SDK/S2S integration when the user is deep linked into the app. Singular forwards any available IDs to Google which are self-attributed reportied in Singular as re-engagements. In the case of "gbraid", these re-engagement attribution's have reduced granularity. "Gbraid" based re-engagement attributions have:

• Campaign ID
• Campaign Name

An engaged view is a user impression of a video ad that lasted more than 10 seconds. Engaged views are counted as click-through attributions in Google and Singular reporting.

In Singular's user-level logs, engaged view conversions are reported under "interaction_type" = "engagement" in the "passthrough" field for conversion/event data attributed to Google.

In aggregate reporting, engaged view conversions are reported under "conversion type" = "click-through".

Google's Integrated Conversion Measurement provides more real-time, comprehensive, and accurate attribution for your Google App campaigns in your third-party App Attribution Partner interfaces. It incorporates innovative technologies, such as on-device conversion measurement using event data, to improve measurement accuracy, all without compromising user privacy. The result is event‑level insight even when user‑level identifiers are missing.

It covers:

• iOS 14.5+ users who declined App Tracking Transparency (ATT)
• Android users in the European Economic Area (EEA), users who have opted out of ads personalization setting on Android.

Google Ads' Integrated Conversion Measurement supports click-through install measurement only.

Integrated Conversion Measurement attributions are reported in Singular as

• Click-through
• Installs
• Attributed as probabilistic (breakdown only available Singular user-level reports)

iOS Integrated Conversion Measurement uses on-device Measurement using event data and it requires integrating Google's ODM SDK as well as Singular SDK (or S2S API) updates.

1. Integrate Google's on device measurement using event data (ODM SDK) using any of these three options:

   Google Analytics for FirebaseSwift Package ManagerCocoapods

   See Google's Guide

   1. In Xcode, navigate to File > Add Packages.
   2. In the prompt that appears, enter the GoogleAdsOnDeviceConversion GitHub repository: https://github.com/googleads/google-ads-on-device-conversion-ios-sdk
   3. After you're finished, Xcode will begin resolving your package dependencies and downloading them in the background.

   1. To your Podfile, add the GoogleAdsOnDeviceConversion pod.

      pod 'GoogleAdsOnDeviceConversion'

   2. Run

      pod install --repo-update

2. Update Singular SDK or S2S API Implementation

   Singular SDK (Native)Singular SDK (Unity)Singular SDK (Flutter, React-Native, Cordova)Singular S2S API

   • Native SDK minimum version 12.8.1
   • Ensure to add “-ObjC” to “Other Linker Flags” to the app target

   • Enable Singular to collect ODM information by adding the enableOdmWithTimeoutInterval configuration option to SingularConfig when initializing the Singular SDK.
     
     enableOdmWithTimeoutInterval is set with a timeout value in seconds. It is recommended to use a timeout value of 5 seconds. The timeout value sets the maximum amount of time the Singular SDK will delay initializing to wait for ODM information from the ODM SDK, the first launch after install.

     Important:The process of waiting for ODM information from the ODM SDK delays Singular SDK callbacks, such as the Singular deep link callback handler. Therefore, deep links may be delayed

     
     Swift:

     config.enableOdmWithTimeoutInterval = 5

     Objective C:

     config.enableOdmWithTimeoutInterval = 5;

   • Unity SDK minimum version v5.5.0

   • Enable Singular to collect ODM information by adding the Enable ODM With Timeout Interval configuration option in your SingularSDKObject.
     
     Enable ODM With Timeout Interval is set with a timeout value in seconds. It is recommended to use a timeout value of 5 seconds. The timeout value sets the maximum amount of time the Singular SDK will delay initializing to wait for ODM information from the ODM SDK, the first launch after install.

     Important:The process of waiting for ODM information from the ODM SDK delays Singular SDK callbacks, such as the Singular deep link callback handler. Therefore, deep links may be delayed

     
     

   • Flutter SDK minimum version v1.8.0
   • React-Native SDK minimum version v3.9.0
   • Cordova SDK minimum version v1.8.0
   • Ensure to add “-ObjC” to “Other Linker Flags” to the app target

   • Enable Singular to collect ODM information by adding the enableOdmWithTimeoutInterval configuration option to SingularConfig when initializing the Singular SDK.
     
     enableOdmWithTimeoutInterval is set with a timeout value in seconds. It is recommended to use a timeout value of 5 seconds. The timeout value sets the maximum amount of time the Singular SDK will delay initializing to wait for ODM information from the ODM SDK, the first launch after install.

     Important:The process of waiting for ODM information from the ODM SDK delays Singular SDK callbacks, such as the Singular deep link callback handler. Therefore, deep links may be delayed

     config.enableOdmWithTimeoutInterval = 5

   1. Fetch On Device Information shortly after the app first launches
      
      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.
      }];

      Important:

      • This step is an asynchronous operation, so it might require you to refrain from sending a Session event before it completes.
      • Collect the odm_info and share it with your app storage so you may append it on the first session. This value will be passed to Singular’s S2S API via the “odm_info” parameter
      • If there is an error, collect the error. This value will be passed to Singular’s S2S API via the “odm_error” parameter
      • Note that the date timestamp passed with setFirstLaunchTime should not differ significantly from the install timestamp passed to Singular’s S2S API via the “utime” parameter.
   2. Pass On Device Information to Singular's S2S API
      
      For every app install session (install=true), include ODM info and ODM error to the Singular S2S /launch endpoint.

When and how to collect user consent signals for EEA users should adhere to your business' and apps requirements for user privacy. Consult your business' legal counsel to understand how your app needs to adhere to internal privacy policies and privacy regulations such as GDPR, ePrivacy Directive, and the Digital Markets Act.

If you decide to collect user consent signals, it is generally recommended that:

• User consent signals be set only when the user has explicitly opted-in or out. It is recommended to leave LDS unset if a user did not make a choice. The absence of a user signal may be important.
• User consent signals are commonly collected in "Privacy Choices" or "Privacy Settings" during the app experience.
• When possible, and depending on your app's consent prompt design and strategy, surface privacy prompts early in the app flows to ensure Singular and other SDKs can collect the user consent signal as early as possible
   

If your business determines that EU privacy regulations for EEA users apply to your app: Implement the Singular SDK/S2S "Limit Data Sharing" feature based on the consent prompts your app presents to these users.

 

If your business determines that EU privacy regulations don't apply to your app, you can opt-out of EEA user consent signals in Singular. check the "EEA opt-out" option under the "User Privacy" section in the partner configuration. LDS and user consent signals are not used by Google with this option.


 

• Implementing LDS for EEA users is not required if using this option
• This option can be enabled prior to Google's March updates going live

Singular's Limit Data Sharing (LDS) is a feature that allows app developers to pass each user's user consent signals to Singular. LDS is set per user and can be set before or after SDK initialization. LDS is used in Singular User Privacy Postbacks and passed to certain partners like Google, who use it to comply with their own data practices.

See "Supporting User Privacy Choices with Limit Data Sharing FAQ"

Google lists Consent Management Platforms (CMPs) that support the required user consent signals. If you use one of these CMPs, you can extract the user consent signals and pass them through Singular's LimitDataSharing feature. 

For EEA users that opt-out to user consent:

• User-level attribution to Google Ads campaigns will not be available in Singular.  Google won't be able to report these attributions to MMPs
• Google Ads will model conversions for these users, which is reflected in the aggregated network metrics Singular pulls from the Google Ads data connector.
• Google Ads won't be able to use this users data for advertising purposes

For EEA users that opt-in to user consent:

• User-level attribution to Google Ads campaigns are possible
• Google Ads will use this data for advertising purposes