A problem we’re currently having for many of our clients is setting up Friendly URLs with custom url variables. I’m hoping that maybe someone here has a better workaround to the [poor] solution we’ve been doing. And if not, I’m wondering if Daemon would consider the proposed solution I am suggesting.
Need: Many of our clients do Google campaigns with url variables.
Example: /friendly-url/goes-here?utm_source=vanityurl&utm_medium=program&utm_campaign=applepie
Problem: FarCry’s Friendly URL system doesn’t support url variables when doing FU redirects (at least, not that I can find).
Sloppy workaround: What we’ve been doing is creating tons of hidden nav nodes (hidden from site navigation) where in the nav node we tell it to do an External Redirect. Then in the field for the External Redirect we manually type in the friendly url and its required url variables. /friendly-url/goes-here?utm_source=vanityurl&utm_medium=program&utm_campaign=applepie
Finally we go to the landing page and create the friendly url that the external redirect will go to. /friendly-url/goes-here
This is messy (we have many of these all over the place) and very difficult to manage - especially since we’ve now separated the friendly url into a manually written reference field.
Proposed solution: When creating a friendly url as a redirect, have an option (an additional field) that allows the user to add additional url variables.
Hmm… I know that when I make a URL like this “/search-batteries/keyword/crap” that 6.2 is parsing the first part, which is the FURL “/search-batteries” correctly, then also parses out the URL variable “keyword” as “crap”. I’m not entirely sure HOW, mind, that it does this… but it seems to for me.
Matt, it does do that, but, the Google campaign must be in the query string for GA to pick up on them.
The other problem with just adding them to the FU is that sometimes you might not want to have them in the URL. Example: if you are using the campaign to track clicks from an email newsletter, then you want them, but if it someone just navigates to that page using the site’s navigation menus then that isn’t part of the campaign so you don’t want to track that.
I suppose if you create /my/special/campaign/FU that redirects to /my/real/FU?campaign_vars=stuff then that would work as a special case.
Sean, the special case you refer to are the ones that concern us. We have many of those. These FU’s are only used in certain marketing material (tv, radio, billboards, paid url adverts, etc).
Hah. Am I the only one that finds it highly amusing that the search engine that lays the smack down for non-seo URL strings is forcing you to inject them for into your apps for their own campaigns? Sorry, I seemed to glanced over the fact that the string needed to maintain that format ;).
But I’ve found something rather strange. My scenario is production runs on Windows and we’re using Helicon ISAPI Rewrite, development runs on Mac and I’m using Apache rewrite.
On production, any query string parameters get rewritten to the format /utm_medium/email/utm_source/Campaign%20Source/utm_campaign/Campaign%20Name which is of course not very useful for GA. However, on my local, these aren’t rewritten which is great.
No, don’t see this here. But pounds to peanuts its the URL rewrite I’d double check to make sure the Apache and Helicon rewrites are actually doing the same thing.
I’m running FarCry v6.2.6. The only other thing to mention I guess is that production is running CF 9 and development is running CF 10.
This is my test case:
<p><a href="http://website.local:8080/apps/campaignAction.cfm?action=linkfollow&campaign=720076B0-073D-11E4-A18CE0F8471F4F68&source=subscriber&request=http%3A%2F%website%2Elocal%3A8080%2F72AE6F30%2DEB8C%2D11E3%2D9086005056B67D9A%3Futm%5Fmedium%3Demail%26utm%5Fsource%3DCampaign%20Source%26utm%5Fcampaign%3DCampaign%20Name" target="_blank">link from campaign to local</a></p>
<p><a href="http://www.website.com.au/apps/campaignAction.cfm?action=linkfollow&campaign=720076B0-073D-11E4-A18CE0F8471F4F68&source=subscriber&request=http%3A%2F%2Fwww%2Ewebsite%2Ecom%2Eau%2F72AE6F30%2DEB8C%2D11E3%2D9086005056B67D9A%3Futm%5Fmedium%3Demail%26utm%5Fsource%3DCampaign%20Source%26utm%5Fcampaign%3DCampaign%20Name" target="_blank">link from campaign to com.au</a></p>
The way this works is, campaignAction.cfm will register a hit in the database, and then redirect (using cflocation) to the url.request address.
I’d double check to make sure the Apache and Helicon rewrites are actually doing the same thing.