Spam Clicks

DCM Engineers are investing heavily in advanced spam filtering in DCM. Spam is an issue that Google has taken very seriously since the earliest days of its business and has invested significant time and resources to combat. We'll be applying our learnings from other areas of the business to this new platform to provide the most accurate ad serving experience possible. Aside from our general our spam technology, Google recently purchased Spider.IO, an anti malware company and we are working closely with them as well other internal Google teams that specialize in spam protection to integrate their technology across our product stack, including DCM.  

Customers migrating from DFA6 to DCM have reported an increase in spam clicks. Conversions and impressions are not affected, as 96% of spam clicks were identified to come from non-cookied users. Our Engineers have identified the cause and are actively working on a fix. The fix will bring parity with DFA6 in mid-May. 

It is also possible that the issue is related to implementation. If you see a spike in the number of clicks for a particular Campaign or Ad, we recommend that you utilize reporting to identify the site that is driving any additional clicks. So, I'd also request you check with the Site "MNI", if they are driving a high number of clicks. If possible, request them to send the report broken down by day with Geo.  Also, if you provide the live URL (instead of test page), it would help me check the implementation and update you with additional information.

Raw impression

Impressions yesterday on the UI gives the number of times yesterday (midnight to midnight, Eastern Time) that users accessed a web page that included this activity's Floodlight tag but it is just a raw data and not the actual data which may not update correctly. Even the warning signs that you see on the UI takes a few days to update even if the floodlight is fixed on the site and it collects data. You should always go with the figures in the report rather than the one on the UI.

Frequency Cap setting

If you would like to apply frequency cap to the ad so that a user would get to see the OTP only once within an hour. If yes, you can achieve this by applying frequency capping to an ad.

Below are the steps to set up frequency cap for an ad:

1. Go to the Delivery Properties section of the Ad Properties page for a new or an existing ad.

2. Enter a Frequency, which is the maximum number of times that the ad can be shown to each user during the time period you'll specify. The frequency can be any number from 1 to 15.

3. Enter a Time Period, which is the number of minutes, hours, days, or weeks before the frequency cap is reset for each user. The maximum is 129,600 minutes (2,160 hours, 90 days, or 12 weeks).

4. Choose the correct unit of time from the drop-down list: Minutes, Hours, Days, or Weeks.

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.