E-Junkie Forum

Post #15

Mon, 28 Jul 2008 06:40:51 GMT

lol - if you dont need a hammer for the job...

right tyson?

Post #14

Mon, 28 Jul 2008 04:34:41 GMT

Please call me directly at 520.248.0364 or email us your phone number so I can call you.

Post #13

Sun, 27 Jul 2008 05:46:16 GMT

Is Robins pc fixed - is it possible he can now respond to my question?

Post #12

Wed, 23 Jul 2008 07:39:01 GMT

never did get an answer - just tell me that you will continue to ignore this and I will go away

Post #11

Fri, 13 Jun 2008 02:38:52 GMT

Tyson

appreciate the response - just a little concerned that all code development stops because one mans pc is broken - I would have thought, like any other business, critical company data is backed up so that work does not grind to a halt - is e-junkie really that small and disorganized a company? - I have lived thru the cart crashing and losing sales due to server "issues" as I really like the cart from a consumers perspective - but am starting to regret moving from a cart I used for 8 years with no down time and great google analytics integration - have put on hold moving 3 more of my web sites to e-junkie

If I cannot get this google integration resolved by the month end, I will be forced to return to Mals cart

Denis

ps

I first started on this forum back in February about the issues with google integration (see below) - long before Robins pc broke!!

The cart is not passing the original click "cookie" so I cannot see which campaigns are resulting in conversions. Can this please be fixed?

POSTED ON: February 22, 2008 @ 19:00 #

Post #10

Fri, 13 Jun 2008 00:44:59 GMT

I can respond, but I really have nothing to add here, as this issue is beyond my knowledge nor ability to address, personally.

If you have sent some affected transaction IDs to development@e-junkie.com for our analysis, then our Lead Developer (Robin, aka E-junkieChef) will get to that when he can. Even with the recently-expanded staff, his plate is still more than full -- now he's only juggling 3 flaming chainsaws instead of 6 (to mix metaphors :^).

Also, at the moment I gather he really can't do much of substance with the service itself, as his laptop has all his development software installed on it, and that lappy went to the shop for a cooling-fan replacement that was estimated to take a week but has now dragged on for nearly a month (no thanks to HP first sending the wrong parts and then saying they're out of the correct ones!). As soon as he gets his main rig back, I'm sure he'll rapidly catch up on his backlog of investigation cases and other tasks requiring direct manipulation of the main E-junkie codebase and database. Thanks for your patience and understanding.

Post #9

Thu, 12 Jun 2008 16:31:10 GMT

Tyson - I know you are out there - please can you respond to this thread

denis

Post #8

Tue, 10 Jun 2008 22:59:59 GMT

Still no answer - I would appreciate an ejunkie response if only to say they are too busy to look at this problem - love the cart from a comsumer perspective - but would not recomend it to anyone as technical response is non existent and google analytics integration is not functioning

Post #7

Sat, 7 Jun 2008 15:05:48 GMT

bunkbedking,

have you tried praying yet?

if you are not paying for the Monthly Super Special Customer Sevice Contract, which they dont offer, well then you know the rest...

Post #6

Sat, 7 Jun 2008 06:51:44 GMT

In response to

We have taken all this in account and we precisely do what you have mentioned here. Can you please send one of your transaction IDs to developement@e-junkie.com?

POSTED ON: May 14, 2008 @ 00:29 #

I have emailed this data twice and have yet to receive a response

Help please

Post #5

Wed, 14 May 2008 21:27:12 GMT

no googles problem was only April 30th to May 4th

Post #4

Wed, 14 May 2008 16:35:29 GMT

I think that's a GA issue. SimpliFun posted about that at http://www.e-junkie.com/bb/topic/2584

Post #3

Wed, 14 May 2008 14:14:12 GMT

Sure - no problem - but unfortunately since the 12th May, I am not seeing any conversions in google analytics (except sales that are processed via google checkout) - not sure, but I think this is linked to your isp problems??

Post #2

Wed, 14 May 2008 07:29:18 GMT

We have taken all this in account and we precisely do what you have mentioned here. Can you please send one of your transaction IDs to developement@e-junkie.com?

Post #1

Mon, 12 May 2008 05:18:57 GMT

I can see clicks and conversions in google analytics - but I cannot see the original source click - google attributes all of my conversions to "not set" or refers them to my own site

I have followed the google recommendation --- and my code replicates the google suggested code

ie
If your website initiates a purchase checkout process on a separate store site
(for example, if you send customers from www.mystore.com to www.securecart.com):

Add the following lines (in bold) to your tracking code on both your store site and your shopping cart pages:

But I believe e-junkie does not conform to the 2nd google suggestion to include onclick="__utmLinker(this.href) ?? to the cart links?

Change the links from the main site to the secure site to use __utmLinker as follows. If your current links look like:
https://www.securecart.com/?store=parameters">Purchase Now

change them to:

https://www.securecart.com/?store=parameters" onclick="__utmLinker(this.href); return false;">Purchase Now

The code above provides links for users with or without JavaScript enabled. It's important to note that apostrophes need to be escaped with a backslash where they appear in the link or link text.

Important: if your pages include a call to urchinTracker(), utmLinker(), utmSetTrans(), or utmLinkPost(), your Analytics tracking code must be placed in your HTML code above any of these calls. In these cases the tracking code can be placed anywhere between the opening tag and the JavaScript call.

I really want to be able to assess the profitability of my ppc's but cannot unless e-junkie can track the original click source

The following is a great article on this - so is e-junkie fully integrated with google analytics? or am I doing something wrong?

How Google Analytics Tracks Third-Party Domains
June 25, 2006 by Justin Cutroni
Time for another installment of how to set up Google Analytics the right way! Today we’re going to talk about how to configure GA if your website spans multiple domain names. This is often the case if you’re using a third party shopping card. Just a note, I’m not going to get into the actual installation steps in this post. I want this to be a conceptual. If you’re looking for step by step instructions you can contact me or find them on them here on the GA Support Site:

http://www.google.com/support/analytics/bin/answer.py?answer=26915&hl=en

Before we get into the nuts and bolts of the setup, it’s important to understand the fundamentals of how GA tracks visitors. GA uses first party cookies to identify your site visitors. We all know what cookies are, right? First party cookies are set with the same domain name that is in the location bar of the visitor’s browser. It is very important to understand that cookies can only be ’seen’, and changed, by the domain that sets them. In fact, it is almost impossible for a website to set a cookie for a different website. This is due to a default security setting that most browsers have. Website A can not set a cookie for website B.

Let’s take this knowledge and apply it to how GA works. When a user lands on a page in your site the urchin.js tracking code looks for the GA tracking cookies. If it finds the cookies then it updates them. If it does not find the cookies it sets them. Remember, if your website domain is www.shirts.com, then the urchin.js tracking code can only recognize cookies with the www.shirts.com domain and it can only set cookies for the www.shirts.com domain.

As the user continues their session the urchin.js interacts with the tracking cookies. Continuing with our example, the user on our site is just about to click on a link to different domain, the third party e-commerce platform we use. They will leave our domain and go to the e-commerce provider’s domain. We’ve been tracking this user with a specific set of cookies on our domain. When the visitor leaves our domain we want them to take their cookies with them. The cookies identify them as a unique visitor, if they don’t take their cookies to the next domain then we will loose the rest of their session information and that’s not good.

So how do we transfer the cookies to the shopping cart site? With Google Analytics we can pass the cookie values to the shopping cart domain via the query string. There are two conditions that need to be met for this technique to work:

We need to add the urchin.js tracking code to the pages on the third party domain (I’ll explain this in a second).
The third party domain must permit us to pass data via the query string.
If the third party domain does not allow the above then you can NOT use GA to track your visitors on the shopping cart pages. Sorry, there’s no way around it, both conditions must be met.

Here’s how we normally configure GA to work with a third party site. We wrap the link (or form) that directs the user to the third party site in a JavaScript function. This function literally picks up the cookie values from the visitor’s computer, appends them to the URL and then forwards the user to the third party domain. Once the user arrives on the destination page the urchin.js pulls the cookie values from the URL and sets a new set of cookies with the values extracted from the URL. That’s why we need to add the urchin.js to the pages on the third-party site. We need the code in the JavaScript file to pull the values for the cookies from the URL. It’s really important to understand this last step because it overcomes the two hurdles we discussed above.

First, we’re transferring the visitor’s cookie values from one domain to another. This means that the entire visitor session will be captured. All the identifying information for the visitor stays with the visitor as they traverse the different domains.

Second, the GA tracking cookies on the third-party site will be first party cookies so they are less likely to be rejected by the browser.

We all know that getting the complete picture of a visitor’s session is vital to better understanding of the referring information and site configuration. I hope this post gives people a better idea of how GA is tracking their traffic across third-party domains so they can configure it correctly.