That’s pretty normal behavior.
Request send to sGTM. Connection lost, but sGTM was able to send all these requests to GA4/FB, etc.
Yeah, that’s right, for some users I may encounter this situation with lost connection or leaving the page too quickly.
But all the ATC events from that day? I think it’s a bit too much.
Initially, this post was related to view_item problems that I found in logs.
You did some updates and for a while there were no problems.
But taking a look at view_item events from yesterday, 24th June I noticed huse discrepancies between GA4 and Data Client.
Don’t get me wrong, I am not trying to find bugs in the logs 
I have some problems with some orders not being correctly associated with my ads campaigns or no being tracked at all. So looking in the logs I was hoping to find some clues. But all I
discovered were some other problems :))
Thanks,
Alin
All fine. And thanks for finding bugs
We discussed your case internally, and this does not look like our bug.
This can be because of this:
- GA4 batch view item always with page_view
- There are issues with tag sequencing and view_item triggered before the ga4 config. And this is why the server URL is not set properly.
To find out why I highly recommend installing the Logger tag. We often use it for ga4 debugging Troubleshooting server-side tagging using server GTM logs - Stape
It will log Body and you will see what inside batch requests.
Also, check that the ga4 config on the web is always firing first.
Thanks for your reply, @Denis
I will definitely try Logger Tag.
But I am a little bit worried because @Dan said before in this post that he didn’t find any fault in my setup. And I didn’t make any major changes in the setup since then.
(BTW, you have acces to my GTM in case you need to take a closer look.)
So, I will try to find some more clues with Logger Tag.
For your no. 2 situation, I am pretty sure that this was solved when I started to fire view_item event on DOM loaded.
But as I said, this is not happening only with view_item, but with ATC and other custom events. For BC and PUR looks like it’s ok. Or at least 90% ok.
I suspect some caching problems, some Flatsome related issue with ATC behaviour (using FB pixel helper I am unable to see ATC because the page reloads very fast, but I can see the events (at least part of them) in my reports).
Hey @Alin_Tatarca
499 - client shut off in the middle of processing the request through the server
An abundance of those + the fact that it’s particular events you have a problem with, to me, signals that your lack of logs might just be due to a fact those events fire too late on page, before redirect or something of the sort. Did you by a chance explore this ‘dimension’ ?
Note that DT when sending a POST also downloads a script, so if we consider what I outlined above true - that could explain why you have more GA4 hits compared to DT.
Hey, @Dan
I am aware that this could be a caching problem since I am using Flatsome + WP Rocket.
Some “ajax thing” from Flatsome/Woo can mess up this, or some script delaying from WP Rocket, but I tried both - with and without script delaying on GA and GTM and I had the same results.
But I am sure that is something there.
The reason that I am worried is that I did not make major updates in GTM, because things went well until a week ago, lets say. Thats why I suspect that maybe some update for Flatsome or WP Rocket did this mess.
And to be honest, I am not a pro with reading the logs Also its a bit weird that all ATC events from a specific day to have 499 status code. 70-80%? Ok! But 100% with errors?
And since I have only 3 days of logs, I cannot see the bigger picture, to find where the sh*t hit the fan. 
well that would be 100% of the recorded ones, we can imagine a bulk remained unrecorded, which would fit my hypothesis.
And to be honest, I am not a pro with reading the logs
And myself I have nothing to contribute on Flatsome + WP Rocket but if like you said, it’s the only thing that changed - I would look in that direction
Hey @Alin_Tatarca
So I was correct in my assumptions, here we go:
-
When I add to cart - the page almost immediately reloads (I assume for the sake of showing the sidebar)
-
This makes its so there are like…milliseconds for DL push to occur and relevant tags to fire
-
As you can see from screenshot below, DT hits are consistently ‘canceled’ (hence the 499 error logged)
this happens precisely because the redirect occurs that quick, I don’t know if it’s clear enough but here’s a demonstration, note how page is refreshed almost instantly after dataLayer push
My suggestions at this point are:
a) remove ‘Send all from DataLayer’ checkbox, I hardly think you need the full DL
b) force DT to send GET (Settings section, Request Type - you have it on Auto currently)
@Denis this FYI, in case you have any other suggestions, thanks!
A big-big thank you, guys!
I will implement the suggestions and see how it goes.
I will also let you know if this was solved.
Hello, guys,
Unfortunately, after a couple of days of monitoring, things are the same.
(these are the results from today)
I did remove Send all from DataLayer in DT ATC Tag.
And forced DT to send Get.
BC and PUR are acting normally, no errors.
So, in this case, should I look for some help at Flatsome and/or WPRocket?
Thanks,
Alin
Hey @Alin_Tatarca
-
Your most straightfoward solution would be to either a) not have page reaload when you add to cart b) fire add_to_cart event on that second page (after reload) - if your devs can pull off either of options - your issue will go away
-
Within a month or so, we will be releasing updates to our TT/FB tags that might also contribute to fix your situation, however this would be secondary and if you want a bullet-proof solution - refer to item 1 of this list.
Cheers,
Dan
Thanks, @Dan for your reply.
Ok, I will try to find a solution with the dev/Flatsome team.
But in this case, should I keep those settings for DT ATC Tag?
Send all from DL checked - I think this will not hurt so much.
But “Send GET” it’s still a must?
Thanks,
Alin
PS - can you please give me a sign here, on this post, when you will have updates on TT/FB tags? I am watching your updates on your FB page and here, in this community, but just in case I miss smth.
@Alin_Tatarca if you go the route described in item 1, then keep whatever settings you want in DT.
as to updates on those tags - I will let you know, but it’s not that they will necessarily address the issue, although they might