Cookie lifetime is often treated as a fixed technical setting. In practice, identifier persistence depends on a combination of analytics configuration, browser behaviour, consent state, storage availability and the identity model used by the implementation. A cookie configured to last for two years may not remain available for two years, and a persistent cookie does not provide recognition across every browser, device or domain.

This distinction is material for user counts, attribution, frequency analysis, conversion paths and data governance. It is also relevant when comparing analytics platforms, investigating discrepancies or assessing whether an implementation reflects actual customer behaviour.

1. Cookie lifetime and identifier persistence are different controls

A cookie lifetime is the period for which a browser is instructed to retain a cookie. Identifier persistence is the period for which an analytics platform can continue associating new activity with the same identifier.

These periods can differ for several reasons:

1. A browser may impose a shorter limit than the analytics platform.
2. A user may delete cookies or use private browsing.
3. Consent may be withdrawn, preventing the cookie from being set again.
4. The identifier may be scoped to one domain, subdomain, browser or device.
5. A rolling expiry may extend the lifetime after each visit.
6. Server-side data retention may end before the browser cookie expires.

A persistent identifier should therefore be understood as a technical approximation of returning-browser continuity. It is not a definitive representation of an individual person.

Recommended action: Document the intended lifetime, actual observed lifetime and scope of every identifier used in the measurement design. The documentation should distinguish browser storage from platform-side data retention.

2. What cookie configuration does not solve

Changing cookie lifetime can support a defined measurement and privacy approach, but it does not solve all sources of identifier loss or reporting inconsistency.

In particular, cookie configuration does not:

• overcome Safari Intelligent Tracking Prevention or comparable browser restrictions;
• identify the same person across multiple devices without an appropriate authenticated identity strategy;
• restore identifiers deleted by a user;
• create continuity where consent has not been granted;
• correct duplicate tags or conflicting analytics configurations;
• reconcile differences between platform processing models;
• extend server-side retention periods;
• provide a lawful basis for setting or using analytics cookies.

A longer lifetime can also create an unintended rolling identifier if expiry is refreshed on every visit. This may conflict with an organisation’s documented privacy position or internal retention policy.

Recommended action: Treat cookie lifetime as one control within a wider identity, consent and data-quality framework. Do not use a longer expiry as a substitute for implementation governance or cross-platform reconciliation.

3. Google Analytics 4

GA4 JavaScript tags use first-party cookies to distinguish users and sessions. Google’s official documentation identifies the following default cookies:

• _ga, used to distinguish users, with a default expiry of two years;
• _ga_<container-id>, used to persist session state, also with a default expiry of two years.

The Google Analytics cookie usage documentation states that browsers can impose shorter limits on first-party cookies. The same documentation identifies a maximum of 400 days for Chrome and seven days for Safari where there is no return visit.

The GA4 configuration reference provides additional detail. The cookie_expires setting defaults to 63,072,000 seconds, equivalent to two years. The expiry is updated when a hit is sent, meaning that the default setting is effectively rolling. If a visitor returns within the configured period, the cookie may continue to persist indefinitely, subject to browser and user controls.

The cookie_update setting determines whether the expiry is calculated relative to the most recent visit or the first visit. A value of zero for cookie_expires creates a session-based cookie.

GA4 also permits cookie expiration to be configured in the Administration interface. The available range extends from immediately to 25 months, with an option to define whether the expiry is relative to the latest or first visit.

These settings affect browser-side identification only. They do not alter GA4 event or user-data retention, which is configured separately at property level.

Recommended action: Inspect both the Google tag configuration and the cookies actually written in each priority browser. A configuration review alone cannot establish the persistence experienced by users.

4. Matomo

TagDataTrust is the only certified Matomo Implementation Partner in the UK.

Matomo’s principal first-party visitor identifier is the _pk_id cookie. Matomo’s official cookie documentation states that the default lifetime of this cookie is 13 months. The Matomo JavaScript tracking API provides setVisitorCookieTimeout(seconds) for changing the visitor cookie timeout.

Other Matomo cookies have different purposes:

• _pk_ses supports session measurement and has a default session timeout of approximately 30 minutes;
• _pk_ref stores referral information and has a default lifetime of six months;
• config_id may be used in cookieless configurations, but is temporary and should not be treated as an equivalent to a persistent visitor ID.

The _pk_id cookie does not provide guaranteed person-level continuity. Cookie deletion, blocked storage, consent withdrawal, browser restrictions and device changes can all result in a new visitor identifier. A cookieless configuration introduces a different set of technical and governance considerations and should be assessed separately from cookie-based tracking.

Recommended action: Record the Matomo tracker settings and verify whether the configured visitor-cookie lifetime is fixed or refreshed by the implementation. The expected behaviour should be tested against the organisation’s privacy and retention requirements.

5. Adobe Analytics and Experience Cloud identity

Adobe implementations may use several identifiers, depending on the collection architecture and migration history.

The Experience Cloud ID Service generally stores the Experience Cloud ID in the AMCV cookie. Adobe’s Experience Cloud cookie documentation states that the intended lifetime can be two years, while modern browsers may reduce effective persistence to approximately 13 months. Safari and other privacy controls may impose shorter limits.

The s_ecid cookie provides a first-party copy of the Experience Cloud ID in relevant implementations. Adobe Analytics may also use the legacy s_vi cookie or the s_fid fallback identifier. The Adobe Analytics cookie documentation explains the purpose and default behaviour of these identifiers.

For AppMeasurement implementations, cookieLifetime can be set to a number of seconds, SESSION, or NONE. The relevant Adobe configuration documentation should be used when assessing the implementation.

Adobe also documents first-party device identifiers, including FPID, for Web SDK architectures. These identifiers can support continuity when other identifiers expire, but they do not eliminate browser restrictions, consent requirements or the distinction between a device and an authenticated person.

Recommended action: Map all Adobe identifiers in use, including legacy cookies, ECID values, fallback IDs and any authenticated identity. A migration from one identifier to another should be analysed as a potential break in historical continuity.

6. Rolling expiry, fixed expiry and consent

Rolling expiry is operationally convenient because it maintains returning-browser recognition for active visitors. It can also make the practical lifetime substantially longer than the nominal period shown in a cookie declaration.

A fixed expiry establishes a defined end date that is not moved forward by subsequent visits. The choice between rolling and fixed expiry should be intentional and documented. It should reflect:

• the declared cookie duration;
• the organisation’s privacy notice;
• consent requirements;
• applicable regulatory guidance;
• the analytical need for returning-visitor measurement;
• the technical limitations of the selected platform.

Consent management adds another dependency. If an analytics cookie is blocked before consent, or deleted after consent withdrawal, a later visit may receive a new identifier. A CMP integration should therefore be tested alongside the analytics configuration rather than treated as a separate workstream.

The UK Information Commissioner’s Office guidance on cookies and similar technologies provides the relevant regulatory context for reviewing consent-dependent storage and tag firing.

7. A practical approach to validation

A controlled validation process should establish the difference between configured and observed persistence.

Step 1: Create an identifier inventory

Record each cookie or storage item, its purpose, platform, domain, path, expiry, update behaviour and consent category.

Step 2: Test the main browser scenarios

At minimum, test:

1. Chrome with consent granted;
2. Safari with consent granted;
3. a browser with consent refused;
4. private browsing;
5. cookie deletion between visits;
6. cross-domain navigation;
7. a returning visit after the intended expiry period;
8. authenticated and unauthenticated journeys.

Step 3: Compare raw and processed data

Use browser developer tools, tag-management previews, network requests and platform reports. Confirm whether the same identifier is sent before and after each test condition.

Step 4: Review reporting consequences

Assess the effect on:

• new and returning users;
• sessions per user;
• attribution;
• conversion rates;
• cross-domain journeys;
• frequency and audience membership;
• reconciliation with CRM or transaction data.

Step 5: Establish monitoring

Monitoring is necessary because browser behaviour, consent configurations and tag deployments can change independently.

Recommended action: Maintain a repeatable test script and run it after browser changes, CMP releases, analytics migrations, domain changes and major tag-management deployments.

8. Conclusion

Cookie lifetime should not be interpreted as a direct measure of how long an organisation will recognise a user in practice. Observed identifier persistence depends on browser controls, consent state, implementation design, storage scope and the selected identity model. For that reason, nominal expiry values are useful only when assessed alongside validation evidence and reporting impact.

A structured review of configured lifetimes, actual browser behaviour and platform-side retention provides a more reliable basis for interpreting user, session and attribution data.

If you’d like to hear more on this topic and set up a 1:1 call with us, please use the contact form. Contact a Consultant