Stape.io. Client Identifier power-up. Restore GA4 client_id across sessions.

What this means for your store

A common misconception: GA4 “remembers” every returning customer for 90 days. On Safari and many mobile browsers, _ga expires after seven days - so a repeat buyer who purchased pet food last week looks like a brand-new user today. Server tags then send checkout with a fresh ID, fragmenting LTV cohorts and retargeting audiences. Client Identifier stores and reissues a first-party client_id on your collect. domain to bridge those gaps.

Scenario on a real storefront

A Denver pet supplies DTC store (42% repeat purchase rate, heavy Safari mobile traffic) enables Client Identifier on Stape. A customer who bought kibble on day 1 and returns on day 14 for flea treatment still shows the same client_id in server GA4 hits:

Stape → Power-ups → Client Identifier → Enable
  Cookie name: _stape_cid (example - follow Stape UI)
  Domain: .petsupplies.com

// Web GTM → transport_url: https://collect.petsupplies.com
// Server GTM - GA4 tag reads restored client_id from request

// Growth team: GA4 DebugView - same client_id on day 1 and day 14
// BigQuery export - fewer (not set) user_pseudo_id splits on repeat buyers

What to do next

• Your analytics team enables Client Identifier on custom-domain sGTM - default googletagmanager.com hosting undermines first-party persistence.
• Performance marketing should not confuse this with User-ID - Client Identifier fixes anonymous cookie continuity; logged-in User-ID needs separate GA4 config.
• Legal reviews cookie duration extensions under UK PECR and EU ePrivacy before marketing extends persistence beyond browser defaults.

Bottom line

Enable Client Identifier on first-party Stape domains when returning customer LTV and remarketing audiences look artificially low - ITP stops splitting loyal buyers into strangers.