Re: [Beacon] spec feedback + few suggestions

Had a chance to chat about Beacon with the GA team earlier this week, some
notes...

- GA SDK for native apps is doing similar aggregation + deferring logic,
which is good validation.
- GA SDK automatically adds an additional "queued time" indicator to sent
beacons.

The latter case in particular is an interesting insight... A lot of
analytics reports rely on having correct timing data about when the event
actually occurred. For example, take time-on-site: when the user arrives on
the page the tracker emits a beacon to mark beginning of the session, and
reporting this with a delay of even 30-60s can significantly skew the
outcome since typical time on site is measured in minutes. Similarly, a
delayed "onunload" beacon will inflate the time on site as it'll get
registered as "last event" for that session.

One "workaround" would be to ask the analytics beacons to embed an event
timestamp in their payloads, but based on their experience, relying on
client clocks (which are often skewed or plain wrong) is not good enough.
As a result, their solution is to automatically append/report the "queued
time" when the beacons are emitted - this is handled by the SDK itself, and
in case of sendBeacon could/should be handled by the UA. With that in mind,
two recommendations:

a) UA should indicate how long the request has been held in the queue
b) Requests should be delivered in order they were queued

Given the "queue time" the backend can correctly offset the event when
building the report (server timestamp of received request - reported queue
time). Similarly, the delivery order should be preserved - technically, if
queue time is provided you can resort out-of-order events, but this by
itself can be a big and quirky operational challenge.

Long story short, one way to address these gotchas in sendBeacon() would be
for the UA to emit an extra header on the request that indicates how long
the beacon has been sitting in the queue.. e.g. "Beacon: x", or something
like it, where x is the number of seconds.

P.S. Still working on getting beacon size data...



On Fri, Nov 8, 2013 at 9:38 AM, Jatinder Mann <jmann@microsoft.com> wrote:

> On Thur, Nov 8, 2013 at 5:43 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> > I definitely think that if the timeout is reached, we should drop the
> message on the floor and
> > *not* notify the page. So it should be a mechanism for doing retries.
> I.e. the timeout means
> > "the data is useless after this point", not "need to try something else
> after this point".
>
> I see. I misunderstood the timeout as a means to retry on the developer
> side. I think it's fair to allow a timeout argument after which the user
> agent will not try to resend. This is of course assuming user agents will
> continue to retry for such a duration. The spec currently doesn't define or
> recommend how often the user agent should retry. I'll propose some
> recommendation language here.
>
> Thanks,
> Jatinder
>