This project aim is to provide the ability to use campaign data values inside the DOM (such as in forms). Many of us in the past added campaign data to our CRM (such as Salesforce) with Google Analytics UTMZ cookies, but with the move to Universal Analytics (UA), it's not possible to retrieve UTMZ cookie values anymore, since Universal Analytics script does not store campaign data on a cookie. This project then 1) creates a new cookie, "traffic_source", which tracks the campaign data based on a query string parameter 2) Stores the existing UTMZ campaign value of returning users so old campaign data won't be lost.
utm-alternative just got better!-Supports using utm_campaign tag as requested by some users
-Now populates the cookie on each user's visit
-Less code, cleaner, easier to customize (but will work absolutely fine out of the box)
-Adding the timestamp of the session was removed from 2.0. Will be added in the future.
-Support for Adwords auto-tagging - use the new parameter OR utm_campaign - see documentation under "tagging URLs".
Note that you can migrate easily as long as you keep the YOURDOMAIN.com value the same. For the documentation of version 1.1, see readme 1.1.
The new release is better adjusted for pure user tracking - regardless of using UTMZ cookie or not.
Since not all analytics platforms employ the utm_campaign query string paraemter, and since the auto-tagging of adwords enables you to omit it, this plugin creates and alternative - relying on your own cookie and a new parameter "src". Each time this parameter is declared in the URL, the utm-alternative code takes action.-
First, checks whether there is an existing UTMZ cookie with a campaign info. If there is one, it saves it to the new cookie - "traffic_source". (This name can be changed to something else)
-
If there is also a src query string parameter value (can be changed as well), it adds it to the cookie (=concatenate it). This way you can track your campaigns effect over time. Since release 2.0 you can use the utm_campaign cookie as well more easily.
-
If there is neither, the script looks at the referrer. It will add the exact referring path (www.example.com/page.html, google.co.uk...)
-
Otherwise, it will put "direct or none"" (strictly speaking, we cannot know for sure it's direct traffic, or a browser favorite, email link, pdf or whatever).
An example of how the traffic source value should look like:
{src value from linkedin campaign}>>{src value from adwords campaign}>>{utmz campaign value}
(>> Double arrow is the separator of the values)
*fill in your site in the variable "site_hostname" at the top of the code.
*Pass your domain name (in the format: .YOURDOMAIN.com) in the closure of the function. You can also change the default cookie name "traffic_source" to something else if you would like to.
Loading the Javascript:
The main javascript could be loaded in the head section, after the body tag, or via GoogleTagManager.
- If you run traffic_source.js in the head, the JS code that prints the value in the form (hereafter: form.html) should run after the body tag.
- If you run all JS after body tag, the traffic_source.js should run before form.html.
- If via GoogleTagManager, you must make sure that traffic_source.js runs before form.html. You can do that by putting both piece of codes in one tag, one after the other.
Q: Why not with Local Storage but a cookie?
A: Local Storage does not allow you to share data across subdomains easily (if at all). Many advertisers run different campaigns on different web assets, so being unable to share this data across subdomains will make this script less effective.
Q: Why Javascript?
A: Cross-platform, server-side agnostic solution.
Q: What to do if I use the utm_campaign any way and I don't use Adwords auto-tagging?
A: From version 2.0 you can do it more easily. Change "tracking_parameter" to "utm_campaign". What you can also do, is from now on just add src=XXX to the target URL. You can make it identical to the utm_campaign so you keep track of your campaigns easily. The ability to rely on the utm_campaign query string parameter alone was considered, however to keep it flexible and to adjust to different implementations of different users, a new parameter was created. Read "Tagging URLs" file for more information on using the plugin.
Q: So is the UTMZ campaign value adds up to the cookie each time the user enters the site?
A: No. Once there is a new "traffic_source" cookie, the script does not check for utm_campaign anymore. You can now rely on the new traffic_source cookie.
Q: Do I must use Google Analytics?
A: The script works independently, so Google Analytics is not required. You can use it for your own projects where you need the campaign data in the DOM. However, it allows marketers who used Google Analytics UTMZ cookie to retain the campaign data accessible via a cookie.
AUG 19 2016
Release 2.0: Thanks bobbylechuga and svensson-david for additions and inspiration.
-Support using utm_campaign tags as requested
-Now populates the cookie on each visit
-Less code and cleaner, easier to customize (but will work absolutely fine out of the box)
-Adding the timestamp of the session was removed from 2.0. Will be added in the future.
-Support for Adwords auto-tagging - use the new parameter OR utm_campaign - see documentation under "tagging URLs".
The new release is better adjusted for pure user tracking - regardless of using UTMZ cooking, or even Google Analytics.
AUG 07 2015
Added notes for implementation "Tagging URLs.md"
FEB 22 2015
Change separators for easier data analysis.
JAN 30 2015
-Domain and cookie name values are passed to the function. If no domain name is passed, the function will take by default the hostname (-->including the subdomain). Thanks caiorogerio.
-Small fix of currTime() function.
Aug 25 2014
Release 1.1: New currTime() function gives you an option to add the time of the session to the traffic source cookie. By default, these lines are commented out.
Aug 15 2014
Add "utmz:" string before the old UTMZ campaign value (that was retrieved from the existing UTMZ cookie of the user).