Analytics Results has an article at http://www.analyticsresults.com/2010/02/tracking-paypal-with-google-anal... from which I infer that our Commerce PayPal link for checkout completion auto return should be appended by "utm_nooverride=1" as a GET parameter, n'est-ce pas?

My setup has Commerce 1.4, or so drush tells me.

CommentFileSizeAuthor
#10 commerce_paypal-utmnooverride-1969732-10.patch936 bytesdiwant

Comments

diwant’s picture

diwant commented

Here's what I'm doing right now, for reference. I'll let you know here if my conversion tracking works from this change.

function mymodule_commerce_paypal_wps_order_form_data_alter(&$data, $order) {
  ...
  $data['return'] .= "?utm_nooverride=1";
  ...
}
diwant’s picture

diwant commented

Yep, goal conversion works for me now!

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented
Status: Active » Reviewed & tested by the community

Should be RTBC. Hopefully Ryan can take a look :)

diwant’s picture

diwant commented
Status: Reviewed & tested by the community » Needs work

Hi Erik.

What I have above isn't a patch, it's my approach with custom code in the hook_form_data_alter function. Mayhaps it's my understanding, but I'm not sure it can be marked RTBC until there's a patch.

Patch is pending the right answers to these questions:

1. Is this something everyone using commerce needs?
2. How do we add this parameter, in harmony with the rest of the Commerce approach?

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

Ah, good points. Guess I jumped the gun and didn't realize how you'd solved it. My thoughts:

1. Doubtful, because this is specific to users running Google Analytics.
2. I'd say the parameter should be based on a setting in the Commerce backend, but only if, say, the Commerce Google Analytics modules is enabled. In that case we'd conditionally allow users to set that to TRUE and then include that snippet in the actual WPS form (rather than in an alter hook).

To be honest, it does seem like a sensible default - but someone who's not using GA won't need it. Therefore it might be good to only show it when necessary, as doing so could save a webmaster lots of head-scratching as they try to figure out where that query parameter is coming from.

So in line 177 of the paypal_wps.module:

  $settings = array(
    // Return to the previous page when payment is canceled
    'cancel_return' => url('checkout/' . $order->order_id . '/payment/back/' . $order->data['payment_redirect_key'], array('absolute' => TRUE)),

    // Return to the payment redirect page for processing successful payments
    'return' => url('checkout/' . $order->order_id . '/payment/return/' . $order->data['payment_redirect_key'], array('absolute' => TRUE)),

    // Specify the current payment method instance ID in the notify_url
    'payment_method' => $payment_method['instance_id'],
  );

  // Allow Google Analytics to track conversions (if enabled)
  if (module_exists('commerce_google_analytics')) {
    $settings['return'] .= "?utm_nooverride=1"; // @todo: Allow this to be turned off
  }
diwant’s picture

diwant commented

That is sensible, I have Google CA installed as well, and I can see its purpose interpreted as the 'fix Commerce for GA' module.

For your approach, could there be the case where the return url already has query parameters? In that case, '?' might break the url. I humbly suggest the below modification to your approach.

// Allow Google Analytics to track conversions (if enabled)
if (module_exists('commerce_google_analytics')) {
  // @todo: Allow this block to be turned off
  $divide_character = empty( parse_url( $settings['return'], PHP_URL_QUERY ) ) ? "?": "&";
  $settings['return'] .= $divide_character . "utm_nooverride=1"; 
}
torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

That makes even more sense. Is there a "Drupal Way" of doing that - adding variables/division characters to URL params? I haven't done much checking but I'd rather do something Drupal-centric rather than, for example, using the php parse_url function or something! (But I do like your approach and of course we want to do whatever we can to maintain integrity of the form and its vars.)

jazzdrive3’s picture

jazzdrive3 commented

Did anyone ever get this working? If so, can they submit a code or a patch?

If not, let me know, and I will probably work on it, as our client will need this soon.

Thanks!

diwant’s picture

diwant commented

I had it working for a bit using the fix I mentioned above, but my eCommerce tracking is broken again. I don't think there was a quorum on the correct way to do this. Do you have a good strategy?

diwant’s picture

diwant commented
Issue summary: View changes
StatusFileSize
new commerce_paypal-utmnooverride-1969732-10.patch936 bytes

Here is a patch that includes the utmnooverride in the latest 2.x code for commerce paypal wps. It includes the utm-nooverride parameter as shown above, however I'll have to ask the community (that's you!) to let me know if it actually helps you track ecommerce correctly.

You are looking specifically for the ecommerce transactions to register in Google Analytics AND you should be able to see the source of the visitor correctly (otherwise I believe all the ecommerce transactions show up as direct link visitors since paypal sends them directly back to your site after the payment flow on their side is completed).

diwant’s picture

diwant commented
Version: 7.x-1.0 » 7.x-2.3

This is still present in the latest 2.3 code. My patch is on the 2.x branch as of today.

diwant’s picture

diwant commented
Status: Needs work » Needs review

Marking as needs review because, well, it does!

mglaman’s picture

mglaman
Primary language English
Location WI, USA
commented
Version: 7.x-2.3 » 7.x-2.x-dev
tomtech’s picture

tomtech commented
Status: Needs review » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.