Events

Phase 1 envelope event tracking API (POST /v1/batch). Methods are no-ops (never throw) until init() is called with an appId.

import ScaleBun from '@scalebun/react-native';
ScaleBun.events.<method>(…);

Members#

Reference#

track#

ScaleBun.events.track(eventName: string, properties?: Record<string, any>)

identify#

ScaleBun.events.identify(userId: string, traits?: Record<string, any>)

trackPurchase#

ScaleBun.events.trackPurchase(input: { revenue: number; currency: string; transactionId: string; [k: string]: any })

setIdentifiers#

ScaleBun.events.setIdentifiers(ids: { idfa?: string; gaid?: string; idfv?: string })

setAttributionClickId#

ScaleBun.events.setAttributionClickId(clickId: string)

flush#

ScaleBun.events.flush()

newSession#

ScaleBun.events.newSession()

ids#

ScaleBun.events.ids()

updateSkanConversionValue#

ScaleBun.events.updateSkanConversionValue(value: number, coarseValue?: SkanCoarseValue, lockWindow?: boolean)

Notes#

events is the namespace almost every integration uses. track and identify are the two calls that decide how much of the rest of the product works — most person-shaped features depend on identify having run.

Calls before init() are buffered, not lost#

Anything tracked before init() finishes goes into an in-memory queue and is drained into the real persistent queue once initialisation completes. You do not need to await init() before your first track.

That buffer is bounded, and the bounds are worth knowing:

Two consequences. A crash before init() completes loses whatever is still in the buffer, because it was never written to disk. And redaction runs on write to the persistent queue, so anything sensitive tracked pre-init sits unredacted in memory until the drain — one more reason not to put personal data in event properties in the first place.

Ordering that matters#

1. 1

   init() first, then everything else

   Buffering makes early calls safe, not free. Initialise as early in your app's lifecycle as you can.

2. 2

   identify() as soon as you know who the user is

   Events before identify are attributed to an anonymous id. That attribution is not rewritten retroactively, so a late identify permanently leaves those events unattached to the person.

3. 3

   setIdentifiers() only once consent allows

   Advertising identifiers are gated on the platform's own consent prompt. Passing them before you have permission is a policy violation, not just a privacy one.

4. 4

   flush() before a moment you might not survive

   Sign-out, or backgrounding at the end of a purchase flow. Otherwise let the SDK batch on its own schedule.

Notes on individual members#

• trackPurchase requires revenue, currency and transactionId. The transaction id must be unique per purchase — it is the deduplication key, and reusing it makes a real purchase register as a duplicate. See Purchases, which shows accepted, rejected and duplicate status per event.

• newSession starts a fresh session boundary. Calling it frequently fragments your session metrics; it exists for genuine boundaries such as a user switch.

• updateSkanConversionValue is iOS-only and interacts with a configuration you set in the dashboard — see SKAdNetwork before calling it.

• ids() returns the identifiers currently in use, which is the quickest way to correlate a device with a session while debugging.

Related#

• Events SDK guide

• Identity SDK guide