[Update 8/24/2012: Noah Cooper at Convio has confirmed this is a bug and suggested a workaround until Convio can fix it. See my Fix section below. -S]

In my ongoing quest to fully install Google Analytics on Convio’s platform, I have sadly found another bug, this one having to do with cross-domain Google Analytics connections.

One of the trickiest things to do in analytics deployment is to correctly track a visitor across a number of domains where you have pages, like www.savethewhales.com, store.savethewhales.com and secure3.convio.net.

Many convio clients actually have a setup very much like this.  They have their main site either on the Convio platform or on their own platform, but their default donation pages are on Convio’s SSL-secured hostnames at secure2.convio.net.

If you know anything about cookies, which is how Google Analytics tracks visitors, you know this won’t work.  The cookies which uniquely identify you every time you return to www.savethewhales.com aren’t shared with secure3.convio.net.   So you look like 2 different people.  What’s worse is that the data about how you arrived at the site, which is crucial to understanding where your conversions are coming from, will be lost.

For example, a standard report you want to run on everyone that donates is “how did they get to my site, and how many times did they come to my site before they gave?”  All this data is lost if you don’t carefully pass the cookies from www.savethewhales.org to secure2.convio.net.

How Google Analytics passes your identity from domain to domain

GA has a solution for this, they put a copy of your cookies into the URL and at the other end, they set them.  So, if when surfing www.savethewhales.org, GA says you’re visitor #66666, then when you click the link to Donate that would normally take you to

https://secure2.convio.net/donationform.html

instead GA appends your id to it, like this:

https://secure2.convio.net/donationform.html?analytics_id=66666

So what’s the problem?   Convio’s Donation application (and possibly others) appear to reload themselves and silently delete the Google Analytics cookie in the process of setting a URL parameter idb.   So instead of landing on

https://secure2.convio.net/donationform.html?analytics_id=66666&idb=67654

you land on

https://secure2.convio.net/donationform.html?idb=67654

Here’s an actual example of a URL progression from one of my clients:

Original page:

http://www.wildcarebayarea.org/site/PageServer

User clicks on a donation form with the following URL

https://secure2.convio.net/wc/site/Donation2?df_id=1360&DONATION_LEVEL_ID_SELECTED=1&1360.donation=root

Google Analytics appends the cookies and turns the URL into this:

https://secure2.convio.net/wc/site/Donation2df_id=1360&DONATION_LEVEL_ID_SELECTED=1&1360.donation=root&__utma=1.419819392.1345758089.1345758089.1345758089.1&__utmb=1.1.10.1345758089&__utmc=1&__utmx=-&__utmz=1.1345758089.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)&__utmv=-&__utmk=77686036

All those parameters that looks like __utm are Google Analytics cookies.  Then the bad thing happened.  Upon arrival at secure2.convio.net, I used a sniffer to confirm that upon arrival, the browser was redirected to:

https://secure2.convio.net/wc/site/Donation2?idb=404683257&DONATION_LEVEL_ID_SELECTED=1&df_id=1360&1360.donation=form1&JServSessionIdr004=t22c5n4tw4.app207b

Whoa, where’s my Google Analytics cookies?  Where’s my campaign conversion data?  Where’s all my valuable marketing info to tell me what marketing techniques drove my people to give?  GONE.

There are a couple of possible fixes to this:

  • Assuming all I need here is the idb number of the user, it would be nice to know exactly how to get that and insert it into the URL so a redirect wasn’t spawned.  I tried using idb=[[S76:idb]], but that didn’t work.  It just generated idb=0, and I still got a reload.
  • The better fix is that when applications like Donation2 perform a reload/redirect, they should preserve all the URL parameters, including the ones they don’t know about.

Fix:

Noah Cooper, a developer at Convio, has confirmed that this is a bug (#63189)

As a workaround, he explains that you can link directly to the first page of a form and avoid the redirect.  Here’s his explanation of why you should not include “1360.donation=root” in your URL when linking to a donation page:

Donation forms can either have a splash page, or not (most do not).The query string 1360.donation=root tells our product "I'm not sure whether this donation form has a splash page or not, I need you to figure that out and take the user to the right URL".
Since this form does not have a splash page, requests to https://secure2.convio.net/wc/site/Donation2?df_id=1360&DONATION_LEVEL_ID_SELECTED=1&1360.donation=root result in a server-side redirect to https://secure2.convio.net/wc/site/Donation2?df_id=1360&DONATION_LEVEL_ID_SELECTED=1&1360.donation=form1, the first step of the donation form. That server-side redirect does in fact drop any query strings that were appended to the original URL.
If, however, you change the URL so that it includes 1360.donation=form1, the server-side redirect isn't needed, thus the query strings are retained.

This will work for probably everyone for the moment as a workaround.  However the destruction of the GA analytics URL query parameters is still being treated as a bug and (presumably) slated to be fixed.

Share →