Event time sending failure

[zsavajji]

Hi! I found out that a lot of events i'm sending through CAPI via my server side GTM implementation are failing, and i pinpointed the issue to the event_time parameter. It seems that a lot of clients are sending timestamps (generated by the getTimeMillis() / 1000 in the event params) in the future.

Is this a common issue that can be mitigated in some way?

Thanks!

[angelbt91]

Hi @Zsavajji!

I got the same error message many times in Facebook's Events Manager. However, when I looked at the total events affected, it was always < 1% of the total events, so I assumed they were caused by networking / connectivity issues when sending the event data instead of a bug with getTimestampMillis().

Is that your case? Could you please show an screenshot of the error you are seeing in Events Manager or elsewhere?

Thanks a lot!

[zsavajji]

I am not seeing errors in the events manager, in fact I am looking for the root cause of a mismatch in the report of Purchase events of an ecommerce website which we manage. There is a big discrepancy between the number of purchase events reported to Google Analytics and the number of purchase events registered by the FB business manager. The trigger is attached to the same frontend event, so i don't really understand where it's losing this information.

BTW, the error I am seeing is easily visualized by putting a log when the CAPI response is not 200 in the tag template. Since the GTM implementation gets no body when the request fails, i made some requests with the same payloads and they failed with "Provided timestamp is in the future".

[angelbt91]

There is a big discrepancy between the number of purchase events reported to Google Analytics and the number of purchase events registered by the FB business manager.

Please be aware that Google Analytics and Facebook have different attribution models. While Facebook will count a Purchase anytime the user clicked on an ad before ordering (in a given time window), Analytics will only attribute that order to Facebook if, of all the channels the user came from to our website, Facebook is the last one non-direct. This used to be the default behavior, not sure if now it's different. Also, Facebook and Analytics could have different attribution time windows too. I would dare to say that your discrepancies are more likely caused because of that than the event_time error.

That said, it's true that I can also see some errors on Facebook Events Manager about timestamp being in the future. As they were really scarce, I assumed it was a network/connectivity error as I said, but I'll investigate this issue further. What I don't understand is how can you repeat the same payload and get "Provided timestamp is in the future", when you actually used the same payload so the event_time should be from the past. If you are able to reproduce that error, could you copy-paste the event_time in this website and check which date it returns?

Thank you a lot for your time and help, btw!

[zsavajji]

Please be aware that Google Analytics and Facebook have different attribution models. While Facebook will count a Purchase anytime the user clicked on an ad before ordering (in a given time window), Analytics will only attribute that order to Facebook if, of all the channels the user came from to our website, Facebook is the last one non-direct. This used to be the default behavior, not sure if now it's different.

So you're telling me that the orders reported in the business manager are only the orders coming from an AD attribution and not all the orders made by my customers? I'm no analytics specialist so i don't know for sure :)

By the way, i could reproduce it because some of the timestamps are WAY more in the future than it could be caused from networking errors, i'm talking from 10mins to half an hour. I guess that since the timestamps are made in the client container they could be indicators of wrong time settings of the client itself.

Thank you!

[angelbt91]

So you're telling me that the orders reported in the business manager are only the orders coming from an AD attribution and not all the orders made by my customers? I'm no analytics specialist so i don't know for sure :)

About this, I'm not expert either, but I think I'm right if I tell you that:

• In Facebook's Ads Manager, you will only see Purchases that came from a campaign click / view.
• In Facebook's Events Manager, you will see all Purchase events, no matter if they originated from a click on an ad or not.

By the way, i could reproduce it because some of the timestamps are WAY more in the future than it could be caused from networking errors, i'm talking from 10mins to half an hour. I guess that since the timestamps are made in the client container they could be indicators of wrong time settings of the client itself.

I modified the Date & Time settings on my OS (Ubuntu 20.04) and I set the clock +2 hours from the current time. And guess what, the timestamp generated by the GTM tag was also +2 hours from the real time. So, it turns out that the API method on the template to generate the timestamp (getTimestampMillis()) takes into account the system's clock (just as browser's Date.now()). Could that be the source of the problem on your side?

[zsavajji]

Yes, i'm talking about the Events Manager reporting, which is where i am "losing" some Purchase events.

I added some logging on the template to send the purchase events to the container logs, and i noticed that Facebook is discarding the events which report the iOS user agent. I now think that this is the default behavior for the iOS sent events, disregarding the fact that there has been an opt-out by the user (since there is no way for them to know anything about it).

I'm pretty sure that the events with the future timestamp are caused by system settings of the users, so i don't think that it's to be considered a bug.

Thank you :)

[angelbt91]

I added some logging on the template to send the purchase events to the container logs, and i noticed that Facebook is discarding the events which report the iOS user agent. I now think that this is the default behavior for the iOS sent events, disregarding the fact that there has been an opt-out by the user (since there is no way for them to know anything about it).

Oh, that's quite interesting, thanks for letting me know about that behavior. I guess it comes from all changes that iOS14 brought to privacy and tracking.

I'm pretty sure that the events with the future timestamp are caused by system settings of the users, so i don't think that it's to be considered a bug.

Agree!

Thanks for opening this issue, it helped me understand better that kind of errors. I will close it if there's nothing else to discuss about this issue, but of course feel free to open another one whenever you see fit :)

[zsavajji]

Yeah, thank you for this discussion, it's been really helpful to understand the technical side of these implementations, which are always considered a matter of web marketing with little to none technical discussion available!