Support calls for setClickUrl on an ad slot for click tracking [#2034269]

The Problem

A lot of people/companies are finding themselves migrating from the DART legacy platform onto DFP until some pretty tight deadlines (Google is mandating at least some of this). For people that relied on the Javascript rendering supported by the DART module (you had a choice of iframe or javascript) made it possible for Omniture sitecatalyst code to detect when a click on an ad occured so it shows up in your exit links editorial report. Since DFP only supports iframe rendering, the site catalyst code doesn't know when a DFP ad is clicked.

The solution/workaround

Since DFP ad slots support the ability to change (it's actually prepend to) the target URL for the ad you could setup your own landing page in order to fire an exit link event to omniture by dropping some omniture code and some logic for a redirect.

So here's what the solution looks like assuming you configure a setClickUrl DFP URL of http://foobar.com/dfpclick?u=:

Ad Click -> Browser goes to your custom landing page (e.g. http://foobar.com/dfpclick?u=http://advertiserdomain.com/landingpage/ad....) -> Browser loads previous landing page where Javascript runs your own custom code (omniture, ga, etc) and handles the redirect to the passed u= URL.

The approach I took was to add an additional global settings form item for the URL to set. It's much more complicated to make this a tag-level setting and the majority of implementations may want to apply this across the board anyway. The function that creates the slot definition tests the existence of a variable and sets up the setClickUrl() call if it is not empty.

Whaddya think? :)

Comment	File	Size	Author
#5	dfp-setclickurl-2034269-5.patch	2.91 KB	blazindrop
#5
#3	dfp-setclickurl-2034269-3.patch	2.06 KB	blazindrop
#3
#1	dfp-setclickurl-2034269-1.patch	1.76 KB	blazindrop
#1

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

blazindrop CreditAttribution: blazindrop commented 3 July 2013 at 19:16

Status:

Active

» Needs review

File	Size
dfp-setclickurl-2034269-1.patch	1.76 KB

Comment #2

blazindrop CreditAttribution: blazindrop commented 3 July 2013 at 19:29

I may actually tweak this patch a bit so you have an option to use an absolute or relative URL path so we don't have to hard code domains. But initial patch is up for chats :)

Comment #3

blazindrop CreditAttribution: blazindrop commented 3 July 2013 at 20:20

File	Size
dfp-setclickurl-2034269-3.patch	2.06 KB

Attaching new patch with support to detect whether an absolute URL was entered in the text field or a relative. If it's relative then automatically prepend the current domain. Saves lots of typing/scripting.

Comment #4

bleen CreditAttribution: bleen commented 8 July 2013 at 02:51

+++ b/dfp.admin.incundefined
@@ -46,6 +46,17 @@ function dfp_admin_settings($form, $form_state) {
+    '#states' => array(
+      'enabled' => array(
+        'input[name="dfp_async_rendering"]' => array('checked' => FALSE),
+      ),
+    ),

I'm not 100% sure but I think you would still need a validation function here ... imagine I add a click URL and then I click async == true... the click URL will then be saved

+++ b/dfp.moduleundefined
@@ -716,8 +716,18 @@ function _dfp_js_global_settings() {
+  global $is_https;

Since we are already using $GLOBALS['is_https'] elsewhere in the code, can we use the same convention

Comment #5

blazindrop CreditAttribution: blazindrop commented 15 July 2013 at 14:52

File	Size
dfp-setclickurl-2034269-5.patch	2.91 KB

Good points. Added validate function call to make sure async rendering is not enabled with a click URL set. Also changed method for using global. Also fixed a bug with missing delimiters on a regex to check for an absolute URL.

Just started to run this code in production with good results so far.