I'm experiencing an issue with the 'checkout_completed' event in my Custom pixel code:

[gprusiyski]

I subscribed for the “checkout_completed” event in Custom Pixel. This is my code:

//subscribe to events
analytics.subscribe("checkout_completed", (event) => {
window.dataLayer.push({
event: "checkout_completed",
orderId: xxx,
currency: xxx,
value: xxx,
});

While I’m testing, I can observe the ‘page_view’ event being pushed to the dataLayer in the console, but I cannot see it in the Chrome extension ‘Tag Assistant Legacy’.

As a test, I changed the event from ‘checkout_completed’ to ‘checkout_started’, and everything worked as expected. I could see this event in the Chrome extension ‘Tag Assistant Legacy’.

Can anyone help me with this issue?

[lynth]

Please help us, I have the same problem here. It looks like checkout_completed doesn’t work or I can’t preview it with Tag Assistant.

[zdunecki_ls]

@lynth

Hi, do you still face the issue? In my company we face the same. We’re checking on which side fault is.

[lynth]

Yes, still the same. Nothing new.

[thebigcagency]

This is actually a major issue judging from what I have been reading in the community threads lately. Devs as well as Admins are facing similar issues from the same API spec. From what I gathered:

• This appears to be a shop-individual issue (I have 3 clients for which the trigger works and 1 for which the checkout_completed trigger does not work)

• This in turn means there could be multiple sources of origin ranging from apps, payment options, shop config to files served in the checkout.

Based on my oberservations this is a shopify API issue with the event not being triggered or not being exposed in the customer events pixels. How I checked:
I created a “Console Log” Web Pixel which basically just logged all Standard and Custom events to the console.
analytics.subscribe(“all_events”, (event) => {console.log(event)}

If the event “checkout_completed” shows up in the console, I know that I am the problem in this equation. If it does not it is likely a backend / web pixels issue.

Turns out: It’s a web pixels issue. But I have a feeling this could still be related to my client’s shopify configuration.
Therefore I recommend also checking other console log events that appear during a test order.
I see

• a MIME type issue with “Refused to apply style from” from some private_access_token URL source

• and some warnings concerning a google maps API call being deprecated

• as well as a warning for a document.write not working for an amazon payment script (I paid by credit card for the test order)

To sum up: I did not fix the issue. But I hope I might have provided some insights into getting closer to troubleshooting this.

[keligijus]

Docs say “It’s triggered once for each checkout, typically on the Thank you page” - I wonder if it’s because we haven’t switched Thank you and Order status pages to Checkout Extensibility.

I don’t want to upgrade Thank You page now, since it it doesn’t seem there’s an easy way to switch back to checkout.liquid for the page.

[lynth]

I have the same problem. Today I’ll test it with the full checkout extensibility, I’ll let you know guys.

[thebigcagency]

This is actually connected to checkout extensibility. As long as there is code in the checkout thank you box on the backend the checkout_completed event does not seem to trigger. However, all other’s do trigger: add_payment_info etc.

There is actually a workaround to this. You can use the web pixels API from within the checkout-code box to pass the conversion to the customer events sandbox.

You would have to use something like this:

Shopify.analytics.publish(conversion_name, conversion_object)

In the conversion_object you could pass the transaction ID as well as the ecommerce value.

Then you can use the analytics.subsribe function to listen for it in the customer events.

[keligijus]

Thanks! That’s a good approach. I’ll try this.

My initial plan was to keep the GTM script we have in checkout.liquid and use it to pass data along. It’s gets a bit complicated since we’re going to upgrade info, shipping and payment pages to checkout extensibility, but keep checkout.liquid for the thank you and order summary pages.

[lynth]

Remember that the checkout.liquid will be deprecated soon. You have about one year for thank you and order summary pages

[lynth]

Do you think my implementation is okay? Should it work?

window.dataLayer = window.dataLayer || [];

(function (w, d, s, l, i) {
  w[l] = w[l] || [];
  w[l].push({ "gtm.start": new Date().getTime(), event: "gtm.js" });
  var f = d.getElementsByTagName(s)[0],
    j = d.createElement(s),
    dl = l != "dataLayer" ? "&l=" + l : "";
  j.async = true;
  j.src="https://www.googletagmanager.com/gtm.js?id=" + i + dl;
  f.parentNode.insertBefore(j, f);
})(window, document, "script", "dataLayer", "GTM-********");

Shopify.analytics.publish("checkout_completed", {
  transaction_id: "{{order.id}}",
  value: "{{order.total_price}}",
  currency: "{{order.currency}}",
  products: "{{order.line_items | json }}"
});

analytics.subscribe("checkout_completed", (event) => {
  window.dataLayer.push({
    event: "checkout_purchase_test",
    timestamp: event.timestamp,
    id: event.id,
    client_id: event.clientId,
    transaction_id: event.data?.checkout?.transaction_id,
    value: event.data?.checkout?.value,
    currency: event.data?.checkout?.currency,
    products: event.data?.checkout?.lineItems?.map((item) => ({
      id: item.id,
      name: item.name,
      quantity: item.quantity,
      price: item.price
    }))
  });
});

[thebigcagency]

I don’t think this would work.
It is important to know where to implement these parts.

• The analytics.subscribe call and the GTM-function belong in the customer events pixels.
• the analytics.publish part belongs in your checkout-settings (the one where you post the extra code) or your checkout.liquid. (wrapped in a script tag)
• On the other hand I would not name the conversion the same as the Shopify standard event - just to be on the save side and avoid complications with it. Name it something like custom_purchase e.g.
• Then there is an issue in the analytics.subscribe function. The data you pass for custom events is available via event.customData. event.customData.transaction_id would return your transaction ID you passed into the publish-call earlier

[lynth]

I’m not totally sure I understand it yet. Is it possible to create a custom app with the web pixels API and put there the Shopify.analytics.publish method to publish custom analytics events? Then I could subscribe to it from the customer events pixel with analytics.subscribe method and push it to the GTM? I know that web pixels API doesn’t allow to sending of data directly to GTM.

[thebigcagency]

So this is the workaround.

You use analytics.publish in the Additional Scripts or checkout.liquid.

Then you can subscribe to the event in the Customer Events like this:

Of course you would have to have the GTM loading in the customer events as well, but I feel like you already understand that concept.

(You can basically pass every event from the frontend into the customer events like this and subscribe to them there.)

[lynth]

Oh, ok thanks, but what if I migrated fully to the checkout extensibility and don’t have access to the checkout.liquid and Additional Scripts anymore? Do you think I can put the snippet from Additional Scripts into the Custom Pixel app I created and activate it? Then subscribe to the event in the Customer Events. New checkout is very tricky and complicated regarding the analytic stuff.

[thebigcagency]

This is all just a temporary workaround for the transition period into checkout extensibility.
However, from what I have seen across different customer shops, after you fully migrated every checkout step to checkout extensibility, the analytics.subscribe(“checkout_completed”) method should work in the customer events section. This means that you won’t have to push the conversion event anywhere and you probably won’t be needing any additional custom apps for your checkout_completed events to available via the customer events (in theory).

This all seems to be a temporary issue in shops not fully migrated yet.