@reservamos/browser-analytics 1.1.7-alpha.0 → 1.1.7

package/CHANGELOG.md

@@ -1,9 +1,15 @@
 # Change Log
 
-## Unreleased
+## 1.1.7
 
+- Delegate Bot Detection delivery to `js-api-client` 6.28.0's `fingerprint.sendObservation`: preserve SDK triggers and Mixpanel events, send `Fingerprint Requested` with configured Core API authentication, and use the client's bounded timeout instead of fetch keepalive.
+- Make `await identify()` represent a bounded local attempt, continue after optional enrichment or SDK cache failures, and observe profile callbacks and geolocation request outcomes with sanitized diagnostics and no retries.
+- Treat Fingerprint `visitorFound` as optional metadata, preserving available booleans and omitting `Visitor Found` updates when absent.
+- Register `Reservamos Version` from the SDK package version alongside `Event Source` during Mixpanel initialization, including it in native `$identify` events without changing Mixpanel's library version metadata.
 - Align npm and Yarn lockfiles with Fingerprint Pro SPA 1.3.3 and its compatible JavaScript agent.
 - Avoid identifying with a Fingerprint client before its agent finishes loading.
+- Set the Mixpanel `Visitor Found` profile property after successful Fingerprint identification.
+- Add a Fingerprint Bot Detection relay for `Search`, `Payment Attempt`, and `Purchase Attempt`. The SDK preserves request IDs for the relay without adding them to Mixpanel events, and asynchronously sends identification context to Core API (`/v1/fingerprint/bot-detection`) without consumer event selection or a Fingerprint Server API secret in the browser.
 - Add a reproducible Compound Engineering workflow shared by Codex, Claude Code, and Cursor.
 - Add canonical fast and full validation commands used locally and in CI.
 - Verify generated package entrypoints and align the package's type declaration paths with the generated declaration bundle.

package/README.md

@@ -46,8 +46,43 @@ window.addEventListener('Tracker Ready', () => {
 
 `appName` is optional. When provided, it is sent as the `x-app-name` HTTP header on Datalake identify and anonymous-profile requests so the API can identify the originating client platform.
 
+## Fingerprint Bot Detection relay
+
+Fingerprint Bot Detection results are retrieved through Fingerprint Server API by Core API. This browser SDK does not call Server API or accept its Secret API Key. It can obtain the request-scoped `requestId` and relay the identification context to Core API.
+
+The SDK owns the eligible event list. Consumers do not configure a URL or choose events. Bot Detection currently runs on `Search`, `Payment Attempt`, and `Purchase Attempt`. The destination is built from the Core API `baseUrl`.
+
+For those events, the SDK requests a fresh Fingerprint identification, bypassing the Fingerprint SPA cache. This adds Fingerprint latency and an identification request before the original Mixpanel event is submitted. All other events keep the existing cache behavior.
+
+When identification succeeds, the original event contains:
+
+```json
+{
+  "User Fingerprint": "visitor-123"
+}
+```
+
+After handing the original event to Mixpanel, the SDK sends this JSON payload to `${coreApiBaseUrl}/v1/fingerprint/bot-detection` with `POST`, `Content-Type: application/json`, optional `x-app-name`, and `keepalive: true`. The browser supplies the actual `Origin` header:
+
+```json
+{
+  "requestId": "request-123",
+  "visitorId": "visitor-123",
+  "distinctId": "mixpanel-distinct-123",
+  "eventName": "Payment Attempt"
+}
+```
+
+`distinctId` is omitted when Mixpanel cannot provide one. The Core API response is not used to modify the original event. The SDK sends the generated `requestId` only in the Core API relay payload. Core API owns the Fingerprint Server API lookup and any later enrichment.
+
+Relay failures are logged with `console.error` and do not turn an event already submitted to Mixpanel into a tracking failure. If the Fingerprint agent is unavailable, the SDK preserves its existing fingerprint fallback, sends the Mixpanel event, and skips the relay. A failure during an identification that already started follows the SDK's existing tracking error behavior.
+
 ## Identifying Users
 
+`await analytics.identify(...)` waits for the local identification attempt, not confirmed remote delivery. The SDK limits readiness to 5 seconds, anonymous-profile enrichment to 3 seconds, and fingerprint enrichment to 2 seconds. Optional enrichment or SDK cache failures do not block the Mixpanel attempt. 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.
+
 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.
 
 ```typescript