Tyson,



Let me also add that this would make us seriously consider another shopping cart.



If we can't track revenue from source, what's kind of Google Analytics integration is that?



Not much.



I hope we can find a custom remedy, because I've loved your product thus far.



Matt

*Bump



Any update on this?





Matt

Matt,



I think you are trying to do what I am trying to do. I am trying to resolve the info found on this page:



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



...with the info found on this one:



http://www.e-junkie.com/ej/help.tracking.htm



...with the info found on this one:



http://www.e-junkie.com/ej/help.redirection.htm



...with the info found on this one:



http://www.e-junkie.com/ej/help.customization.htm



It seems to me that code found on the ejunkie page will NOT suffice for eCommerce tracking, which for those reading who might not know goes above and beyond standard google analytics tracking. You are actually on the right track with the way you added google's recommended code after e-junkie's code. Obviously, what you are missing are the values that need to be passed, such as price. Unfortunately, according the e-junkie "redirection" page mentioned above, all the pertinent info involved in a sale is missing when redirecting to a custom thankyou page (with the exception of txn_id.) I believe all of our problems would be solved if e-junkie would send more variables to the thank you page, such as total price, etc (basically all the variables you see as "customizable" on a generic e-junkie thankyou page per the "customization" help page above.)



Having said all that, I'm hoping I have stumbled across the thread I've been looking for. (If I've repeated a bunch of stuff already understood by most, I apologize. I needed to clarify everything for myself to make sure I'm in the right place.) Does this sound like what you are trying to do?



-Matt

Matt,



This is exactly what I'm trying to do.



If you check your transaction logs, e junkie collects all the data. They just need to support the javascript code that sends the data to google analytics.



What is your transaction process like? What kind of thank you page are you using? Will any kind of thank you page setup send the necessary e-commerce data to GA?



I am redirecting all my buyers to another URL that I designed, and I have my google analytics code on this page. I have a credit card provider, paypal, and google checkout. All of which have been recorded with 95% accuracy for tracking conversions. (E junkie has stated that sometimes using paypal and other parties will not redirect).



You can email me at mattpresto@gmail.com or matthew.preston@razorfish.com for a quicker response. I would like to figure this out as soon as possible.





-Matt

Matt,



I am using a custom designed thank you page as well. So far, I am only using the e-junkie-recommended analytics code and have not put any ecommerce tracking in (although I would like to.)



"Will any kind of thank you page setup send the necessary e-commerce data to GA?"



I think the unfortunate answer to that right now is no. It doesn't appear e-junkie supports Google's ecommerce tracking code...at least not from a custom thankyou page. (Any other type of support is useless to me, as I only want to ever use a custom thankyou page, and it sounds like you do too.) The javascript e-junkie provides simply does not do everything ecommerce tracking needs, and the redirection they provide does not send enough data for us to use in google's supplied javascript. A lot of those variables ARE however included in the "integration" link, which is the link e-junkie will POST all the transaction data to, but unfortunately that would fall outside the user's analytics tracking session.



"E junkie has stated that sometimes using paypal and other parties will not redirect"



Hm, I wasn't aware of that. Do you mean when people purchase through paypal they sometimes won't even get to our custom thankyou pages?? That could explain why some of my goals seem to activate less than I would assume they would. I probably get more paypal purchases than google checkout on average.



I think the solution for this falls in e-junkie's hands. We simply need the values for all of these variables you listed passed to the custom thankyou page:



pageTracker._addTrans(

"order-id", // required

"affiliate or store name",

"total",

"tax",

"shipping",

"city",

"state",

"country"

);



pageTracker._addItem(

"order-id", // required

"SKU",

"product name",

"product category",

"unit price", // required

"quantity" //required

);



That's all I can think of at the moment. E-junkie?



-Matt

Matt,



I think we are stuck until development gets back to us.



Tyson - any timeline on when this will happen?



Thanks,



Matt

At the moment, consistent/complete E-commerce tracking is really only possible with Google Checkout, since GC can send E-commerce tracking data directly from their end without any involvement from us.



The tradeoff you have to accept when accepting PayPal payments is that you won't get consistent nor complete tracking of any sort, since PayPal cannot automatically redirect a buyer to any thank-you page after completing Checkout, and many-to-most buyers may not bother to voluntarily click the "return to merchant" link once they've finished Checkout on PayPal's site.



See more details about how the different payment processors handle the checkout-to-thankyou transition, as described at the top of our Tracking help page here:

http://www.e-junkie.com/ej/help.tracking.htm

I am interested in a solution to this integration as well. I followed the conversation above and finally thought to follow Tyson's advice on handling the tracking on Google Checkout side. In other words, is there a way to link Google Checkout and Google Analytics to track everything? Here is what I found...



Google has a handy guide on this: http://code.google.com/apis/checkout/developer/checkoutanalytics_integration.html#Tracking_Checkout_Orders



Basically they suggest using the following code, which contains the usual Analytics code as well as some extra:



<script type="text/javascript">

var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");

document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3Cscript%3E"));

</script>



<script type="text/javascript">

var pageTracker = gat.getTracker("UA-XXXXX-X");

pageTracker._initData();

pageTracker._trackPageview();

</script>



<script src="http://checkout.google.com/files/digital/gapost.js"

type="text/javascript">

</script>





<form action="..." method="POST" onsubmit="setUrchinInputCode(pageTracker);">

<input type="hidden" name="cart" value="...">

<input type="hidden" name="signature" value="...">

<input type="hidden" name="analyticsdata" value="">

<input type="image" name="Google Checkout" alt="Fast checkout through Google"

src="http://checkout.google.com/buttons/checkout.gif?merchantid=YOUR_MERCHANT_ID

&w=180&h=46&style=white&variant=text&loc=en_US" height="46" width="180"/>

</form>





However, it seems that you need to have their checkout buttons to be able to use the above code (you need the <form> tag).



So far so good. My questions is, can we customise e-junkies buttons or the cart, to integrate this code, or what Google wants, so that we finally start getting data from the e-commerce side.



Tyson, you mentioned that e-commerce can be handled on Google side, perhaps you can tell us about this a bit more.



Thanks

No replies still :-(



I am trying to get some ecommerce data and I still cant succeed so I want to know what is currently possible.



From what I understand, I need to put the following on each page (with the appropriate tracker code of course)



<script type="text/javascript">

var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");

document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));

</script>

<script type="text/javascript">

var ejGATracker = gat.getTracker("UA-XXXXX-X");

ejGATracker._setDomainName("none");

ejGATracker._setAllowLinker(true);

ejGATracker._trackPageview();

</script>



Then activate the e-commerce tracking in analytics and the rest is taken care of by e-junkies and google checkout. I should then expect to see ecommerce data on those purchases who used Google Checkout to process their payments. Is this correct? Do I need to do anything else? Is anyone able to see any results in analytics using e-junkies? At the moment this is what I have done, and I can't see any data in analytics!



Has anyone succeeded with this?



After thought: I read somewhere that multi domain tracking by google doesn't work if the tracking code in the javascript is different on both domains. Doesn't this mean that ejunkies should use the same tracking code as we do on our site and use it on their shopping cart when the domain is transferred? Is this the reason why it doesn't work?



I appreciate any help. Ecommerce data is like gold. It would be a wonderful feature for the already quite cool ejunkies services. So it's certainly worth investing time and effort in.

E-junkieGuruThe tradeoff you have to accept when accepting PayPal payments is that you won't get consistent nor complete tracking of any sort, since PayPal cannot automatically redirect a buyer to any thank-you page after completing Checkout, and many-to-most buyers may not bother to voluntarily click the "return to merchant" link once they've finished Checkout on PayPal's site.

May I propose a 90/10 solution? I'd like to see e-junkie implement a selectable option that fires off the GA e-commerce details BEFORE transferring to PayPal. I fully understand that scenario would generate false positives if the user abandons the payment, but it sure beats no e-commerce data at all. The reality is that users just don't press the Return to Merchant link.



My reality is that as Henry says "ecommerce data is like gold." However, it's not accounting data, but statistical data used for marketing decision-making. We can deal with a little bit of noise in the data, but we cannot deal with no data. Anyway, "the ones that got away" aren't just random noise since an abandoned cart is likely to be statistically in line with actual sales.



E-JUNKIE HEAR THIS: E-COMMERCE DATA IS A BIG DEAL. You need to get SOME KIND of solution going, even if it's an approximation. Stop hiding behind PayPal.

E-junkieGuruThe tradeoff you have to accept when accepting PayPal payments is that you won't get consistent nor complete tracking of any sort, since PayPal cannot automatically redirect a buyer to any thank-you page after completing Checkout, and many-to-most buyers may not bother to voluntarily click the "return to merchant" link once they've finished Checkout on PayPal's site.

May I propose a 90/10 solution? I'd like to see e-junkie implement a selectable option that fires off the GA e-commerce details BEFORE transferring to PayPal. I fully understand that scenario would generate false positives if the user abandons the payment, but it sure beats no e-commerce data at all. The reality is that users just don't press the Return to Merchant link.



My reality is that as Henry says "ecommerce data is like gold." However, it's not accounting data, but statistical data used for marketing decision-making. We can deal with a little bit of noise in the data, but we cannot deal with no data. Anyway, "the ones that got away" aren't just random noise since an abandoned cart is likely to be statistically in line with actual sales.



E-JUNKIE HEAR THIS: E-COMMERCE DATA IS A BIG DEAL. You need to get SOME KIND of solution going, even if it's an approximation. Stop hiding behind PayPal.

I will pass your suggestion on to our development team.

I agree with MilesK, it's a huge deal. Even huger is just being straight up front about what you can and can't do. I love e-junkie, but sometimes I hate it.



I'm going to read a bunch of these other articles before I suggest you guys make a decision tree to help people figure out what to do about tracking. You could probably do this using a free mind map like Freemind, and post it as a free download. It would be hugely useful.



Also, your document is excellent in it's thoroughness. I want you to know that. Because the way it's written is maddeningly difficult to understand. Seriously, I have to get a paper and pencil and flow chart through all the "if then" statements. It would be easier for me to understand if you just wrote it all out in some clean c code. Then at least I could run it through indent and a prayer of understanding wth I was reading.

I did recently post this Tips page (linked from the bottom of the Tracking help page), explaining a fairly reliable method for tracking sales conversions IF your products are file downloads:

2http://www.e-junkie.com/ej/tips.tracking.conversions.htm2



If you're really serious about mining your own e-commerce data, we can recommend using only Google Checkout combined with Google E-commerce Tracking, since those two are "joined at the head" and don't rely on any jinky methods like thank-you page visits to track conversions.



We really wish PayPal was more conducive to this sort of thing, but we just have no way to make them do what they can't or won't do, and it would be pointless (if even possible) to trigger a conversion when the buyer first goes to checkout, because a huge number of "window shoppers" only abandon their order during checkout, when they're faced with the prospect having to either actually pay for their order for real or bail out.



We do try to err on the side of completeness in our help pages; often here in the office we'll be discussing a support issue that someone ran into because of some fringe case or technicality, and our Founder/Lead Developer will say that really needs to go in the documentation, so I add it in and maybe revise the rest of the page for clarity while I'm at it.



Unfortunately, completeness is often the enemy of simplicity when you have such a complex application as ours, and one that depends on so many different third-party service providers in various ways, and Tracking/Analytics is probably THE most complex issue we have to deal with.



If we try to make the help pages simple and as easy as possible to understand, it glosses over a lot of technicalities and special cases that we'll asked to explain over and over, and some may even get angry at us for keeping useful secrets, and if we try to be clear about every possibility and condition, then it becomes too complex to scan through and understand at a glance.



Our position is to make the documentation as accurate and complete as possible to help the majority of our do-it-yourself'er users who wish to figure things out on their own, and if someone still wants a simplified overview, upshot summary, or step-by-step instructions tailored to their own, specific needs, we're always glad to provide that here on the forum or via email.

I don't envy you guys at all.



Documentation is tremendously difficult, even when - especially when - you're really close to the product.



Frankly, it's an opportunity for me to write some blog posts which will rank up there in position 2 or 3 on Google, and grab some consulting business. Except (no offense) it's kind of boring work and I would have to charge more than people would want to pay.



I know a couple of VAs who might be interested.



I still think a mindmap or flow chart would be killer.



Thanks for your time, I appreciate the service you provide.



Off to read the tips page.



(Also, I am commenting back on these in part so that I can search on my user name later and find these threads.)

E-junkieGuruIf you're really serious about mining your own e-commerce data, we can recommend using only Google Checkout combined with Google E-commerce Tracking.

E-junkieGuruit would be pointless (if even possible) to trigger a conversion when the buyer first goes to checkout, because a huge number of "window shoppers" only abandon their order during checkout, when they're faced with the prospect having to either actually pay for their order for real or bail out.

I have some actual data I can contribute to quantify "huge." I also consult for an unrelated site on Magento where we can measure the number of people who drop out after they press the "Pay Now" button which transfers them to PayPal. The drop-out rate is consistently around 10%.



As to whether it is possible to trigger a conversion before the handoff to PayPal, the answer is "yes." We had somebody code up a custom module for Magento that does exactly that.



I'm well aware of the countless breathless articles out there which whine about the "shocking" cart abandonment rate, but that's something else entirely. Lots of visitors put stuff into their carts and then abandon them to check shipping rates, because they're window shopping, because they get distracted, etc, but the people who abandon after pressing Pay Now/Finalize are much more serious. Typically, it seems those drop-outs are mainly due to declined credit cards.



I wish you would revisit your assumptions about the "pointlessness" of pre-handoff data due to abandonment. I submit that you just don't have the data to dismiss the pre-handoff conversion approach. The only people outside of PayPal who know this for sure are real merchants such as ourselves who have the ability to see shoppers being handed off to PayPal and then to match them up with actual PalPal receipts. E-junkie doesn't let us measure that, but it does do a nice job of giving shoppers up-front shipping estimates, etc, so I can see no reason why the drop-out percentage should be any different from the ~10% we see on Magento. On the contrary, the analytics have greatly helped us to optimize the marketing & adversiting for the custom Magento site. The data isn't accounting-grade, but we just kick the to-the-penny accountants out of the room when we're discussing marketing stats. 10% error is plenty good enough for us marketing chickens.

E-junkieGuruIf you're really serious about mining your own e-commerce data, we can recommend using only Google Checkout combined with Google E-commerce Tracking.

E-junkieGuruit would be pointless (if even possible) to trigger a conversion when the buyer first goes to checkout, because a huge number of "window shoppers" only abandon their order during checkout, when they're faced with the prospect having to either actually pay for their order for real or bail out.

I have some actual data I can contribute to quantify "huge." I also consult for an unrelated site on Magento where we can measure the number of people who drop out after they press the "Pay Now" button which transfers them to PayPal. The drop-out rate is consistently around 10%.



As to whether it is possible to trigger a conversion before the handoff to PayPal, the answer is "yes." We had somebody code up a custom module for Magento that does exactly that.



I'm well aware of the countless breathless articles out there which whine about the "shocking" cart abandonment rate, but that's something else entirely. Lots of visitors put stuff into their carts and then abandon them to check shipping rates, because they're window shopping, because they get distracted, etc, but the people who abandon after pressing Pay Now/Finalize are much more serious. Typically, it seems those drop-outs are mainly due to declined credit cards.



I wish you would revisit your assumptions about the "pointlessness" of pre-handoff data due to abandonment. I submit that you just don't have the data to dismiss the pre-handoff conversion approach. The only people outside of PayPal who know this for sure are real merchants such as ourselves who have the ability to see shoppers being handed off to PayPal and then to match them up with actual PalPal receipts. E-junkie doesn't let us measure that, but it does do a nice job of giving shoppers up-front shipping estimates, etc, so I can see no reason why the drop-out percentage should be any different from the ~10% we see on Magento. On the contrary, the analytics have greatly helped us to optimize the marketing & adversiting for the custom Magento site. The data isn't accounting-grade, but we just kick the to-the-penny accountants out of the room when we're discussing marketing stats. 10% error is plenty good enough for us marketing chickens.

The key, thorny issue here is that -- unlike a full-featured, freestanding e-commerce software package like Magento, where you get your own copy of the software to install on your own server, reconfigure and modify as-needed -- E-junkie is "software as a service", a centrally-managed Web application which executes only on our own servers and is shared in common among all our users.



This means there is no practical way to modify our software for just one client without applying that very same modification to every other client who uses us, or at least without developing that modification into a fully-fledged feature that any of our clients could enable/disable or (re)configure as needed. That makes every "custom modification" request into a general feature request for the wishlist, which falls under our overall development strategy explained here:

http://www.e-junkie.com/bb/topic/4079#post14073



Nobody can be everything to everybody, and trying to be that is how software turns into a bloated, sprawling, bug-ridden, crufty monstrosity that nobody actually wants. We are not trying to be, nor interested in becoming, an all-singing-all-dancing, full-featured e-commerce storefront solution competing with Magento, Zencart, Xcart, etc. That market segment is already well-served by those and other competing solutions.



Our focus, and where we have found success, is with a heretofore grossly under-served demographic: "mom'n'pop" do-it-yourself'ers of modest technical ability. E-junkie is, always has been, and always will be targeted as a simple, basic service for simple, basic needs. The majority of our subscriber base comes to us precisely because they don't want nor need the complexity of Magento, et al., so we don't try to compete with those solutions. If a seller's needs become greater or more sophisticated than what we can reasonably support or provide for all our clients across the board, we would suggest that perhaps that client has simply outgrown us and is ready to level-up to a full-fledged e-commerce storefront solution.



We are like a hammer: a simple tool with a few simple uses; if you really need a Swiss Army knife, just get one of those instead of sharpening your hammer and bolting attachments to it. :^)

Is there a way to add two different tracking ids?



This is what our old GA tracking code looked like:







var _gaq = _gaq || [];

gaq.push(['setAccount', 'UA-XXXXXX-39'],['b._setAccount', 'UA-XXXXXX-1'],

['b._trackPageview']

);

gaq.push(['trackPageview']);



(function() {

var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;

ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';

var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);

})();