Instant analytics not sending purchase data

[jripmeester]

Question

We've updated a client webshop to commerce 3 and did a full refactor of the front-end. After updating the website and launching the website all instant analytics data is send nicely except for the purchase event. The store had multiple orders last weekend but none we're received in analytics but add to cart events are registered.

What's the best wat to check what events are being send? Logging shows no errors. Is there a way to test instant analytics without me var_dump-ing in your code files?

Additional context

Craft CMS - 3.6.11.1 Craft Commerce - 3.2.17.3 Instant Analytics - 1.1.11

[khalwat]

It should be logging any time events are sent -- are you not seeing anything?

Did you implement any kind of caching on the frontend that could affect things?

[jripmeester]

Are the events also logged in production? Because in that case i don't see them in web.log. We had a service-worker in place but we removed that as it did lead to some weird situations.

No other caching in place right now.

[jripmeester]

@khalwat After some strategic dumping of vars in our staging env i found out that the order event is triggered but the event is not received in Analytics. So or it's blocked in analytics somehow or the $analytics->setProductActionToPurchase(); $analytics->sendEvent(); on line 58 of services/commerce.php are not doing their job.

But this seems on GA side. Any idea how to further debug this?

[jripmeester]

@khalwat Sorry to keep buggin you with this. But is there a way to trigger the order send event from twig. To test if a manual trigger does work or maybe give an error.

[khalwat]

What version of GA are you running?

[jripmeester]

Not the new GA4 one. GA Property has been created in 2017 so it’s a legacy one.

There is one thing that's different on this new version of the site and the old one. It's that we use a few custom snapshot properties on the line items. Might that cause the trouble? As this is the event where the order is send with and the order is the only place where these custom properties on the product snapshot are set.

[jripmeester]

@khalwat Some more debugging led me too trying trigger the orderComplete function from a custom module variable. When i use that path all is working fine. So it seems that the webhook way used by the payment service is the killer here.

Does that classify as a bug?

[jripmeester]

@khalwat Last week we went a bit deeper with pin pointing this error and we found something out.

The orders of logged in users is getting sent to GA, orders of guests are not. This webshop is behind cloudflare. Bypassing Cloudflare made al orders come through.

Difference between the 2 situations is that:

1. a guest with Cloudflare gets a _ga clientId in the format: 1197138454.1617354777

2. An logged in user with Cloudflare or all users/guests without Cloudflare get the _ia clientId in the format: 75da40e3-95ea-4d34-bcbe-57dfbc8ca085

Situation 1 is the majority of the visitors.

We bypassed this now to (ugly fix), change:

    private function gaParseCookie(): string
    {
        $cid = '';
        if (isset($_COOKIE['_ga'])) {
            $parts = preg_split('[\.]', $_COOKIE['_ga'], 4);
            if ($parts !== false) {
                $cid = implode('.', \array_slice($parts, 2));
            }
        } elseif (isset($_COOKIE['_ia']) && $_COOKIE['_ia'] !== '') {
            $cid = $_COOKIE['_ia'];
        } else {
            // Only generate our own unique clientId if `requireGaCookieClientId` isn't true
            if (!InstantAnalytics::$settings->requireGaCookieClientId)  {
                $cid = $this->gaGenUUID();
            }
        }
        if (InstantAnalytics::$settings->createGclidCookie && !empty($cid)) {
            setcookie('_ia', $cid, strtotime('+2 years'), '/'); // Two years
        }

        return $cid;
    }

private function gaParseCookie(): string
    {
        $cid = '';
        if (isset($_COOKIE['_ia']) && $_COOKIE['_ia'] !== '') {
            $cid = $_COOKIE['_ia'];
        } else {
            // Only generate our own unique clientId if `requireGaCookieClientId` isn't true
            if (!InstantAnalytics::$settings->requireGaCookieClientId)  {
                $cid = $this->gaGenUUID();
            }
        }
        if (InstantAnalytics::$settings->createGclidCookie && !empty($cid)) {
            setcookie('_ia', $cid, strtotime('+2 years'), '/'); // Two years
        }

        return $cid;
    }

This makes sure every visitor gets the_ia cookie. But this is far from a fix. Does this info give you some more insights on what a good fix might be?

[khalwat]

mmmm so it sounds like it's something specific to CloudFlare in terms of how this is not working for you.

It looks like your change is just dropping any parsing of the _ga cookie, which causes it to fall back on using the _ia cookie... but that means we're not retaining any unique id from Google, which probably has some unfortunate implications in terms of tracking.

I guess I'm unclear why if the _ga cookie looks like this: 1197138454.1617354777 that the original code doesn't work. Wouldn't that set the $cid to properly?