Floodlight tag and Google AdWords

Floodlight tags accept Google AdWords Conversion Tracking as part of their dynamic tags. There are just few things to bear in mind when implementing this:

1) Each AdWords Account will be linked to one DoubleClick Floodlight Tag.

2) You can choose to integrate the Full Javascript Tag or the 1x1 Pixel as either a "Publisher" tag or a "Default" tag. The Google code will only send a conversion signal if the user clicked on a Google ad within the account.

3) If you need to use more than one Google AdWords Account, please make note of the following exceptions:
- You/Your client will need to generate the AdWords Conversion Tracking code for each account that your advertiser wants to track conversion activity.
- You will need to use "Publisher" tags for each account and will be required to associate the "Publisher's Site" in the Floodlight interface with the "site" that is used in the DFA creative tag. These must be two separate publishers as the pixels cannot fire at the same time.


When deciding where to place your Google AdWords Conversion Tracking, you should consider the differences between the two types of dynamic tags:

- Default Section
The pixel will fire every single time someone hits the conversion page. The AdWords Conversion Tracking code will only record a conversion if it can detect that the user has a cookie that ties to the advertiser's AdWords campaign.

I.e.: If a user clicks on a Google ad, then goes to NY Times and clicks on the advertiser's ad as part of a direct buy with the NY Times, DoubleClick will credit the NY Times with the conversion but Google will count the conversion, too, because the user has a Google cookie tied to the campaign that came from the first click.

- Publisher Section
This method requires that the advertiser is using DCM click tracking or 3PAS tags. When they create the click trackers or 3PAS tags, they will assign the site of those tags to the 'Google Display Network'. In their publisher section, they will then implement our conversion pixel under the same site name of 'Google Display Network'. This lets the Floodlight code do the heavy lifting and it will detect that the user who just converted came from a click that was associated with one of the click or 3PAS tags that they have assigned to the 'Google Display Network' and will then fire the conversion code associated with that site. This might lead to more accurate conversion numbers as Google will only be asked to count a conversion when DoubleClick tells it to count a conversion (eliminating the discrepancy example above) but if there is a longer Look-back window than 30 days, they are not using DCM click/3pas tracking or if they do not have their tagging set up properly the values will be completely off.

%P macros

Syntax errors on the %p macros used inside the 3rd party pixel are preventing the pixels from working as intended.

General %p syntax: %p[start_key_string]![end_character]

The [end_character] should be defined. The end character tells the macro "stop passing values when you hit this character".

Your Floodlight tag looks like follows:

{Insert Floodlight tag that is suffering the issue, with values included if possible}

In the 3rd party pixel, our %p macros are expecting an ending character that will tell them when stop reading, however, this is not implemented at the moment. As a result, when our macro starts reading the value that is coming after the parameter {name of the parameter}, for example, it just keeps reading till the end of the line.

This erros is preventing the pixels from tracking properly. To fix this, add an end character for each %p macros. The [end_character] is typically a semicolon (;) or a question mark (?) to end the string. For example:

- Quantity: %pqty=!;

- Revenue: %pcost=!;

- Order ID: %pord=!?

For more information on DCM macros, please go through the following links.
https://support.google.com/dcm/table/6096962?hl=en&visit_id=1-636177386777577723-156265568&rd=2


https://support.google.com/dcm/answer/2837696?hl=en

In-APP Floodlight Events

1) An ad call from within an app is made to the Doubleclick server
The app network is responsible for passing the hashed device identifier in the ad calls for impressions and clicks*
Note: if you are buying on DBM, the parameter is already passed in the bid request for most mobile app inventory

2) Doubleclick maps the hashed device identifiers to another value to protect user privacy

3) The conversion activity in an app (through the use of Google Tag Manager for Mobile SDK or a supported 3rd party SDK) includes the passing of the hashed device identifier

4) Doubleclick will match up values when a conversion occurs, and the conversion will show up in Reporting


In-APP Tracking set up:

Google Tag Manager

Setup GTM Mobile Container. Integrate into app, resubmitting to app/play store.

Floodlight Configuration:

Create/edit Floodlight config to link to GTM container.

Floodlight Activities:

Setup each Floodlight Activity, save, then push to linked GTM container.

InApp tracking: setup

http://ad.doubleclick.net/ddm/activity/src=[AdvertiserID];type=[GroupString];cat=[ActivityString];dc_muid=[MD5-hashed value of IDFA, Android ID, or AdID];dc_lat=[0|1];u1=[FriendlyName1];u2=[FriendlyName1];ord=[Timestamp]?

Integrate Floodlight tag into app, resubmitting to app/play store.

ALL Mobile Floodlight parameters must be parsed in the GET call.

dc_muid is the MD5-hashed value of IDFA, Android ID, or AdID. dc_lat=[0|1] (if available) is a flag (with a value of 1) indicating if the user has enabled the "Limit Ad Tracking” option for IDFA or AdID.

src is the advertiser ID that is the source of the Floodlight activity. cat is the activity tag string, which Floodlight servers use to identify the activity group to which the activity belongs. type is the group tag string, which identifies the activity group with which the Floodlight activity is associated.
ord is a random number that is used to make the Floodlight tag unique and prevent browser caching.
u1, u2, ... (if available) are the custom Floodlight variable key-values.

DCM Mobile targeting

What:

There are new mobile targeting criteria: Platform Type (PC, tablet, smartphone, feature phone - MDL), Operating System (Apple, Android, Palm, etc), Operating System Version.
These three already existed: Connection Type (Wifi, Mobile), Mobile Carrier (T-Mobile, AT&T, etc), Browser (Mobile Browsers, Safari ipad, Android Browsers, etc)

Why:

These new mobile metrics: Platform Type, OS's, and Operating System Version allow you to be more targeted with your mobile advertising.

- Platform Targeting: Serve richer ads to tablets versus phones because tablets have larger screen real estate. Serve call prompting ads to phones.
Connection Speed Targeting: Make sure to serve your high-end video ads to users with a fast connection speed (because users with slow connection speed won't be able to download videos).
- OS: Let's say you have a new app on the iTunes store and on the Google Play store. By targeting your ads to correct OS, you'll ensure that Apple users click through to the iTunes store and Android users click through to the Google Play store.
 - OS Version: Let's say you are running a complex rich media ad that uses heavy HTML5. Some lower versions of iOS may not support HTML5, so you'd want to target the iOS that does support HTML5.

Where:

Similar to all other targeting parameters in DFA6, Mobile Targeting parameters (connection, carrier, platform, operating system, browser) are managed in the Ad Properties tab. In contrast to all other targeting parameters in DFA6, Mobile Targeting parameters are housed under a section in the Ad Properties tab labelled "'Technology".

How:

Use these mobile targeting criteria in the same way that you would other targeting criteria.
Go to the Ad Properties tab.
Scroll down to Technology.
Select the mobile metrics that you'd like to target.

Certification Type for Rich Media and HTML5

Rich Media InApp (MRAID) Certification: certifies that mobile applications are MRAID-compliant and our Rich Media InApp Creatives render properly. Certification needs to be completed before any InApp Campaign goes live with a publisher/network.

HTML5 InApp and Desktop/Mobile Verification: verifies our Standard HTML5 Creatives render and function correctly on mobile applications and web. It is a nice-to-have, but it does not have to be completed before a campaign goes live since the product is normalized. Have publisher to test iFrame/JavaScript tags that serve HTML5 creatives.

What is DCM 'Skippable Ad Tracking'?

This DCM feature in In-Stream Video creatives does not enable a publisher to have a skip button.Rather, it allows a publisher that already has a skip button to fire off two new tracking metrics in our DCM Reporting called 'Video Skip' and 'Video True View'.

To get a bit technical, you get two new sections in the VAST tag’s ad response if 'Include Skip Button' is checked in an In-Stream Video creative in DCM: 'skip' and 'engagedView', MET IDs 29 and 30, under the section . This can be added retroactively to existing VAST tags by checking off 'Include Skip Button' in your In-Stream Video creative in DCM.

Video True View: Number of times the user has watched 30 seconds of the ad or to its
completion, whichever is shorter.

Video Skip: Number of times the user has clicked to skip the ad. This metric does not include
instances where the user abandons the page without clicking skip or viewing the ad.

In addition, VAST tracking can support multiple 1x1 urls (such as Nielsen and Comscore) as well as
support most existing DFA Reporting including Geo reporting and Reach/Frequency reporting.

What is TrueView?

YouTube’s TrueView In-Stream format lets you show pre- or mid-roll video ads against all lengths of
content. After the ad plays for five seconds, the viewer gets the choice to skip or watch the ad. You only pay when the viewer has either watched 30 seconds of an ad, or watched the ad to complete
(whichever comes first).
In DoubleClick Campaign Manager (DCM), we provide the 'Include Skip Button’ checkbox on the creative level that allows TrueView metrics like ‘Video Skip’ and ‘Video True View’ to track in DFA Reporting.