The client-side timestamp approach is unreliable because it assumes that the client clock is correct. In practice, based on experience / feedback from the GA team, you want the browser to report how long the beacon has been delayed and then let the server calculate the timestamp offset itself. That's the approach they've taken in their native SDK and one they recommended for Beacon. In short, +1 for an HTTP header. ig On Thu, May 15, 2014 at 5:52 AM, Arvind Jain <arvind@google.com> wrote: > Jonas, your alternate suggestion seems easy too. I'd prefer to keep the > Beacon spec as minimal as possible. Kornel, would Jonas' suggestion address > your concern? > > > On Thu, May 15, 2014 at 1:50 AM, Jonas Sicking <jonas@sicking.cc> wrote: > >> On Wed, May 14, 2014 at 2:55 PM, Kornel Lesiński <kornel@geekhood.net> >> wrote: >> > It would be very useful if the beacon request included age of the >> beacon, in seconds (perhaps as an HTTP header). This would allow the server >> to easily calculate `current time - age` as the time of the event. >> >> I kind'a like this idea. The page could still do this by calculating a >> "client-time - server-time" difference when a page is first created, >> and then put an adjusted time stamp in the beacon data. >> >> However it seems easy enough to include an age in the beacon. And it >> seems like a common enough feature that it's worth helping authors. >> >> / Jonas >> >> >
Received on Thursday, 15 May 2014 19:21:36 UTC