if first_time_accessed does not return true

[timd]

I have a custom checkout script that include a {% if first_time_accessed %} query which has been working fine and I've just noticed over the last couple of days it is no longer returning true when I first land on the order confirmation page.

There have been no changes to the checkout scripts. 

When I check the value of {{ first_time_accessed }} with console.log it doesn't return any data:
console.log('{{ first_time_accessed }}') — should this be either true or false?

Has anyone else noticed this or run into this issue in the past?

[NomtechSolution]

The {% if first_time_accessed %} condition in your custom checkout script is evaluated based on the value of the first_time_accessed variable. If the variable is not being passed or is empty, it could explain why the condition is not returning true as expected.

When you use console.log('{{ first_time_accessed }}') in your script, it outputs the Liquid code {{ first_time_accessed }} itself rather than the actual value because the Liquid code is executed on the server side before the page is rendered. Therefore, it won't provide you with the true or false value you're expecting.

To troubleshoot the issue and understand why first_time_accessed is not being set correctly, you can perform the following steps:

1. Check the code that sets the first_time_accessed variable: Review the code where the first_time_accessed variable is defined or assigned a value. Make sure that it is set appropriately and passed to the order confirmation page.

2. Verify the variable's value on the order confirmation page: On the order confirmation page, you can inspect the page source or check the rendered HTML code to ensure that the first_time_accessed variable is present and has a value assigned to it.

3. Debug the value using Liquid tags: Instead of using console.log('{{ first_time_accessed }}'), you can output the value directly in the HTML code for debugging purposes. For example, you can use <p>{{ first_time_accessed }}</p> to display the value on the page. This way, you can see the actual value of the first_time_accessed variable when the page is rendered.

[timd]

Thanks for the thorough response @NomtechSolution. I've included some feedback to your suggestions below:

1. I can confirm that previously the first_time_accessed object was being set and firing correctly until very recently where it has stopped working with no changes to the code.

2 & 3. It shouldn't matter whether {{ first_time_accessed }} is included in <p> tags or a console.log script — the value should still be outputted to the page source, which it isn't.

This seems to be linked to another issue where our order confirmation page doesn't alway have {{ order }} object data available when we first land on the confirmation page. eg. {{ order.id }} is empty.

But if we refresh the page a few seconds later, the {{ order }} object has data. So what we were doing in looking for {{ first_time_accessed }} and if it was true, we'd display a loading animation for a couple of seconds and then refresh the page so we could display {{ order.id }} etc on our custom confirmation page.
But it seems like all of a sudden, even first_time_accessed is no longer available.

[timd]

FYI there a a few other cases of missing order data reported on the forums:

https://community.shopify.com/c/technical-q-a/shopify-checkout-object-on-order-status-page-does-not-...
https://community.shopify.com/c/technical-q-a/additional-scripts-on-order-status-page-checkout-objec...
https://community.shopify.com/c/technical-q-a/please-help-me-expose-the-checkout-object-on-order-con...
https://community.shopify.com/c/technical-q-a/order-objects-sometimes-blank-on-confirmation-page/td-...

https://community.shopify.com/c/technical-q-a/order-objects-sometimes-blank-on-confirmation-page/td-...

[jessesai]

Hi, I am having this exact issue. Can the shopify team give an estimated timeline for a fix ?

[fallen-domino]

I can also confirm that this value is returning `false` when it should be returning `true`. This seems intermittent however.

[Havik]

Hai, is there any update on this issue? We got similar problem to this where after giving it time to load still leads the checkout code block empty or outright makes the first_time_accessed false thus not firing the tracking code. 

We have to resort to removing first_time_accessed and make condition to check if the checkout object is empty or not. But, now we having inflated tracking analytics problem since we make this change.

[Mitrodol]

Hi, we also have encountered this issue as our tracking script with purchase is fired on the order status page with first_time_accessed condition. But sometimes it's working , sometimes not.

Also we have found that in some cases there is a wrong sequence of the thank you pages , firstly is loaded page without 'thank_you' in url (i.e.  the page '.../62373691644/orders/1be0c61c579e97a8d64cc56c1e49580d..') although firstly the page with '../checkouts/c/21321rfwfwfw1/thank_you' should be loaded where our script with purchase event is fired.

Because of this issue lots of transaction is missing in GA4. But if compare with native integration Shopify-GA4 this discrepancy is smaller . Native integration works much worse. There are shops where 50 % transactions are not recorded. 

Here's a link to the topic https://community.shopify.com/c/shopify-apps/ga4-not-counting-every-purchase/m-p/2078398#M63428

[Havik]

Thanks for this! I have been searching for what is the problem for quite a while and this is very weird way of confirming the orders. This must be a recent change as it was not like this earlier of the year. My team decided we create a workaround by putting the Order ID into local storage. It mitigates the short term problem of customer going back to the thank you page again after a while. But this doesn't solve the long term problem that the first_time_accessed code block is still wack.

And I do agree that native integration is kinda bad now. Our Meta CAPI via the integration option is now reporting upwards to 5 to 10 orders missing per day which affects our reporting. I'm still at a loss regrading this. 

[Mitrodol]

So what I have noticed with the last test purchases that I've made.

There is some redirect from the thank you page that loads order status page without 'thank_you' in URL . This redirect leads to the order status page that we can open for example when click in the Orders section to view thank you page of the certain order

The schema of the redirect looks like 

1. First page after the order processing .../checkouts/c/b937106bf77e085574e34669ed5b86ff/thank_you

2. Second page

.../50329321627/orders/49b3d9275579b2cb666bae5706cc922e/authenticate?key=c0573e70d569e94893c2eb38c1f96d1e

3. Third and the last

.../50329321627/orders/49b3d9275579b2cb666bae5706cc922e

What I am observing in this case on the Preview mode of GTM

There is no our dataLayer push with the purchase event (script wrapped by the {{ first_time_accessed }} condition). And also there is no gtag purchase event (that is fired when you turn on Conversion tracking option in Google channel app and that is sent to 'AW-' or 'G-' tags if you connect your Ads or GA4 correspondingly). So Shopify connector is also using that {{ first_time_accessed }} condition, IMHO.

Two hypothesis I have here:

a) Are all the scripts added to the order status page should be fired on the first one thank you page with /thank_you?

If so - then they are just not fired because of this quick redirect.

b) If they should not be fired on the first one but on the last one page loaded. Then it means that because of {{ first_time_accessed }} returning empty value nothing is fired on the last one loaded thank_you page including gtag purchase event mentioned above. 

The key point is that sometimes /thank_you page is normally loaded without this redirect. But there are no scripts firing also in this case (neither our, nor gtag).

Another point is that we have situation when transactions are being recorded. And it's only some percentage of transactions not being recorded. This can't be explained.

[1080]

@Mitrodol  I have same issue do you find the any solution ?

does this shopify liquid issue ?

[Mitrodol]

Hi @1080 
This issue still persists as I know.

But on the other hand in the beginning or mid of July Shopify fixed the issue with missing transactions in GA4. Since that time any of our clients' stores encountered missing transactions either setting up GA4 with automatic integration or with manual set up via GTM.

Everything looks fine now so I have stopped my investigation. 

[AllAwareTommy]

We are having the same problem. I suspect there is something wrong with the redirects that happen after an order is processed. I have confirmed that "first_time_accessed" resolves to an empty string ("") by 1) passing the liquid variable into JavaScript and calling console.log, and 2) rendering the liquid value in the same context in which I'm trying use it: (<span>{{ first_time_accessed }}</span>).

This is making it extremely difficult to track purchases reliably.

[Wayne_Foster]

We came across a similar issue a while back - and then discovered that the use of the "first_time_accessed" variable / liquid tag is not recommended for use in the actual checkout.liquid file itself.  It is designed exclusively for the additional scripts section.  We have a block in there that sets a javascript variable  - that is then required for our purchase tracking to fire.  Even this was not sufficiently robust - so we add a cookie to ensure we don't double track.  Been reasonably accurate after those two changes.  The new web pixels are going to be interesting - implementing a dataLayer with no preview mode in GTM - and I wonder how the first time accessed logic is going to be addressed - hmmmm.

[AllAwareTommy]

Thank you for the additional insight, @Wayne_Foster . I will note here that we are indeed using "first_time_accessed" exclusively in the context of Settings > Checkout > "Additional Scripts" (Order Status Page), and not in checkout.liquid / theme files. It is in this context that I'm finding "first_time_accessed" resolves to an empty string, leading to missed purchase events and inconsistent tracking data.