AdWords Revenue stopped after 9.00063 update

[pbrynie]

Google offers two different ways to track completed orders. On the Google Analytics Settings tab, you can see which mode the module is in. The Universal mode has an option on the Tracking tab to enable tracking of completed orders. The Universal Enhanced Ecommerce mode tracks completed orders by default along with shopping behavior events like product link clicks, add to carts, and remove from carts. The code you referenced above is output when the module is in Universal mode on INVC.

[lesliekirk]

Ahhh, that you for the explanation. Since the Google Analytics Settings is set to Universal Enhanced Ecommerce mode would the code I mentioned be considered redundant? Again, I have no idea why it was added. It showed up months ago before any version of 9.6 was released.

[pbrynie]

Correct, the snippet you referenced is only meant to be output if the module is in Universal mode. I'm not sure how exactly Google handles having both of those different method calls on the same page.

[Dan - Glendale Designs]

Duplicate conversion tracking snippets on the invoice screen would most definitely cause conflicts/missing data. I tested on one of our dev stores and couldn't get 9.6 to auto-inject that snippet, it's possible that Google Analytics was setup this way intentially at some point, with the Universal Ecommerce conversion tracking isolated to the Invoice screen vs. the main template. There were some bugs/issues with earlier releases, so I could easily see this happening. When the store was upgraded to 9.6, the proper tracking code/method was reintroduced causing the conflict. Recommend running through the store and a full transaction with Google Tag Assistant after that snippet is removed, should let you know if there are any further issues or concerns.

[lesliekirk]

Thanks Dan.

[srmb]

I noticed that my Google Analytics tracking code is slightly different from the one recommended below.

<mvt:if expr="( g.UI_Exception NE 1 ) OR ( g.Session:cache:last_ui_exception EQ 'order_invoice' )">
ga( 'send', 'pageview', { 'page':'<mvt:item name="ga_jsencode" param="ga_tracking:url_override_unencoded" />' } );
</mvt:if>

Mine has a "/" between 'page':' and <mvt:item name='ga_jsencode". Here is mine:

<mvt:if expr="( g.UI_Exception NE 1 ) OR ( g.Session:cache:last_ui_exception EQ 'order_invoice' )">
ga( 'send', 'pageview', { 'page':'/<mvt:item name="ga_jsencode" param="ga_tracking:url_override_unencoded" />' } );
</mvt:if>

Which one is correct?

[lesliekirk]

I may have figured what was at the root of my issue. I'll be able to positively confirm it after a couple more days of tracking. More to follow.

[lesliekirk]

Following up on this - first apologizes for assuming that the update caused this issue - it did not. I did two things on the same day. I ran the updates and I added defer to the mvga.js call as suggested in this post. I removed the defer and the Sessions started climbing back to where they had been before I added that tag.

http://www.miva.com/forums/forum/iro...at-need-fixing

[Dan - Glendale Designs]

Funny this turned out to be the issue, we were just having internal discussions yesterday regarding the hidden dangers and high potential for breakage in the name of speed optimization. Tracking snippets are particularly tricky because it can be difficult to test for issues with some of them, it only becomes apparent when the stats start dropping. Glad you got this one sorted, good info.