always approach button buyer cart client combined custom data doesn downloads email explained file method nor number pay paypal product products sales server shopping software standard summary support text thank-you-page

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:
http://www.e-junkie.com/ej/tips.tracking.conversions.htm

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.

...unless, for example, you need to accept multiple currencies. For us, this is a hard requirement imposed by a key marketing partner.

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.

...unless, for example, you need to accept multiple currencies. For us, this is a hard requirement imposed by a key marketing partner.

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);
})();

You could just use the standard tracking code from GA and follow their method for multiple IDs. This would give up the ability to track cart button clicks and the GA Ecommerce Tracking data we can provide on our thank-you pages when you use our version of the GA tracking code. It might also work if you use our version of the GA tracking code for one ID and the latest GA-provided code for another ID.