There are some oddities with sendBeacon that make it tricky to use more often (e.g. Size limits per session, Number of requests active at a single time and such).
does that mean a change in how the "exitlink" tracking works? do we need to pay attention in our current implementation (especially how much data we add to the exitlink tracking beacon)?
Thanks justin_grover for the update. Can you please let me know, how reporting side is impacted with this? When I was quering about this, my objetive was to identify visitors(for retargeting) as soon as they leave our site irerespective of session status?
@ursboller and @itaparia You shouldn't need to pay any special attention to exit links other than what you are currently doing. The limit is most browsers enforce is that you can only have 64k of stuff queued in sendBeacon (See the spec). This is usually not a problem for most exit links but can become a problem for other tracking scenarios (especially in offline mode of a PWA). With our new implementation the only effects should be exit links should unload slightly faster and the data transmission is slightly more reliable.
Is it possible to configure sendBeacon for custom link server calls? There are cases (i.e. CTA links which transition visitors to pages under the same domain) that sendBeacon would be useful in order not to miss traffic. I know that we can use navigator.sendBeacon but this requires to generate the URL and data of the server call before calling it. Is there any function in the AppMeasurement JS object which can do this?
The AppMeasurement object also has a property called useBeacon (s.useBeacon) which is set to 0. Do we need to apply any configuration on the value to enable sendBeacon for exit Links?
