While we’re introducing different options to track, let me tell you about redirect tracking.
Before I go into the technical details and explain how to implement it, let me explain what it is and what people use it for.
onClick handler? Use Redirect Tracking. (I could do that on this blog, which is hosted on wordpress.com, not on my server.)
How about tracking links that point to something other than a web page? Say a phone number or an email? Sure, use Redirect Tracking.
The latter is an interesting one. Say your site allows people to post ads (“car for sale, GBP9000, as new!”). Your site is supposed to make it as easy as possible for the potential buyers to contact sellers, so if the seller supplied a phone number, the site will display it next to the add. On a mobile phone, the visitor can tap that link and the phone will launch the dialler and allow the visistor to make that call.
Yes, you can track that with Redirect Tracking.
My colleague Ben Gaines has written an article about it: Measuring mobile user actions.
How Does it Work?
The system will read all the “variables”, then answer with a HTTP Status 302 and tell the browser to go to the URL you provided.
Here’s an example:
Say I have a link to example.com and when someone clicks on that link, I want to track event12 and add time parting into eVar43.
Here is what your link would look like:
The system will capture the event and the eVar, then redirect your browser to http://www.example.com.
Some things I want to point out:
- See the
/5/? That tells the data collection servers that this is a mobile link. The servers may handle visitor identification differently, but as far as I know, they currently (as of 2013) don’t. It doesn’t hurt to put a 5.
/REDIR/is what makes the difference. This tells the system to collect all the parameters on the URL, then reply to the browser with an HTTP Status 302.
- The first parameter,
url, contains the URL that the browser should ultimately load. This can be any sort of URL (URI?) that the browser understands.
url=tel%3A+441234567890is perfectly fine and handles use case 3 above.
- The parameters for link tracking,
pev2have to be present, otherwise the system will track this as a page view with an empty URL, which is not what you want.
- See how I cleverly used a Dynamic Variable for
pev1? No need to hard code any URLs here.
- Because redirecting like this means the user cannot see what the ultimate URL will be (bit of a security thing), redirect tracking is only possible to white-listed URLs. If you want to use it, you need to work with Customer Care to enable your target URLs.
A note about the white-listing: in some cases, the list might be quite long or even infinite (like the phone numbers). In those cases, you could implement your own redirection service (preferrably with some check or your own white list) and have Adobe servers redirect to that server.
Draw backs: two 302s will take longer than one. And you will have to supply a server that handles redirects sensibly.
With potential comes complexity, of course. And with complexity comes the challenge of understanding all available options and making the right choice.
I will start posting articles about these choices in the future now that we have laid the foundation.
One thought on “Redirect Tracking”