@reservamos/browser-analytics 1.1.8-alpha.2 → 1.1.8-alpha.3

package/CHANGELOG.md

@@ -4,6 +4,10 @@
 
 - Pin js-api-client 6.28.1 to keep an initiated Fingerprint observation relay alive across navigation within browser limits; retain its five-second timeout and add a local redirect fixture.
 
+- Recover pending `reservamos_one_id` profile enrichment after same-tab, same-origin navigation without another application identify call. Scope the original normalized Core request in sessionStorage to the current user and configuration, expire it after ten minutes, and limit profile requests to three attempts. Keep foreground identity nonblocking and fall back to ordinary in-memory enrichment when storage is unavailable.
+
+- Reduce the Mixpanel batch flush interval to one second for events and people updates, including native identity events, while retaining batching and local identify completion semantics. Smaller batches can increase HTTP requests; the interval does not guarantee delivery before redirects.
+
 - Apply Identify identity and initial people properties before optional profile/fingerprint enrichment; resolve locally before enrichment and suppress stale results without mutating caller properties.
 - Add `analytics.identifiers.waitForFingerprintId(timeoutMs = 2000)` to await cached or in-flight identity within a caller budget without forcing fresh identification; preserve late successful cache updates when the caller times out and the identity lifecycle remains current.
 - Accept optional validated `product` on Purchase Confirmation Viewed. These additive public changes require minor release impact.

package/README.md

@@ -83,7 +83,7 @@ Relay failures are logged with `console.error` and do not turn an event already
 
 `await analytics.identify(...)` resolves after Mixpanel identity and initial people properties are submitted locally, without waiting for optional enrichment or confirming remote delivery. Readiness is limited to 5 seconds before that submission; anonymous-profile enrichment and fingerprint enrichment run afterward with limits of 3 and 2 seconds. Once readiness expires, a later `Tracker Ready` does not reactivate that call.
 
-Mixpanel profile callbacks and the existing geolocation request are observed separately for up to 5 seconds. The SDK does not retry requests; a missing callback means its outcome was not observed. Diagnostics use controlled stage/reason values without user identifiers or personal properties. `Visitor Found` is optional metadata: available booleans are preserved, and absent values are not replaced with `false` or inferred from cache state.
+Mixpanel profile callbacks and the existing geolocation request are observed separately for up to 5 seconds. Profile recovery after navigation is bounded as described below; other optional requests are not retried. A missing callback means its outcome was not observed. Diagnostics use controlled stage/reason values without user identifiers or personal properties. `Visitor Found` is optional metadata: available booleans are preserved, and absent values are not replaced with `false` or inferred from cache state.
 
 The `identify` method accepts a main identifier and an object containing user information. The object has four predefined fields: `email`, `firstName`, `lastName`, and `phone`. In addition to these, you can include any custom fields to store additional user-specific information as needed.
 
@@ -170,6 +170,12 @@ When OpenSpec is used, `tasks.md` is the canonical implementation plan. Do not a
 
 `await analytics.identify(userId, properties)` resolves after Mixpanel identity and the initial people properties are submitted locally. Anonymous profile and fingerprint enrichment run afterward, with their existing time limits. A later profile ID updates `reservamos_one_id` without identifying again. New identify attempts or initialization invalidate stale enrichment; caller properties are not mutated. Redirects can interrupt background work, and local completion does not guarantee remote delivery.
 
+The SDK keeps Mixpanel batching enabled and configures a 1000 ms batch flush interval for events and people updates, including the native `$identify` event. This reduces queueing time before short redirects, but can produce smaller batches and more HTTP requests. Network delays and retries can extend delivery beyond that interval; it does not guarantee receipt before navigation.
+
+Pending `reservamos_one_id` enrichment can resume after a full-page redirect when the destination initializes the SDK in the same tab and origin, with the same Mixpanel project/proxy, Core API base URL/application, and current user. No additional application `identify()` call is needed. Recovery restores native people readiness for that unchanged user without emitting a new `$identify` event; it does not replay business events or location identification.
+
+The SDK stores at most one 4 KiB recovery entry in `sessionStorage`, containing the current user ID, configuration scope, attempt metadata, and the normalized original Core profile request: its email/phone, additional identifiers (including captured fingerprint and distinct ID), and name fields when supplied. Arbitrary custom properties and credentials are excluded. Replaying the same request preserves profile matching and details; it does not rebuild identifiers in the destination. The SDK replaces that request with the profile ID once resolved, then removes the entry after Mixpanel accepts the property update into its queue or confirms an unbatched request. Queue acceptance does not confirm remote delivery. Unresolved profiles allow at most three HTTP attempts, including the original, with no retry loop within one initialization. Entries expire after ten minutes and are checked and cleaned on SDK reads; tab closure ends their storage lifetime. Invalid entries and user/configuration mismatches are discarded. Blocked storage preserves ordinary in-memory enrichment but prevents recovery across navigation. A recovery HTTP request starts only after its attempt count is saved.
+
 `analytics.identifiers.getFingerprintId()` remains a synchronous cache lookup. To wait for agent loading or an identification already in flight, use:
 
 ```typescript