Mobile Tagging - How Tealium deals with timestamps for queued request?

[koen_crommentui]

Hi there! Iâ ve got a question for mobile app tagging, and specifically for the SiteCatalyst requests. When an app is used without an internet connection, requests are being queued. When the device comes online, the queued request are being processed/sent. Now my question is how this queuing affects the timestamps of the SiteCatalyst requests. It is important that the timestamps on the SiteCatalyst measurements show the moment of the measurement and not the moment that the device came online. Does Tealium take this into account? And if so, how? On a side-note, which requests are actually being queued? The â utag.viewâ calls or the pixel requests â http://googlads....â ? I presume the utag.view calls, based on the Mobile Companion movie (https://community.tealiumiq.com/posts/583653, time: 02:45). Kind regards, Koen.

[Clint]

Koen, As far as I know, SC will assign it's own timestamp according to when the 1x1 request is received at it's collection server and I'm unaware of a way to over-ride this value. So there will be some discrepancies between when the actual event occurred vs. when SC reports that it occurred in situations where events have been queued due to lack of connectivity. You could potentially pass along our timestamp to a custom var in SC and that at least gives you access to the actual time of the events in reporting.

[jon_williams]

Hello Koen, The timestamp in SiteCatalyst is 'grabbed' when the s_code runs. Since the s_code creates the GET request that is sent the timestamp will occur when the event happens not when the request actually gets sent. So the queue shouldn't affect the timestamp.

[Clint · Accepted solution]

Koen, we did a bit more research on this and SiteCatalyst also allows to manually override the server timestamp via s.timestamp variable. From the SiteCatalyst documentation here are some requirements: 1.) The ReportSuite must be configured to receive custom time stamps, after this is enabled ALL requests to that Report Suite must contain the s.timestamp or they will be rejected. 2.) Timestamps must be in either UNIX or ISO-8601 format. The following restrictions apply to ISO-8601: - Both date and time must be provided, separate by a "T" [ex: 2012-04-20T12:49:31-0700] - The date must be a calendar date with full precision (year, month, and day). Week dates and ordinal dates are not supported. - The date can be in standard or extended format (YYYY-MM-DD or YYYYMMDD) but they must include hour and minute (seconds are optional) (HH:MM, HH:MM:SS, HHMM, or HHMMSS). Fractional minutes and seconds can be passed in, but the fractional parts are ignored. - An optional timezone can be specified in standard or extended format (+/-HH, +/-HH:MM, +/-HHMMM, or Z)

[koen_crommentui]

Thanks for the support Clint! The timestamp variable is indeed the solution to this problem. I've also learned that timestamp override has to be enabled for a certain report suite by Adobe Client Care. Kind regards, Koen.

[koen_crommentui]

Hi Jon, Thanks for trying to answer my question! It is, however, the utag.view function that is being queued, not the GET requests. From Clints answer the best way of doing this is to include a timestamp variable in the data layer and map this variable to the SiteCatalyst variable s.timestamp. Regards, Koen.