How to use Google Analytics Tracking through RBS WorldPay

A very technical post this time, so that others with the same problem don’t have to struggle as hard as we did:

What’s the Problem?

We encountered that Google Analytics shows the wrong referrer information when tracking through the payment pages of RBS WorldPay (Business Gateway). The payment pages are served by WorldPay, and Google Analytics shows WorldPay as the referrer, instead of the original referrer (e.g. an organic google search or an Adwords ad). The original referral/visitor information is lost. This in particular annoying for the tracking of e-commerce transactions on the payment response pages, which will all show WorldPay as the referrer.

All code snippets are in PHP and JavaScript. It shouldn’t be a problem to translate the snippets into other languages. This solution should also work with the announced changes to the WorldPay payment pages (which will forbid any JavaScript).

[Jump to solution summary]

What doesn’t work and why?

The Analytics help explains that you should add linker methods to your Analytics code for cross domain tracking between different servers (your server and the WorldPay server in this case):

var pageTracker = _gat._getTracker("UA-12345-1");
pageTracker._setDomainName("none")
pageTracker._setAllowLinker(true);

on the second (linked) website and

onSubmit="pageTracker._linkByPost(‘https://select.wp3.rbsworldpay.com/wcc/purchase’);"

or

<a href="https://select.wp3.rbsworldpay.com/wcc/purchase" onclick="pageTracker._link(this.href); return false;">go to WorldPay</a>

on the first (linking) website.

These linker methods represent a workaround for the cookie based tracking that Analytics uses by default. Since a cookie can only be accessed by the web server placing the cookie, another website cannot use the same cookie to ‘continue’ tracking a user coming from a different server. The linker methods modify the target-URL of the link. On the target website, they also instruct Analytics to use the GET parameters (from the linked URL) instead of the (non-existing) cookie to retrieve the referral information, and to place a cookie with that information for the new web server. Hence, the linker methods ‘copy’ the cookie from the first (linking) server to the second (linked) server.

However, since you are reading this, you probably know already that this solution does NOT work with WorldPay.

We believe it is due to the internal re-directions on the WorldPay pages: WorldPay automatically redirects the user through different subdomains on their servers during the payment process, and there is no way to evoke the above mentioned linker methods for these redirects.

In addition, with the announced changes to the WorldPay payment pages (which will forbid any JavaScript), tracking on the payment pages wouldn’t work any longer anyway.

So what’s the solution?

The answer is to bypass tracking on the WorldPay pages altogether, and to track only on the payment response page . The payment response page is served by WorldPay, but you can instruct WorldPay to fetch the code from your server (WorldPay only asks you to include a special banner-tag, so that they can show some payment related information). While you cannot track the correct referrer information on the payment response page directly (because it is served by WorldPay, and thus doesn’t have access to the original cookie from your server with the referrer information), you can include an iframe from your server on the payment response pages . In this iframe (which may be hidden), you can include your tracking code for page tracking and for e-commerce transactions. The iframe is served from your server, so it has access to the original cookie and can read the original (and correct) referrer information. In the example below, we pass on our own order ID to track it within the track-transaction.php file.

On the payment response page, include:

<iframe id="wp_frame" src="www.your-server.com/track-transaction.php?id=<?php echo $order_id; ?>" style="border:none; display:none"></iframe>

That solves the problem. Well, almost. It solves the problem for all browsers except for… you guessed it… Internet Explorer (6 and higher). Internet Explorer with standard privacy settings does not accept third-party cookies. And your iframe is considered third-party content, because it is not served by the same host as the payment response page.

While pageviews and transactions are tracked with the correct referrer in FireFox, Chrome, Opera, and the other browsers, the pageview and transaction is not tracked for visitors using Internet Explorer.

A bit of internet research will tell you to include a P3P privacy policy using

header(‘P3P: CP=\"CAO PSA OUR\"’);

in the beginning of your code to overcome this problem. Placing this code on the page that serves the iframe content will instruct Internet Explorer to trust your site, and hence allow access to the cookie.

When you include the privacy policy in your code, the pageview and transaction tracking actually takes place, and you can see it in Google Analytics. But… You are back at square one (at least for IE), because it shows the WorldPay server as the referrer. For some unknown reason, the Analytics code is not able to read the correct referrer information from the cookie, and replaces it with a new referrer, just as if there hadn’t been any cookie at all.

To overcome this you have to use the linker methods mentioned above: On the page that links to the WorldPay payment pages (i.e., your cart or checkout page), you need to invoke the _getLinkerUrl method to prepare the correct URL:

var save_url=pageTracker._getLinkerUrl("www.your-server.com/track-transaction.php?order_id=");

Save that URL somewhere on your server (e.g. in the orders table of your database) or pass it through WorldPay using their hidden fields. Then, upon reaching the payment response page, retrieve this information and use it as the URL for the iframe:

<iframe id="wp_frame" src="<?php echo $save_url ; ?>" style="border:none; display:none"></iframe>

Finally, on the page containing the iframe content, you need to include the following statement to instruct Google Analytics to read the referrer from the GET parameters in the URL instead of from the cookie:

var pageTracker = _gat._getTracker("UA-12345-1");
pageTracker._setAllowLinker(true);
pageTracker._trackPageview();

In addition, you also need to include the P3P privacy policy as mentioned above, because Analytics still needs to write the cookie back to the system.

And that’s it. A small step for mankind…

What it doesn’t do

The mentioned solution does NOT track on the WorldPay pages itself. It merely enables you to link the tracking before and after a user visits the WorldPay pages, so that you get the original referrer information for e-commerce transaction on the payment response pages. With the announced changes on the WorldPay payment pages (which will forbid all JavaScript), tracking wouldn’t be possible on these pages anyway. If you really need to track that a user has visited the WorldPay pages, you might try using an additional iframe in the header or footer of these pages, or calling an Ajax request on your own server upon linking to WorldPay. We haven’t tried that, though.

Solution Summary

Here is a page-by-page summary for those who don’t care how and why it works.

1) On your checkout page (the page that links to WorldPay, e.g. www.your-domain.com/cart.php or www.your-domain.com/checkout.php)

Execute the following statement just before transferring to WorldPay:

var save_url=pageTracker._getLinkerUrl("www.your-server.com/track-transaction.php?order_id=");

Save the "save_url" variable in your database or pass it through WorldPay’s hidden field. You need to access it on the payment response page.

2) On the payment response page (served by WorldPay, but fetched from your server)

Somewhere in the bottom, add:

<iframe id="wp_frame" src="<?php echo $save_url ; ?>" style="border:none; display:none"></iframe>

where $save_url is the URL string created using _getLinkerUrl in step 1.

3) In the iframe content page (track-transaction.php)

a) Add a P3P policy:

<?php
session_start();
header(‘P3P: CP=\"CAO PSA OUR\"’);

(click here for examples in other programming languages)

b) Add the _setAllowLinker method to your Google Analytics code:

var pageTracker = _gat._getTracker("UA-12345-1");
pageTracker._setAllowLinker(true);
pageTracker._trackPageview();

and track the transaction using the _addTrans, _addItem and _trackTrans methods as explained in the Google Analytics help.

That’s it. Cheers!

This entry was posted in Technical Tips & Tricks and tagged , , . Bookmark the permalink.

11 Responses to How to use Google Analytics Tracking through RBS WorldPay

  1. Mike C says:

    Hi,

    Great post, but unfortunately i’m not sure that this will work under Worldpays proposed updates taking placce August / September 09. I’ve been working to try and solve the same issue with a client of mine that used Worldpay and Google Analytics and took a similar apporach to you. Didn’t get quite as far along but i was (and am currently) using an Iframe to house the GA code. So when i found your post explaining how to solve the IE problem using the P3P headers i was really impressed. Unfortunately just tried it on WorldPay test server which has all of their lastest updates and they appear to no longer support iframes! Sad Face!

    Back to the drawing board, i’ll let you know if i fin a way round it.

  2. Daniel says:

    Hi Mike,

    Thanks for your comment. The described method currently DOES work in the live environment. We also encountered some strange behavior in the test environment today (it was working a few days ago), and we are investigating this. Unfortunately, I noticed that WorldPay tends to announce changes, then postpones them, and then appears to implement them step-by-step at ‘random’, unannounced intervals, with very vague descriptions. We will investigate it further and report on updates. Would be nice if you could keep us updated as well.

    Anybody from WorldPay reading this?

    Cheers,
    Daniel – http://www.GuideGecko.com

  3. Mike C says:

    Lol, i wish they would! Might actually get something that is easy to use if they did.

    It works in my (clients) live env too, unfortunately not in the Test env. After a bit of digging this is down to the whitelist of allowed HTML tags that they are implementing on the live env on 23rd September (well so they say). This is active on the test env by default. But you can login to the payment gateway and turn this off in the installation setup untick the ‘Enable whitelisting?’ checkbox and it will work once more on the test env. Unfortunately they will be implementing this on the live env on the 23rd September, but will allow developers to disable it until the 14th October when it will be enforced on all env’s. Another sad face!

    See http://www.rbsworldpay.com/support/bg/index.php?page=news&sub=xss&c=UK#pptech for the full detail. They are using AntiSamy Project allowed attribute list as the whitelist which if you download and look through it has the following directive;
    [code]

    [/code]

    Evidentailly it is this that is the scurge of worldpay marketeers the world over! Thinking of putting in a support request to worldpay to highlight this as an issue. Although dont like my chances of getting this omitted!

  4. Mike C says:

    Sorry missing code

    [code]
    tag name="iframe" action="remove"
    tag name="frameset" action="remove"
    tag name="frame" action="remove"
    [/code]

  5. Craig T says:

    Yes, I am looking to see how to overcome the World Pay issue with Javascript too, as it not only affects my Google Analytics (and PPC), but also two different affiliate programs I use as well. These new World Pay changes are not very user-friendly for webmasters.

  6. Ravi says:

    Hi Daniel,

    Great post ! I had looked up this one when I tried doing this.We at Tatvic just finished one implementation of Ecommerce tracking for Google Analytics if Worldpay is a payment Gateway. Have a look at it . It will be great to hear your feedback !

    Cheers,
    Ravi

  7. Daniel says:

    Hi Ravi,

    I read through your article. Good idea. The drawback of your solution is that you require the user to click one more time, hence adding an extra burden (when in fact, he has paid already). Anyway, I assume everybody will click and the tracking will work, as they want to ‘complete the order’ after paying.

    Thanks for letting us know.
    Daniel

  8. Matt says:

    Hi,

    I’m quite the novice with WorldPay and cross domain tracking but am working on a client and this appears to potentially solve our problem. Any news on how this has been affected by World Pay’s whitelisting? From what I understand from the comments I can’t be totally sure if your suggestion would work if implemented so would be good to get an idea of current/future situations with this.

    Thank you,
    Matt

  9. Daniel says:

    Hi Matt,

    Our solution currently works in boh the live and the test environments, as long as you disable the ‘whitelisting’ option. This is still possible, because WorldPay keeps on postponing the final changes, and I guess we won’t see them in place any time soon (but who knows?).

    However, once WorldPay finalizes the changes, whitelisting will be enforced, and the solution in the main article won’t work. This is because WorldPay will strip out (‘whitelist’) not only javascript, but also the iframe on the payment notification page. Therefore, the tracking code inside the iframe will not be executed.

    Unfortunately, I feel WorldPay is not very customer friendly with respect to this issue. When I called last time, I’ve quite abruptly been told Google Analyitcs is a 3rd party tool and WorldPay is not responsible that their service works with 3rd party tools. Sure, right. But GA is the de-facto standard for web analyses, and WorldPay just one of many payment “service” providers. I told them in that case, I cannot really recommend WorldPay to clients and partners anymore.

    In any way, you can always use Ravi’s solution (see above), at the expense of an additional click for the customer.

    Anybody else tried calling WorldPay on that issue?

    Best,
    Daniel

  10. Matt says:

    Thank you Daniel,

    I completely agree that WorldPay’s customer service is, at best, one eyed on this issue, and given the demand you’d think they’d take a more holistic approach to this issue. Almost certainly to be their loss in the long term.

    I have already looked into using Ravi’s approach with the client and once we’ve got the client’s WorldPay account details will look to implement this. We’re even hoping to incorporate it into an auto-redirect back to the client’s site (ie from Page 3-Page 4) to get around the extra click. If I can personally understand how we do this with the coding, which isn’t guaranteed, I’ll pass the comment onto Ravi’s blog.

    Thanks again,

    Matt

  11. Daniel says:

    Hi,

    An automatic redirect from page 3 to 4 can be done easily using a meta-redirect in the HMTL you serve on page 3.

    Daniel

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>