Google ClientID should use the real one, not a random one

[chriscct7]

Right now, GiveWP generates a fake UUID for google on the measurement protocol hit for the purchase, meaning none of the customer metrics, nor funnels nor goals will work. You should capture the real ClientID and use that.

[Benunc]

Hi Chris,

The folks at filarete digital forwarded us the email that you sent them. Can you copy/paste that detail here? I can't figure out a way to get those images/etc into this issue, and the way you explained it to them was super-helpful.

Thanks!

Related

Helpscout link: https://secure.helpscout.net/conversation/558440981/16736/ Other users affected: https://secure.helpscout.net/conversation/564893377/17234/ https://secure.helpscout.net/conversation/615955481/21114?folderId=1823994

[Benunc]

(Copy/paste from the referenced email)

MonsterInsights is used on more eCommerce sites than any other GA solution for WordPress, and I can confidently say this is not coming from our addon.

On further inspection, we have determined the cause.

This is the User Explorer report for GA filtered from April 1 - 4 for just users who have made a purchase.

Notice the 5 items outlined. These are not valid GA IDs. Those are UUIDs (a dead giveaway is the format, or the lack of time on site and/or bounce rate), commonly made by GA plugins when a clientID cannot be determined for a user. MonsterInsights does not use these, except in cases of absolute last resort, which are incredibly rare. To see so many in such a short timespan was a red flag something else is going on with your account.

Let's notice how when I filter the orders for the same time span to the same period, there is also exactly 5 orders coming from your server's city.

And when we click on one of those UUIDs, we find the answer to what's causing the issue:

(image deleted from original email)

This is a user purchasing from GiveWP. Notice the lack of checkout events or other pages. This is most definitely not a MonsterInsights tracked user. And it's not a user tracked by GA (else you'd have a proper GA clientID and proper pageviews, but note despite there's an ecommerce event there's no pageview on even a checkout page).

What this tells us is something in GiveWP is very wrong with their tracking of eCommerce users.

Interestingly, this is the code for their tracking they use on your site:

jQuery.noConflict(); (function($) { window.addEventListener('load', function give_ga_purchase(event) { window.removeEventListener('load', give_ga_purchase, false); var ga = window[window['GoogleAnalyticsObject'] || 'ga']; if ('function' === typeof ga) { var give_forms = $('form.give-form'); give_forms.each(function(index, value) { var form_id = $(this).find('input[name="give-form-id"]').val(); var form_title = $(this).find('input[name="give-form-title"]').val(); ga('ec:addImpression', { 'id': form_id, 'name': form_title, 'category': 'Donazioni', 'list': 'DonationForms', 'position': index + 1 }); ga('ec:setAction', 'detail'); ga('send', 'event', 'Fundraising', 'Donation Form View', form_title, { 'nonInteraction': 1 }); }); give_forms.on('submit', function(event) { var ga = window[window['GoogleAnalyticsObject'] || 'ga']; if ('function' === typeof ga) { var form_id = $(this).find('input[name="give-form-id"]').val(); var form_title = $(this).find('input[name="give-form-title"]').val(); var form_gateway = $(this).find('input[name="give-gateway"]').val(); ga('require', 'ec'); ga('ec:addProduct', { 'id': form_id, 'name': form_title, 'category': 'Donazioni', 'brand': 'Fundraising', 'price': $(this).find('.give-amount-hidden').val(), 'quantity': 1 }); ga('ec:setAction', 'add'); ga('send', 'event', 'Fundraising', 'Donation Form Begin Checkout', form_title); ga('ec:setAction', 'checkout', { 'option': form_gateway }); ga('send', 'event', 'Fundraising', 'Donation Form Submitted', form_title); } }); } }, false); })(jQuery);

This is a standard GA funnel set for enhanced eCommerce tracking. But if they're tracking the user, why aren't they linked to the actual Google user. And where is this generated UUID coming from.

This is the measurement protocol hit they use:

$args = apply_filters( 'give_google_analytics_record_offsite_payment_hit_args', array( 'v' => 1, 'tid' => $ua_code, // Tracking ID required. 'cid' => give_analytics_gen_uuid(), // Random Client ID. Required. 't' => 'event', // Event hit type. 'ec' => 'Fundraising', // Event Category. Required. 'ea' => 'Donation Success', // Event Action. Required.

You see, despite tracking the user checkout flow in GA, they don't actually use the client ID. They generate a random one and pass that.

That means your user purchasing the GA will be exactly like the above. Not linked to a real user, and with no prior information on them.

And since this clientID doesn't actually exist, Google can't pull geographical data from the clientID, so GA falls back to the passed country and geo data. But GiveWP doesn't pass that either. Nor does it pass the client IP.

So Google Analytics falls all the way back to the only thing it can go on, the IP address of who sent the call to their server. Which 100% of the time will be your server, and thus, every GiveWP ecommerce order will always show as coming from the city where your server is.

As you know, we don't support the GiveWP Addon, for a solution we currently support, you'd need to use WooCommerce.

In fact, after checking, all of the orders you've ever gotten with a city correctly have come exclusively from MonsterInsights, because we store all of the clientID, ip and geodata and then pass them in succession to Google, so even though our measurement protocol call may sometimes (example adblock) fall back to a UUID, this is incredibly rare.

So basically what needs to happen here is GiveWP needs to update their GA integration. We'll reach out to them and try to give them a hand but we can't make guarantees, and we again will note we don't make the GiveWP Addon so we cannot guarantee it accurately works.

Thank you,

Chris

[kevinwhoffman]

@DevinWalker I'm assigning this to you since you have the most experience with this add-on. See Chris's notes above.