Type of issue

Feature request

Description

Currently, when configuring a user ID sub-module, the publisher must choose between a storage method of cookie or html5 (localStorage). Both of these methods individually have advantages and limitations. cookie size, for example, is limited to 4K but can be persisted in the root domain, whereas html5 size is virtually unlimited (10MB) but storage is restricted is the current sub-domain. Developers working for publishers are not necessarily aware of these tradeoffs, and even if they are, it's not necessarily obvious which option will yield more optimal ID persistence.

To address this issue, I'd to introduce a third storage method that saves IDs to both cookie and localStorage. ID retrieval will re-synchronize the cookie value to localStorage if present in only the cookie (or vice-versa if present only in localStorage) before returning the value. We can name this storage method both, though we are open to alternatives. The net result -- assuming the ID module uses a domainOverride like domainOverrideToRootDomain -- is that lightweight IDs become global to the root domain, and the heaviest IDs are still stored but restricted to the current subdomain.

There is already some precedent for this technique among modules that manage their own storage. For example, LiveIntent uses this in LiveConnect's caching module.

Steps to reproduce

Test page

Expected results

Actual results

Platform details

Other information