Track mobile app conversions with Floodlight

Floodlight gives you insight into the actions that users take after they view or click on ads. There's no special setup for Floodlight on the mobile web. You can traffic your ads and set up your Floodlight activities and tags for any web page, whether users will be seeing that page on a desktop or a mobile device.

Some setup is needed if you want to use Floodlight for app installs or in-app activities. This article explains what you need to do to make Floodlight work in an app.

Due to differences in cookies and device ID settings, there may be times when conversions can't be measured directly. In some cases, Campaign Manager 360 uses machine learning and historical data to model conversions.

This article discusses implementation details for iframe and image Floodlight tags only. The Google tag is not intended to work in mobile apps.

Expand all sections Collapse all sections

About Floodlight in apps

Overview

With in-app Floodlight activities, you can learn more about what actions users take within mobile apps after they interact with your ads, similary to how you can do so on a website. You can track installs of your app or activities that take place in the app, such as purchases or logins, which make it easier for you to determine the effectiveness of mobile app campaigns. View-through and click-through conversion data is available in Reporting, enabling you to view desktop and mobile campaign performance in one place.

In-app activities can be attributed to display and video ads that run in other apps. These attributed conversions appear in the standard Conversion metrics available throughout Campaign Manager 360. For conversions attributed to ads that ran on web sites or on other devices, these metrics are reported on within the cross-device conversions report.

To implement Floodlight inside apps, first you’ll need to create and configure your Floodlight activities in Campaign Manager 360. Once your tags are ready, we provide two different options for tracking in-app installs or activities with them.

Who's involved

There are two partners that make in-app Floodlight work:

The agency or advertiser that uses Campaign Manager 360 to serve ads in apps and wants to use Floodlight to track installs or other app activities for their promoted app back to their ads.
A media partner or publisher that has available inventory in apps.

Values passed to tags

Before you can attribute app installs or activities back to ad impressions and clicks in apps, the partners need to work together to ensure that user-resettable device identifiers and other values are passed to both Floodlight tags and the ad tags running in apps. Campaign Manager 360 uses the identifiers to uniquely identify a user and attribute app activities back to the in-app ads they viewed or clicked on.

dc_rdid=: User resettable device identifiers in the form of IDFA for iOS or advertising ID (AdID) for Android. This parameter is required. The publisher must pass a value into this parameter in order to enable in-app conversion tracking. The values should be the unhashed, raw value. We will only accept values passed securely over SSL-enabled tags.

Note: We strongly recommend using the dc_rdid parameter for device IDs instead of the legacy parameter dc_muid, which accepts uppercase MD5-hashed IDFA, Android ID, and AdID values.
- SSAID is available for non-Play Android devices in China.
tag_for_child_directed_treatment=: Accepts a value of 0 or 1. A value of 1 indicates that this particular request may come from a user under the age of 13, under COPPA compliance.
dc_lat=: Accepts a value of 0 or 1. A value of 1 means that the user has enabled the “Limit Ad Tracking” option for IDFA or AdID in order to opt out of interest-based ads and remarketing. If "Limit Ad Tracking" is off, the value is 0.

Make sure that the HTTP header user agent is the same as that of the app where the conversion activity took place. This is especially important when making server-to-server calls to Floodlight.

Set up Floodlight in apps

Ensure ad tags pass proper values from publishers

Tracking in-app conversions requires that specific values are passed into ad tags by the app publisher when the ads are served.

Advertisers or agencies should send example ad tags to the app publisher and get confirmation that the publisher can pass parameters into the ad tags, particularly into the required dc_rdid parameter. Usually, the app publisher will support site-macros to provide these values.

Below are samples of what ad tags might look like once the publisher passes the values needed for in-app ads:

The beginning of a sample ins tag (the preferred option for mobile environments):

<ins class='dcmads' style='display:inline-block;width:320px;height:50px' data-dcm-placement='N9200.284657.MYSITE/B7841342.2' data-dcm-rendering-mode='script' data-dcm-https-only data-dcm-gdpr-applies='gdpr=${GDPR}' data-dcm-gdpr-consent='gdpr_consent=${GDPR_CONSENT_755}' data-dcm-addtl-consent='addtl_consent=${ADDTL_CONSENT}' data-dcm-ltd='false' data-dcm-resettable-device-id='' data-dcm-app-id=''> <script src='https://googletagservices.com/dcm/dcmads.js'></script> </ins>

A sample standard tag (used for image banners):

<IMG SRC="https://ad.doubleclick.net/ddm/trackimp/N1315459.3748068PROGRAMMATICSERV/B29422130.359600204;dc_trk_aid=550722822;dc_trk_cid=186748336;ord=[timestamp];dc_lat=;dc_rdid=;tag_for_child_directed_treatment=;tfua=;gdpr=${GDPR};gdpr_consent=${GDPR_CONSENT_755};ltd=;dc_tdv=1?" attributionsrc BORDER="0" HEIGHT="1" WIDTH="1" ALT="Advertisement">

The beginning of a sample JavaScript tag (typically used for HTML5 or rich media banners):

<SCRIPT language='JavaScript1.1' SRC="https://ad.doubleclick.net/ddm/adj/N300050839.134362FOXHULU/B90176049.2000357744;abr=!ie;sz=1x1;ord=[timestamp];dc_lat=;dc_rdid=;tag_for_child_directed_treatment=;tfua=;dc_sdk_apis=[APIFRAMEWORKS];dc_omid_p=[OMIDPARTNER];gdpr=${GDPR};gdpr_consent=${GDPR_CONSENT_755};dc_tdv=1?"> </SCRIPT>

A sample pre-fetch tag (used for in-stream video and audio ads):

VAST 2.0 pre-fetch tag

https://ad.doubleclick.net/ddm/pfadx/N300050839.134362FOXHULU/B90176049.2000396259;sz=0x0;ord=[timestamp];dc_lat=;dc_rdid=;tag_for_child_directed_treatment=;tfua=;dc_tdv=1;dcmt=text/xml;dc_sdk_apis=[APIFRAMEWORKS];dc_omid_p=[OMIDPARTNER];gdpr=${GDPR};gdpr_consent=${GDPR_CONSENT_755};dc_mpos=[BREAKPOSITION];ltd=

VAST 3.0 pre-fetch tag

https://ad.doubleclick.net/ddm/pfadx/N300050839.134362FOXHULU/B90176049.2000396259;sz=0x0;ord=[timestamp];dc_lat=;dc_rdid=;tag_for_child_directed_treatment=;tfua=;dc_tdv=1;dcmt=text/xml;dc_sdk_apis=[APIFRAMEWORKS];dc_omid_p=[OMIDPARTNER];dc_vast=3;gdpr=${GDPR};gdpr_consent=${GDPR_CONSENT_755};dc_mpos=[BREAKPOSITION];ltd=

VAST 4.0 pre-fetch tag

https://ad.doubleclick.net/ddm/pfadx/N300050839.134362FOXHULU/B90176049.2000396259;sz=0x0;ord=[timestamp];dc_lat=;dc_rdid=;tag_for_child_directed_treatment=;tfua=;dc_tdv=1;dcmt=text/xml;dc_sdk_apis=[APIFRAMEWORKS];dc_omid_p=[OMIDPARTNER];dc_vast=4;gdpr=${GDPR};gdpr_consent=${GDPR_CONSENT_755};dc_mpos=[BREAKPOSITION];ltd=

A sample tracking ad image tag for impressions:

A sample tracking ad tag for clicks:

https://ad.doubleclick.net/ddm/trackclk/N1315459.3748068PROGRAMMATICSERV/B29422130.359600204;dc_trk_aid=550722822;dc_trk_cid=186748336;dc_lat=;dc_rdid=;tag_for_child_directed_treatment=;tfua=;ltd=;dc_tdv=1

The dc_rdid=, tag_for_child_directed_treatment= and dc_lat= parameters are included in tags for all placements. The publisher passes the value into all of the keys at serve time.

Fire Floodlight tags when tracking app activities

Campaign Manager 360 provides two different methods for agencies and advertisers to use Floodlight tags for apps. The advertiser or agency should work with the developer of the promoted app to confirm that either of these methods are supported.

Use a GET request to make Floodlight calls directly

You can use a GET request to make Floodlight calls directly from your app or server code whenever there’s an install or other app event. This method may be preferable if your app developer has custom code or doesn’t use Google Tag Manager. The advertiser's app can make a GET request to Floodlight using the corresponding activity values (src, cat, type). Be sure that the necessary values are passed to parameters, particularly the required dc_rdid= value.

Example:

https://ad.doubleclick.net/ddm/activity/src=1234567;cat=fghij456;type=abcde123;dc_rdid=38400000-8cf0-11bd-b23e-10b96e4ddddd;tag_for_child_directed_treatment=0;dc_lat=0;u1=[friendlyname1];ord=1312312312

Fire Floodlight tags with Google Tag Manager

You can use a Google Tag Manager container to dynamically fire your tags in-app when there's a conversion activity.

If you have multiple mobile Floodlight tags, you can easily manage how they’re dynamically loaded and fired in-app using Google Tag Manager. First you’ll need to establish a link between the Floodlight configuration and a Google Tag Manager container, then push your activities to the container. The steps are similar to those for linking a regular Floodlight configuration and a Google Tag Manager container, but with a few additional changes required, mostly on the Google Tag Manager side.

If you’ve already created a Google Tag Manager container to fire your regular Floodlight tags, note that you’ll need to create and maintain a separate mobile container specifically for mobile Floodlight tags.

To link your Floodlight configuration to a Google Tag Manager container:

Follow the steps for creating Floodlight activities in Campaign Manager 360.
Follow the instructions for creating a container for mobile apps in Google Tag Manager (additional details are provided in Setup and Workflow: Mobile Apps). Make sure you keep the container ID on hand.
In Campaign Manager 360, select your advertiser and click Floodlight > Configuration.
Expand the Google Tag Manager section and click Link to a Google Tag Manager container. Enter the ID of your mobile container in the new row that appears.
Click Save.
A link request will be sent to the Google Tag Manager administrator. When the administrator approves the association, the container type will appear as “Mobile apps” and its status will be “Linked”.

Once your Floodlight configuration is linked to a Google Tag Manager container, you can start pushing tags to the container so that they can be fired when an in-app conversion event occurs. You can configure the tags to fire on one-time events (such as when a user installs the app) or events that may be repeated (such as completing a purchase).

You'll need to set up a mobile tag container using the Google Tag Manager for Mobile SDK and add it to your iOS or Android app before publishing it. Note that additional libraries are needed to pass iDFA. You can then generate tags for your placements and traffic them on mobile app networks or app publishers as usual. The SDK makes a GET request to Floodlight when it receives a conversion event that matches the values you set for your Floodlight activities.

Select the activity in Campaign Manager 360 and expand the Google Tag Manager section. You should see any containers you’ve already linked to for this Floodlight configuration.
Select the specified mobile container and (optionally) enter instructions for the administrator who will be implementing the tag in Google Tag Manager. You can include specific conditions for firing the tag.
Click Push to Google Tag Manager.
Save your changes.

After you save, the updated tags will be sent to the Google Tag Manager administrator. When the administrator approves the updated tags, the tag status will change to “Approved.”
The Google Tag Manager administrator will review the tag settings and set up rules for when they fire.
- Unrepeatable: Check this box if the Floodlight tag should fire only once over the lifetime of the app (for example, when a user downloads or installs an app).
- Firing rules: The activity must be tied to a firing rule in Google Tag Manager so that the tag fires.
Validate your changes by testing the implementation.

If you later decide to make changes to a mobile activity and re-push it, you’ll actually be creating a new instance of the tag rather than replacing the existing tag. Make sure to disable the original tag before enabling the new one.

Was this helpful?

How can we improve it?