#9 — Restore functionality to store query string tracking variables individually in action records

The tracking variables from the query string need to be stored separately from the 'Landing' and 'Onsite Origin' URLs in the Action Record (as was present in pre-release versions 0.1.9 and 0.1.8 of the eCampaigning Tool)

At present, the 'Landing' (aka Entry or Arrival) and 'Onsite Origin' URLs are stored in the Action Record and includes the full query string (which may also contain tracking variables for other tracking systems like Google Analytics). On saving an action record, these URLs needs to be parsed and:
1) The individual tracking values each stored in separate action record fields
2) The query string tracking variables and values removed from the Landing URL that is saved (but not all query string values in case there are others)

The default query string variables are:
's' = source code (referrer: google, homepage, newsletter4)
'm' = medium code (promotion medium: email, banner, cpc, co-reg, tell-a-friend, rss)
'p' = person ID (a personal identifier)
'c' = content code (version or other content identifier)
't' = term(s) (keywords used)
'n' = name (campaign, action, promo code, or slogan)

Note that:
a) These are not the original codes used in 0.1.8 and 0.1.9. since this has to be re-implemented, these codes are used to align the tracking system with the concepts used in Google Analytics. It thus adds one more variable than before and renames them - however the basic purpose and meaning of all is the same as before.

b) The 'Landing' and 'Onsite Origin' URLs can both contain tracking tags (as part of the query string)

c) If a query string variable contains more than one value or if two different values for the same query string variable exist in the 'Landing' and the 'Onsite Origin' URLs, then each distinct value is to be stored in the same Action Record field. (e.g. separated by a comma, semi-colon or other method as appropriate)


The main uses of this are:

- It makes it easier for analysis (since many analysts won't know how to strip them out of the URL)
- These values will need to be fetched from the record post-submission for use in conditional blocks and ATDataMerge
- These values will need to be fetched pre-submission for use in conditional blocks and ATDataMerge


This can be tested by:
1) Setting up an action edition and ensuring the tracking is configured in the site access rule
2) In a new browser session, append the 'take action' URL for the Action Edition with something like: ?s=source&m=medium&p=personid&c=content&t=termA+termB&n=name
3) Submit the action after completing the required fields
4) Check the Action Record via the ZMI to see if these values are individually stored and stripped from the Landing URL.

Repeat Test with the following scenarios:
1) With an on-site URL to check if it works from the 'Onsite Origin' URL (an on-site url immediately before the Take Action page)
2) With the same query string as above but going to the page with the link to the take action page rather than directly to the take action page and see if BOTH 'Landing' and the 'Onsite Origin' tracking value storage works together.