Maybe this should be called cross-person conversion tracking, because the problem is normally caused by conversion funnels that traverse across human operators – job recruiter, reservations staff, car rental phone operator etc. Or even pure online companies but which for some reason require a staff member to complete or confirm the applications internally, or even an automated system which completes in the dark after a period when the customer has long since closed their browser window. Cross person tracking helps to see the source of conversion even if someone else carried out the action which triggered the tracking codes to run by a terrible hack of the GA system to pull out the cookie, store it, and return it at the end on the other machine.
Getting Access To the Cookie
Cookies are integral to tracking systems like Google Analytics. However they can’t move from the browser that created them which makes it impossible to use them to track “offline” conversions, or deep conversions. An example of a deep conversion is not just when a potential client fills out a contact form, but when a sales rep has actually phoned them back and converted them into a customer. The point of conversion in that case would not lie with the customer it would be the sales rep operating the companies CRM or backend accounting setup to process the order.
So here is my idea: when the first conversion occurs (lead form, booking enquiry etc) and a bunch of stuff is stored in the database with a unique ID and so forth, also grab the Google Analytics cookie and store that against the booking/purchase whatever. You can easily pull this using the cross domain tracking feature which neatly forms a URL-encoded string to grab.
Here is a sample that I just generated to make it really freaking obvious what I’m talking about. The following string was generated by GA (Google Analytics) using the cross domain tracking functions (_link and _linkByPost), and can be used to show that I started my browsing session from the nzs.com web directory (referral) even showing the page I was on.
So you grab this string on the conversion page, store it in the database alongside the order, call it “GA Cookie”. Then you make it so that in your deep conversion page or actual conversion page you dynamically pull out this cookie from the db and have it served alongside the normal tracking of that actual conversion. This effectively turns the the sales reps browser into the customers browser in terms of how GA sees it (sure the browser and screen resolution etc will suddenly change), but most importantly, the Goals and Conversions in the reports will show where the sales came from.
This would allow call centre operator based conversions that occur to be tracked in Google Analytics.
Potential uses: In recruitment. When a potential job seeker signs up and converts using their Safari on Mac say, you store the traffic source cookie during the conversion. Then when the person is say actually placed in a job – many months later in some cases – the recruitment system see’s his record being manipulated by the recruitment agent, pulls out the GA cookie string from his db record, appends it to the URL of the status or confirmation page, and triggers a Goal in GA say called “placed”. GA will think the conversion was sourced from it’s actual source, rather than say http://CompanyInranet/ or where ever that employee used to navigate to the content in his work day (info that’s not important basically). This way you can see if different forms of advertising bring in different levels of qualities of candidates. You could compare the performance of Facebook traffic compared with Seek and other job sites, and against Google organic and PPC ads, and make up your mind better about which forms of advertising are working.
Note: the system should probably delete this cookie when it’s done since it’s effectively like cookie hijacking.